textfiles/piracy/CRACKING/howto2.txt

              HOW TO CRACK, A TUTORIAL - LESSON 2
                 by +ORC (the old red cracker)

How to crack, an approach                         LESSON 1
-> How to crack, tools and tricks of the trade    LESSON 2
How to crack, hands on, paper protections         LESSON 3 (1-2)
How to crack, hands on, time limits               LESSON 4
How to crack, hands on, disk-CDrom access         LESSON 5
How to crack, funny tricks                        LESSON 6 (1-2)
How to crack, intuition and luck                  LESSON 7
How to crack windows, an approach                 LESSON 8
How to crack windows, tools of the trade          LESSON 9
How to crack, advanced cracking                   LESSON A (1-2)
How to crack, zen-cracking                        LESSON B
How to crack, cracking as an art                  LESSON C
How to crack                                      INDEX

LESSON 2- How to crack, tools and tricks of the trade       

LOST IN THE DARK CODEWOODS
     When you break into a program you end up in portions of code
that are unfamiliar to you. It is also not uncommon for the
breakpoints to occur outside of the confines of the program you
want to crack. Getting your bearings is, in these cases, very
important.
     One of the handiest utilities is the memory dump tool -it
tells you where all the device drivers and TSR are loaded, in
which memory locations the program you are cracking dwells, how
much memory is left and what the next program load point is. The
tools you use should report on the following:
-    the contents of interrupt vectors
-    the state of the BIOS data area, beginning at address 40:0
-    internal structures within DOS, such as the MCB chain, the
     SFT (System File Table) chain, the chain of installed
     device drivers, the PSPs and memory allocations associated
     with installed TSRs
-    memory allocation statistic from XMS and EMS drivers

     When seeking to understand a section of foreign code, you
must be especially careful to seek the real intent of the code.
Consider using a profiler prior to undertaking an analysis of an
unfamiliar program. This will help you by ensuring that you don't
waste time studying sections of the program that aren't even
involved in the protection scheme you are chasing down.
     Using a utility that charts a program's calling hierarchy
can give you an important perspective on how your babe conducts
its internal operations.

YOUR DEBUGGER: YOUR FAVOURITE TOOL
     First and foremost, your debugger must be designed for use
with resident modules (or must be itself a resident module).
Trying to crack with simplistic [debug.com] is a sure way to get
absolutely nowhere. We recommend Softice.exe from Nu-Mega
technologies (Version 2.6 [S-Ice.exe] has been cracked by MARQUIS
DE SOIREE and its vastly available on the Web). You could also
use [Periscope] or [Codeview] or Borland's Turbodebugger... all
these programs have been boldly cracked and/or distributed and
are now on the Web for free... learn how to use YAHOO and find
them. In emergency cases you could fix some quick cracking
patches using [debug] or [symdeb], but, as said above, most of
the time these older debuggers won't do. I'll nevertheless ALWAYS
give the final crack procedure for [debug.com], in order to
permit even idiots to crack their programs (altruistic, isn't
it... besides, every wizard has started with debug.com).
     When you first smell a protection, it can be tempting to
immediately begin your crack using invasive types of techniques.
While there is certainly nothing wrong with this approach,
provided that you are fairly familiar with the protection scheme
used, going in too deep too soon can be a problem when you don't
have a strong hunch. Most of the time you'll end up missing
important details. So first of all sit down and ponder... that's
the zen-way, the only one that really works.
     Single-stepping is expensive, not only because of the time
it requires but also because of the amount of detail with which
you must contend. Your immediate goal is to home in on the
protection scheme through a series of successively refined traps,
your broader aim is to get an overview idea of the program's
action... the wise use of breakpoints will condense these
minutiae into an understandable form.
     The first step is to try to identify the section of the
program where the protection scheme is snapping.
     Once you are able to isolate a certain section of a program,
breakpoints can be used to gather a trace history of the
program's execution. If your debugger sports a backtrace buffer,
logging window, or similar feature, by all means learn how to use
it. The debugger it's your best weapon, you must know all the
possibilities it offers and all the capabilities it possesses.
Having a debugger's display output echoed to a printer is another
possibility.
     Using breakpoints is beneficial for two basic reasons: speed
