As a raw new entrant to the established world of reversers, even if I did do some interesting (and indeed more satisfying than many other satisfying things) cracking earlier, this time I made up my mind and decided to write an essay, as I find this specific crack a bit different for the following reasons.

1. it involves wdasm32 as a debugger and not merely as a disassembler
2. it involves commercial protection scheme used by BIG people in the software industry. (I still fail to understand, why such BIG people are trusting a ‘commercial’ protection which can be removed even by an almost beginner like me)

Wdasm32 8.9 – for disassembly and debugging

Ultra Edit - for applying the patch

I have seen the same type of protection used by Macromedia (dreamweaver), Norton (AV), Starfish (Sidekick 98) and several other known names. The commercial protection is offered by a company called releasesoft systems (www.releasesoft.com). The protection is done by converting the full working executable into a file with dl_ extension. The time trial executable is a small loader program responsible to check the time/ trial mode and also to place the irritating nag on the execution of the trial version. The loader loads the file with dl_ extension, to run the application.

In case of SideKick 98, the trial can be ‘purchased’ by keying in a ‘registration key’. Finding the code was child’s play and does not even deserve a cracking essay. On entering the key, the file with dl_ extension is converted in to a full-fledged executable by another pop.exe program. Somewhat similar is the case with Dreamweaver.

Back to cracking Imageready.EXE.

I disassembled the loader programme ImageReady.exe. Thanx for this type of protection, the disassembly was fast and the disassembled file is only about 3.7 MB. I ran the app by pressing F9 after loading (Ctrl L) from within wdasm. The time trial nag is produced with two buttons ‘trial’ and ‘exit’. I switched back to wdasm and pressed F7 (step into)., then switch back to the nag and pressed Trial. The relevant code is

* Referenced by a Jump at Address:00406121(U)

* Reference To: USER32.DialogBoxParamA, Ord:008Eh
|
:00406139 FF1550A54400      Call dword ptr [0044A550]      ; put the nag
:0040613F 83F802            cmp eax, 00000002             ; Is ‘cancel’ selected?
:00406142 89357C514300      mov dword ptr [0043517C], esi
:00406148 0F8581000000      jne 004061CF                   ; If not, good goahead
:0040614E EB6F               jmp 004061BF                   ; prepare to quit
:00406150 8B0D7C514300      mov ecx, dword ptr [0043517C]
:00406156 53                 push ebx

So AX value is 2 if Exit is selected 1 if Trial is selected. Good. Now I advanced the clock and ran the target again. The nag is produced but this time with the Trail button greyed and only selectable option is Exit. Switched back to Wdasm by pressing F7 I landed at code,

* Referenced by a Jump at Address:00406077(U)

* Reference To: USER32.DialogBoxParamA, Ord:008Eh

:0040608E FF1550A54400     Call dword ptr [0044A550] ; put the nag
:00406094 83F806           cmp eax, 00000006         ; Is exit selected
:00406097 752B             jne 004060C4              ; If not ??
:00406099 E8D20E0000       call 00406F70              ; If yes quit
:0040609E 3BC3             cmp eax, ebx
:004060A0 7409             je 004060AB
:004060A2 8B1524794300     mov edx, dword ptr [00437924]
:004060A8 52 push edx
:004060A9 EB20 jmp 004060CB

So this time the nag is produced by a different set of code. Now how can I run the app? With any other value for AX other than 6 (exit) a purchasing option screen is produced (marked ??)(incidentally, this option is unapproachable ordinarilly).

I thought for a while. In the previous nag, a conditional jump at 00406148 to 004061CF means good guy with sufficient time left. As a different nag is produced after the trial period is over, it is most unlikely that there are any time checks after the jne to 004061CF. Out of curiosity, I decided to check whether there are references to 004061CF at any other places. On searching up I found atleast 6 references and all are conditional jumps. I set the break point at one of the conditional jumps (I did for the fist reference from the top at 405F25) and ran the app from within wdasm. The break point was encountered before the production of the nag and I forced the jump by selecting patch code and continue running. Voilo!! No nag. Application loaded well and functioning properly. Whatt'dya say? Wish all protection schemes were so smooth

At this moment I thought that the crack was completed and I could not believe that a commercial protection trusted by software "masters" like Adobe could be cracked by a "simple" average reverser...

But wait!!. This target had some more surprises in store.

I quit out of wdasm, and in order to have a working patched copy, I used my trusted UltraEdit to patch the exe.

The patch is to

Change

:00405F25 0F85A4020000 jne 004061CF

to

:00405F25 E9A50220000 jne 004061CF

;00405f29 90 nop

After patching I ran the app. And... No!!!! It was not working!
Worse! It produced an 'illegal operation' and the os intimated me the same. I pressed the details button in the error message box and I found the following text.

So the crack is not so simple after all, and it is not yet complete. It seems that the program is checking for file integrity by some technique like checksum, which detects the patching and so is producing the page fault. Cracking a file integrity checking is not so easy at times... anyway I decided to give it a try, of course. I opted for a bruteforce nopping crack (I know it's not very elegant, but I just wanted to study and verify this protection scheme, not to give out serial numbers to the lusers...)

If the program can work through a patch done through wdasm but not through a hex editor. Probably the integrity check is done BEFORE 405F25. I noted that the page fault occurred at 405139. To verify this hypothesis I disassembled and ran the patched exe file from within wdasm with a breakpoint at 405139. The code is

:00405131 0FAFC6            imul eax, esi
:00405134 83C404           add esp, 00000004
:00405137 85C0              test eax, eax
:00405139 C70064000000     mov dword ptr [eax], 00000064 ; problematic code
:0040513F 7409             je 0040514A
:00405141 50                push eax
:00405142 E8C9BB0100       call 00420D10

At the breakpoint I simply noped the code at 405139 (can be done in one step by ‘modify data’ option) and ran. Another similar page fault occurred, but this time at 401cd3.

:00401CCE 83C404            add esp, 00000004
:00401CD1 85C0              test eax, eax
:00401CD3 C70064000000     mov dword ptr [eax], 00000064 ; problematic code
:00401CD9 7409             je 00401CE4
:00401CDB 50                push eax
:00401CDC E82FF00100       call 00420D10
:00401CE1 83C404           add esp, 00000004

I repeated the nopping at 401cd3 and ran. No problem.

I patched the code with Ultra edit the changes are;

Change
00405139 C70064000000 mov dword ptr [eax], 00000064
to

00405139 90 nop
0040513A 90 nop
0040513B 90 nop
0040513C 90 nop
0040513D 90 nop
0040513E 90 nop

change
00401CD3 C70064000000 mov dword ptr [eax], 00000064
to
00401CD3 90 nop
00401CD4 90 nop
00401CD5 90 nop
00401CD6 90 nop
00401CD7 90 nop
00401CD8 90 nop

The patched copy ran like a treat!!! And there are no more hidden surprises.

That’s all.

Thanx for the teaching, masters.