Nov 1998
How to Crack A VB5 Hardlock Dongle
Win '95 PROGRAM
Win Code Reversing
 
 
by YuGung 
 
 
Code Reversing For Beginners 
 
 
 
Program Details
Program Name: NoName
Program Type: Data Management
Program Location: no Internet location 
Program Size: 35 mb
 
   
Tools Used:
 Softice V3.2 - Win'95 Debugger
Smartcheck - VB Analizer
IDA - Dissembler
 
Rating
Easy ( )  Medium ( X )  Hard (    )  Pro (    ) 
There is a crack, a crack in everything. That's how the light gets in.
 
  
 
How to Crack...
A Visual Basic V5 program that is protected with a Hardlock dongle.
Written by YuGung
 
 
Introduction
 
I will not give the name of this target for two main reasons: this target it's a very big & specialized program, priced around $ 8-10.000, useful only if you want to analyze a really big, huge amount of data extracted from a main database, normally from a server; second reason is that this program it's not downloadable from any internet site and no demo exist.
 
But i think (& i hope) that this tutorial could be useful because this beast has two features that normally any cracker hate: it's written in Visual Basic 5 and it's protected with Hardlock dongle !
 
About this protection system
 
About  Hardlock cartridge you can look at official site (www.Hardlock.com) they have a great number of useful infos for better know how it work, also i think that u must read the entire dongle section at www.Fravia.org: you can find here many essays about dongle-cracking and many infos about Alladin/Rainbow cartridges.

Normally a dongle  protection system could work with differents methods: the hardest one is when the programmers encrypt part of the code using some utilities from dongle producer, the easiest  one is when they just check the presence of the dongle with the usual calls to serial/parallel port.

This time we are lucky because the main executable is not encrypted, so all we need to do is search the part of the code where is the out/in routine to/from parallel/serial port (parallel in this case).
 
The Essay 
     
During the installation, monitored as all must usually do with Filemon, we see that the target place many files dll into the windows/system directory, but just two are important for our work Hardlock.vxd and Hlvdd.dll (on the properties of this file you can read "///FAST Hardlock Win32 DLL").

The main exe is a 5.5 mb file, in the import table we see just one dll: MSVBVM50.DLL aaarghhh it's a Vi$ual Ba$ic one !!!

Against all the rules i try to dissasemble it with IDA; it's my personal record: i leave my Pentium 300 diasassembling the exe at 10pm and at 7am IDA still was "thinking" at the code, when i was back at 8 pm finally i get my beautiful 55mb IDA database.

Then i try the usual approach to dongle-cracking as i read in many essays: i launch the program with Softice beakpoint set to "BPIO -h 378" and "RtcMsgBox" (remember it's VB file); after some time (too much) i jump directly into the RtcMsgBox code deep in the VB jungle. BPIO don't work so we can't look where the code send the IN/OUT commands, they must use other methods to check the dongle presence.

Using Filemon during the launch i see also that the program load first C:\WINDOWS\SYSTEM\HLVDD.DLL then C:\WINDOWS\SYSTEM\HARDLOCK.VXD so i think that it's here that the program make the check. At this point i decide to leave the SoftIce approach (i don't want to waste my time inside the VB code): this is a VB program and we have our precious Smartcheck  ready to use.

So i run the target from inside Smartcheck just to the "Hardware Key Not Found" message: it's not a long output just about 8000 lines.

Then i search where the HLVDD.DLL is called by the main exe:
 

 
as you can see at line 2371 the execution is passed to HLVDD.DDL, we can inspect this dll disassembling and studing, but i think that the weakest side of any dongle protection is inside the main program code, not in the dongle-producer code. We know that despite any complex routine this dll could do, at the end he must pass a simple information to the main program: the dongle is (not) here.

Look forward when the execution return to the target:
 

 
 the line 2423 is the last one of the HLVDD.DDL (you can read this info clicking in the line and looking at the right details pane of Smartcheck), as we can see at the return from dll the code execute two VB routines _VbaSetSystemError and immediately _VbaStrCopy.

Now  i want to look the disassembled code; i  run IDA, load the 55mb database, go to names window, search for a _VbaSetSystemError call followed by _VbaStrCopy call.
I jump to the following part of the code:

007FE1F5      push    ecx
007FE1F6      lea     edx, [ebp+var_60]
007FE1F9      push    edx
007FE1FA      mov     ax, [ebp+var_6C]
007FE1FE      push    eax
007FE1FF      mov     cx, [ebp+var_30]
007FE203      push    ecx
007FE204      call    sub_447FCC                 <---- call for HLVDD.DLL
007FE209      mov     [ebp+var_B4], ax
007FE210      call    ds:__vbaSetSystemError     <---- (see line 2424)
007FE216      mov     dx, [ebp+var_B4]
007FE21D      mov     [ebp+var_50], dx
007FE221      mov     edx, offset off_455B80
007FE226      lea     ecx, [ebp+var_28]
007FE229      call    ds:__vbaStrCopy            <---- (see line 2427)
007FE22F      movsx   eax, [ebp+var_50]
007FE233      test    eax, eax
007FE235      jnz     loc_7FE312                 <---- Patch here
007FE23B      call    sub_448044
007FE240      mov     [ebp+var_B4], ax
007FE247      call    ds:__vbaSetSystemError
007FE24D      movsx   ecx, [ebp+var_B4]
007FE254      test    ecx, ecx
007FE256      jnz     loc_7FE312                  <---- Patch here
007FE25C      mov     edx, [ebp+var_70]
007FE25F      push    edx
007FE260      lea     eax, [ebp+var_78]
007FE263      push    eax
007FE264      call    ds:__vbaStrToAnsi

Hmmm... two test at line 007FE233/007FE254, all two followed by the same jnz sound suspect. I try a live patching with Softice just to see if i was right and YESSS no more  "Harware Key Not Found" message, the target now run perfectly.

For your information the program repeat the call to HLVDD.DLL 3 times and just at the end of the third produce the output error message; just before the rtcMSgBox call we find another time the same calls _VbaSetSystemError and immediately _VbaStrCopy.
 
 
The Patches 
     
It's not interesting the patch because, as i wrote above, the target is not reachable via  Internet.

 
Final Notes 
  
This could be an unusual approach to dongle cracking, but i hope that you have anyway learned a little bit more today.
 
 
Ob Duh 
 
Do I really have to remind you all that by buying and NOT stealing the software you use will ensure that these software houses will encourage them to produce even *better* software for us to use and enjoy.

Ripping off software through serials and cracks is for lamers..
 
If your looking for cracks or serial numbers from these pages then your wasting your time, try searching elsewhere on the Web under Warze, Cracks etc.
 


 
 
 [ Return ] 
 

Essay by:          YuGung7
Page Created: 07th November 1998