http://www.yurisw.com/hedit/download.htm
 

About this protection system

 
In this version of Hex Editor V2.1 there is no Registration Screen for you to enter any registration\serial number into. You have 30 days to use this program and then it expires, leaving you to either find out how to register this program or you can simply exit the program completely.
 
The programmers don't want to give you the chance of attacking their program and hope that it will discourage you from further examine it's code. *grin*
     

The Essay

     
On the face of it, this program may well look like a 'dead duck' to many people wishing to *crack* it, since the programers have taken measures to prevent you from registering this program.  How can you you register a program that does not have the facility to register itself with?.
 
It's about here that you have to put these thoughts out of your mind and think like a *cracker*.  OK, so what protection does the program employ?..  Nag screens reminders only appear at certain intervals during your 30 day trial, you won't normal see any until you've used the program for 2 weeks where it will remind you that you've had two weeks to-date to evaluate this program and then again on your last day of using this program.

If you now set your clock so that 1 month has elapsed then you will be told that your 30 day trial has been used up and the program now gives you the option to either see how to order this program or exit back into Win'95.  Not a pretty sight...
 
So it seems that this program is using a 'counter' somewhere, and it's based on your pc's clock, the day, month, and year are recorded by the program when it is first run.  So we can correctly assume, that if we disable the location within the target program's code that checks to see if it's 'within' this 30 day period we can in effect, make this babe run indefinitely with no 'reminders' and disabling of some of it's functions.
 
Most programs of this type use the system function GetLocalTime provided by the Kernel32.DLL to see what day,month,year your computer is running in, so it makes sense to use this fact to enter the target program's code from here, before the program does it's time checks in fact.
 
First, create a 'dead Listing' of Hex Editor V2 using W32Dasm. Checking the program's String Data Resources reveals little other than the normal text used in programs of this sort.  Now Search for the function 'GetLocalTime', there is only one mention of this in the target program's code, you will find it here..

* Referenced by a CALL at Address: :0041B4DE

:0040C2E0 81ECCC000000            sub esp, 000000CC
:0040C2E6 8D442410                lea eax, dword ptr [esp+10]
:0040C2EA 50                      push eax
:0040C2EB FF154CC24300            Call [KERNEL32.GetLocalTime]
:0040C2F1 8D4C2400                lea ecx, dword ptr [esp]
:0040C2F5 51                      push ecx
:0040C2F6 FF1558C24300            Call [KERNEL32.GetSystemTime]
:0040C2FC 668B54240A              mov dx, word ptr [esp+0A]

So far so good, now we want to find out where in the program, this block of code gets called from and W32Dasm provides us the answer here too, it's called from memory location :0041B4DE  so lets now go there and see if there was some sort of 'trigger' that makes the program go here in the first place..
 
* Referenced by a CALL at Addresses: :004032A7 , :0040336C
 
:0041B4DC 6A00                    push 00000000
 
:0041B4DE E8FD0DFFFF              call 0040C2E0 ;This calls the routine
                                                ;that gets the local time.
:0041B4E3 59                      pop ecx
:0041B4E4 8B4C2404                mov ecx, dword ptr [esp+04]
:0041B4E8 8901                    mov dword ptr [ecx], eax
:0041B4EA 8BC1                    mov eax, ecx
:0041B4EC C20400                  ret 0004
 
As we can see, there are no cmp then jump instructions here to work on so we must once more back-track our way further into the code. We now have two *possible* locations within the target program that needs to know what time period your pc is running in.  These two addresses are quite close to each other, so lets choose the first CALL address at memory location 004032A7because it's likely that this gets called before the other memory call address at address 40336C
                                   |
:0040326A FF1500C04300            Call [ADVAPI32.RegQueryValueExA]
:00403270 8BD8                    mov ebx, eax
:00403272 8D4C2410                lea ecx, dword ptr [esp+10]
:00403276 F7DB                    neg ebx
:00403278 1BDB                    sbb ebx, ebx
:0040327A 89B42484000000          mov dword ptr [esp+00000084], esi
:00403281 F7DB                    neg ebx
:00403283 E80CDE0100              call 00421094
:00403288 84DB                    test bl, bl
:0040328A 0F85D7000000            jne 00403367 ;Our first conditional jump
                                               ;statement!
:00403290 51                      push ecx
:00403291 8B4C240C                mov ecx, dword ptr [esp+0C]
:00403295 8BC4                    mov eax, esp
:00403297 89642414                mov dword ptr [esp+14], esp
:0040329B 8D542420                lea edx, dword ptr [esp+20]
:0040329F 8908                    mov dword ptr [eax], ecx
:004032A1 8D442414                lea eax, dword ptr [esp+14]
:004032A5 52                      push edx
:004032A6 50                      push eax
:004032A7 E830820100              call 0041B4DC ;This calls goes to the
                                                ;block of code we've just
                                                ;looked at.

