- A question that is often asked in different forums is: "I
have a program. How do I start to crack it?" To help all you
newbies (btw: I saw plushmm's list of cracking knowlege today and
this list makes me a intermediate - advanced cracker. Nice, but I
consider myself a newbie :) out there that have no clue how to start
to crack a program I write this essay. I will describe *my* way of
cracking a prog. This is probably not the best, but has worked *often*.
I. The very start:
So we have the prog. Should we start with SICE, W32Dasm, File Monitor
or Registry Monitor. Some guys say: Look at the imports of the EXE
using Window's Quickview at first. I say: That's crap (sorry guys).
I never did it and will never do it. Same with RegistryMonitor and
FileMonitor. I use them only when I amd stuck with my cracking approach
(and hope I will find some "magic hint"). So there are two
tools left: W32Dasm and SICE. Which one to use first? Imagine you're
a knight: You have a sword (SICE) and a shield (W32Dasm). Using only
a sword would decrease your defense in a way that makes it easy to
slay you, but using only a shield makes it impossible to
slay your enemy. So take the shield at first, but always remember
you have a sword in your other hand. Gain knowledge about your enemy
(exe file) using the deadlisting. Then take the sword and "kill"
the program. To make it short: Disassemble and look at the ASM code.
When you found something important look at it with SICE.
II. The deadlisting:
So disassemble the exe file. If you don't get any string references,
the file is either packed/encrypted or VB. You can easily check if
it is VB. Look at the imported functions. Does it contain VBRUNXXX,
then it is a Visual Basic program. I don't know how to crack a VB
program properly (also I cracked some using the W32Dasm deadlisting
approach :), so I won't tell you further. For good essays see Eternal
Bliss' site.
If it doesn't contain VBRUNXXX, then the file is probably packed.
Open the file into a hexeditor and look for strings that indicate
that it is packed (for example: ASPack, Petite, PE-Crypt, PE-Lock,
Neolite...). Then try to find a unpacking tool for it. If you can't
find one make a manual unpack. (See my last tutorial.)
If you have unpacked it or it is a "normal" program we can
go on here.
While the program disassembles start the prog and look for suspicious
strings like "Unregistered" or remember the strings that
appear in nag-screens and "Invalid serial" messages. The
program should be disassembled now. Look at the string references
and try to find the strings.
II.1.1 You find the strings
OK, you found the strings.
If it is a nag-screen you should look out for the caption of the nag-screen.
If that cannot be found, then use the first line of text. Now scroll
up from the line the string appears. If you scroll up a bit you should
come to a conditional jump or a call reference. Try changing the jump
and NOPing the call in a hexeditor. If the nag is gone you did it
:) If not, then try to be imaginative. Explaining every nag approach
would be far too much for this tutorial.
If you want to get a serial you have to find the "Invalid serial"
message (if there's no "Invalid..." message, search for
"Thank you..."). If you scroll up from the "Invalid"
message a bit you will come to a "*Referenced by a (U)ncondititional
or (C)onditional Jump at Address"or a conditional jump that leads
to the "Thanx" message. This conditional jump is the important
one (unless the programmer dosn't fool you with fake strings. In (at
least) 75% of all progs the conditional jump will look like this.
mov eax, XXX ;; correct
(or entered) serial
mov ebx, YYY ;; entered (or correct)
serial
call ZZZZZZ ;; compare them
je AAAA ;;
If they are (jne=not) the same, then jump
Eax can be ebx, ecx, edx or any other register, too. The same for
ebx. Mov can be lea or pop, too. The je can be jne, jz or jnz. If
you see this (two values are written to registers, one call, one conditional
jump leading either to the "Thanx" or "Invalid"
message), you have the serial in 99% of the progs :) (See the SICE
part for details)
II.1.2 You cannot find the string
If you cannot find the strings for a nag-screen, then leave W32Dasm
and go to SICE. If you cannot find the string of a "Invalid"
message that appears in a messagebox search for the API function MessageBox
(or MessageBoxA). If you found one, scroll up a bit and look for a
conditional jump. If this conditional jump leads to another messagebox,
it can be the "Thanx" message. If you scroll up and find
"*Referenced by a (U)ncondititional or (C)onditional Jump at
Address" look if there's a messagebox directly below this conditional
jump, then a "jmp XXXX" must follow and then your first
messagebox.
There is one more completely different approach: Search for RegSetValueExA
(that could be when the serial is stored after the program is registered)
or RegQueryValueExA (to see if the serial is correct if the program
starts).
III. The debugger
III.1 A nag-screen
If the nag-screen is only a messagebox telling you ro register the
prog, then set a breakpoint on MessageBoxA (bpx messageboxa). If it
is just another kind of window, set the breakpoint on CreateDialogIndirect
ParamA or CreateDialogParamA (search for more information in TORN@DO's
cRACKER's nOTES). Whatever, if you have luck, the program will
break at the start and you are kicked back to SICE. Now press [F12]
once and you will be in the code that called the API function. Scroll
little up ([CRTL]+[CURSOR-UP]) and search for a conditional jump.
Set a breakpoint on it (bpx XXXX:XXXXXXXX, where XXXX:XXXXXXXX=the
adress of the instruction). Now restart the program and the SICE should
break at this line. If the jump is je/jne/jz/jnz, then change the
value of the "zero flag" by entering "r fl z",
is it jl/jb/jle/jbe then change the value of the "overflow flag"
by entering "r fl o". If the nag-screen has disappeared,
then locate the instruction in W32Dasm, get the offset and patch it
(to EB) in a hexeditor. Now the nag has disappeared forver. If the
nagscreen didn't disappear in SICE, then you got the wrong jump. You
have to search on :(
III.2 The serial
If you were able to locate the important jump, then it is (most time)
easy to get the serial. Start the program, enter a serial, go to SICE
and set a bpx on hmemcpy, Push the "Register" button, SICE
should break, push [F12] and set a bpx on the address of the important
jump (it is the same as in W32Dasm). SICE should break on this line.
Now we have this:
mov eax, XXX ;; correct (or entered)
serial
mov ebx, YYY ;; entered (or correct)
serial
call ZZZZZZ ;; compare them
je AAAA ;;
If they are (jne=not) the same, then jump
Look at eax (d eax) and in ebx (d ebx) and you will (often) see the
serial you entered and the correct serial. Just leave SICE and enter
the serial you found here. Now the program should be registered.
If you were not able to find the string, set a bpx on hmemcpy, push
[F12] and then trace through the code [F10] until you find a construction
like the above. Then look at the registers and you have the serial.
If there's no instruction like the above, it's getting difficult (Or
you missed a check for the length of the serial or name). Everything
could happen during the calculation and the only thing you can do
is tracing through the code and understanding what happens in every
line.
|