Patching a poorly implemented Hasp dongle
Not Assigned
by +Tsehp
98xxxx
handle
1100
NA
PC
+Tsehp
|
Patching a poorly implemented Hasp dongle |
Not Assigned | |
|
|
|
|
|
|
|
by +Tsehp |
| fra_00xx 98xxxx handle 1100 NA PC |
+Tsehp |
|
|
|
||
|
|
|
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.
|
|
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.
|
|
WDasm -- Windows disassembler Hex Workshop -- Hex Editor Brain -- ( Somewhat Optional )
|
|
Vendor : Cadlink Technologies Website : www.cadlink.com Download : From the maintenance section. Password : RMCCZH,CNXVK7,QZ3FJ2,T3XZ77,DFB8S1
|
|
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:
:00471C38(C)
: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
3) POSSIBLE ERROR WITH LAST PASSWORD -- Occurs once
*Hint* One of these dongle checks are performed from within one of the program
support files. ( DLL )
Good Luck !
|
|
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
|
|