SignLab 5.0 Rev 7
Patching a poorly implemented Hasp dongle
Not Assigned
by JAS
Courtesy of Fravia's page of reverse engineering
slightly edited
by +Tsehp
A private message to the programmers : You will get much more money if you remove the dongle protection, the dongle's price costs more than your single program.
There is a crack, a crack in everything That's how the light gets in
(x)Beginner ( )Intermediate ( )Advanced ( )Expert

 This essay was written for the Intermediate cracker who want's to get started in the
 dongle arena.  We are going to cover some of the most basic technics of string searching,
 and file patching.

SignLab 5.0 Rev 7
Patching a poorly implemented Hasp dongle
Written by JAS

 It is assumed that you have the above tools installed, and that you know how to use them.
 It is not the intent of this essay to provide a complete step-by-step crack for this program.
 I will cover enough of the protection to demonstrate how lazy programmers can take and
 butcher, what could have been a challenging protection.  Shame shame lazy programmers !

 In this essay we will demonstrate the simple technic of  :
  1)  Locating our error msg strings,  
  2)  Tracing backwards  to the offending call
  3)  Modifing the code to bypass that particular security check.
 It is Always a good idea to keep a backup of *any* file that you are going to be modifing.
 So doing so now, would be a pretty good idea.  I usually create a new folder in the 
 program directory called original.  Then I put a copy of all the files I am going to 
 modify into this directory.  Now, just as a general rule of thumb,  If you're like me,
 I prefer to have WDasm running at the same time I am making changes to the program with
 my Hex Editor.  That way I am constantly reviewing the code, and looking for my next move.
 However,  you cannot have the program loaded into WDasm *and* save changes  with our Hex
 Editor, at the same time, using the same copy.  So to keep it simple, and seperate, when
 you decompile the exe file in our essay today,  decompile your *backup* copy. WDasm does
 not make any changes to the file that it decompiles.  So our backup copy will always 
 remain safe, and in tact.

 Ready to get started ??   Good.    Let's get to work.
Tools required
 WDasm -- Windows disassembler
 Hex Workshop  -- Hex Editor
 Brain -- ( Somewhat Optional )
Target's URL/FTP
 Vendor :  Cadlink Technologies
 Website :
 Download : From the maintenance section.
 Password : RMCCZH,CNXVK7,QZ3FJ2,T3XZ77,DFB8S1
