Cracking (Lucifer48) 
Cracking is for me a part of something more general that is reversing (RE). Understanding
perfectly assembly is deadly important (crackers should always be coders). Reading
various essays is important too. I also really advice trying some crackmes, a few ones are
so amazing; it's really a good excercise! Beyond patching, debugging, there are a lot of
other fundamental knowledge: mathematics, algorithms, languages (ASM, C, Pascal, Java,
Prolog, Caml, ...), cryptography, OS (not only Windows, try Linux / Unix), ...
(it's a part of the computer sciences in fact).
Knowlegde is definitely power! To become a cracker act like a cracker. Always think that
experimented crackers can help you for everything, IRC / forums / email are made for that.
Never loose a day : learn, learn, lean. Be fascinated or die!
|
NOP Patching (+ORC)
|
Do not use NOP unless totally necessary, there is usually a better way. For instance you
could replace 2 NOPs with a simple INC EAX, DEC EAX or something of that kind. There are
a lot of things to use instead of a NOP, which is BTW fairly easy to detect in code.
|
Patching (MisterE)
|
I'll say it to you right now: I hate patching. There are numerous reasons why you should
not patch, though there are situations when you can't do anything else. Like when you want
to remove that NAG Screen from some program that doesn't let you enter a name/serial. If
you can enter a serial or register the program without patching, do it!! If you want to
patch you might encounter problems like programs that do some CRC checks or check multiple
times. Another common problem is that newbies patch some jump just before the call to a
MessageBoxA. The programs tells you it's register, but meanwhile you only thing you patched
was that the program displays the 'regged' message instead of the 'unregged' message.
|
Patching Packed Files (Lord Soth)
This whole method, in a couple of words require some planning, but when its executed, its
well worth it. What we're doing is find the OEP (Original Entry Point), and before
we go into the main program, we put in another code snippet to patch what we want. If we
have the room to just throw the code in, the better!
However if we don't have the room, we'll have to look elsewhere and redirect the program
to that location. When redirecting, always make sure you get the address right, because
you'll have to patch the EXE file and put the code in the EXACT same place that the JUMP
is pointing at, and this could be tricky. Again, a good way to do this is by finding a
familiar pattern and writing it down (or remembering whichever you prefer).
|
Thinking like a Cracker (rudeboy)
Programmers are taught that whenever you have a task that is going to be done more
than once, you should create a function to do that task, and just CALL the function
when you need to perform the task.
Now, most programs that use a Name / Serial combination check the code at least twice,
once when you enter the code, and once when the program starts up. Because of this the
programmer will usually CALL a function to test the validity. And usually, this function
will be CALLed every time the code is checked.
So if you patch the function that is CALLed to test the validity of your Serial, it will
show up as valid whenever the program does it's check.
The techniques employed here do not only apply to cracking programs with a Name / Serial
combination. Do not limit yourself by thinking 'Inside the Box', these techniques can be
used with many other types of protections as well. For instance many times a date check
and a NAG Screen are done by one function.
|
Tools (rudeboy)
|
Don't limit yourself to one tool, use SoftICE, W32DASM, IDA, and any other tools you have
together. Information gathered in one can usually be used with another.
|
|
00. INDEX
11. General Cracking Theory