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?