Program History
 All previous versions of SignLab (4.95 - 5.0) will work using this method.
 When downloading the Signlab program from Cadlink's site, you will need the
 above listed password.
 Use this same password when installing the program after you download it.
 SignLab will *not* check for the dongle when using a demo password. 
 That's why the above Non-Demo password is supplied.
 First of all do you have Signlab 5.0 Rev 7 Installed on your computer ?     No ??  
 Then do so now.

 Note :   If you cannot find Signlab 5.0 Rev 7, that's ok.   The technics presented here
 will still work with previous versions.  However, obviously the file offsets  will not 
 be the same.  

 Got it installed ?   Great !   Let's get going.	

 The first thing that we need to do is fire up Signlab and poke through some of the screens.
 And what we're looking  for, is to find out as much as we can about the protection.   Hmmm.   
 Not much at first.   So click on the Icon that looks like a little yellow pencil on the 
 left side of the screen.    Now click 3 or 4 times on the drawing canvas.

 Now you should have had a error message box popup.  Write down the error message exactly 
 as it appears.
 It should read :  " ERROR LOCATING SECURITY DEVICE : xxxxxxxxxx" blah blah....

 Ok now that you have this message written down,  go ahead and click the [Cancel] button.
 Signlab was so kind as to shut itself down for us.  Wasn't that thoughtful of them.  hehe
 We need to find the section of code that displayed this error message.
 We have several options available for doing this.    

  We could :
  1)  Use a Windows Spy Tool to get the popup window's handle, and then , using softice,
     break on the window  message wm_destroy.  
     ( which is the method windows uses to erase the popup dialog box. )  
     In softice it would look like this :    bmsg ( handle ) wm_destroy    From here we 
     would trace backwards (Using  F12) until we reach our program's code, and the routine
     that generated  this dialog box.  

 This method would help to trace back and find the relevant sections of code.  But you 
 can not make permanent  changes to our program using softice.  So a second method  is 
 better suited for our needs.

 2)  A second option would be to decompile the program and produce a ' deadlisting '.   
     We could then browse  our decompiled listing, and look for the error message that
     we recieved.

 So let's do that now.
 We need  to decompile the Signlab executable. ( signlab5.exe )
 So we can now fire up Wdasm.   Once that is loaded, we need to select the file to be
 decompiled.  Click on the menu item   Disassembler -> Open File To Disassemble.  Browse
 to the directory that you have installed Signlab to, and select signlab5.exe,  and then
 click [ Open ].  ( Remeber to use your backup copy.) 	
 Got it ?  Great.  Still waiting for it to decompile ?  Yeah me too.  hehe  

 Now that we have our listing,  it is a good idea to save this listing, so that we can 
 access it at another time without having to wait for it to decompile again.	
 To do this click on the menu item  Disassembler -> Save Disassembly Text File and Create 
 Project File .

 Now what we want to do is search for our error message.    In Wdasm click on the menu item  
 Refs -> String Data  References.  Good.  Scroll through the listing of strings looking for
 our specific error message.	Does this look familiar ? 
   [*v*]ERROR LOCATING SECURITY DEVICE     Yep that's the one we want.
 Now if you  double-click the left mouse button on this string,  Wdasm will take you right
 to the next occurance of this string in our program.   This string occurs multiple times 
 in our program, but you should be looking at the following code snipet :

 * Referenced by a (U)nconditional or (C)onditional Jump at Address: 

 :00474E1C 8D9424EC040000    lea edx, dword ptr [esp+000004EC]

 * Possible Reference to Dialog: AUTOSAVE, CONTROL_ID:0064, "(*v*)Automatic &save enabled:"
 * Possible Reference to String Resource ID=00100: "(*v*)Maximum size"

 :00474E23 6A64              push 00000064
 :00474E25 52                push edx

 * Possible StringData Ref from Data Obj ->"(*v*)ERROR LOCATING SECURITY DEVICE: " ->"%ld "
 :00474E26 6800FD6500        push 0065FD00

 Ok.   We know that this is directly related to our dongle check, but we don't really see
 any calls to check out, or conditional jumps.  From this point we need to trace backwards,
 and find out where this call orignated from.
 So starting from our error message and scrolling up,  we see an interesting reference.  
 Notice it says that this point was reference by a Unconditional / Conditonal Jump at
 Address 00471C38.  
 Let's take a look at that address and see what's there.  If you feel energetic enough, 
 you could scroll up using the keyboard  arrow keys, the mouse buttons,  or better yet, 
 why don't we let Wdasm take us right to that very spot.
 Click on the menu item Goto -> Goto Code Location  and type in the address that it gave us. 
 Go ahead and click Ok.  Now you should see the following snipet of code :

 * Reference To: cut5._SetPlotResol@16, Ord:0068h
 :00471C2A E883511A00    Call 00616DB2   :;  Set Plot Function Call
 :00471C2F E8CC92FCFF    call 0043AF00   :;  Our dongle security call
 :00471C34 8BF0          mov esi, eax    :;  Return codes from dongle check
 :00471C36 85F6          test esi, esi   :;  Test to see if they are the same
 :00471C38 0F85DE310000  jne 00474E1C    :;  Jump to Error message if not equal. 
 :00471C3E   FF4722      inc [edi+22]
 * Reference To: signlab5._FindPorts2@0
 :00471C41 E85A97FCFF    call 0043B3A0

 Hmm.  We know that the conditional jump at 0471C38 ( JNE ) should *not* be executed right ?
 Right,  cause that's what gave us our error message.    But how do we fix this ??
 Any ideas ??   Good.  I can see the wheels a turn'in.  hehe

 There are various ways in wich we could fix this routine.  Here are a couple of ideas :
 We could NOP this instruction, wich would effectively 'erase' the conditional jump.
 We could reverse the conditional jump at 00471C38 from jne to je.  ( Change 0F85 to 0F84 )
 We could modify the return flag being set at 00471C34 to reflect the return code we want.

 The way in wich we are going to 'fix' this little jump, is by setting the return code to
 what we want.  This is going to be quite simple indeed.  
 First of all, do you notice the command at 00471C2F ?  
 This is the call that checks for the dongle.  Because we are going to bypass this call,
 we can then overwrite this bit of code.   So the code that says ' call 0043AF00 ' we are
 going to change to  ' xor eax, eax '.  What this does is simply reset whatever value is
 in the eax register, to now equal 0. (zero).
 So then at line 00471C34, 0 is moved into the esi register, and then at line 00471C36  the
 'test esi, esi' is going to return a ' true' result, instead of 'false' which it would 
 have been the original results.  Which is why we got our nasty  Error Message.  
 So now to make our changes permanent.  
 Using our hexeditor we are going to  change E8CC92FCFF to  33C0909090  .
 But how do we know where to find this  location in our hexeditor ?   You could do a 
 search for the byte pattern ' E8CC92FCFF '.  However there could be multiple occurances
 of this byte pattern.  So a more reliable, and by far the most easy, method for doing
 this, is just to let WDasm tell us the exact location.   Back in WDasm, scroll down
 until you see the line of code listed in the example above. ( Line  00471C2F )
 Now using the mouse,  double click right on this line, so that it is now highlighted.
 Look at the status line at the bottom of WDasm.    You see that long line of numbers
 and such.   Ok now look towards then end of the line and you'll see something like this  :  

 00471C2F @ Offset 0007102Fh in file: signlab5.exe
 This is the exact location that we are looking for ! !   How easy is that !  : )

 At this point we want to go ahead and fire up our trusty hex editor.  I prefer HexWorkshop. 
 So that's the one I'll  be refering to.    Once HexWorkshop is up and running,  we can click
 on the Menu Item  File --> Open.   Next we need to browse to the directory that Signlab is
 installed to.  ( Usually C:\Signlab5 ,  unless you specified otherwise. )
 Now click on the file signlab5.exe , and click open .   Once this is done, click on the
 menu item edit --> goto , and type in the value we got from WDasm. ( 0007102F )  
 Remember that this value is *HEX* not decimal.  So be sure to check the radio button that
 says 'Hex' .   Go ahead and click to Go button.   Now you should now be looking at the
 code to be modified.  ( Right at the blinking cursor. )   So go ahead and type 33C0909090 . 
 Notice that these are the number 0 (zero) not the letter o.  Be extra careful to only 
 overwrite the exact byte codes that we have listed here.    Click File -- Save  to save
 the changes we just made.
 Notice :  If you get any error message from HexWorkshop when you are trying to save the
 changes,  be sure to check that the program is *not* running.  You cannot save modifications
 to a program while it is currently running.  
 (Or being accessed by another program.  Such as WDasm.  :)  )

 Congratulations !  You have now successfully reversed the first of 8 such security calls.
 I will tell you these are the functions protected : 
   * Import    * Export
   * Print     * Cut 
   * Open      * Save As

 You can expect these error messages :
  1)  ERROR LOCATING SECURITY DEVICE --  Occurs a total of 6 times
  2)  INTERNAL ERROR -- Occurs once
 *Hint*  One of these dongle checks are performed from within one of the program 
  support files.  ( DLL )
 Good Luck !
Final Notes
 As I sum up this intial security check,  I want to point out that each of these dongle 
 checks can be found using this same technic.   Once you find the error message, trace
 back from there until you find the conditional good guy / bad guy jump.  Simply modify
 the code to produce the results we want.  Following this same technic, one could go on
 to complete this crack for a fully working program.  
 This is another example of lazy programmers who look to dongles as the 'un-crackable'
 protection.   But due to their lack  of effort, have actually made a crack like this
 routine, and a walk in the park. 

 GREETZ -- go out to everyone who contributes to The +Sandman's awesome Msg Board
                        Reverse Code Engineering for Newbies
Ob Duh
I wont even bother explaining you that you should BUY this target program if you intend to use it for a longer period than the allowed one. Should you want to STEAL this software instead, you don't need to crack its protection scheme at all: you'll find it on most Warez sites, complete and already regged, farewell, don't come back.

You are deep inside Fravia's page of reverse engineering, choose your way out:

redhomepage redlinks redsearch_forms red+ORC redhow to protect redacademy database
redreality cracking redhow to search redjavascript wars
redtools redanonymity academy redcocktails redantismut CGI-scripts redmail_Fravia
redIs reverse engineering legal?