Thursday, April 14 2005 @ 07:13 PM CEST Contributed by: detten Views: 6041
Level : beginner
Not every application uses a simple GetDlgItemText or simular API to get the input from an editbox.
This crackme by basse uses an alternate way to grab the keyboard input.
The next crackme has some interesting but unusual approaches. Curious?
Read on :)
I'm going to explain how this crackme works, but you won't find a valid
solution in here, if you want to find one, you'll have to brute it...
Get the crackme here : attachment
TOOLS USED : WDASM
Let's dig in :)
Where to start?
Ok, Disassemble the crackme with WDasm. We see it is not packed. And because
it is written using MASM, it's pretty clear code :)
After a quick look in the string table and the import table we can notice
the following :
There is no GetDlgItemTextA or GetWindowText
The author uses a hook (SetWindowsHookExA) to get the input...
If we try to enter a combination 3 times, the program crashes...ans possibly
your computer too! How is that possible?
The author uses the 'foofbug' here, an opcode combination that crashes
Pentium and Pentium MMX procesors. (Find more info on this subject here)
Followed by some garbage code...no wonder we crash :)
* Possible StringData Ref from Data Obj ->"Success!"
00401093 6870304000 push 00403070
00401098 FF350D314000 push dword ptr [0040310D]
* Reference To: USER32.SetWindowTextA, Ord:0259h
0040109E E807020000 Call 004012AA ; Put "success" in captionbar
Ok, what do we have here? If we press the
'test' button, a hash value get's checked with 02FB00F7h, if we would
like to patch, the jnz is the place :)
As said before, we do not find the code in the DlgProc that calculates
the hash. There is no WM_CHAR message too... but we get a hint from the
import table (SetWindowsHookExA) that this proggy uses a hook to get the
This is what the API reference says about SetWindowsHookExA :
The SetWindowsHookEx function installs an application-defined
hook procedure into a hook chain. An application installs a hook procedure
to monitor the system for certain types of events. A hook procedure can
monitor events associated either with a specific thread or with all threads
in the system. This function supersedes the SetWindowsHook function.
int idHook, // type of hook to install
HOOKPROC lpfn, // address of hook procedure
HINSTANCE hMod, // handle of application instance
DWORD dwThreadId // identity of thread to install hook for
* Reference To: USER32.SetWindowsHookExA, Ord:025Dh
00401162 E849010000 Call 004012B0
00401167 0BC0 or eax, eax ; if Hook succeeds
00401169 7405 je 00401170
0040116B A303314000 mov dword ptr , eax ; Save hook handle
Next, the focus is set on the editbox, we are ready for input :)
What happens in the above code? Well, when the DialogBox is created the
WM_INITDIALOG message is sent, so this code gets executed once at the
First the variables for the hash calculation are initialized. (BYTE ptr
 = 35 ) and DWORD ptr [4030FF] is already initialized at BAD0DEADh
Next, the hook is set up. It' s a hook for WH_GETMESSAGE and the hook
routine starts at address 4011C0h.
Let's check out this hook routine :
004011C0 55 push ebp 004011C1 8BEC mov ebp, esp 004011C3 837D0800 cmp dword ptr [ebp+08], 00000000 004011C7 731A jnb 004011E3 ; If we have input, go to 'calculate hash' 004011C9 FF7510 push [ebp+10] ; Else pass to next 004011CC FF750C push [ebp+0C] ; hook in the chain 004011CF FF7508 push [ebp+08] 004011D2 FF3503314000 push dword ptr 
* Reference To: USER32.CallNextHookEx, Ord:0014h
004011D8 E89D000000 Call 0040127A
004011DD C9 leave
004011DE C20C00 ret 000C
The next part, displays the hash in the captionbar (I think) Although I didn't see it (in XP) :(
0040126F C9 leave
00401270 C20C00 ret 000C
Ok, in the hook procedure all the CHARS are intercepted and the hash
is further calculated every time you press a key.
If you want to know a valid serial, you have to write a bruter with the
code from the hook routine. keep in mind that the hash is initialized
BAD0DEADh. The hash result should be 02FB00F7h.
The second byte var, is not needed for the algo, so we can cut it out
to speed up the bruting.
This is the hash calculation part out of the hook routine (a little optimized
The serial points to an address where you should store the combination
currently bruting. edi is the counter.
Let it run till byte ptr [serial+edi] = 0
A little problem is that we can't know the keylength...if this crackme
uses 10 chars and only lower cased chars, we have :
SUM (26^i) = 146.813.779.479.510 possibilities.
To put that in perspective, if you process 1 milion serials each second,
you would still need 4.6 years :(
And then the serial could be longer, and we don't even know the range
(1-9, a-z,A-Z,...) So feel free to brute it :)
Although the algorithm probably allows a lot of valid keys :)
=> Note from the author if you want to start bruting
It's only numbers, 0 - 9, and the length is 10.
If you get bored, try *******967 (the * you have to brute :-)
Now you should be able to brute it in little time...
That's it. The advantage of getting the input through a hook, is that
it's not buffered by windows (so no Hmemcpy, or translatemessage breaking to get at the right place!)
The disadvantage is that you cannot use backspace or del because they
generate a keycode too... It requires extra coding to handle every keypress right.
If you have questions, or remarks about this tutorial, feel free to drop a comment here, or ask on the BiW forum.
Greetz to Basse for this nice crackme! Keep on sending them :)
and to CoDe_InSiDe for pointing out the 'foof bug' thanx :)