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.

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.