and reduction of detail. Manual single-stepping is invaluable
when you are close to the protection scheme, but too much of it
will bore you to death.
     When selecting breakpoint locations and the types of
breakpoint to use, it is important to step back once more, drink
a cool Martini-Wodka (use only Moskovskaja: non-russian Wodkas
are appalling) and ask yourself: "What is this going to tell me?"
and "What else will I need to know once the break occurs?". MOST
IMPORTANT OF ALL: "Is my current cracking approach the simplest
and most direct?", coz you do not want to waste precious cracking
time.
     When devising a set of breakpoints it is wise to consider
how "a trail of bread crumbs" can be left. Not allowing for an
execution chronicle from the start can mean having to restart a
cracking session.
     Setting breakpoints on certain software interrupt calls is
an excellent way to get an overview of a program's operations.
The INT_21 DOS services interrupt is probably the most universal
useful of these, with BIOS interrupts such as the INT_13 (BIOS
Disk services) and INT_16 (BIOS keyboard services) useful for
specific cracking.
     When working with a debugger, evaluative breakpoints are
usually your best shot. To avoid having to deal with a plethora
of calls, you would want to have a debugger capable of being told
to "break on any INT_21 call except where AH == 2C or AH == 0B".
     A real understanding of the working of a program is surely
important, but don't overdo it! To reverse-engineer even a small
program can involve many hours of analysis and documentation
work. If you'll not be able to use the zen-cracking techniques
described in this tutorial (sadly not everybody can) pace
yourself and make sure your chair is comfortable: you'll be
sitting for quite a spell.
     Much of the work involved in reverse-engineering consist of
chasing down tentacles. In order to understand the operations of
one function, you must understand what happens within each of the
functions it calls- its child functions. To understand these
child functions you must study their children; and so on down the
calling hierarchy tree. Then there is the data. Tracing tentacles
based on a program's calling hierarchy is a directed process.
Each function you encounter is basically a list of other
functions you must reckon with. When it comes to analyzing a
function's interrelationship with the program's data structure,
no such list is provided. You must have instinct, feeling and
luck.
     Data analysis requires more of a broad-based inquisition.
For each memory variable you are interested in, you must survey
all functions to determine which ones read and write that
variable. The use of memory conditional breakpoints and of a
disassembler that builds a cross-reference table can make this
task a lot easier. (Use Sourcer! It's a fairly good tool and
version 4.08 of [sr.exe] has been long ago cracked by me, +ORC,
and distributed on the Web).

ALL SYSTEM CALLS IN ONE LOCATION
     Remember that if the program you are cracking was written
in assembler in the first place (very unlikely knowing the
laziness of to_days programmers), it is probable that system
calls are made directly from the functions which need them. But
when a program is developed in a high-level language, it is more
likely that common library functions will be used for many
operations involving system calls. When a program makes all of
its INT_21 calls from the same location, you know that this is
certainly the case.
     Now, what happens sometimes is that the programmers write
the whole application in a overbloated language like C++, but are
afterwards compelled to "speed up" critical sections of the code
writing them in assembler. And loo! A section where you
repeatedly find assembler crafted patches is precisely the
section containing the protection scheme! So you could have a
program with all INT_21 calls from the same location but for one
or two calls which are coming out of the section where the morons
have "hidden" their protection strategy. By just "looking" at the
dead code of a program, you should be capable to tell wich parts
have been "added on" in a later phase. They presents themselves
as unevenness and irregularities, especially if you use an
utility that represents graphicallly the code of a program.
Protections are often added on at the end.
     Should you determine that the system calls relevant to your
cracking are made from common library functions, all is not lost.
The specific function from which these library calls were made,
the function you are seeking to locate, is executing at some
point in between these calls. Break in with your debugger at the
end of the first system call, just where it is returning to the
point of call. From there, trace through the remainder of the
common library routine until it returns to its caller. In short
order, you should find yourself in the function you need to see.
The trick is to be able to identify it for what it is.

ASCIIZ IN CODE
     In the interest of gaining an overall familiarity with the
program you want to crack, it can be enlightening to use a hex
dump utility to examine the message strings contained within the
program's binary modules. If the program happens to load its
message strings from separate files, your search has just been
simplified.
     Your debugger's memory-dumping feature is one tool that can
