Zen and the Art of Dongle Cracking
(A somehow 'general' essay about dongles)

by zeezee

(24 December 1997, slightly edited by fravia+)

---

Courtesy of fravia's page of reverse engineering

---

Well, our dongle cracking project was being a little neglected... which is not nice, yet somehow understandable... huge economic interests are in play here, and many 'lower' crackers prefer to find an 'economic' arrangement with the dongle producers instead of publishing their (simple) cracks... (which is something that real +crackers should never do!)
And we have unfortunately had other delays as well: Marta never sent his contributions (we all know how lazy these spanish friends are :-) and we are all still awaiting Quine's promised HASP tutorial (should be there soon, be prepared!)
Luckyly we have zeezee working hard on this as well! This is what zeezee wrote me:

hi fravia+

This time comes a little more 'general' essay about dongle cracking.
After winning with 4 dongles and loosing with one I can draw some general
conclusions which may help all will-be dongle crackers

                     Zen and the Art of Dongle Cracking
                     ------------------------------
                               by zeezee


Disclaimer:
I don't publish here any dongle-protected program names since it's not my goal
to make battles with lawyers, you see only relevant code snippets. This
tutorial is not about one specified software or dongle. The example given is
from a real program not widely available. The program itself isn't important.

So, let's start with blah-blah, sorry, with basics.

Dongles are small boxes connected to the LPT port (or sometimes to COM port) of
your computer. They should be (in fact they are in 99%) invisible to printer
connected to this port. There are variants of dongles mounted inside computer
but for us, the exact appearance of the dongle isn't important.

Inside of the dongle is an EEPROM or ASIC or maybe a dead fly. For us this is
only a black box which receives / sends data from our application via piece of
software (dongle API) which is sold with the dongle to app developers.
The app writers call the API and check values returned to make good/bad guy
jumps.

Most popular dongles are:
- Sentinel (big family) from Rainbow Technologies (USA)
- Hasp (not bad) from Aladin (Israel)
- Fest (if I recall made in Germany)
- Actikey (France)
and tens of others... See your favourite Dr Dobb's page.

Tools needed are usual: IDA, SoftICE, HIEW. And of course our application.
No logic analyzer, oscilloscope, maybe LED monitor if you really want it.

So, dear cracker, first step in our tutorial is:

*1* Identify the dongle you are dealing with.

It's not so hard in most cases. Either look at the dongle if you have
access to it, or look at all files that install with your soft, then you may
search all .DLL's, .VXD's etc. for copyright text other than application authors.
You find it quickly in almost all cases.

*2* Gather all possible information from www pages of dongle vendor.
This is VERY IMPORTANT STEP!

You will wonder how much doc you get. Full API, often with source, demo soft,
examples how to use API with your future biggest program etc. Get it all and
study carefully.
Remember: ALL computer hard/soft vendors are present in the Net. Just find them.
Don't panic when you read all info about dongle security. They ARE secure. OK.
You can't crack them unless they're done by complete idiots. OK.
But you want to crack the application, NOT the dongle.
When you read about RSA encryption, one-way functions and see in the
API some interesting Question/Answer hashing functions, remember that it's only
API. No one uses it. Only simple functions like Check/Serial Number/Read and
sometimes Write are used.

*3* You may also get an evaluation dongle from dongle dealer. For free.
If not for free ask for 14-day lease. It works! They want to sell these boxes.
Call these 0-800 or 0130 numbers. They want to help you unless you say something
stupid when asked for software you want to protect.
The people at Rainbow and Aladin dealers are _extremely_ helpful.

*4* Now you know the dongle/app you want to crack and have (or not) some additional
info. Time to think (+Orc calls it Zen).

Imagine a software company making big good proggy. The proggy is almost finished,
then comes the boss and says: "Ok, we're ready, now is the time to protect our
fantastic product. We have a demo kit from dongle X. So, dear programmers, use
it".
And poor programmers are studying dongle docs, API etc and putting some API
calls into their code.

Sometimes it ends like this:

        call DONGLE
        or ax, ax
        jz goodguy
badguy:

Yes, you may not believe it, yet it's true. (See previous essays)

Sometimes they go little further but in most cases, I repeat: in MOST cases
the idea is stupid.

But the chain is so strong as its weakest link. And in all 4 different progs
protected with different dongles the weakest link was the interface:

     Application - Dongle API (mostly contained in a DLL)

