Simple unix busting
(the microphar dongle galore)

by Dr. Fuhrball
(6 November 1997)

Dongle cracking

---

Courtesy of fravia's page of reverse engineering

Well, I have received this good essay more than a week ago, yet I bat Dr. Fuhrball to 'deepen' it a little, since many of our readers could be VERY interested in unix cracking, yet may not be very well acquinted with some of the concepts that unix experts give for granted. Dr Fuhrball was so kind to modify and revise his essay. Here it is, I'm sure many of you will find it partiicularly interesting.

---

Simple unix busting

by Dr. Fuhrball


modified 6 November 1997

The rest has been deleted for brievity

Anyway, its obviously C code, virtually

all unix drivers are. So lets dis-compile

the whole thing, which once you get the

knack, goes quite quick.



Also note that good C compilers generate code thats

so obvious that its easy to dis-compile.



Here is the dis-compiled code



It took about 3 hours with my favorite drink

which is 50 year old single malt north highlands

SCOTCH. I did have a bottle of real russian vodka

once, but in the USA, its virtually impossible to find.



Notice that its still in french. They did not even

have the brains to strip the debugging symbols out

of the final Driver.o module which made dis-compilation

that much easier.



One thing that makes this easier is that at any point

you can re-compile and compare to the original object

module. At some point they will both be the same except

for the compile date.

Whats going on here. A bunch of mucking around to hide

the real and trivial protection stuff. Also various

ands, ors, and inverts to further hide the data, plus

moving around more than the one data line and clock

line to the eeprom to throw off my Tektronix 7d01/df2

logic analyzer. (NOT)



Before going any further it helps to print out and study

this driver. It shows many things including the required

entry points, and functions that pass strings to and from

kernel space. Device drivers must pay strict attention to

memory and stack usage, as well as calling most intrinsic

functions. Thats why for example in the code below debugging

strings have to be written to the Common Error routine instead

of calling another driver. In virtually all cases one device

driver cannot call another.





Back to the story





Basically you write to the device driver a "P#####*"

and when you issue a read call you get an ascii string as the answer.



The ##### is an ascii number between 0 and 65535



for example P0*   P00*     P1234*





further example



cat >/dev/mp



type in P1234* 



hit a control Z



cat </dev/mp



5678





So now lets write a simple program which when compiled and

run with the output re-directed to the file "datafile"

generates all 64K possible output answers without having

to really figure out the entire thing.



The algorithm part of the software sentinel pro works in

exactly the same fashion. (Until you realize that its just

an 8 bit shift register with tapped feedback, then its easy)





What we are doing here is taking the simple way out. Instead

of figuring out the 32 words of data in the eeprom and then

calculating the masks, we just interrogate every possible

request and tabulate every possible answer. If this was a

32 bit number, this technique would not be practical.





Furthermore, if Aries actually wrote to the eeprom (which it

definitely does not), we would have to do a bunch more work.

The eeproms used in this device have a maximum write capacity

of between 10,000 and 100,000, and since aries interrogates the

device more than once a minute, writing to it is impractical.



Thus

which generates int data [] = {#,#,#,#.....}





Pretty simple huh. OH, and yes this takes a while

to run. (about 15 minutes)





Now lets hack the origional device driver removing

lots and lots of useless garbage. We cannot null out the

open and close routines, because they prevent re-entrancy.



Thus

Now we compile this thing, call it Driver.o, replace their driver

with our own (saving theirs someplace safe), relink and install

the unix kernel, and bye bye dongle.



To compile, install and link the kernel do;



cc mp.c -o Driver.o



mv Driver.o /etc/conf/pack.d/mp



cd /etc/conf/cf.d



./link_unix          (thats dot slash link underscore unix)



after rebuilding the kernel (takes about 5 minutes) it will

ask if you want to install the kernel as default.



Answer yes.



Then it will ask whether you want the environment rebuilt.



The answer here does not matter. But for example if you have

changed major and minor device numbers (which we have not) you

would have to answer yes, because device names in the /dev directory

would no longer be pointing to the right place.



Now reboot    (type init 0)    and you are done.





In addition, all the utilites necessary to break this come as

part of the operating system (use the crippled C compiler or get

GCC). This is unlike Windows95 where you need softice, wdasm,...



What we have seen here is that parallel port dongles used on

unix boxes give virtually worthless protection, far easier

than their dos/windows counterparts. They all fail the

freddy the freeloader part of the fiat-shamir zero knowledge test!



Matter of fact, a lot of things fail the fiat shamir test. Go search

the web, lots of good reading on this topic.





And while we are on the subject of fiat-shamir, the biggest failure

on this so far is the DSS-02 smart cards for the DSS receivers in

the USA market. The pirates are making way too much money selling

solutions that do not work for long. Look people it does not make

sense. Why give a pirate $500 for a T or L or Battery card, which

1.5 years later croaks permanantly, just to buy the latest twiddled

H card for another $500, and then buy the shim card for another 500.

Its way cheaper to legally subscribe (Canada is a different story).

This is something that needs to be brought to the grass-roots level.

The latest card is way to easy to twiddle. Lets put the people that

are strictly in this for the money out of buisness. We know who you

are. I personally do not have a DSS, and because i have a REAL dish,

I am not likely to ever get one. (4dtv is another story). And since

I live in the USA, I will NOT get involved in DSS activities...







Soon will come an essay on the Rainbow Technologies Software

sentinel superpro. Which can also be busted numerous ways.

And just slightly harder. I now have a virtually 100 percent working

programable hardware solution. And yes you can read the algorithm

and time keys out of the device. Although you can certainly crack

this via the software methods, or replace their driver with another,

A downloadable version of a hardware emulator can make this quite

easy to use.



Also an essay on breaking protection on the EESOF (now hp)

touchstone, montecarlo, linecalc and other high priced spreads.

hint( one cmos 8 bit eprom size >128 bytes, 8 diodes, one cap,

one cmos buss transiever). The hardware solution here was just

too simple to ignore.





Other fun targets. The protection DEC uses on their unix that runs

on the alpha motherboards. This one could be fairly tough.



Other fun targets: serial dongles (like netsentinel). Almost as

easy, you have to create a shim between the program and the real

tty driver...





       later            Dr. Fuhrball

project3

---

homepage links anonymity +ORC students' essays academy database
tools cocktails antismut CGI-scripts search_forms mail_fravia
Is reverse engineering legal?