be useful for this type of exploration. You could also construct
a filtering program, which would read a binary file and output
all sequences of bytes that are comprised of displayable
characters and are over a certain minimum length (the best
cracker tools are often the ones you write yourself).
     When a protection scheme is marked by the issuance of a
specific message on the screen, you could go into the program and
locate the code that emits this message, and then determine what
triggers it. A good way to start the location process is to see
if a system call is used to display the string. Interrupt INT_21,
INT_10 or INT_29 are usually used to display text messages to the
console.
     When the message's display is not a result of one of these
system calls, direct video writing is probably being used. If you
know the screen location used, and if that part of video memory
is not used for anything else at the time (a big if), a memory
write breakpoint could be set on the video buffer address
corresponding to the first character's position. If this won't
work, use the step-over/step-around tracing technique while
watching for the message to appear.
     Now you found it: from a disassembled listing, you could
locate the address of the message string and then survey the
reminder of the file for any instructions that reference this
address. [Sourcer.exe] can generate labels for specific memory
locations and then generate a cross-reference table showing where
these labelled locations are referenced. Otherwise, load the
disassembled listing file into your editor and use its search
capabilities. Manually searching for such things in a listing
will make you old before your time.

CODE AND DATA
     When stepping through code at the assembler level, watch out
for interrupt calls that are followed by data. Sometimes you will
find an interrupt call, typically within the range INT_34 to
INT_3F, where several bytes immediately following the interrupt
instruction will be data rather than code.
     Be especially suspicious of this type of code-and-data
mixture when your debugger's disassembly output of the
instructions immediately following an interrupt call doesn't make
sense. Sometimes you  can determine the offset of the next true
instruction by inspecting the following code and data. In other
cases, you will have to trace through the interrupt call to see
how it accesses the data following the interrupt call instruction
and how it manipulates the return address on the stack.

HOOKED VECTORS
     Seeing what interrupt intercepts already exist within a
system before running the program you want to crack, as well as
what interrupt handlers are established by the target program,
can provide useful clues. For example, if a protection
establishes an INT_09 intercept just before the snapping of a
keyboard verification routine, your range of suspects has just
been narrowed significantly.
     To study the interrupt vector activities of an application,
a vector dump map utility is useless. It can't be run while the
application you want to crack is running. One solution is to run
the program under a debugger and watch for system calls to INT_21
functions 25h (set interrupt vector) and 35h (get interrupt
vector), but in the event that the program  reads and writes
interrupt vectors directly, this method will not give you a
complete picture. Normally you'll use a spy (trace) utility.
     APPLYING A MEMORY WRITE BREAKPOINT TO A SPECIFIC VECTOR OR
TO THE ENTIRE TABLE is another way to deal with this.
     Note that some sort of direct vector writing must be
occurring if a vector change is detected between system calls.
     If a vector change is detected during a system call but it
isn't function 25h of INT_21, suspect that an IRQ handler may be
effecting the change.

LITTLE TRICKS OF THE TRADE: determining interrupt vector
addresses
     How do you determine the interrupt vector addresses? As