The dongle manufacturers are smart guys, they know how to encrypt data, make
self-modifying code, anti-debug tricks etc. I recommend: Leave their code as is.
The application side is much easier to crack.

The first thing in real crack is to find THE call (rarely more than one)  to
the dongle API, Use IDA or WDASM and remember the name of the DLL containing
dongle API and after several minutes (last time 2 hours and 40MB .IDB file!)
you have it.

There should be a part of API statically linked to the executable we are
cracking which calls the DLL, funny people at Aladin make self-mod code here,
so our further goal is to go a bit up.

Our poor programmers are lazy. Everyone is lazy when it comes to make some
dumb work like calling the dongle. So they write their own functions like:

QuickCheckIfDonglePresent()
GetDongleSerialNumber()
ReadDongleByte( addr ) - or word, or dword, or even full table
WriteDongleByte( addr, value )

Maybe they are exported by name? Maybe the name is ReadDongle or similar?

Look carefully at references IDA gives you. You certainly find it.
You should find procs called only once - they should be interfaces between
application/API. Who writes two wrappers to one function?

The dongle API is very well structured in most cases, the function number is
explicitly given, 0 - check, 1 - get number, 2 - read, 3 - write, etc...
Identify where are params/results.
And this is the thing which helps us crack. We may have also the API docs!
The API producers want to make API maximally user-friendly. They make it also
more cracker-friendly... We may find quickly what the app expects from the
dongle by studying API calls and 'cmp ax' following it.

*5* Then comes the active part (you may need dongle for short period of time)
Patch the code inserting a CC byte in the 'App-API Interface' place(s).

Run SoftICE with BPINT 3.

Replace INT 3 with the original byte, then set BPX to this address, trace...
Look what happens when there is no dongle. You may have luck and quickly find
a checkpoint with bad/good guy switch. Try to go the other way and see what
happens (maybe your app starts running).

Try to patch the code to emulate QuickCheckIfDonglePresent function.
Simply return a value which satisfies calling proc.

This may be sufficient in most stupid cases.

Then try to emulate GetSerial# routine. Remember that dongle serial# may be
stored and used to display # in About box. See references IDA gives you.
Not all dongles have GetSerial# proc. Sometimes serial# is read like normal
data from dongle.

This may be sufficient in most not-so-stupid cases.

And then comes to dongle reading. Several bytes are read, I assume that you find
the place where they are stored and all references to this place.
Several checks may happen and certainly will happen in programs with different
options enabled/disabled by the dongle.

maybe so (real example from one of leading SCADA programs)
  cmp eax, some_value1
  je is_model_1
  cmp eax, some_value2
  je is_model_2
  etc.


or maybe so (real example from Israeli program with Israeli dongle)

  test eax, mask_1
  jz lab1
  call enable_option_1
lab1:
  etc.

or maybe so (electrical engineering tools made in France with french dongle)

  12 words read from dongle are stored from [ebx]

  mov ecx, 12
lab1:
  cmp word ptr [ebx], 1
  jne lab2
  call enable_option(cx)
lab2:
  inc ebx
  loop lab1

Believe me. It's real.

If you have a working dongle, read all values from it, and you know what to
emulate (set BPX after API read function does his job and make notes).

And here the real example. The app is useless to you, it isn't freely available,
so let's study the disassembly I prepared for you.

*1* Our dongle is french Actikey and the DLL is CCNMMNT.DLL
*2* We do the disassembly of our target (40 MB) and look into .idata section.
    It takes a little longer than one cocktail...
    The result is astonishing, but I wait until ALL references were displayed.
*3* Crtl-S and go to .idata section. I found extern imported from CCNMMNT.DLL
    Go to reference of it.

00594510 ; Imports from CCNMMNT.dll
00594510
00594510                 extrn CCNMM:dword       ; DATA XREF: j_CCNMMr

Only one reference! The name j_CCNMM is assigned by IDA!
then:

00408770 ;               S u b r o u t i n e
00408770
00408770 j_CCNMM         proc near               ; CODE XREF: key_io+6Fp
00408770                 jmp     ds:CCNMM        ; jump to Dongle DLL
00408770 j_CCNMM         endp

The name key_io and other below are assigned by me, they are not exported ;-)

