307 lines
17 KiB
Plaintext
307 lines
17 KiB
Plaintext
|
|
HOW TO CRACK, A TUTORIAL - LESSON 1
|
|
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 1 - HOW TO CRACK, AN APPROACH
|
|
|
|
The best way to learn cracking (i.e. understanding, broadly
|
|
individuating, locating exactly and eliminating or suspending or
|
|
deferring one or more protection schemes inside a software
|
|
application you do not possess the source code of) is to begin
|
|
your tampering experiments using OLDER applications which have
|
|
OLDER protection schemes.
|
|
In this way you 'll quickly grasp the base techniques of the
|
|
trade. Do not forget that the evolution of the protection schemes
|
|
has not been a one way road... strictly speaking it's not even
|
|
an evolution: you'll eventually find some very clever new tricks,
|
|
but most of the time you 'll unearth only various trite
|
|
repetitions of past (and well known) tricks. This is no wonder:
|
|
the REAL knowledge of the "commercial" programmers themselves
|
|
(the "protectionists") is often very limited indeed: they are
|
|
inclined to use the old methods (albeit somehow changed,
|
|
sometimes even improved) instead of conceiving new methods. This
|
|
typical "commercial" degeneration happens every time people act
|
|
for money instead of doing things for the sake of it or for
|
|
pleasure. This "commercial" trend is blindly encouraged by the
|
|
stupid, money-oriented society we are coerced to live in.
|
|
So I'll begin the "hands on" part (-> starting from lesson
|
|
3), using as examples, some "old" applications and some "old"
|
|
tricks. We'll be able to come later over to the newest protection
|
|
schemes in order to understand them, and you 'll learn how to
|
|
defeat this kind of junk too. I'll also explain WHERE you can
|
|
find a lot of programs to crack for next to no money at all, and
|
|
HOW 'grossomodo', you should proceed in your work.
|
|
|
|
The applications you'll use to learn with can be divided into:
|
|
1 - Password crippled applications (the easiest to crack)
|
|
2 - applications crippled on how many times, or how many
|
|
days, you use them (fairly easy to crack)
|
|
3 - applications crippled on which date you use them before
|
|
(easy to crack)
|
|
4 - applications that have some functions present but
|
|
disabled (sometimes easy, sometimes difficoult)
|
|
5 - applications crippled on Disk access (protections schemes
|
|
that are now defined as "obsolete") and apps crippled on
|
|
CD-ROM presence (more or less the same methodes, but -
|
|
somehow- not defined as "obsolete") (vey easy to crack)
|
|
6 - CRYPTOGRAFED ADDS ON (i.e. one of the previous protection
|
|
schemes, but with some scrambled or self modifying code
|
|
(XORring and SHRLing codes) (fairly easy to crack)
|
|
7 - None of the above (sometimes difficoult to crack)
|
|
|
|
WHERE TO GET THE STUFF
|
|
The recent widespread appearance of "Demo"-CDROM on magazine
|
|
covers is a treasure for all crackers! Obviously even if they are
|
|
cheap, you should never buy such magazines immediately on their
|
|
release, coz after a short time you 'll get all the copies that
|
|
remain unsold for next to free. The demos on CD-ROMs will permit
|
|
you to gather quickly a lot of applications -old and new- that
|
|
have somehow been crippled (at times with interesting schemes).
|
|
Truly a wonderful world of cracking possibilities! Gee! For next
|
|
to no money you can secure on one CDROM the whole of LOTUS
|
|
applications (or Microsoft or Wordperfect, or you name them) on
|
|
"trial for 30 days" or "try it 20 times" editions. You'll really
|
|
enjoy to crack them and to use them subsequently for ever and
|
|
ever (and/or graciously donate them on the Web to the poor lamers
|
|
that have no money and no brain).
|
|
GAMES are definitely not to be frowned upon! They are
|
|
extraordinarily interesting from a cracker prospective coz they
|
|
are often "overprotected". With this I mean that they possess
|
|
protection schemes of a relatively HIGH level hidden inside files
|
|
that are not very large. Now, see, it is much more easy, and
|
|
simple to track down and eliminate protection schemes inside a
|
|
single 35.000 bytes long executable file than to locate them
|
|
inside a collection of many lengthy DLLs and overlaids that could
|
|
have swollen as long as 2.000.000 bytes each. The lazy bunch of
|
|
"modern" programmers relies systematically for protection schemes
|
|
on this "hide the sting in the wide desert" logic. As a matter
|
|
of fact they are no longer able to program in assembler: they
|
|
bank more and more on overbloated "fatty" monstrosities like
|
|
Visual Basic, Delphy or Visual C++. (But do not worry... I'll
|
|
nevertheless teach you how to crack -and quickly- those huge apps
|
|
too).
|
|
There is another reason for employing games instead of
|
|
applications as study material: often EXACTLY THE SAME protection
|
|
schemes that you find in a simple (and short) shareware game will
|
|
be used -without much improving- a little later in order to
|
|
"protect" some huge and extremely expensive graphic application.
|
|
For this reason in my tutorial we'll often crack games
|
|
protection schemes, even if we'll later apply what we learn
|
|
mainly in order to crack the protection schemes of commercial
|
|
applications, or to crack the access protection routines to
|
|
remote servers, or BBS, or even ATM (cash dispensers).
|
|
Here follows an example cracking session, that will show you
|
|
-I hope- the dos and donts of our art: let's crack together as
|
|
introductory example a time crippled application. We'll learn
|
|
later (-> LESSON 4) that all applications that are crippled on
|
|
time (i.e. "how many times" you use them or "how long" you use
|
|
them) rely on analogous protection schemes (albeit with a huge
|
|
palette of small variations):
|
|
1- they may have a counter which "clicks" every so often: FIND
|
|
IT AND DISABLE IT!
|
|
2- they may fetch the time_clock interrupts in your machine:
|
|
INTERCEPT THEM YOURSELF!
|
|
3- they may compare a random_seed with a variable: NOOP IT!
|
|
4- they may check randomly the date of your other, unrelated,
|
|
files on the hard disk: find this verification routine and
|
|
INVERT the JUMPS!
|
|
I wanted to start with a modern example of this "counter clicks"
|
|
protection type, just to give you a feeling for cracking, and I
|
|
have chosen a widely published demo: you should be able to find
|
|
it pretty easily. In order to show you some of the problems you
|
|
may encounter we'll crack this example "wrongly" (you'll learn
|
|
how to crack effectively in the "HANDS ON" lessons).
|
|
EXAMPLE: ARCADE POOL, Demonstration version, PC Conversion
|
|
by East Point Software Ltd, (c) Team 17 Software Ltd 1994. This
|
|
demo has been published by many magazines on their CDRom covers
|
|
throughout 1995.
|
|
What follows will be useful even if you do not have our
|
|
example; nevertheless you should get a copy of this widespread
|
|
demo in order to better grasp some of the points that follow.
|
|
This nice demo of a billiard game is time-crippled. It is
|
|
crippled on how long you use it: i.e., you can only play 2
|
|
minutes, afterwards a "nag" reminder of where and how you can buy
|
|
the real version snaps: protectionist squalor at its best.
|
|
So, how do you proceed? Where does the beginning begin?
|
|
Here is what you could (but not necessarily should) do:
|
|
|
|
Get [Soft-ice] and load it in your config.sys. See the TOOLS
|
|
OF THE TRADE lesson (-> LESSON 2) about this debugger. Version
|
|
2.6 of [Soft-Ice] has been cracked by MARQUIS DE SOIREE and can
|
|
be found on the Web for free.
|
|
- vecs s (save all the vectors before loading the babe)
|
|
- start [pooldemo.exe]
|
|
- vecs c (vector compare, save a printing of all hooked
|
|
vectors)
|
|
- enter and leave Soft-ice a few times to understand what's
|
|
going on and where in [pooldemo.exe] are we roaming around
|
|
(you should always check MORE THAN ONCE your findings when
|
|
you snoop around: nothing moves and confuses pointers in a
|
|
more frenzied way than good old "inactive" DOS).
|
|
- have a good look at the map of memory usage ("map")
|
|
- now "snap_save" the main memory regions where
|
|
[pooldemo.exe] dwells... snapping saves "photographyes" of
|
|
memory areas.
|
|
- do not do anything, let just the seconds go by.
|
|
- "snap_compare" every two or three seconds without moving
|
|
anything at all on the game board (no mouse_clicking,
|
|
NOTHING), so that the only changes are (hopefully) the
|
|
changes caused by the time counters.
|
|
- snap_compare twice in a second.
|
|
- snap_compare at second 00:59 and at second 1:01.
|
|
- snap_compare just before and just after the time limit and
|
|
the snapping of the nag screen.
|
|
- Now collect carefully your printed "snaps" data: write
|
|
clearly on the various sheets the occurrences of the snaps.
|
|
- now comes the graceful "zen-cracking" moment: Sit down with
|
|
a dry Martini and Wodka (obviously only russian Wodka will
|
|
do) and contemplate the printing of the various mutant
|
|
locations. Feel, perceive, empathize! Look closely at the
|
|
locations that have changed in the snap compares. Analyse,
|
|
interpretate, evaluate.
|
|
- Mmm! Hey! Something fishy is changing there, and there, and
|
|
there! (you are lucky, few do actually change in this case:
|
|
only two dozen)
|
|
- breakpoint on execute at the location that you believe act
|
|
as a "continuous" counter, i.e. the location that triggers
|
|
the "a second went by" event when it zeroes.
|
|
- Now set the occurrence counter of BPX in order to break at
|
|
the moment where the location "refills" and restarts from
|
|
the beginning (the equivalent of "one second" went by,
|
|
let's start anew). Use the occurrence counter in order not
|
|
to single-step through the program your life long!
|
|
- IN THIS CASE you 'll quickly locate the refill at location
|
|
3DD0. Here follows the "refill" line:
|
|
xxxx:3DCC C706F1013C00 MOV WORD PTR [01F1], 003C
|
|
The "3C" byte at xxxx:3DD0 represents a counter_byte... i.e. the
|
|
program "charges" 3C in this location and then DECs it step by
|
|
step to 3B, 3A, 39, 38 etc... till 0. When it reaches 0: bingo!
|
|
Sucker user has lost one second more of his precious two minutes.
|
|
Now, you would get a first wizard level if you searched
|
|
further on for the exact point where you get the "nag screen" in
|
|
order to eliminate the whole witless protection, but you may
|
|
think you got it already and you remember anyway that the first
|
|
principle in cracking is the following: "once you can eliminate
|
|
the effects of a protection, do not look further!"
|
|
Most of the time this is true: you do not always need to
|
|
eliminate a "whole" protection scheme (unless you are just
|
|
studying it for the joy of it). It's normally easier (and
|
|
quicker) to eliminate the "effects" of a given protection scheme.
|
|
Unfortunately this is not true in this case.
|
|
Here you believe that you have already found the way: you
|
|
got the counter that charges the reverse clock that triggers the
|
|
particular protection scheme of [pooldemo.exe]. Now you may think
|
|
that if you could modify the refill_value... say changing "3C"
|
|
to "EE" (Yeah, the maximum would be FF... but it's always good
|
|
practice to avoid such extreme values when cracking) you should
|
|
get four times more playtime for your game... more than enough
|
|
in order to make the protection scheme useless.
|
|
So you change location xxxx:3DD0 from "3C" to "EE". To work
|
|
on bytes you should use a good Hexeditor like PSEDIT (Parity
|
|
solutions, [Psedit.exe], brilliant shareware: see the "tool of
|
|
the trade" section) but you could also work with simpler
|
|
debuggers like [debug] or [symdeb] (-> see lesson 2). If you do,
|
|
remember to work on a "dead" copy of your crippled [*.exe] file,
|
|
i.e.:
|
|
ren POOLDEMO.EXE POOLDEMO.DED
|
|
symdeb POOLDEMO.DED
|
|
-s (cs+0000):0 Lffff C7 06 F1 01 C3 <- this string
|
|
corresponds to the
|
|
refill line).
|
|
cs:3E85 <- symdeb gives you two locations as answer
|
|
cs:3EEA
|
|
-e cs:3E85+4 EE <- refill changed from C3 to EE
|
|
-w
|
|
ren POOLDEMO.DED POOLDEMO.EXE
|
|
Now you run your tampered pooldemo. You think you cracked it, you
|
|
glee with satisfaction... but loo! Nothing at all has changed,
|
|
everything's as lame as before, you still have only 2 minutes
|
|
playtime. How disappointing: how comez it did'nt work?
|
|
Well, for a start you have not been attentive enough! The
|
|
search in debug gave you TWO locations, you moron, and not just
|
|
the one you just tampered with. Check and you 'll see that the
|
|
second location (cs:3EEA) is a MIRROR/CONTROL location (more on
|
|
this later). Some times there exist "double" locations... coz at
|
|
times it's quicker to use a double routine than to use a
|
|
branching if or switch structure... some times the second
|
|
locations do mirror the first ones and correct them on the fly
|
|
if need be.
|
|
So you need to modify this too... you act as said above but
|
|
this time you enter in debug a
|
|
-e cs:3EEA+4 EE
|
|
before writing back the dead file and then renaming it to exe and
|
|
then running it... and loo! Hoow sloow! THERE YOU ARE! Your
|
|
crippled POOLDEMO.EXE is now (sort of) unprotected: You think
|
|
that you can now play the stupid game up to 12 minutes real time,
|
|
even if the protection scheme (and the counter) "believes" that
|
|
it is playing only two minutes.
|
|
So you begin to play, and the seconds look veeery sloow, and
|
|
everything seems OK, but -alas- NO! At screen second 28 you get
|
|
the irritating "two minutes are over" nag screen! Obviously you
|
|
were dead wrong: the program "knows" the time directly from the
|
|
timer... you only modified the stupid counter ON THE SCREEN.
|
|
So it's back to cracking, and now you are angry, and forget
|
|
the quiet ways of the zen-analyse and begin the heavy cracking
|
|
you should reserve -if ever- for really complicated schemes. You
|
|
now start to check the hooked vectors (you did your routinely
|
|
VECS_save before loading pooldemo in [Soft-ice] and your
|
|
VECS_compare afterwards) and you see some findings that you
|
|
believe interesting:
|
|
vecs c
|
|
08 1EFD:84C6 0CD1:17AC <- the clock
|
|
09 1EFD:85EC 136A:069C <- the keyboard
|
|
22 0BCE:02B1 0BCE:017E <- the terminate
|
|
That's more like it -you think. Smack at the beginning: the
|
|
first hooked vector does it! It's good old interrupt_08: the
|
|
timer_clicker!
|
|
Some basics for those of you that do not know anything:
|
|
INT_08 controls indirectly the INT_1C timer interrupt. The 8253
|
|
clock chip generates an IRQ_0 hardware interrupt at a rate of
|
|
18.2 interrupts per second. This gives control to the ISR
|
|
(Interrupt Service Routine) that the INT_08 points to... and this
|
|
should be at 0CD1:17AC, but has been hooked here, by pooldemo,
|
|
to 1EFD:84C6.
|
|
One of the actions taken by the INT_08 ISR within the BIOS
|
|
is to issue a software interrupt call to INT_1C, just in case any
|
|
software modules within the system have established an intercept.
|
|
If no intercepts have been established, the default contents of
|
|
the INT_1C vector point to an iret instruction within the BIOS,
|
|
so that a null action results. (Iret retrieves the three words
|
|
of stack information which were automatically saved when the
|
|
interrupt call began, and uses them to restore execution control
|
|
to the appropriate point).
|
|
Normally a protectionist would intercept INT_1C, coz at
|
|
every ISR from INT_08 the CPU would fetch the contents of the
|
|
corrisponding interrupt vector and make an interrupt style call
|
|
to the code at that address (which should contain the iret at
|
|
address F000:9876 but can contain any trick they could think of).
|
|
So -you think- the protectionist hooked here INT_08 directly
|
|
(a pretty infrequently used protection scheme by the way): What
|
|
now?
|
|
A rather drastic misure would be, in such circumstances, to
|
|
disable the IRQ_0 level timer interrupt, which is controlled by
|
|
bit 0 of the mask register, at address I/O 0021h. The controllers
|
|
have IMRs (Interrupt Mask Registers) which can be used to hide
|
|
or mask specific interrupts. The IMR of the first controller is
|
|
located at port address 21h, while the IMR of the second
|
|
controller is located at port 0a1h. When bit 0 within the mask
|
|
register is set to 1, no further interrupts will be recognized
|
|
for this IRQ level. This unfortunately won't work here, but it's
|
|
an interesting technique per se, so you better learn it anyway,
|
|
just in case you should need it elsewhere:
|
|
|