example let's find the address of the INT_21 interrupt vector.
Since the interrupt vector table starts at address 0000:0000
(easy to remember, isn't it?) and there are four bytes per
vector, the basic process is to multiply the interrupt number
four times and use the result at the offset with a segment of
zero.
x21h + x21h = x42
x42h + x42h = x84
The int_21 vector is located at address 0000:0084
You could also use a calculator, for instance, the address of
INT_63 is x63*4=x18c = 0000:018C 
     
LITTLE TRICKS OF THE TRADE: address conversion 
     After a painstaking cracking session, you have finally
determined that a byte of memory at address 6049:891C is the
trigger. But when you isolate the offending instruction, you find
that the address it is generating when the protection occur is
different, being 6109:7D1C instead! How can this be?
     An 80x86 type CPU, when running in real or VM86 mode, uses
what is known as segment:offset type addressing. One side effect
of this addressing method is that one physical address can be
equivalent to many different segment:offset addresses.
     To find the PHYSICAL ADDRESS for a given segment:offset do
the following:
- convert the segment portion of the address to a 1-based number
by multiplying it by 16 (x10)... it's easy: add 0 at the right
end of the number!... 
     6049 -> 60490
     6109 -> 61090
now all you have to do is to add this value to the offset value
     60490+891C  -> 68DAC     
     61090+7D1C  -> 68DAC
Got it?
And the other way round? If you have a physical address, say
19AC3, and you want to obtain a segment:offset address you must
first of all decide in which segment you want the address... if,
say, you choose segment 16CC, you proceed as follows:
     16CC           -> 16CC0
     19AC3-16CC0    =  2E03 (offset)
     address for 19AC3 in segment 16CC = 16CC:2E03

TOOLS OF THE TRADE
[MEMSCAN.EXE]
     One of the most fascinating tools that I have ever seen is
a (very old) program: MEMSCAN.EXE.
This program was originally written in 1988 by Scott A. Mebust,
running in CGA. It's a "visual" utility: it enables you to see
graphically the 1-meg of PC memory in 8 kbyte chunks. It's a
powerful tool in order to locate quickly bit mapped graphics and
other 'objects' in memory, like program data tables, stack areas,
code areas, available RAM, etc. I used this great idea to create
(in C) my own tools: a "dead_programs scanner" and an ameliorate
version of Memscan itself. Looking at the VISUAL STRUCTURE of a
program it's a great help when you'll crack higher levels.

[TRACKMEM.COM]
     A very good tool by James W.Birdsall, tracks memory usage
of programs (EMS, XMS, conventional).

[SCANCODE.COM]
     "THE" scancode lister, by the code_masters from clockwork
software. The must utility for crackers that do not learn all
scancodes by heart.

[MAP.EXE]
     Actually "MAP2", THE memory mapper from the code_masters at
clockwork software. It's a very good tool and an interesting one
too, coz you get it with the "Nigel" nag screens. They are not
difficult to remove (a "passletter" protection scheme, you'll
learn how to find and remove it from [Map.exe] in LESSON 3.2).

[FILEDUMP.COM] [HEXDUMP.COM] [TDUMP.EXE] [DUMP.EXE]
     There are hundred of file dump utilities, coz file dumping
is one of the first exercise they learn you at C-school.
Hexdump.com is 558 bytes long, Tdump.exe 120.704, pick the one
you like better or write your own (even better). Filedump.com,
by Daniel M.O'Brien, 1046 bytes long, it's nice.

[SPRAY.COM]
     That's a good crack utility indeed! This 1989 program by
Daniel M.O'Brien gives you a "post-mortem" picture of your
memory. You redirect it to <myfile> and study it at ease. It's
difficult to say how many hours of cracking it did spare me (you
should study the program, only 252 bytes long, and will have to
modify it a bit, coz it's pretty primitive, in the original
version, for instance, the redirection to the printer works only
if there is NO SPACE between "spray" and ">").

[VEXE.EXE]
     A good EXE files analyzer, useful for windows programs too
(see --> LESSON 7). Some of its functions are present in
TDUMP.EXE too. This 1991 program by S.Krupa it's sometimes very
useful.

[SNOOP UTILITIES --> KGB.EXE INTMON.EXE INTRSPY.EXE etc...]
[TRACE UTILITIES --> TRACE.EXE STEPDOS.EXE etc...]
     A must to study the "calling hierarchy" of an unknown
program. KGB.EXE, a 1992 program by Petr Hor k could be the best
one. I'll teach you how to crack without any of them (you do not
need them if you zen-crack), but they can nevertheless be very
useful in some situations. Stepdos.exe is a excellent program:
a pleasure to crack in order to use it for slightly different
purposes :=)
      
[SOURCERING UTILITIES]
     SR.EXE can be used for sourcering unknown programs. It's a