Let's go one step up. See: Only one reference. A green light! We are on our 
good way.
then:

0040BA10 key_io          proc near               ; CODE XREF: main_key_check+8
0040BA10                                         ; main_key_check+18Cp
0040BA10                                         ; key_check2+45p

After checking, I found that key_check2 is called only from the main_key_check,
so we still only have one reference here. We are still inside dongle API code.

Let's go up.

0040B840 ;               S u b r o u t i n e
0040B840
0040B840 main_key_check  proc near               ; CODE XREF: key_fun_00+4Dp
0040B840                                         ; keyfn_18_sernum+68p
0040B840                                         ; keyfn_02_write+5Bp
0040B840                                         ; keyfn_03_read+56p
0040B840                                         ; key_fun_1b+50p
0040B840                                         ; key_fun_1c+54p
0040B840                                         ; key_fun_1d+5Cp

Of course you may ask, how do I know that this is API and not our 
application? Quick answer: Funcs 1b, 1c and 1d aren't called!
Do you imagine writing wrappers that are never called? They were written by
the dongle makers and linked to the app.
In fact keyfn_02_write isn't called also. This is good news, the key should 
always respond with the same data.

The names of the callers are self-explanatory. Where I got them from? 
Studying the procs, that's all, see for example:

0040A250 keyfn_18_sernum proc near               ; CODE XREF: (several)
0040A250
0040A250 arg_0           = dword ptr  8
0040A250
0040A250                 push    esi
0040A251                 call    key_fun_00
0040A256                 cmp     ax, 1
0040A25A                 jnz     short skc110
0040A25C                 mov     ax, 1           ; 1 - error?
0040A260                 pop     esi
0040A261                 retn

0040A262 skc110:
0040A262                 mov     word ptr ds:key_fun, 18h  ; function 18!!!
0040A26B                 xor     eax, eax
0040A26D                 mov     esi, [esp+4+arg_0]
0040A271                 mov     word ptr ds:key_result_1, magic1
0040A27A                 mov     word ptr ds:key_par3, ax
0040A280                 push    offset key_par4
0040A285                 mov     word ptr ds:key_par4, ax
0040A28B                 push    offset key_par3
0040A290                 mov     word ptr ds:key_par1, magic2
0040A299                 mov     word ptr ds:key_par2, magic3
0040A2A2                 push    offset key_par2
0040A2A7                 mov     [esi], eax
0040A2A9                 push    offset key_par1
0040A2AE                 push    offset key_result_1
0040A2B3                 push    offset key_fun
0040A2B8                 call    main_key_check        ; here our call
0040A2BD                 mov     word ptr ds:main_result, ax
0040A2C3                 add     esp, 18h
                    ....store results...

The magic values are identifying the dongle and the product, so I removed 
them... they are unimportant for our cracking.

And this is the top of dongle API. Now it's time to identify what the
API is expected to return. Several 'cmp ax, something' and I was able to emulate
API functions 00 (quick check) and 18 (get serial).
I applied a short patch using HIEW to emulate these functions.

After that my proggy started with all options disabled.
Analyzing other 'cmp ax, something' was almost trivial.

So I wrote a short emulator of key_fn_02_read and now the proggy opens all
options to me.

Conclusions.

* Dongle cracking is not much more complicated as serial# cracking. You need
  more theoretical background from dongle producers, good disassembler which
  finds all Xrefs and SoftICE of course. The shareware protections are often
  much more sophisticated than simple dongle calls in expensive commercial apps.
  Of course, there are programs protected better, but they are exceptions.

* Don't start cracking from BPIO on LPT ports. Try to find The Weakest Link!

* Remember, Programmers are lazy when it comes tu put foreign code into their own.
  Not all API calls are used. Check simplest functions first and see what happens.

* Let your cracked program run for several minutes. Almost always there is
  a dongle check performed each 1 minute or so. Your crack should survive this.
  Try all actions the program should perform. Select every item from menu.
  Or, if you prefer, study whole disassembly for dongle calls...

* Beware when cracking with real dongles connected. There is theoretically the
  possibility to destroy a dongle. Use dongles only to read their contents
  and remove them when SoftICE-ing your cracks. They aren't necessary at this
  time :-) However I never found any auto-destruction procedure when studying
  various dongles API.
  Neverthless, you have been warned!

Good Luck!

zeezee

Back to Project 3

---

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