A beginners Guide to Cracking
Chapter 1 overview
Chapter 2 some tips on how to use the debugger
Chapter 3 some basic cracking techniques
Chapter 4 walk through of an easy crack
Chapter 5 how to use the disk editor
Chapter 6 other cracking tools
Chapter 7 source code to a simple byte patcher
Chapter 8 conclusion
Programs included at the end of this guide
Section 1 uuencoded cracking tool
Section 2 another uuencoded cracking tool
Section 3 uuencoded program to crack for the walk through
CHAPTER 1 OVERVIEW
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
You might be wondering what type of programming skills you need to become a
cracker. Knowing a higher level language such as Basic, Pascal, or C++ will
help you somewhat in that you will have an understanding of what's involved in
the process of writing a program and how certain aspects of a program
function. If you don't have any programming skills at all, you have a long
road ahead of you. But even if you can program in a high level language, in
order to crack you have to know assembly...
It really doesn't matter what language a program was written in in order to
crack it, because all programs do the same thing. And that is issue commands
to the microprocessor. And all programs when broken down to their simplest
form are nothing more than a collection of 80XXX instructions and program
specific data. This is the level of assembly language. In assembly you have
total control of the system. This is also the level that the debugger operates
at.
You don't have to become a master at assembly to crack a program, but it
helps. You do need to learn some rudimentary principles, and you absolutely
have to become familiar with the registers of the cpu and how the 8088
instruction set uses them. There is no way around this.
How proficient you are at assembly will determine how good of a cracker you
become. You can get by on learning a few basic instructions, how to use a
debugger, and one or two simple techniques. This will allow you to remove a
few shareware nag screens, and maybe you'll luck out and remove the copy
protection from a game or two, but that's it.
As soon as a programmer throws some anti-debugging code into a program or
starts revectoring interrupts, you'll be whining for someone to post a crack
for this or that... And you can forget about ever learning to crack windows
programs.
It's much much easier to learn to crack in DOS than windows. DOS is the
easiest environment to debug in. This guide will focus on DOS programs as
cracking windows apps is a little bit overwhelming unless you are already an
experienced cracker. And if you are, your wasting your time by reading this.
This manual is geared towards the raw beginner who has no clue as to where to
start and needs a little hand holding in order to get going.
There are several good beginners manuals out there, but most of them assume a
person has at least some experience in cracking or knows how to use the
different tools of the cracker, and the raw beginner usually becomes
frustrated with them very quickly because they don't understand the concepts
contained in them.
I wrote this guide as sort of a primer for the beginner to read before reading
the more comprehensive guides. I tried to keep it as simple as possible and
left a great deal of information out so as not to overwhelm anyone with too
much information at once. Hopefully after reading this guide it will be easier
for the beginner to understand the concepts of the more arcane guides out
there. So if you are reading this and it seems a little bit remedial,
remember, at one time you didn't know what a debugger was used for either.
Now in case your not familiar with the debugger and disk editor and what their
different roles in cracking are, I'll give a brief explanation of each. As
these are the crackers most used tools.
The debugger is what you will use to actually crack the program. When you load
a program you wish to crack into the debugger, it will load the program and
stop at the first instruction to be executed within the code segment. Or, you
can also optionally break into an already running program and it will halt the
program at the instruction you broke into it at and await further input from
you. At this point, you are in control of the program.
You can then dynamically interact with the program and run it one line of code
at a time, and see exactly what the program is doing in real time as each line
of code is executed. You will also be able to re-assemble instructions (in
memory only), edit the contents of memory locations, manipulate the cpu's
registers, and see the effects your modifications have on the program as it's
running. This is also where all your system crashes will occur... There is a
lot of trial and error involved in cracking.
As stated above, the debugger will only modify the program while it's up and
running in memory. In order to make permanent changes, you need to load the
program file to be patched into the disk editor and permanently write the
changes you've made to disk. A detailed explanation of how to do this will be
made in chapter 5.
So, with this in mind, you need a few essential tools... The first one is a
good debugger. The original draft of this guide gave explicit instructions on
how to use my favorite debugger. After considerable deliberation, I decided to
re-write it and make the instructions more generic so you could apply them to
most any debugger. You will also need a disk editor, it doesn't matter which
one you use as long as it will load the program file, search for and edit the
bytes you want to change.
I uuencoded a few cracking tools that you will find indespensible and placed
them at the end of this guide. I won't go into the use of the cracking tools
right now. But believe me, you absolutely need one of them, and the other one
will save you a lot of effort. I also uuencoded the program that we will crack
in the walk through and included it in this guide as well.
As you get better, you'll have to write programs that will implement your
patches if you decide to distribute them. The patches themselves don't have to
be written in assembly.
The source code I included in this manual for the byte patcher is the first
patcher program I ever wrote, and is extremely simple. It's written in
assembly because that's the only language I know how to program in. but if you
are already proficient in a higher level language, it should be trivial for
you to duplicate it's methods in your preferred language.
CHAPTER 2 SOME TIPS ON HOW TO USE THE DEBUGGER
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ok, before I begin, I'd just like to stress how important it is that you know
at least some assembly before trying to continue. If you don't, you will get
lost pretty quick from here on out. Comprehension of the base 16 (hexadecimal)
number system is also required.
I'm not about to give a remedial course on assembly or hex math, that would
take too long and I'd probably leave too many questions un-answered. Besides,
there is enough information on them available from a myriad of other sources.
So, from now on in this guide, I'm assuming you have a fair working knowledge
of assembly and hexadecimal. If I say something you don't understand or you
cannot grasp some concept, look it up somewhere...
I've tried to make this section as generic as possible. I used general
descriptions when explaining HOTKEYS and COMMANDS as different debuggers will
use different keys and command syntax to implement these functions.
You should be able to translate these instructions to the actual key strokes
and commands that your debugger uses... If you don't know how to use a
debugger, PAY ATTENTION!!! If you already know how to use a debugger you can
skip this section as it is only a general overview of different windows and
functions designed for the absolute beginner who has no clue as to what he is
looking at.
The reason I included this section is because most manuals for debuggers tell
you how to use the various features of the debugger, but they don't give any
insight on how to apply those features, as they assume the person reading them
already knows how to debug a program.
First, I'll give an overview on the different windows that most debuggers use.
REGISTER WINDOW:
The register window contains the general purpose and flags registers of the
cpu. You will notice that the general purpose registers contain hexadecimal
values. These values are just what happened to be in there when you brought up
the debugger. you will also notice that some of the flags are highlighted
while some are not. Usually, the highlighted flags are the ones that are SET.
While the ones that are not highlighted are CLEARED. The layout of this window
will vary from debugger to debugger, but they all basically are the same.
From this window you will be able to manipulate the contents of the cpu's
registers. some debuggers accomplish this by clicking on the register to
modify with the mouse and then entering a new value. Other more powerful
debuggers use a command line interface, you'll have to discover how your
debugger goes about this yourself.
You can change the values of the registers while debugging a program in order
to change the behavior of the running program. Say you come across a JNZ
instruction (jump if not zero), that instruction makes the decision on whether
or not to make the jump based on the state of the (Z)ero flag. You can modify
the condition of the (Z)ero flag in order to alter the flow of the programs
code.
By the same token, you can modify the general purpose registers in the same
manner. Say the AX register contains 0000, and the program bases it's actions
on that value, modifying the AX register to contain a new value will also have
the effect of modifing the flow of the code. After you become comfortable with
using a debugger you'll begin to appreciate just how powerful this window is,
and you'll aslo discover soon enough just how totally it can screw your
system.
DATA WINDOW:
The data window will display data as it exists in memory. From this window you
can usually display, search, edit, fill, and clear entire ranges of memory.
The two most common commands for this window are display and edit. The search
command is also useful in cracking. But for the level of debugging I'll be
teaching you in this guide, we won't make much use of this window. You have a
lot to learn before this window becomes an asset to you.
CODE WINDOW:
The code window is the window in which you will interact with the running
program. This is the most complex window, and it is where the bulk of
debugging occurs. I'll just go over some keystrokes and a few commands here,
as the majority of learning how to use this window will come when I show you
how to crack a program.
The layout of the window is pretty simple, the group of 8 numbers with the
colon in the middle of them to the far left of the window is the
address:offset of that line of code. Each line of code in this window is an
instruction that the program will issue to the microprocessor, and the
parameters for that instruction. The registers that contain the address for
the current instruction waiting to be executed are the CS:IP registers (code
segment and instruction pointer).
You will also notice a group of hex numbers to the right of the addresses,
this group of numbers is the hexadecimal equivalent of the mnemonic
instructions (pronounced new-mon-ik). The next group of words and numbers to
the right of the hex numbers are the mnemonic instructions themselves.
HOTKEYS AND COMMANDS:
Now we'll move onto the HOTKEYS. I won't go into all of them, only the most
useful ones, same for the commands.
The RESTORE USER SCREEN KEY: This key will toggle the display between the
debugger and the program you are debugging without actually returning control
to the program itself. it's useful to check what the program is doing from
time to time, especially after stepping over a CALL.
The HERE KEY: This key is the non-sticky breakpoint key. To use it, Place the
cursor on a line of code and hit it. The program will then run until it
reaches that line. When (and if) the program reaches that line, program
execution will halt, control will be returned to the debugger and the
breakpoint will be removed.
The TRACE KEY: This key will execute one line of code at a time and will trace
into all calls loops and interrupts.
The BREAKPOINT KEY: This is the sticky breakpoint key. This will enable a
permanent (sticky) breakpoint on the line of code that the cursor is on. When
a sticky breakpoint is enabled, program execution will halt and control will
be returned to the debugger every time that line of code is encountered within
the running program until you manually remove it.
The SINGLE STEP KEY: The most used key on the keyboard. This key will execute
one line of code at a time but will not trace into calls loops or interrupts.
When you step over a call interrupt or loop with this key, all the code
contained within the sub-routine is executed before control is returned to the
debugger. If the program never returns from the sub-routine, you will lose
control and the program will execute as normal.
The RUN KEY: This key will return control to the program being debugged and
allow it to execute as normal. Control will not be returned to the debugger
unless a breakpoint that you've set is encountered.
Now for a few commands. The GO TO command functions like the HERE key in that
it will insert a non-sticky breakpoint at the specified address.
When you enter this command the debugger will return control to the program
until the line of code you specified in the GO TO command is reached. When
(and if) the CS:IP registers equal the address you typed in, the program will
halt, control will be returned to the debugger and the breakpoint will be
removed.
You might be wondering why you would want to type all this in when you can
just hit the HERE KEY instead. The answer is this; the HERE KEY is great if
you want to set a local breakpoint. By a local breakpoint I mean that the
breakpoint you want to set is somewhat close to your current location in the
program.
But what if you want to set a breakpoint on a line of code that isn't in the
current code segment? You wouldn't want to use the HERE KEY cause the address
is no where near the point you are at in the program. This, among other uses
is where the GO TO command comes in.
The ASSEMBLE command is the command you will use to re-write the programs
instructions. This command will allow you to assemble new instructions
beginning at the address you type in, or at the current CS:IP. The
instructions you enter will replace (in memory only) the existing program code
at the address you specified. This is another method you will use to alter the
running program to behave as you wish and not as the programmer intended it
to.
EXAMPLE: Lets say that there is a line of code that reads JNZ 04FC, and we
want to change it to read JMP 04FC. You would issue the ASSEMBLE command and
specify the address of the code you wish to change, then type in JMP 04FC.
Now the line of code in the code window who's address you specified in the
ASSEMBLE command will be overwritten with the code you typed in. Some
debuggers automatically default to the address contained in the CS:IP for this
command.
There are a whole host of other commands available in this window depending on
what debugger you are using, including commands to set breakpoints on
interrupts, memory locations, commands that list and clear breakpoints,
commands to un-assemble instructions etc etc...
Well, that's pretty much it on debuggers without going into explicit
instructions for specific debuggers. The only other thing I can tell you is
that the more you use it, the easier it'll get. Don't expect to become
familiar with it right away. As with anything, practice makes perfect. It's
taken me 5 years and thousands of hours of debugging to reach the level I'm at
now. And I still learn something new, or re-learn something I forgot on just
about every program I crack.
No comments:
Post a Comment