We finally find a conditional jump instruction that comes before the call statement that we know checks the time that our pc is running in.  But we still have some loose ends to sort out BEFORE we can go patching this program..

Remember, in the last block of code at location 0041B4DC we had at least TWO possible CALL locations [004032A7 ,:0040336C] that called that section of code, we've still one more lead to check out.  So if we now examine where the other CALL 0041B4DC came from we arrive here.
 
* Referenced by a (C)onditional Jump at Addresses::0040321F(C),:0040328A(C)
 
:00403367 8D542410                lea edx, dword ptr [esp+10]
:0040336B 52                      push edx
:0040336C E86B810100              call 0041B4DC
:00403371 8B00                    mov eax, dword ptr [eax]

*Look, we also have two conditional jump statements that head to this code block as well, best make a note of this *

I hope you've understand the 'logic' so far of why we have to also check this section of code before we start patching the program.. We must UNDERSTAND how the program *thinks* under different circumstances. In this case we've worked out that there are two *possible* paths that the program can take that will both end up with the program finding out that we've used up our 30 days trial period, so we want to try and make the program 'ignore' this check forever.  So if we have TWO places where the program will end up checking the date our pc is running in, then it makes sense if we can disable the FIRST date check and see if that will also make the program ignore the SECOND date check.
 
Here's where we can start to tie all those loose strings..
 
Lets have another look at the FIRST memory location that has that CALL 0041B4DC instruction, which we know goes to the date checking routine.
 
:00403288 84DB                    test bl, bl
:0040328A 0F85D7000000            jne 00403367 ;Our first conditional jump
                                               ;statement!
:00403290 51                      push ecx
:00403291 8B4C240C                mov ecx, dword ptr [esp+0C]
:00403295 8BC4                    mov eax, esp
:00403297 89642414                mov dword ptr [esp+14], esp
:0040329B 8D542420                lea edx, dword ptr [esp+20]
:0040329F 8908                    mov dword ptr [eax], ecx
:004032A1 8D442414                lea eax, dword ptr [esp+14]
:004032A5 52                      push edx
:004032A6 50                      push eax
:004032A7 E830820100              call 0041B4DC
 
Look at that jne 00403367 statement, see where it's jumping to?, that's right, it's going to the SAME location where our SECOND CALL 0041B4DC is located!!. But wait a minute, if the jump is 'triggered' then the program will expire after 30 days of use, and if the jump is not 'triggered' it will STILL hit that CALL 0041B4DC instruction in which case the program will STILL expire after 30 days!.  So patching this jne instruction won't do us any good.  Lets now find out where that SECOND conditional jump location is, perhaps that's the 'key' to unraveling this whole protection system?.

OK, if we now scroll up the W32Dasm window we should see the SECOND JNE 00403367 instruction here:-
 
:00403212 84DB                test bl, bl
:00403214 0F85B6010000        jne 004033D0
:0040321A 837C241401          cmp dword ptr [esp+14], 00000001
:0040321F 0F8442010000        je 00403367 ;Our SECOND jump instruction!!
 
Perhaps our first instinct at this point is to nop (90h) out this jump instruction but if you follow the code afterwards we will be back to square one.. What we want is to bypass BOTH sections of code that check what date the pc is running in so lets look for another jne instruction that does just that..  Low and behold there is a test then jump set of instructions right above our je 00403367 instruction which, if we follow where it goes to by passes BOTH sections of code that checks what date the pc is running in!.
 
Bingo!, here's the key to the whole protection system, it's based on one single test then jump in instruction..
 
:00403212 84DB                test bl, bl
:00403214 0F85B6010000        jne 004033D0
 
All we need to do now is to change the conditional jump instruction so that it will always ignore whatever the results are from the testing of the bl against itself and always jump to our 'Good Guy Routine'.

Job Done.....
 

The 'Crack'

 
All that remains for us to do is to change the je 004033D0 instruction into a unconditional jump, so that it will ALWAYS jump to this memory location.
 
Load up HEdit.exe into your favorite hex editor (hey that's good, using a hex editor to patch a hex editor!) then:-

SEARCH FOR THE FOLLOWING BYTES: 84DB0F85B6010000
REPLACE HIGHLIGHTED BYTES WITH: 84DBE9B701000090
 

Final Notes

 
It was much easier to *crack* this babe than it was to explain how I did it!. If you are going to learn *cracking* then being able to *think* ahead and logically will pay dividends.. Make sure to always tie up any loose ends BEFORE patching the program permanently..  Watch those jump/Call references to different blocks of code, miss one and your *crack* could make the program do some unpredictable things to your data.
 
My thanks and gratitude goes to:

Fravia+ for providing possibly the greatest source of Reverse Engineering
knowledge on the Web.
 
+ORC for showing me the light at the end of the tunnel.

 

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 continue to  produce even *better* software for us to use and more importantly, to continue offering even more challenges to breaking their often weak protection systems.
 
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.