fairly good sourcering tool. Version 4.08 has been long ago
cracked by me (it's a "ORIGINAL NUMBERCODE" protected program)
and distributed on the Web, so you should easily find it. This
said, you should NEVER use such a brute force approach, unless
you are really desperate: I'll teach you how to crack without
sourcering (you don't need to sourcer if you zen-crack). 
 
[HEXEDITORS]
Every idiot has written at least one hexeditor, and you can find
very bad tools everywhere (the SIMTEL collection, on the Web,
lists at least 35 hexeditors). I suggest you write your own and
contribute to the flood, or (better) get PSEDIT.EXE, a good 1990
program by Gary C. Crider (Parity Solutions, 1903 Pavia Ct.
Arlington, TX 76006... sometimes even americans can write good
programs). If you do use it (as you should) disapt the nag screen
as small exercise in cracking.

[DEBUGGER]
     Your best friend in cracking, your weapon, your hidecloak...
I suggest [Softice.exe] from Nu-Mega technologies (Version 2.6
has been cracked by MARQUIS DE SOIREE and its vastly available
on the Web). You could also use [Periscope] or [Codeview] or
Borland's Turbodebugger... all these programs have been boldly
cracked and/or distributed and are now on the Web for free...
learn how to use YAHOO and find them. It's the only tool you 'll
REALLY need, believe me. So choose wisely and learn how to use
backtrace ranges and breakpoint on user written qualifications
routines. You 'll be able to crack almost EVERYTHING using these
features in the right way. 

     You should get all the programs mentioned above (and more)
for free on the Web. Use them, but also modify them recklessly!
REMEMBER THAT YOU ARE (GOING TO BE) A CRACKER! The first programs
you should crack and modify are therefore your very tools! So
steal the code of the best tools you find! Snatch the best
routines and change them for the better! That's the whole point
in cracking: a mission to IMPROVE the best accomplishments of
humanity's genius :).

HOW TO CRACK, ZEN-CRACKING
     You 'll learn, beginning with next lesson, how to crack
systematically the different protection schemes: paper & password
protections, time protections, access protections. At the end of
the "methodolocical" part, you'll be able to deprotect programs,
but you will still not be a cracker. In order to crack in a real
effective way you must use what I call (lacking a better
definition) "zen-cracking". I 'll give you right now an example
of this, so that you know what I'm talking about, but -unless you
are already capable- you'll have to finish the tutorial for
"normal" cracking before attempting this techniques. Let's zen-
crack together a password protection scheme (aka "paper
protection", coz you need the original manual of the program in
order to answer). This one is based on the typing, at the nag
screen, of the correct sequence of numbers. We are using as
example a game for the reasons explained in lesson 1, but you 'll
find the SAME protection scheme in the access protection
procedure of the old Tapestry networks... so do not frown upon
games protections.

INDIANAPOLIS 500, Papyrus software & Electronic Arts, 1989
It's a rather widespread program, so you should be able to find
it pretty easily. The nag screen asks for data based on the
historical performances of race cars... that means that the
answers will consist in two to three digits. 
     Now, the normal way to crack such a program will be
described in lesson 3.1 and embodyes following steps:
-    snap save program memory areas before typing your answer
-    snap compare after typing, say, "666"
-    search for the sequence 36,36,36 (i.e. 666)
-    breakpoint on memory range for reading
-    look at the program part fetching your data
-    find the snap procedure
-    disable it.
     The above it's a relatively quick crack, and most of the
time 'll be fairly effective, but there is a better way: the "zen
way", the only one that can really bring you to crack peculiar
protection schemes.
-    Run the program and break in at the nag screen
-    Answer consist of 2-3 digits? Search for "AC" (i.e. the
instruction LODSB, load digit of answer in AL) in the area 500
bytes BEFORE and 500 bytes AFTER your position. You'll get some
locations. (In the case of INDY 500 you get 6 such locations).
-    "feel" the locations (that's the tricky part).
-    OK, you already made it! Here is the protection strategy:
  8BBF28A5     MOV  DI,[BX+A528]<-- DI points to coded data area
:compare_loop
  AC      LODSB          <-- load first digit of answer in AL
  B4FF    MOV  AH,FF     <-- load mask in AH
  2A25    SUB  AH,[DI]   <-- sub coded data from mask and get
                         real answer
  47      INC  DI        <-- ready to get next coded data
  3AC4    CMP  AL,AH     <-- user answer = real answer ?
  751A    JNZ  bagger_off_you_do_not_know_the_right_answer
  0AC0    OR   AL,AL     <-- more numbers?
  75F2    JNZ  compare_loop
  59      POP  CX        <-- nice guy, you may go on
  ...
And if the protection scheme had been more far away? And if you
cannot "feel" the right one? And if my grandma had wheels? You'll
learn it, believe me.
Now let's quickly crack this crap.