Cracking "Simple crackme by Ozzman v2.0" - by Sunshine
crackme by Ozzman v2.0
File : crackme2.exe (16.896 bytes)
|Downloaded from :||EOD's Crackme Site|
|Level :||Newbie (like me...)|
|Tools :||Wdasm, Softice, Hex Editor (I used Hex Workshop)|
|Info :||Keyfile check, not packed, no anti-debugging|
Ok, start the crackme and we see just 2 buttons. So click Register and the nice message "Nice try lamah...:) Try again!" pops up. Close it and open a copy of the file (always do this so you don't get an error if you wanna patch that file) in WDasm, go to String References and doubleclick on our message. Scroll up and we'll see this:
push 00000028 ;
length of data buffer
:00403855 8B45F8 mov eax, dword ptr [ebp-08]
:00403858 50 push eax ; pointer to buffer for read data
:00403859 53 push ebx ; handle to file
* Reference To: kernel32._lread, Ord:0000h
:0040385A E8B5FEFFFF Call 00403714
:0040385F 85C0 test eax, eax
:00403861 7518 jne 0040387B ; if successfully read, jump to go on, else bad boy message
:00403863 6A00 push 00000000
* Possible StringData Ref from Code Obj ->"Crackme 2.0 by Ozzman"
:00403865 6818394000 push 00403918
* Possible StringData Ref from Code Obj ->"Program not registered!"
:0040386A 6830394000 push 00403930
:0040386F 6A00 push 00000000
* Reference To: user32.MessageBoxA, Ord:0000h
:00403871 E8DEFEFFFF Call 0040375
First 4 bytes are xored with first bytes of second half of the keyfile (14h, 15h, 16h, 17h bytes) and stored back in esi. Then it increases the pointesr by 4 to read next 4 bytes (of first and second half of keyfile), xor them again and so on... Trace it a few times and have a look at eax and ebx to understand what I mean.
it compares calculated values with original values from our keyfile in a loop.
This makes it *very hard* to reverse. Cause the crackme takes bytes from the
keyfile, calculates new values by xoring them and finally compares these new
values with original values from the keyfile.
Now you think: Well, just trace with softice to 004038C2 jne 004038E9 and always write down eax (which is the calculated value) and put them in our keyfile so the compare succeeds... That doesn't work cause if you change only on byte in the keyfile the calculated value will change! The fucking xors depends more or less on each other and one byte will change the calculation.
So what do now? Completely reversing the whole calculation would take MUCH time...
Hey, but if we fill the whole file with zeros, it must work! Cause 0 xor 0 = 0! So all calculated value are zeros (there are just xor operations...) and all values in the file are zeros.
So a valid keyfile is a file called "ozzman.key" 28h bytes big and just containing zeros! Well, it's quite lame but it works...
Hope you like it and understand everything! C U soon...
Sunshine, February 2003
00000000 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020 0000 0000 0000 0000 ........
This site is part of Sunshine's