informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/piracy/CRACKING/howtocrk.txt

9217 lines
292 KiB
Plaintext
Raw Normal View History

Initial commit
2021-04-15 13:31:59 -05:00
HOW TO CRACK, by +ORC, A TUTORIAL
--------------------------------------------------------------
(Htocrk10.txt) Lesson 1: an approach
(Htocrk20.txt) Lesson 2: tools and tricks of the trade
(Htocrk31.txt) Lesson 3.1: hands on, paper protections (1)
(Htocrk32.txt) Lesson 3.2: hands on, paper protections (2)
(Htocrk51.txt) Lesson 5.1: disk & CD-Rom access (basics)
(Htocrk61.txt) Lesson 6.1: funny tricks
(Htocrk81.txt) Lesson 8.1: how to crack Windows, an approach
(Htocrk82.txt) Lesson 8.2: how to crack Windows, a deeper approach
(Htocrk91.txt) Lesson 9.1: how to crack Windows, hands on
(Htocrka1.txt) Lesson A.1: advanced cracking: internet cracking (Unix)
(Htocrkc1.txt) Lesson C.1: how to crack, cracking as an art
(Htocrkc2.txt) Lesson C.2: how to crack, cracking as an art HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 1: an approach
---------------------------------------------------------------------------
[Pooldemo.exe]
--------------------------------------
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.
This tutorial is for people who are getting started with
cracking. Maybe you are just contemplating doing some cracking,
maybe you have tried it with mixed success. If you are here to
get aimed in the right direction, to get off to a good start with
the cracking tricks and procedures, then you have come for the
right reason. I can't promise you'll get what you want, but I'll
do my best. On the other hand, if you have already turned out
some working cracking code in assembler and already cracked many
different protection schemes, then this tutorial is likely to be
on the elementary side for you. (If you want to review a few
basics and have no where else pressing to go, then by all means
stay).
In order to crack successfully you need four basic things:
* A passing knowledge of assembler language (the more you
know, the better and quicker you crack)
* Some intuition
* Some help from more experienced cracker
* A non mercantile mind (more about this later)
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 difficult)
5 - applications crippled on Disk access (protections schemes
that are now defined as "obsolete") and applications
crippled on
CD-ROM presence (more or less the same methods, but -
somehow- not defined as "obsolete") (very 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 difficult to crack)
WHERE TO GET THE STUFF
The recent widespread appearance of "Demo"-CDROM on magazine
covers is a treasure for all crackers! A short time after their
release 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, to use them 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
very 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
relatively small. 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" atrocities like Visual
Basic, Delphy or Visual C++. (Don't worry... I'll nevertheless
teach you how to crack -and quickly- those huge applications
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 following points.
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 "photographs" 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. Analyze,
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 didn't 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-analyze 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.
Normally a protectionist would intercept INT_1C, coz at
every ISR from INT_08 the CPU would fetch the contents of the
corresponding 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 measure 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. 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:
--- Trick to disable the timer ("IRQ_0 masking" by +ORC) ---
* prompt $t and hit ENTER a few times, see how the dos_clock
is merrily ticking along?
* enter DEBUG.COM
* Assemble using the command 'a'
- a
in al,21
or al,1
out 21,al
ret
RETURN
RETURN <- twice to exit immediate assembler
- g 100 <- to run the tiny program.
- q <- to quit debug.
prompt $t is still on: hit ENTER a few times:
whoa! The clock has stopped advancing!
Compliments: you loaded the current mask register's contents
into AL, you set the mask bit in the bit 0 position (which
corresponds to IRQ_0) at then updated the value back to the mask
register.
When you are ready to activate IRQ_0 events again, reenter DEBUG,
run the following and then reset the clock you stopped with DOS
TIME command:
- a
in al,21
and al,fe
out 21,al
ret
RETURN twice
- g 100
- q
A word of caution: with the timer click disabled some processes
will not operate correctly: once you access the diskette drive,
the motor will continue to run indefinitely afterwards, etcetera.
-------------------------------------------------------
Unfortunately the above technique cannot work with our
[pooldemo.exe], where you now are looking closely to the INT_08
hook you found, believing that it hides the protection scheme:
herein you find immediately the EoI (End_of_interrupt: MOV
AL,20h... OUT 20h,AL). Both controllers have a second port
address at 20h (or 0a0h), from which the instructions are given.
The most important is the EoI command (20h). This instruction
indicates the end of the interrupt handler and frees up the
corresponding controller for the next interrupt. If somebody
writes a new custom interrupt handler (as many protectionists
do), it's up to him to see to it that at the end of the handler
the EoI command (20h) is written to either port 20h or port 0a0h.
After the EoI follow the usual pushes, then some CALLS then
a call that issues some OUT 40,AL that look like timer refreshing
(OUT transfers data to an output port and ports 40-42 correspond
to the Timer/counter). Some do_maintenance follows, then a double
CALL, one more conditional CALL and then a "mysterious" call FAR
CS:[AA91] on which depends a byte PTR[970C] that decides another
final CALL... then the routine pops all registers and irets away.
Ah! You say, and begin disassembling, reverse engineering
and looking inside each suspect call (the quicker method in
these cases is to breakpoint calls on entrance and see if you
find the one that's only called at the awakening of the time
limit protection).
You work, and work, and work... and eventually find nothing
at all, coz the protection of this program is NOT HERE!
Back to the zen-analyze of the snap printings... we forsake
it too soon, as you will see.
If you watch with more attention the compare locations for
the range DS:0 DS:FFFF you 'll notice that one of them changes
relatively slowly from 0 to 1 to 2 to 3 and so on... the
precedent location changes very quickly, and runs the complete
cycle 0...FF. That's a counter, at locations DS:0009 and DS:000A!
How long will it tick along? Well, we saw above that the "charge"
every second is 3C, so it will be x3C*x78=x1C20, coz x78 is 120
seconds, i.e. the two minutes time limit.
Now search this 1C20 value around inside the code
(protections are most of the time at the beginning of the
CS:offset section), and you 'll find quickly what follows:
The protection in [pooldemo.exe] is at code_locations
CS:0A8A 813E20A7201C CMP WORD PTR [A720], 1C20
compare location A720 with limit 1C20
CS:0A90 7C07 JL okay_play_a_little_more
CS:0A92 E834FD CALL beggar_off_time_is_up
BINGO!: FOUND!
Now let's quickly crack it:
------------------------------------------------
CRACKING POOLDEMO.EXE (by +ORC, January 1996)
ren pooldemo.exe pooldemo.ded
symdeb pooldemo.ded
- s cs:0 Lffff 81 3E 20 A7 20 1C
xxxx:yyyy <- this is the answer of the debugger
- e xxxx:yyyy+5 4C <- this time limit is much better
- w
- q
ren pooldemo.ded pooldemo.exe
-------------------------------------------------
We have done here a "weak" crack: we limited ourselves to
accept a (better) time limit, changing it from 1C20 to 4C20 (4
minutes instead of two). We could obviously have done a more
radical crack if we had changed the JL (jump lower) instruction
in a JMP (jump anyway) instruction. In this case it would have
worked, but for reasons that will be explained in lesson 4, you
should choose a rather delicate approach in cracking when you
deal with time-limit protection schemes.
As you have seen, in this artificial cracking session we
found the protection scheme after a little snooping around. But,
as you will see in the hands on part, there are always MANY ways
to crack a single protection scheme. You could -for instance-
have found this protection the other way round: set a trace on
memory range for the program, restricting the trace to the first
part of it (say CS:0 to CS:1000, if you do not fetch anything you
can always try the other blocks). Breakpoint at the nag screen,
have a look at the last 300-400 backtraced instructions, if you
did not move anything, everything will follow a repetitive
pattern, until the protection snaps on:
...
JL 0A99
CMP BYTE PTR [A72A],01
...
JL 0A99
CMP BYTE PTR [A72A],01
...
for ages and ages and then...
...
JL 0A99
E834FD CALL 0759 <- BINGO! (CALL beggar_off_time_is_up)
... there it is, found the other way round. (But this apparently
better method is unfortunately very unstable: it depends on your
timing of the breaking in and on the distance between protection
and nag screen, therefore the somehow more complicated, but more
sure previous one should be favoured).
The reason why "minimal" approaches in cracking are often
more successful than heavy vector_cracking, is that the programs
are hardly ever "overprotected", and therefore the protections
are seldom difficult to find (and those that are really worth
cracking for study reasons).
Sometime you don't even need to crack anything at all! Some
applications are fully functional -per se-, but have been
crippled in a hurry in order to release them as demos. The
commercial programmers want only money, do not even try to
understand our zen ways, and do not care at all for a well done
job. That means, among other things, that the hard disk of the
user will be cluttered with files that the main program module
never calls. A typical example of this sloppy method is the demo
of [Panzer General] from SSI that appeared in the summer '95.
This was in reality no less than the complete beta version of the
game: you just had to substitute to one of the two "allowed"
scenarios one of the 20 or more scenarios of the beta version in
order to play them freely... you didn't ever need to crack!
The pooldemo crack example above should not discourage you
from cracking intuitively. Be careful! Perform a thoroughly
zen_analyze before attempting deeper methods: do remember that
you want to crack the protection scheme SOMEHOW, and not
necessarily following the same line of thought that the
programmer eventually WANTED YOU TO CRACK IT with.
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 2: tools and tricks of the trade
---------------------------------------------------------------------------
[INDY.EXE]
--------------------------------------
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 crack 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 lusers
to crack programs.
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 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), system calls are probably 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
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 of the development.
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 locate
the address of the message string and then survey the reminder
of the file for any instructions that reference this address.
[Sourcer] can generate labels for specific memory locations and
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
running the application you want to crack. 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 or "step"
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 (on segment zero).
21h + 21h = 42h 42h + 42h = 84h
The int_21 vector is located at address 0000:0084
You could also use a calculator, for instance, the address of
INT_63 is 63h*4=18ch -> 0000:018C
* 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
Before starting this section, for those of you that do not know
anything, here is the ARCHIE way you get all the program that do
EXIST on the planet: e-mail following
1) (address) archie@archie.univ-rennes1.fr
I use this french archie, but you can get a worldwide list using
the metacommand "servers"
2) (text) set search sub <- anywhere in string
set maxhits 140 <- (100-1000)
set maxhitspm 15 <- not just 1 file all over
find stepdos <- search e.g. this file
Wait two hours, get your post and ftp the file you wanted (and
YES!, you 'll find also EVERYTHING else for free on the Web).
You could, instead of using archie, also learn how to use YAHOO.
[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<6F>k could easily be
the best one, and comes with source code(!). 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, by Mike Parker, 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 cracked (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 ARCHIE and YAHOO in order to find them. Your
debugger is the only tool you 'll REALLY need, believe me. So
choose your weapon wisely and learn how to use backtrace ranges
and (FOREMOST!) 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 (all the
programs that EXIST for that matter) 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 still wont be a cracker. In order to crack higher 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 this tutorial part 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 protection is based on the typing, at the nag
screen, of the correct sequence of numbers. Our example is a game
for the reasons explained in lesson 1, but you 'll find the SAME
protection scheme in the access protection procedure of some old
Tapestry networks... so do not frown upon games protections.
INDIANAPOLIS 500, Papyrus software & Electronic Arts, 1989
It's a rather widespread program, you should therefore 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 (described in
-> lesson 3.1) 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 crack it's relatively quick and should be most of
the time fairly effective, but there is a better way: the "zen
way", the only one that can really enable you to crack high
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 beggar_off_coz_false_answer
0AC0 OR AL,AL <-- more numbers?
75F2 JNZ compare_loop
59 POP CX <-- all OK, go on, nice guy
...
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.
------------------------------------------------
CRACKING INDY.EXE (by +ORC, January 1996)
ren indy.exe indy.ded
symdeb indy.ded
- s (cs+0000):0 Lffff B4 FF 2A 25 47 3A C4 75 1A
xxxx:yyyy <-- this is the answer of the debugger
- s (cs+1000):0 Lffff B4 FF 2A 25 47 3A C4 75 1A
(nothing, but you must be sure there isn't a mirror)
- e xxxx:yyyy+8 00 <-- "JNZ 1A ahead" changes to "JNZ 0"
- w
- q
ren indy.ded indy.exe
-------------------------------------------------
Cracked: you just changed the JNZ beggar_off instruction in a JNZ
go_ahead_anyway. Nice, isnt'it?
WHY WE CRACK
Strange as it may seem, the reasons for cracking are very
important for the success of our task. We (at least we old
crackers) crack AGAINST society, and OPPOSING laws and
conventions. We usually DO NOT crack for money or for other
"commercial" reasons (just sometimes, and we are expensive: I
have plenty of money already and my services are VERY expensive
if you need an aimed deprotection). But in general we don't care
much for money and -as you can see- I am giving away the basis
of what I know for free with this tutorial. The programs we crack
should be made free for everybody, even if we spent some of our
time deprotecting them. We could not care less of the commercial
value of a given program, not to mention the holy work of the
ethical programmers... we program ourselves, but only because we
LIKE it... if somebody does something only in order to gain
money, he does not deserve anything. It's the mind challenge that
counts, NEVER the profit! (Even if you can make good use of the
cracked programs and even if -as I said- there is at times a
personal profit).
This is an indispensable attitude! Only a non-mercantile
mind can leap forward to the "satori" knowledge that you
desperately need if you want to crack quickly and elegantly huge
iperbloated monstruosities that somebody else wrote and
protected, or if you want to gain access to some hidden
information, data that you would like to snoop but that somebody
declared "off limits", coz a stupid government, or useless
industry sector, or money oriented programmer or dirty lobby of
interest decided it.
If you do accept the society where we are compelled to live,
its awfully egoistic way of life and its dirty "profit" values,
you may eventually learn how to disable some simple protections,
but you'll never be able to crack in the "right" way. You must
learn to despise money, governments, televisions, trends,
opinion-makers, public opinion, newspapers and all this
preposterous, asinine shit if you want to grasp the noble art,
coz in order to be emphatic with the code you must be free from
all trivial and petty conventions, strange as it may sound. So
you better take a good look around you... you'll find plenty of
reasons to hate society and act against it, plenty of sparks to
crackle programs in the right way... Hope all this did not sound
too cretin.
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 3.1: hands on, paper protections (1)
---------------------------------------------------------------------------
[UMS.EXE] [LIGHTSPD.EXE] [GENERAL.EXE]
--------------------------------------
SOME PROBLEMS WITH INTEL's INT
The INT instruction is the source of a great deal of the
flexibility in the PC architecture, because the ability to get
and set interrupt vectors means that system services (included
DOS itself) are infinitely extensible, replaceable and
MONITORABLE. Yet the Int instruction is also remarkably
inflexible in two key ways:
- an interrupt handler DOES NOT KNOW which interrupt number
invoked it.
- the int instruction itself expects an IMMEDIATE operand:
you cannot write MOV AX,x21, and then INT AX; you must
write INT x21.
That would be very good indeed for us cracker... unfortunately
many high level language compilers compile interrupts into PUSHF
and FAR CALL instruction sequences, rather than do an actual INT.
Another method is to PUSH the address of the handler on the stack
and do RETF to it.
Some protection schemes attempt to disguise interrupt calls,
1) camouflaging the code, 2) putting in substitute interrupt
instructions which look harmless and modifying them "on the fly"
or 3) replicating whole interrupt routines inside the code. This
is particularly frequent in the various "disk access" protection
schemes that utilize INT_13 (the "disk" interrupt) and will
therefore be thoroughly explained in -> lesson 5.
A LITTLE BASIC ASSEMBLER
In order to understand the protection schemes and to defeat them,
you must acquire a passing knowledge of assembler, the "machine
language" code. You can find a lot of good, well explained code
for free: viruses are one of the best sources for good "tight and
tricky" assembler code. You can find the source code of almost
all viruses on the web: oddly all the would be hackers seem to
have an aberrant passion for this kind of stuff instead of
studying cracking techniques. But there are millions of lines of
good explained "commercial" assembler code on the net, just fish
it out and study it: the more you know, the better you crack.
I'll restrict myself to some observations, sprinkled throughout
this tutorial. Let's start with some must_know:
------------------------ STRINGS ----------------------------
The string instructions are quite powerful (and play a great role
in password protection scheme). ALL of them have the property
that:
1) The source of data is described by the combination DS:SI
2) The destination of data is described by the combination
ES:DI
3) As part of the operation, the SI and/or DI register(s)
is(are) incremented or decremented so the operation can be
repeated.
------------------------- JUMPS -----------------------------
JZ ero means what it says
JNZ ero means what it says
JG reater means "if the SIGNED difference is positive"
JA bove means "if the UNSIGNED difference is positive"
JL ess means "if the SIGNED difference is negative"
JB elow means "if the UNSIGNED difference is negative"
JC arry assembles the same as JB, it's a matter of
aesthetic choice
CRACKING PASSWORD PROTECTED PROGRAMS
Refer to lesson one in order to understand why we are using
games instead of commercial applications as learn material: they
offer the same protection used by the more "serious" applications
(or BBS & servers) although inside files that are small enough
to be cracked without loosing too much time.
A whole series of programs employ copy protection schemes
based upon the possess of the original manual or instructions.
That's obviously not a very big protection -per se- coz everybody
nowadays has access to a photocopier, but it's bothering enough
to motivate our cracks and -besides- you'll find the same schemes
lurking in many other password protected programs.
Usually, at the beginning of the program, a "nag screen"
requires a word that the user can find somewhere inside the
original manual, something like: "please type in the first word
of line 3 of point 3.3.2". Often, in order to avoid mistakes, the
program indicates the first letter of the password... the user
must therefore only fill the remaining letters.
Some examples, some cracks:
---------------------------------------------------
UMS (Universal Military Simulator) version 1
by Dr Ezra SIDRAN
(c) 1987 Intergalactic Development
European Union: Rainbird Software
United States: Firebird Software
---------------------------------------------------
This very old EGA program is one of the first I cracked in
my youth, and it's very interesting coz it employs a very basilar
protection scheme (a "PRIMITIVE"! More than 80% of the protection
schemes used to day (January 1996) are directly derived from one
of the 12 primitives.
The nag screen snaps at the beginning and keeps indefinitely
asking your answer, only the use of CTRL+C will bring you out of
it, back to DOS. That's a clear sign of older protection schemes:
newer schemes let you in for only 3 attempts or even only one,
and pop out to the OS if you fail. In UMS, besides, there is no
"first letter" aid, a later improvement.
The cracking procedure for password protected programs is,
first of all, to find out where are stored the letters that you
type in. So examine your memory map, find out where the program
dwells in memory, do a snap save of these memory areas and a
series of snap compares as you type your password in.
Strangely enough, in the case of UMS, as you type your
password there seems to be no difference at all in the memory
locations where this program dwells... yet the data must be
somewhere... Usually such a situation is a clear sign that an
hooked interrupt is used to hide the data.
Checking the hooked vectors you find out the following:
vecs 00, 02, 22 are hooked where needs be
vecs 34-3D are hooked at xxxx:0
vec 3E is hooked at xxxx:00CA
Ha! Let's have a closer look at this bizarre 3E hook. Let's
search for some words used in the nag_screen and then let's dump
the area where we find them (in UMS that will be at 3E_hook
address + 7656) and loo! You'll see the content of the nag screen
and, immediately afterwards, ALL the passwords "in extenso", i.e.
not encoded, not scrambled, nothing at all... THERE THEY ARE
(that's a very old protection scheme indeed). You could now, for
instance, easily patch all the different passwords to (for
instance) "PASS", and this would work... it's a very primitive
protection, as we said, nevertheless the use of a hooked vector
as hiding place for the protection code is not yet obsolete...
we'll find it elsewhere, in many "more modern" programs.
Now let's go deeper and examine the "compare" mechanism, we
want to crack, here, not just to patch.
Password protected programs (and access protection routines
for server and BBS, for that matter) have quite a lot of weak
points. The most obvious one (you 'll find out the other when
you'll high crack) is that they MUST compare the password of the
user with the original one(s). So you do not need to steal a
password, you just need to "ear" the echo of the original one in
the memory locations used for the compare, or, and that's more
correct, to crack the compare mechanism itself so as to make it
let you in even with a totally false password.
The compare mechanism of UMS can be found setting a
breakpoint on the memory range that covers the three locations
where the password is stored (and you 'll find these with your
search capabilities and with a pair of snap compares):
ES:0F8E (here you 'll see a copy of the password that the
program is asking)
ES:0F5C (here you 'll see a copy of the password that the user
types in)
INT_3E hook_address + 7656 (here are all the possible passwords
in extenso).
Here is how the protection scheme looks out:
MOV CX,FFFF Charge MAX in CX
REPNZ SCASB Scan ES:DI (the user password)
NOT CX Now CX holds the number of the
character that the user typed in
MOV DI,SI Real password offset to DI
LDS SI,[BP+0A] User password offset in SI
REPZ CMPSB Compares DS:SI with ES:DI (user
password and real password) then snap
out at CX=0 or at char_different,
whichever comes first.
Nice, we found the compare schema... how do we crack it now?
There are many elegant solutions, but let's remain on a basic
level... you look at the code that follows the CMPSB searching
the "snapping schema"... here it is immediately afterwards
(that's the case in most of the primitives). Remember: we sprung
out of the CMPSB check at the first different char, OR at the end
of the count of the user chars. Here it is what follows:
MOV AL,[SI-01] loads in AL the before_different char
of the user password (should be zero)
SUB AL,ES:[DI-01] subs with the before_different char of
the real password (should be zero)
CBW zero flag set, "TRUE", if OK_match
Well let's now look for the next JZ near (it's a "74" code)
CS:IP 740D JZ location no_good
Wait, let's continue a little... is there another check (often
you have a double check on DI)... yes there is!
CS:IP 7590 JNZ location no_good
Cracking such a schema is very easy: you just need to substitute
75 to 74 and 74 to 75: transform your JZ in a JNZ and the JNZ in
a JZ... now you will always pass, no matter what you write,
unless you exactly guess the password!
Now let's quickly crack it:
------------------------------------------------
CRACKING UMS.EXE (by +ORC, January 1996)
ren ums.exe ums.ded
symdeb ums.ded
- s (cs+0000):0 Lffff 74 0D 1E B8 C2 3F
(nothing)
- s (cs+1000):0 Lffff 74 0D 1E B8 C2 3F
(nothing)
- s (cs+2000):0 lffff 74 0D 1E B8 C2 3F
xxxx:yyyy (this is the answer of the debugger)
- e xxxx:yyyy 75
- e xxxx:yyyy+17 74
- w
- q
ren ums.ded ums.exe
-------------------------------------------------
In the debug/symdeb crack above we use as search string the
bytes comprising and following immediately the first JZ.
I know, I know... we saw them in [Soft-ice] and we could have
modified them there, but I'm teaching also pupils who may not
have [Soft-ice].
Note that the program is x431A0 bytes long, and therefore
has a BX=4 sectors adding to the CX=31A0 in the initial
registers... that's the reason I wanted to examine all the
sectors (even if I knew that the snap was in sector (cs+2000):
that's good practice! If you do not find your string in the first
sector you must search for it in the next sectors, till you find
it, coz in many programs there may be MORE THAN ONE repetitions
of the same schema (more about this double check later).
That's it, pupils, that's the way to crack old [UMS.EXE].
Let's go over, now, to more elaborate and more modern password
protection schemes.
--------------------------------------------------------
LIGHTSPEED, from Microprose (we crack here version 461.01)
--------------------------------------------------------
This program, released in 1990, operates a more "modern"
variation of the previous scheme. You 'll find this variation in
many access routines of remote servers (and this makes it very
interesting indeed).
Let's begin as usual, with our hooked vectors examination
and our snap compares.
Hooked vectors: 00, 08, 1B, 22, 23: nothing particular.
The snap_comparisons of the main memory area -as you type the
password in- gives more than six pages of changing locations...
that's clearly much too much to examine.
What now?
Sit down, have a Martini Wodka (I'm afraid that only
Moskovskaja 'll do) and meditate. Get the memory map of the
program's layout. Start anew: snap_save (before typing anything
in). Type as password "ABCDE". Get the print of the snap
compares. Sit down, sip Martini Wodka, relax. You know that the
code for A is x41, for B x42, for C x43 and so on... and in the
snap_compares, that you made between letters, you 'll have only
some locations with these values changing. Focus on these.
You 'll soon enough find out that for LIGHTSPEED absolute
location (in my computer) 404307, i.e.: relative locations (in
my computer) 30BE:F857 or 4043:0007 evoke the characters you
type, i.e. something like
-----------------------------------------------------
F855 F856 F857 F858 F859...
41 3E first_ready_letter your_1st_letter your_2nd_one...
-----------------------------------------------------
Inspecting the same prints, you 'll find out that absolute
location 30C64 (imc) or relative location 30BE:F83E evokes the
LAST character you typed in. The relative code line is:
CS:0097 MOV AX,[BP-08] where SS:F83E = 00+letter_code
Now breakpoint at these locations and investigate what's
going on (for instance, the instruction that follows is
CS:009A MOV [BX], AX
and this means that the code of the letter you just typed in will
be now copied in BX=F85A. What else can you do? Time to use a
little intuition: look for an instruction "CMP AX,000D", which
is the typical "IF the user hits ENTER then" instruction, coz
"x1D" its the ENTER keystroke. This must be somewhere around
here. Ha! You 'll soon enough find the line
CS:0073 3D0D00 CMP AX,000D
And now the way is open to the crack. But YOU DO NOT NEED ALL
THIS! Since the password protection schemes are -as I told you-
all more or less the same, I would suggest that you use first of
all following trick: in the largest part of the program (use
memory map to see where the program dwells) search the "F3A6"
sequence, that's instruction REPZ CMPSB.
In the case of Lightspd you 'll get as answer FOUR addresses
with this instruction: (pgsg=program main segment)
pgsg:C6F9
pgsg:E5CA
pgsg:E63E
pgsg:EAB0
There you are! Only four... have a short look at each of them:
you 'll see that the second one (pgsg:E5CA) is the "good" one.
The compare mechanism in this program of 1990 it's more or less
the same as in 1987'UMS (and do believe me: the same mechanism
is still in use to day (1996)!
B9FFFF MOV CX,FFFF charge Max in CX
F2AE REPNZ SCASB this scans ES:DI (the original
password)
F7D1 NOT CX so many chars in the original pw
2BF9 SUB DI,CX change DI for compare
F3A6 REPZ CMPSB compares DS:SI with ES:DI (real
pw with user pw) then snaps out
at CX=0 or at char_differs
See how easy? They all use the same old tricks the lazy
bastards! Here the section is preceded by a small routine to
lowercase the user password, coz the original muster is always
lowercased.
Now you would like, may be, to breakpoint at one of these
locations, in order to stop the program "in the snap area" and
inspect the snap mechanism... that WILL NOT DO with a "fixed"
breakpoint, coz these locations are called by the snap with a
different segment:offset numeration as the one you found (that's
old dos magic). So you MUST first set a memory_read/write
breakpoint on these locations, and then get at them at the snap.
Now you can find out the segment:offset used by the snap and only
now you'll be able to set a fixed breakpoint (for instance on the
NOT CX instruction).
Now run the program and breakpoint in: have a dump of the
ES:DI and see the original password. How nice! We have now the
original password in extenso in our memory dump window. That's
the "echo". By the way, there is a whole school of cracking
devoted to find and use these echoes... we work on different
paths, nevertheless password fishing can be interesting: where
are the password stored? From which locations do they come from?
A common practice of the protectionists is to hide them in
different files, far away, or in hooked vectors, or in SMC parts.
This is a program of 1990, that differs in respect to UMS: the
passwords are not "hidden" inside a hooked vector, coz that's a
pretty stupid protection: any hexdump utility would still permit
you to see them. Here the passwords are encoded (albeit in a very
primitive manner): looking for them (with memory range
breakpoints) you'll quickly find a section of the program code
that looks like this:
sg:0118 8C 91 9D 95 9B 8D 00 B8 EC 94 9B 8D 8F 8B 9B
sg:0128 94 9B 8D 00 AE EC 9C 9B 8A 9B 86 00 A9 EC 91
This is a typical encoded matrix, with clear 00 fences between
the encoded passwords.
Ha! If all codes where so easy to crack! This is no better than
children's crypt! It's a NEG matrix! And there is direct
correspondence: 91=6F="o"; 92=6E="n"; 93=6D="m" and so on... Ha!
Let's now leave the "hidden" passwords and proceed with our
cracking... let's follow the snap procedure after the REPZ CMPSB
instruction looking for the "jump to OK" instruction...
F3A6 REPZ CMPSB ; compares DS:SI with ES:DI
7405 JZ preserved_AX=0000 <--- Here the first JZ
1BC0 SBB AX,AX
ADFFFF SBB AX,FFFF
:preserved_AX=0000
8BF3 MOV SI,BX
8BFA MOV DI,DX
5D POP BP
CB RETF
....
83C404 ADD SP,+04
0BC0 OR AX,AX
7509 JNZ 0276 <------ And here it is!
Now, remembering the UMS crack, you would probably want to
change the JZ instruction in a JNZ instruction (you tried it on
the fly INSIDE [Soft-Ice] and it did work!), the "74" with a
"75" also. And then you would like to change the JNZ instruction
in a JZ instruction... Please feel free to try it... it will NOT
work! (You will not even find the second JNZ in the program
code). You should always be aware of the SMC (self modifying
code) protections: parts of the code my be decrypted "on the
fly", as needs arise, by the program. The code you modify while
the program is running may be different from the code of the
"dead" program.
Here we have a small "improvement" of the primitive: the
same instruction is used as "muster" for manipulation of other
parts of the program... if you do change it in a JNZ you get an
overlay message and the program pops out with instability! You
cannot easily modify the JNZ instruction either, coz the part
after the RETF will be compiled "on the fly" by lightspeed, and
you would therefore have to search the decryption mechanism and
modify the original encrypted byte somewhere... and may be they
do encrypt it twice... and then you must hack all night long...
very annoying.
So do the following: back to the snap, a sip of martini-
Wodka and meditate: loo! The only thing that happens after the
JZ, is the setting of the AX register to flag *FALSE* (AX=1...
that's what the two SBB instructions do) if the snap went out
with a non-zero flag... i.e. if you did not know the password.
So let's nop the 5 bytes of the two SBB instructions, or, more
elegantly, let's have a INC AX, DEC AX, NOP, INC AX, DEC AX
sequence instead of the two SBB! There is a good reason to use
a sequence of working instructions instead of a series of NOPs:
recent protection schemes "smell" patched nops inside the program
and trash everything if they find more than -say- three
consecutive NOPs! You should always try to choose THE LESS
INTRUSIVE and MORE "CAMOUFLAGED" solution when you crack!
Eliminating the two SBBs we get our crack! No need to bother
with the second JNZ either... the program will work as if you got
the password if you have it AND if you do not (that's better as
the previous type of crack -seen for UMS- when you crack computer
accesses: hereby the legitimate user will not have any suspects
'coz the system will not shut him out... everybody will access:
the good guys and the bad ones... that's nice isn't it?).
Now let's quickly crack LIGHTSPD:
------------------------------------------------
CRACKING LIGHTSPEED.EXE (by +ORC, January 1996)
ren lightspd.exe lightspd.ded
symdeb lightspd.ded
- s (cs+0000):0 Lffff 2B F9 F3 A6 74
xxxx:yyyy (this is the answer of the debugger)
- s (cs+1000):0 Lffff 2B F9 F3 A6 74
(nothing, but do it nonetheless, just to be sure)
- s (cs+2000):0 lffff 2B F9 F3 A6 74
(nothing, just to be sure, now it's enough)
- e xxxx:yyyy+6 40 [SPACE] 48 [SP] 90 [SP] 40 [SP] 48
- w
- q
ren lightspd.ded lightspd.exe
-------------------------------------------------
All this CMPSB is very common. Some programs, nevertheless,
utilize a password protection scheme that is slightly different,
and does not rely on a F3A6 REPZ CMPSB instruction. Let's
analyze, for instance, the protection scheme used in the first
version of Perfect general I from QQP-White wolf, July 1992.
When you break in, at the nag screen, you are in the middle of
the BIOS procedures, coz the program expects your input (your
password, that's is). You 'll quickly find out (MAP MEMORY
USAGE!) that [General.exe] dwells in two main areas; Setting
breakpoints on memory write you 'll find out that the memory area
"queried" by the protection mechanism is
xxxx:1180 to xxxx:11C0
where xxxx represents the second of the memory segments where the
program dwells. Now do the following (a very common cracking
procedure):
* Breakpoint on memory range WRITE for the small memory area
touched by the program in querying you for the password.
* Breakpoint TRACE on the whole memory range of the MAIN
CODE.
* Run anew everything
It's already done! Now it's your intuition that should work a
little: Here the last 9 traces (traces [!], not instructions
following on a line) before the calling of the procedure sniffing
your memory area:
-9 xxxx:0185 7425 JZ somewhere, not taken
-8 xxxx:0187 2D1103 SUB AX,0311
-7 xxxx:018A 7430 JZ somewhere, not taken
-6 xxxx:018C 2DFD04 SUB AX,04FD
-5 xxxx:018F 7443 JZ next_trace, taken
-4 xxxx:01D4 E85500 CALL funny_procedure
-3 xxxx:022C 803E8F8C11 CMP BYTE PTR[8C8F],11
-2 xxxx:0231 750E JNZ somewhere, not taken
-1 xxxx:0233 9A0A0AC33E CALL procedure_that_sniffs
our_memory_area
Well, the call to funny_procedure followed by a byte compare
"feels" fishy from very far away, so let's immediately look at
this part of the code of [General.exe]
:funny_procedure
803E8F8C11 CMP BYTE PTR[8C8F],11
750E JNZ compare_byte
9A0A0AC333 CALL procedure_that_sniffs
0AC0 OR AL,AL
7405 J2 compare_byte
C6068F8C2A MOV BYTE PTR [8C8F],2A
:compare_byte
803E8F8C2A CMP BYTE PTR [8C8F],2A
7504 JNZ after_ret
B001 MOV AL,01
C3 RET
You should be enough crack-able ;=), by this lesson, to notice
immediately the inconsistency of the two successive instructions
MOV 2A and CMP 2A, coz there would be no sense in comparing the
"2A" in order to JNZ to after_ret if you just had the 2A set with
the precedent MOV instruction... but the first JNZ jumps to the
compare WITHOUT putting the "2A" inside. And "2A" is nothing else
as the "*" symbol, commonly used by programmer as "OK"! This
protection works in the following way (this is the above code
explained):
- compare holy_location with 11
- jump non zero to compare holy_loc with "*"
- else call sniffing protection part
- or al,al (al must be zero, else)
- jump zero to compare holy_loc with "*"
- if al was zero mov "*" inside holy_loc
- compare holy_loc with "*"
- if there is a difference then JNZ beggar_off_ugly_copier
- else ret_ahead_nice_buyer
Now let's quickly crack it:
------------------------------------------------
CRACKING GENERAL.EXE (by +ORC, January 1996)
ren general.exe general.ded
symdeb general.ded
- s (cs+0000):0 Lffff 8C 11 75 0E
xxxx:yyyy (this is the answer of the debugger)
- e xxxx:yyyy+2 EB [SPACE] 09
- w
- q
ren general.ded general.exe
-------------------------------------------------
And in this way you changed the JNZ to the cmp "*" instruction
in a JMP to the mov "*" instruction. So no more nag screens, no
more protections... serene, placid, untroubled [general.exe].
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 3.2: hands on, paper protections (2)
---------------------------------------------------------------------------
[TOP.EXE] [F19.EXE] [POPULOUS.EXE] [MAP.EXE]
--------------------------------------
You have seen in the previous lesson that the use of a password
protection, independently of the coding and hiding methods used
to store them in memory, implies the use of a comparing procedure
with the password that the user types in. You therefore have many
options to begin your cracking work:
- find the location of the user password
- find the "echo" in memory of the real password
- find the routine that compares both
- find the passwords hideout and encryption type
- find the go_ahead_nice_buyer exit or jump
- find the beggar_off_ugly_copier exit or jump
just to name the more obvious ones. In order to make things more
difficult for us crackers, the protectionists have devised many
counter-strategies, the more obvious ones being:
- keeping the various part of the store/compare/hide routines
well apart in code (no match for zen-cracking);
- filling these routines with "bogus" compares, bogus jumps
and bogus variables, in order to make things more difficult for
the crack (no match for decent crackers);
- disseminating the code with anti-debugger tricks, like INT_3
instructions or jumps in and out protected mode (no match for our
beloved [Soft-Ice]);
- trying to eliminate the need for passwords altogether
letting the user input "one letter" or "one number" or "one
image" as answer to some variable question. In this lesson I'll
teach you how to crack these "passletters" protection techniques.
Let's first resume the "uses" of a password protection:
PASSWORDS AS PERMISSION TO ACCESS
These passwords serve to acknowledge that a legitimate user is
using the program. This is the type of password that you'll find,
for example, protecting your user account on Compuserve, on
Networks or even in ATM machines used by banks or corporations.
These require a little hardwiring to crack: ATM passnumber
protection schemes rely on an answer from the central computer
(they do NOT verify only the three magnetic areas in the magnetic
strip on the card). The lines between ATM's & their hosts are
usually 'weak' in the sense that the information transmitted on
them is generally not encrypted in any way. (Some banks use
encrypted information, but this is fairly easy to crack too).
So for ATMs you should do the following 1) cross over the
dedicated line between the ATM and the host; 2) insert your
computer between the ATM and the host; 3) Listen to the "normal"
messages and DO NOT INTERFERE YET; 4) Try out some operations
with a legal card, make some mistakes, take note of the various
codes; 5) When you are ready insert a fraudulent card into the
ATM. Now the following happens:
- the ATM sends a signal to the host, saying "Hey! Can I give
this guy money, or is he broke, or is this funny card invalid?";
- the microcomputer intercepts the signal from the host,
discards it, sends on the "there's no one using the ATM" signal;
- the host gets the "no one using" signal and sends back its
"good, keep watching out if somebody comes by, and for God's sake
don't spit out any money on the street!" signal to the ATM;
- the microcomputer intercepts this signal (again), throws it
away (again), and sends the "Wow! That guy is like TOO rich! Give
him as much money as he wants. In fact, he's so loaded, give him
ALL the cash we have! He is a really valued customer." signal.
- the ATM obediently dispenses cash till the cows come home.
All this should be possible, but as a matter of fact it has
not much to do with cracking, unless there is a special software
protection on the line... so if you want to work on ATMs contact
our fellow phreakers/hackers and learn their trade... and
please remember to hack only cash dispenser that DO NOT HAVE a
control camera :=)
PASSWORDS AS REGISTRATION
This type of password is often used in shareware programs. When
you register the shareware program, you are sent a password that
you use to upgrade your shareware program to a complete and more
powerful version. This method, used frequently for commercial
applications, has recently been used quite a lot by many windows
applications that come "crippled" on the magazines cover CD-roms,
requiring you to telephone a hot line (and paying) in order to
get the "unique key" to unlock the "special protection". It's all
bullshit: we'll learn in the "how to crack windows" lessons how
easy it is to disable the various routines that verify your
entry.
PASSWORDS AS COPY PROTECTIONS
This type of password is often used for games and entertainment
software. The password query does not usually appear any more at
the start of the program, or as the program is loading. Instead,
the password query appears after one or more levels are completed
(this innovation was pioneered by "EOB I" and the "Ultima"
series) or when the user reloads a saved game or session.
DONGLE PASSWORDS
A few extremely expensive programs use a dongle (also called
an hardware key). A dongle is a small hardware device containing
a password or checksum which plugs into either a parallel or a
serial port. Some specially designed dongles even include
complete program routines. Dongles can be cracked, but the amount
of work involved is considerable and the trial and error
procedure currently used to crack them via software is extremely
tedious. It took me more than a week to crack MULTITERM,
Luxembourger dongle protected program. The quickest method to
crack dongle protected programs, involves the use of pretty
complicated hardware devices that cannot be dealt with here. I
myself have only seldom seen them, and do not like at all to
crack dongles via software, coz it requires a huge amount of zen
thinking and of luck and of time. If you want more information
on the hardware way to crack dongles, try to contact the older
ones on the appropriate web sites, they may even answer you if
you are nice, humble and really technically interested.
The obvious principle, that applies to the software password
types mentioned above is the following: The better the password
is hidden, and the better it is encrypted, the more secure the
program will be. The password may be
- encrypted and/or
- in a hooked vector and/or
- in an external file and/or
- in a SMC (Self modifying code) part
Let's finally inspect the common "ready_made" protection
schemes (used by many programmers that do not program
themselves):
* password read in
* letters added to a key to be entered
* complement of the letters formed xoring with 255
* saved key (1 char)
* saved password (256 chars)
* saved checksum (1 char), as protection, against simple
manipulations
* generating file PASSWORD.DAT with password, to be inserted
inside a different file than the one containing the calling
routine
Now the lazy programmer that wants to "protect" his program
searches first the file where the password is stored, then loads
the key, the password and the checksum. He uses a decrypt
procedure to decrypt the password and a check_checksum procedure
to check whether the password was modified. All this is obviously
crackabe in few seconds.
[PASSWORD ACCESS INSIDE THE SETUP]
Some computers have a password protected access INSIDE the
Setup (at the beginning), the protection scheme does not allow
a boot with a floppy and does not allow a setup modify. In these
cases the only possible crack is an old hack method:
* open the PC
* find on the motherboard a small jumper (bridge) with the
words "Pw"
* take it away
* PC on
* run the setup with F1 or Del (depending from the BIOS) (the
protection will not work any more)
* deactivate inside the setup the option password
* PC off
* put the small jumper (bridge) back again
* close the PC
* PC on, cracked (if you want to be nasty you could now use
the setup to set YOUR password)
If you want to know more about access refuse and access
denying, encryption and locking of the FAT tables, get from the
web, and study, the (very well written) code of a virus called
"Monkey", that does exactly this kind of devastation. Virus
studying is, in general, very useful for cracking purposes, coz
the virus'code is at times
- very well written (pure, tight assembly)
- using concealing techniques not much different from the
protection schemes (often far superior)
- using the most recent and best SMC (self modifying code)
tricks
But, and this is very important, do not believe that the
protection schemes are very complicated! Most of the time the
protection used are incredibly ordinary: as a final example of
our paper protection schemes, let's take a program released not
long ago (1994), but with a ridiculous protection scheme: TOP
(Tiger on the prowl) a simulation from HPS.
Here the cracking is straightforward:
- MAP(memory_usage) and find main_sector
- type "AAAA" as password
- (s)earch main_sector:0 lffff "AAAA"
- dump L80 "AAAA" location -40 (gives you a "wide" dump),
this gives you already the "echo" of the correct password
- breakpoint on memory read & write to "AAAA" location and
backtrace the complete main_sector
it's done! Here the code_lines that do protect TOP:
8A841C12 MOV AL,[SI+121C] move in AL first user letter
3A840812 CMP AL,[SI+1208] compare with echo
7402 JZ go_ahead_nice_buyer
EB13 JMP beggar_off_ugly_cracker
Now let's quickly crack it:
------------------------------------------------
CRACKING TOP.EXE (by +ORC, January 1996)
ren top.exe top.ded
symdeb top.ded
- s (cs+0000):0 Lffff 8A 84 1C 12 3A 84
xxxx:yyyy (this is the answer of the debugger)
- e xxxx:yyyy+2 08 (instead of 1C)
- w
- q
ren top.ded top.exe
-------------------------------------------------
And you changed the MOV AL, [SI+121C] instruction in a MOV AL,
[SI+1208] instruction... it is now reading the ECHO instead of
the characters you typed in... no wonder that the ECHO does
compare exactly with itself... and you pass!
"SOMETHING FISHY UNDER COVERS"
Back to the "Passletter" type of password protected programs.
Let's take as an example the protection used in a game of 1990:
"F19", where the protection scheme asks you to identify a
particular plane's silhouette. This kind of protection is used
in order to avoid the use of memory locations where the passwords
are stored: we saw in the first part of our "passwords hands on"
how easy it is to crack those schemes.
To crack this kind of protection, you could try a technique know
as "memory snuffing". The protected program, START.EXE, install
itself first at location xxxx:0000 with a length of 6C62 bytes,
but proceeds to a relocation of its modules (with some SMC, self
modifying code parts) in different locations. What does all this
mean? Well, this could mean quite many things... the most
important one for crackers is that the protection code will
probably snap way ahead of the actual user input phase.
Now you 'll quickly find out that the routine determining
(randomly) which plane is being chosen, leaves the progressive
number of this plane in one memory location: (imc) 43CD:DADA.
This brings us to the random triggering mechanism:
E87FAF CALL random_seed
83C402 ADD SP,02
8946E8 MOV [BP-18],AX and ds:(BP-18) is the location
you are looking for
Now, every time this random triggers, you get a different number
(00-x14) in this location, corresponding to the different plane
the user should choose.
The random seed routine, evidently, comes back with the random
seed in AX... what we now need is to zero it: the user will
always have to choose the same plane: "plane 0", and he will have
given the correct answer. Note how elegant all this is: we do not
need to interfere with the whole mouse pointing routines, nor
with the actual choosing of the planes... the random seed may
choose whatever plane it wishes... the memory location for this
choice will always report the (legitimate) choice of zero.
So, let's quickly crack this program:
---------------------------------------------------
CRACKING "F19" [START.EXE] (by +ORC, January 1996)
ren start.exe start.ded <- let's have a dead file
symdeb start.ded <- let's debug it
- s cs:O lffff 83 C4 02 89 46 E8 <- search ADD SP,02
xxxx:yyyy <- debugger's answer
- e xxxx:yyyy 58 [SPACE] 31 [SPACE] C0 [SPACE]
- w <- write the crack
- q <- back to the OS
ren start.ded start.exe <- re-write the exe
----------------------------------------------------
You just transformed the instruction you searched for
83C402 ADD SP,+02
in the following sequence:
58 POP AX <- respecting ADD SP,+02
31C0 XOR AX,AX <- xoring to zero
(the POP AX instruction increments the stack pointer by 2, in
order to respect the previous ADD SP,+02).
Well, nice. It's getting easier, isnt'it? Now let's take as
example a protection that has no "echo" in memory. (At the
beginning this was a smart idea: "the cracker won't find the
correct password, 'coz it's not there, ah!". We'll now therefore
crack one of the first programs that used this scheme:
[Populous.exe], from Bullfrog.
[POPULOUS.EXE]
A old example of the protection scheme "password that is not
a password" can be found in [Populous.exe], from Bullfrog. It's
a very widespread program, and you'll surely be able to find a
copy of it in order to follow this lesson. The program asks for
the identification of a particular "shield", a combination of
letters of various length: the memory location were the user
password is stored is easily found, but there is (apparently) no
"echo" of the correct password. You should be able, by now, to
find by yourself the memory location were the user password is
stored. Set a breakpoint memory read & write on this area, and
you 'll soon come to the following section of code:
F7AE4EFF IMUL WORD PTR [BP+FF4E] <- IMUL with magic_N<5F>
40 INC AX
3B460C CMP AX, [BP+0C]
7509 JNZ beggar_off_ugly_copier
8B460C MOV AX, [BP+0C]
A3822A MOV [2A82], AX
E930FE JMP nice_buyer
817E0C7017CMP WORD PTR[BP+0C],1770 <- beggar_off
I don't think that you need much more now... how do you prefer
to crack this protection scheme? Would you choose to insert a MOV
[BP+0C], AX and three NOPS (=6 bytes) after the IMUL instruction?
Wouldn't you rather prefer the more elegant JMP to nice_buyer
instruction at the place of the JNZ beggar_off? This solution has
less nops: remember that newer protection schemes smell
NOPs_patches!). Yeah, let's do it this way:
---------------------------------------------------
CRACKING [Populous.exe] (by +ORC, January 1996)
ren populous.exe populous.ded <- let's have a dead file
symdeb populous.ded <- let's debug it
- s cs:O lffff F7 AE 4E FF <- the imul magic_N<5F>
xxxx:yyyy <- debugger's answer
- e xxxx:yyyy+4 EB [SPACE] 03 <- JMP anyway
- w <- modify ded
- q <- back to the OS
ren populous.ded populous.exe <- let's re-have the exe
----------------------------------------------------
This time was easy, wasnt'it?
Now you are almost ready with this course... let's crack a
last application, a memory utility that is very widespread, very
good (the programmers at Clockwork software are Codemasters),
very useful for our purposes (you'll use it later to crack a lot
of TSR) and, unfortunately for Clockworkers, very easy to crack
at the level you are now.
But, Hey! Do not forget that you would have never done it without
this tutorial, so do the following: look toward east from your
window, sip a Martini-Wodka (Two blocks of ice first, 1/3 dry
Martini from Martini & Rossi, 1/3 Moskovskaia Wodka, 1/3
Schweppes indian tonic) and say three times: Thank-you +ORC!.
[MAP.EXE]
Let's now go over to one of the best TOOLS for mapping your
memory usage that exist: MAP.EXE (version 2) from the masters at
Clockwork software. The usage of this tool has been recommended
in Lesson 2, and you should learn how to crack it, coz it comes
with an annoying nag-screen ("Nigel" screen). In [Map.exe] this
ubiquitous "Nigel" screen appears at random waiting for a random
amount of time before asking the user to press a key which varies
every time and is also selected at random.
The use of a single letter -mostly encrypted with some XOR
or SHR- as "password" makes the individuation of the relevant
locations using "snap compares" of memory much more difficult.
But the crack technique is here pretty straightforward: just
break in and have a good look around you.
The INT_16 routine for keyboard reading is called just after
the loading of the nag screen. You 'll quickly find the relative
LODSB routine inside a routine that paints on screen the word
"Press" and a box-edge after a given time delay:
B95000 MOV CX,0050
2EFF366601 PUSH CS:[0166]
07 POP ES
AC LODSB
...
You could already eliminate the delay and you could already force
always the same passletter, in order to temperate the effects of
the protection... but we crack deep!: let's do the job and track
back the caller! The previous routine is called from the
following section of the code:
91 XCHG AX,CX
6792 XCHG AX,DX
28939193 SUB [BP+DI+9391],DL
2394AA94 AND DX,[SI+94AA]
2EC7064B880100 MOV WORD PTR CS:[884B],0001
2E803E5C0106 CMP BYTE PTR CS:[015C],06
7416 JZ ret <- Ha! jumping PUSHa & POPa!
505351525756 PUSH the lot
E882F3 CALL 8870
2E3B064B88 CMP AX,CS:[884B]
7307 JAE after RET <- Ha! Not taking the RET!
5E5F5A595B58 POP the lot
C3 RET
... <- some more instructions
E86700 CALL delay_user
BE9195 MOV SI,9591
2E8B3E255C MOV DI,CS:[5C25]
83EF16 SUB DI,+16
2E8A263D01 MOV AH,CS:[013D]
50 PUSH AH
E892C7 CALL routine_LODSB <-- HERE!
B42C MOV AH,2C
CD21 INT 21 <- get seconds in DH
80E60F AND DH,0F
80C641 ADD DH,41
58 POP AX
8AC6 MOV AL,DH
83EF04 SUB DI,+4
AB STOSW
E85A00 CALL INT_16_AH=01
B400 MOV AH,00
CD16 INT 16
24DF AND AL,DF <- code user's letter_answer
3AC6 CMP AL,DH <- pass_compare
75F3 JNZ CALL INT_16_AH=01
E807F3 go_ahead
You just need to look at these instructions to feel it: I
think that unnecessary code segments (in this case protections)
are somehow like little snakes moving under a cover: you cannot
easily say what's exactly going on yet, but you could bet that
there is something fishy going on. Look at the code preceding
your LODSB routine call: you find two JUMPS there: a JZ ret, that
leaves a lot of pusha and popa aside, and a JAE after RET, that
does not take the previous ret. If you did smell something here
you are thoroughly right: The first JZ triggers the NIGEL screen
protection, and the second JAE does THE SAME THING (as usual,
there are always redundances, exactly as there are a lot of
possibilities to disable a single protection). Now you know...
you can disable this protection at different points: the two
easiest blueprints being
1) to change 7416 (JZ ret) in a EB16 (JMP ret anyway)
2) to change 7307 (JAE after ret) in a 7306 (JAE ret).
We have not terminated yet: if you try locating this part
of the code in order to change it, you won't have any luck: it's
a SMC (Self modifying code) part: it is loaded -partly- from
other sections of the code (here without any encryption). You
must therefore first of all set a breakpoint on memory range;
find out the LODSW routine; find out the real area; dump that
memory region; find out a search sequence for the "dead" code...
and finally modify the "dead" program.
Now let's quickly crack it:
------------------------------------------------
CRACKING MEM.EXE (version 2) (by +ORC, January 1996)
ren map.exe map.ded
symdeb map.ded
- s (cs+0000):0 Lffff 74 16 50 53 51 52 57
xxxx:yyyy <- this is the debugger's answer
- e xxxx:yyyy EB
- w
- q
ren map.ded map.exe
-------------------------------------------------
Now you have done it, NIGEL has been cracked!
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 5.1: Disk & CD-Rom access (basics)
---------------------------------------------------------------------------
[MARIO ANDRETTI] [REACH FOR THE SKY] [FS v.2.12]
--------------------------------------
LESSON 5 (1) - HOW TO CRACK, HANDS ON - Disk/CDROM access (plus
bypasses "on the fly")
Somewhere I have to put the bypasses (loader programs) in this
tutorial, allow me to put them here:
Preparing a loader to bypass a protection [MARIO ANDRETTI]
At time the protectionists hook vectors in order to impose
a particular protection. In this (and similar) cases a good
crack-way is to prepare a "loader" program, that "de-hooks" the
vector used for the protection. This kind of crack can be used
also for internet cracking (on some firewall configurations, see
lesson A.2).
As example let's take "Mario andretti racing challenge", a
stupid game that uses the SAME (!) protection scheme you'll still
find to day on some access routines of military servers around
the witlessly called "free" world.
In order to crack this cram you would prepare a loader on the
following lines:
loc code instruction what's going on
-------------------------------------------------------
:0100 EB44 JMP 0146
...
:0142 0000 <- storing for offset of INT_21
:0144 5887 <- storing for segment of INT_21
:0146 FA CLI
:0147 0E PUSH CS
:0148 1F POP DS
:0149 BCB403 MOV SP,03B4
:014C FB STI
:014D 8C1EA901 MOV [01A9],DS <- save DS
:0151 8C1EAD01 MOV [01AD],DS three
:0155 8C1EB101 MOV [01B1],DS times
:0159 B82135 MOV AX,3521 <- get INT_21
:015C CD21 INT 21 in ES:BX
:015E 891E4201 MOV [0142],BX <- store offset
:0162 8C064401 MOV [0144],ES <- store segment
:0166 BA0201 MOV DX,0102
:0169 B82125 MOV AX,2521 <- set INT_21 to
:016C CD21 INT 21 DS:0102
:016E 0E PUSH CS
:016F 07 POP ES <- ES= current CS
:0170 BBB403 MOV BX,03B4
:0173 83C30F ADD BX,+0F
:0176 B104 MOV CL,04
:0178 D3EB SHR BX,CL <- BX= 3C
:017A B8004A MOV AX,4A00 <- Modify memory block
:017D CD21 INT 21 to 3C paragraphs
:017F BA9E01 MOV DX,019E <- ds:dx=program name
:0182 BBA501 MOV BX,01A5 <- es:bx = param. block
:0185 B8004B MOV AX,4B00 <- load ma.com
:0188 CD21 INT 21
:018A 2E8B164201 MOV DX,CS:[0142] <- reset old int_21
:018F 2E8E1E4401 MOV DS,CS:[0144]
:0194 B82125 MOV AX,2521
:0197 CD21 INT 21
:0199 B8004C MOV AX,4C00 <- terminate with return
:019C CD21 INT 21 code
:019E 6D612E636F6D00 "ma.com"
0000 fence
:01A7 B2015887
:01AB B2015887
:O1AF B2015887
0000 fence
let's now prepare a routine that hooks INT_21:
push all
CMP AX,2500 <- go on if INT_21 service 25
JNZ ret
CMP Word Ptr [0065], C00B <- go on if location 65 = C00B
JNZ ret
MOV Byte Ptr [0060], EB <- crack instructions
MOV Byte Ptr [0061], 3C
MOV Byte Ptr [0062], 40 <- INC AX
MOV Byte Ptr [0063], 90 <- NOP
MOV Byte Ptr [0064], 48 <- DEC AX
pop all
JMP FAR CS:[0142] <- JMP previous INT_21
From now on this loader will work every time that a program
with location [0065] containing an 0R AX,AX instruction (0BC0:
it's the case of ma.com) calls INT_21 service 25 (hook a vector),
the target program will be modified on the fly and will get, at
location [0060], the instruction JMP 3C locations ahead, despite
the fact that it has routines capable of self checking in order
to make sure it has not been modified.
The most important thing is the routine that YOU write that
will precede the call to INT_21 (or any other INT) service 25 (or
any other service) in order to crack on the fly the offending
program. I'll show you another one, this one for [Reach for the
skies] (reach.com):
push all
CMP AH,3D <- is it service 3D? (open file)
JNZ ret <- no, so ret
CMP DX,13CE <- you wanna open file at 13CE?
JNZ ret <- no, so ret
MOV AX,[BP+04] <- in this case
MOV DS,AX
CMP Byte Ptr [B6DA],74 <- old instructions
JNZ 015B
CMP Byte Ptr [B6DB],0F <- ditto
JNZ 015B
CMP Byte Ptr [B6DC],80 <- ditto, now we now where we are
JNZ 015B
MOV Byte Ptr [B6DA],EB <- crack
MOV Byte Ptr [B697],40 <- camouflaged no-opping
MOV Byte Ptr [B698],48 <- cam nop
MOV Byte Ptr [B699],90 <- cam nop
MOV Byte Ptr [B69A],40 <- cam nop
MOV Byte Ptr [B69B],48 <- cam nop
MOV DX,CS:[0165]
MOV DS,CS:[0167]
MOV AX,2521 <- set hook
INT 21
POP all
JMP FAR CS:[0165]
Here you did change the instruction 740F in the instruction EB0F,
and you did "noop" the instructions at B697-B69B. (Well, more
elegantly than "noop" them with "90" bytes, you choose a INC AX,
DEC AX, NOP, INC AX, DEC AX sequence instead! There are sound
reasons to use a sequence of "working" instructions instead of
NOPs: recent protection schemes "smell" patched nops inside the
program and trash everything if they find more than -say- three
consecutive NOPs! You should always try to choose THE LESS
INTRUSIVE and MORE "CAMOUFLAGED" solution when you crack!)
You can apply this kind of crack, on the same lines, to many
programs that perform self checking of the code and hook the
vectors.
REAL DISK ACCESS STUFF
Now we may come to the subject of this lesson:
As usual, let's begin from the beginning: history is always
the key that allows an understanding of present and future, in
cracking matters too. As the older 5 1/4 inch big black floppy
disks were still used (the 320K/8 tracks or 360K/9 tracks ones,
that were really "floppy" and have nowadays almost disappeared)
one of the more common methods to protect a program, was to
format the "master" (key) disk in a weird way. Old floppy disk
for the PC did usually store 360K at 9 sectors per track.
Some basics for those of you that do not know anything: in
order to defeat this kind of cracks you need to know two things:
the floppy disk parameter block (FDPB) and the interrupt routines
dealing with format/read disk (basically INT_13).
Most often, the protection scheme is to either format one
or more sectors or tracks with sector sizes other than the
standard 512 bytes, or to either give one of the sectors a wild
sector number like 211 or just not format a whole track of
eight/nine/15 sectors. If you, for instance, have got the same
(very old) copy of VisiCalc master I do, you'll find that sector
8 on track 39 is missing entirely. The interrogation with
assembly or with an "ad hoc" utility (I use the tools I wrote
myself, but you 'll be able to find many such utilities in public
domain, the oldest one, from 1984 (!) being the seasoned [U-ZAP]
an "Ultra utility" from the "Freesoft company") will tell you
which sector numbers were altered, their size in bytes, and if
they were formatted with a CRC error (another not so fancy
trick).
The floppy disk parameters are stored in the BIOS: interrupt
vector 1E contains the address of the floppy disk parameter
block. The FDPB's contents are the following:
Offset Function crackworthy? Example
0 Step rate & head unload no DF
1 head load time no 02
2 Motor on delay no 25
3 Number of bytes per sector yes 02
4 Last sector number yes 12
5 Gap length yes 1B
6 Data track length yes FF
7 Format gap length yes 54
8 Format byte no F6
9 Head settle time no 0F
A Motor start time no 02
0) Offset #0: the left "nybble" (single digit) of this value
is the step rate time for the disk drive head. The right
nybble is the disk head unload time. These values are best
left alone.
1) Offset #1: again, don't fool around with these values. The
left nybble is the disk head load time, and the right
nybble is the direct memory access mode select.
2) Wait time until motor is turned off. Not normally of use.
3) Bytes-per-sector value: AH-HAH! If you place a "0" in this
value, the PC expects all sectors to be 128 bytes long. A
"1" means a sector size of 256 bytes, a "2" means 512
bytes (this is the standard DOS value), and a "3" means
1024 bytes per sector.
4) Highest sector number on a track: this is used for
formatting and tells DOS how many sectors there are on each
track.
5) Gap length for diskette reads: this is what you fool around
with if you keep getting CRC errors when you try to read a
non-standard size sector. Normally, you can just leave this
alone except when formatting with a U-Format tool.
6) Data length: This contains the number of bytes in a sector
when the value in table byte #4 doesn't contain a 0, 1, 2,
or 3.
7) Number of bytes in the gap between sectors: this is also
only used when formatting special tracks.
8) Format fill byte: When formatting, this is the
initialization byte that will be placed in all new sectors.
9) Head settle time: leave this alone.
A) Motor start time: don't fool with this either.
In order to modify globally the number of tracks on a given disk
and the number of sectors per track you can always format with
the DOS command switches "/t:" and "/n:"
FORMAT /t:tracks /n:sectors
If you want to find out what the existing parameters are,
run [Debug.exe] or [Symdeb.exe] and enter the following commands:
- d 0:78 l 4 <- get FDPB address
0000:0070 22 05 00 <- debugger's likely response
- d 0:522 l a <- get 10 FDPB values
0000:520 DF 02 25 02 12 1B FF... <- see preceding table
Remember that all standard disk formats under DOS support
a sector size of 512 bytes, therefore, for one-sided 5.25 inch
floppies:
40t*8s*512b=163.840 bytes (160Kb)
40t*9s*512b=184.320 bytes (180Kb)
and for two-sided 5.25 inch floppies:
40t*8s*512b*2sides=327.680 bytes (320Kb)
40t*9s*512b*2sides=368.640 bytes (360Kb)
Beginning with DOS version 3.0 (Yeah, more and more
history!) a new floppy disk format has been supported: The IBM
AT (80286 CPU) introduced the so called "high capacity" 5.25 u-
inch floppy, capable of storing 1.2M at 15 sectors per track:
80t*15s*512b*2sides=1.228.800 bytes (1.2Mb)
Later on were introduced the to-day universally used 3.5
inch floppies, the ones inside a rigid small plastic cartridge,
and we have, similarly:
3.5-inch double sided/double density 720K
3.5-inch double sided/quad density (HD) 1440K
3.5-inch double sided/high density 2880K
[INT_13, AH=18, Set media type for format]
In order to create weird layouts, the protectionists use
interrupt 13h, service 18h, that specifies to the formatting
routines the number of tracks and sectors per track to be placed
on the media:
* Registers on entry: AH=18h; CH=N<> of tracks; CL= Sectors
per track; DL= Drive number (A=0; B=1;C=2... bit 7 is set
if the drive is an hard disk)
* Registers on Return: DI: Offset address of 11-byte
parameter table; ES: Segment address of 11-byte parameter
table.
[INT_13, AH=2, Read disk sectors]
In order to read them, they have to use INT_13, service 2, read
disk sectors, with following layout:
* Registers on entry: AH=2h; AL= N<> of sectors; BX= Offset
address of data buffer; CH=track; CL= Sector; DH= Head
(side) number; DL= Drive number; ES: Segment address of
data buffer.
* Registers on Return: AH= return code. If the carry flag is
not set, AH=0, therefore the weird sector has been read, if
on the contrary the carry flag is set, AH reports the
status byte as follows:
76543210 HEX DEC Meaning
1 80h 128 Time out - drive crazy
1 40h 064 Seek failure, could not move to track
1 20h 032 Controller kaputt
1 10h 016 Bad CRC on disk read
1 09h 009 DMA error - 64K boundary crossed
1 08h 008 DMA overrun
1 04h 004 Bad sector - sector not found
11 03h 003 Write protect!
1 02h 002 Bad sector ID (address mark
1 01h 001 Bad command
[Return code AH=9: DMA boundary error]
One of the possible errors should be explained, coz it is
used in some protection schemes: AH=9 DMA boundary error, means
that an illegal boundary was crossed when the in formation was
placed into RAM. DMA (Direct memory access) is used by the disk
service routines to place information into RAM. If a memory
offset address ending in three zeros (ES:1000, ES: 2000...) falls
in the middle of the area being overlaid by a sector, this error
will occur.
[INT_13, AH=4 Verify disk sectors]
Another possible protection interrupt is interrupt 13H,
service 4, Verify disk sectors. Disk verification takes place on
the disk and DOES NOT involve verification of the data on the
disk against data in memory! This function has no buffer
specification, does not read or write a disk: it causes the
system to read the data in the designated sector or sectors and
to check its computed cyclic redundancy check (CRC) against data
stored on the disk. See INT_13, AH=2 registers and error report.
[CRC]
The CRC is a checksum, that detects general errors. When a
sector is written to disk, an original CRC is calculated AND
WRITTEN ALONG with the sector data. The verification service
reads the sector, recalculates the CRC, and compares the
recalculated CRC with the original CRC.
We saw that some protection schemes attempt to disguise
interrupt calls. This is particularly frequent in the disk access
protection schemes that utilize INT_13 (the "disk" interrupt).
If you are attempting to crack such programs, the usual
course of action is to search for occurrences of "CD13", which
is machine language for interrupt 13. One way or another, the
protection scheme has to use this interrupt to check for the
special sectors of the disk. If you examine a cross section of
the program, however, you'll find programs which do not have
"CD13" in their machine code, but which clearly are checking the
key disk for weird sectors. How comez?
There are several techniques which can be used to camouflage
the protection scheme from our nice prying eyes. I'll describe
here the three such techniques that are more frequent:
1) The following section of code is equivalent to issuing an
INT 13 command to read one sector from drive A, side 0, track
29h, sector ffh, and then checking for a status code of 10h:
cs:1000 MOV AH,02 ;read operation
cs:1002 MOV AL,01 ;1 sector to read
cs:1004 MOV CH,29 ;track 29h
cs:1006 MOV CL,FF ;sector ffh
cs:1008 MOV DX,0000 ;side 0, drive A
cs:100B XOR BX,BX ;move 0...
cs:100D MOV DS,BX ;...to DS register
cs:100F PUSHF ;pusha flags
cs:1010 PUSH CS ;pusha CX
cs:1011 CALL 1100 ;push address for next
instruction onto stack and branch
cs:1014 COMP AH,10 ;check CRC error
cs:1017 ... rest of verification code
...
...
cs:1100 PUSHF ;pusha flags
cs:1101 MOV BX,004C ;address of INT_13 vector
cs:1104 PUSH [BX+02] ;push CS of INT_13 routine
cs:1107 PUSH [BX] ;push IP of INT_13 routine
cs:1109 IRET ;pop IP,CS and flags
Notice that there is no INT 13 command in the source code, so if
you had simply used a debugger to search for "CD13" in the
machine code, you would never have found the protection routine.
2) Another technique is to put in a substitute interrupt
instruction, such as INT 10, which looks harmless enough, and
have the program change the "10" to "13 (and then back to "10")
on the fly. A search for "CD13" would turn up nothing.
3) The best camouflage method for interrupts I have ever
cracked (albeit not on a INT 13) was a jump to a section of the
PROGRAM code that reproduces in extenso the interrupt code. This
elegant (if a little overbloated) disguise mocks every call to
the replicated interrupt.
LOADING ABSOLUTE DISK SECTORS
Old good [debug.com] has been called the "swiss army knife" of
the cracker. It allows a lot of nice things, inter alia the
loading, reading, modifying and writing of absolute sectors of
the disks. The sector count starts with the first sector of track
0, next sector is track 0, second side (if double sided), then,
back to the first side, track 1, and so on, until the end of the
disk. Up to 80h (128) sectors can be loaded at one time. To use
you must specify starting address, drive (0=A, 1=B, etc...),
starting sector and number of sectors to load.
- l 100 0 10 20
This instruction tells DEBUG to load, starting at DS:0100, from
drive A, sector 10h for 20h sectors. This allows at times the
retrieval of hidden and/or weird formatted data. If you get an
error, check the memory location for that data. Often times, part
of the data has been transferred before the error occurs, and the
remainder can be manually entered or gathered through repetitive
retries.
Bear all this in mind learning the following cracks.
Let's now crack an "oldie" primitive:
MS Flight simulator (old version 2.12, from 1985!)
This old program used -in 1985!- following beautiful protection
scheme: on the disk you had only a "stub", called FS.COM with few
bytes, which had following instructions:
loc code instruction what's going on
-------------------------------------------------------
:0100 FA CLI ;why not?
:0101 33C0 XOR AX,AX ;ax=0
:0103 8ED0 MOV SS,AX ;ss=0
:0105 BCB0C0 MOV SP,C0B0 ;SP=C0B0
:0108 8EC0 MOV ES,AX ;ES=0
:010A 26C70678003001 MOV Wptr ES:[0078],0130 ;Wp 0:78=130
:0111 268C0E7A00 MOV ES:[007A],CS ;0:7A=Segment
:0116 BB0010 MOV BX,1000 ;BX=1000
:0119 8EC3 MOV ES,BX ;ES=1000
:011B 33DB XOR BX,BX ;BX=0
:011D B80102 MOV AX,0201 ;AH=2 AL=1 sector
:0120 BA0000 MOV DX,0000 ;head=0 drive=0
:0123 B96501 MOV CX,0165 ;track=1 sector=65 (!)
:0126 CD13 INT 13 ;INT 13/AH=2
:0128 B83412 MOV AX,1234 ;AX=1234
:012B EA00000010 JMP 1000:0000 ;JMP to data we just read
:0130 CF IRET ;Pavlovian, useless ret
You see what's happening in this old protection scheme,
don't you? Herein you can watch the same snap that happens in
more recent (much more recent) protection schemes (as you'll see
in the next lesson): the protection searches for a weird
formatted sector and/or for particular data.
That should be no problem for you any more: you should just
reverse engineer everything (and that goes on pretty quickly:
just watch and break on the INT_13 calls), fetch the "weird"
data, tamper the whole crap and have your soup as you like it.
One more word about "old" protection schemes. Be careful not
to spurn them! Some of them are
-- CLEVER
-- STILL USED
-- DIFFICULT TO CRACK... I mean, this older DOS programs had
nice protections... it's pretty annoying to crack windows
programs that require a registration number: as you saw in Lesson
3, you just type your name and a serial number of your choice in,
say "666666666", break into the program with WINICE, search the
"666666666" and search too, for good measure, your own name, set
a memory read breakpoint where the number dwells and look at the
code that manipulates your input. As [Chris] rightly pointed out,
you can even rip the code straight out of the program and create
a key generator which will produce a valid code. This code will
work for any name you typed in only in the "pure maths
manipulation" protection schemes, and will on the contrary be
specific, following the name you typed in, the "alpha-maths
manipulation" protection schemes (like MOD4WIN, see the Windows
lessons), watch in this case the "pseudo-random xoring" of the
letters that compose your name.
-- STUNNING, coz new ideas have always been infrequent, and
they are getting more and more rare in this objectionable world
of lazy, incapable programmers patronizing us with ill-cooked
outrages like Windows'95... yeah, as usual there is no
"development" at all, quite the contrary, I would say. Take a
step backward, sip a good Martini-Wodka (please remember that
only Ice cubes, Dry Martini, Wodka Moskovskaja, Schweppes'
"Indian tonic" a green olive from Tuskany and a maltese lemon
zest will really be perfect) and watch from your balcony, with
unsullied eyes, your town and the people around you: slaves
everywhere, leaving home at 7.30 in the morning, stinking in a
progression of identical cars, forced to interminably watch
advertisement panels and endlessly listen to boorish publicity,
happy to go to work (if they happen to have the "luck" to work,
in this inequitable society) the whole day long in order to
produce other cars in order to buy, one day, a new car with a
different colour...
Why people don't look at the stars, love each other, feel
the winds, ban the stinking cars from the places where they live
and eat, study colours... name yourself a not-consumistic
activity? Why don't they read any poems any more? No poetry any
more, in the grey society of the publicity-spots slaves...poetry
will soon be forbidden, coz you cannot CONSUME as you read poems,
and in this farce of a society you are BOUND to consume, that's
the only thing they want you to do... you are CULTIVATED to
consume... no books worth to read any more... stupid american
conventional cram everywhere... boy, at times I'm missing some
well placed neutron bombs, the ones that would kill all these
useless zombies and leave noble books and good Wodka untouched.
It's difficult to believe in democracy any more... if I ever
did... all the useless zombie do -unfortunately- vote, and they
do vote for "smiling semblances", for "conventionally minded
idiots" that so act as if they would "really" be like what they
"look" like and could not care less about anything else than
making bucks and defend intolerant and petty patterns. The slaves
choose the people they have "seen" on TV... as if the egyptians
would VOTE for their pharaohs, exhilarated under the whips of
publicity... sorry, at times I forget that you are here for the
cracks, and could not care less about what I think...
You 'll obtain the OTHER missing lessons IF AND ONLY IF you
mail me back (via anon.penet.fi) with some tricks of the trade
I may not know that YOU discovered. Mostly I'll actually know
them already, but if they are really new you'll be given full
credit, and even if they are not, should I judge that you
"rediscovered" them with your work, or that you actually did good
work on them, I'll send you the remaining lessons nevertheless.
Your suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 6.1: Funny tricks (1)
---------------------------------------------------------------------------
LESSON 6 (1) - Funny tricks. Xoring, Junking, Sliding
EXERCISE 01: [LARRY in search of the King]
Before the next step let's resume what you have learned in
the lessons 3-5, beginning with a very simple crack exercise
(again, we'll use the protection scheme of a game, for the
reasons explained in lesson 1): SEARCH FOR THE KING (Version
1.1.). This old "Larry" protection sequence, is a "paper
protection" primitive. It's a very widespread (and therefore easy
to find) program, and one of the first programs that instead of
asking meaningful passwords (which offer us the possibility to
immediately track them down in memory) asked for a random number
that the good buyer could find on the manual, whereby the bad
cracker could not. (Here you choose -with the mouse- one number
out of 5 possible for a "gadget" choosen at random). I don't need
any more to teach you how to find the relevant section of code
(-> see lesson 3). Once you find the protection, this is what you
get:
:protection_loop
:C922 8E0614A3 MOV ES,[A314]
...
:C952 50 0E PUSH AX & CS
:C954 E81BFF CALL C872 <- call protection scheme
:C957 5B POP BX twice
:C959 8B76FA MOV SI,[BP-06] <- prepare store_room
:C95C D1E6 SHL SI,1 <- final prepare
:C95E 8942FC MOV [BP+SI-04],AX <- store AX
:C961 837EFA00 CMP Word Ptr [BP-06],+00 <- good_guy?
:C965 75BB JNZ C922 <- loop, bad guy
:C967 8E0614A3 MOV ES,[A314]
:C96B 26F606BE3501 TEST Byte Ptr ES:[35BE],01 <- bad_guy?
:C971 74AF JZ C922 <- loop, bad guy
:C973 8B46FC MOV AX,[BP-04]... <- go on good guy
Let's see now the protection scheme called from :C954
:C872 55 PUSH BP
...
:C8F7 90 NOP
:C8F8 0E PUSH CS
:C8F9 E87234 CALL FD6E <- call user input
:C8FC 5B POP BX
:C8FD 5B POP BX
:C8FE 8B5E06 MOV BX,[BP+06]
:C901 D1E3 SHL BX,1
:C903 39872266 CMP [BX+6622],AX <- right answer?
:C907 7505 JNZ C90E <- no, beggar_off
:C909 B80100 MOV AX,0001 <- yes, AX=1
:C90C EB02 JMP C910
:C90E 2BC0 SUB AX,AX <- beggar_off with AX=0
:C910 8BE5 MOV SP,BP
:C912 5D POP BP
:C913 CB RETF <- back to main
Here follow 5 questions, please answer all of them:
1) Where in memory (in which locations) are stored the "right"
passnumbers? Where in memory is the SEGMENT of this
locations stored? How does the scheme get the OFFSET?
2) Would setting NOPs instructions at :C965 and :C971 crack?
Would it be a good idea?
3) Would changing :C907 to JZ crack? Would it be a good idea?
4) Would changing :C907 to JNZ C909 crack? Would it be a good
idea?
5) Write down (and try) at least 7 OTHER different patches to
crack this scheme in spades (without using any NOP!).
Uff! By now you should be able to do the above 5 exercises in
less than 15 minutes WITHOUT USING THE DEBUGGER! Just look at the
data above and find the right answers feeling them... (you 'll
now which one are the right one checking with your debugger...
score as many points as you like for each correct answer and sip
a good Martini-Wodka... do you know that the sequence should
ALWAYS be 1) Ice cubes 2) Martini Dry 3) Wodka Moskovskaja 4)
olive 5) lemon 6) Schweppes Indian tonic?
Let's now come to the subject of this lesson:
-----> [Xoring] (Simple encryption methods)
One easy way to encrypt data is the XOR method. XOR is a bit
manipulation instruction that can be used in order to cipher and
decipher data with the same key:
Byte to encrypt key result
FF XOR A1 5E
5E XOR A1 FF
As you can see XOR offers a very easy way to encrypt or to
decrypt data, for instance using the following routine:
encrypt_decrypt:
mov bx, offset_where_encryption/decryption_starts
xor_loop:
mov ah, [bx] <- get current byte
xor ah, encrypt_value <- engage/disengage xor
mov [bx], ah <- back where you got it
inc bx <- ahead one byte
cmp bx, offset_start_+_size <- are we done?
jle xor_loop <- no, then next cycle
ret <- back where we came from
The encrypt_value can be always the same (fixed) or chosen at
random, for instance using INT_21, service 2Ch (get current time)
and choosing as encrypt_value the value reported in DL (but
remembering to discard the eventual value 0, coz otherwise it
would not xor anything at all!)
random_value:
mov ah,2Ch
int 21h
cmp dl,0
je random_value
mov encrypt_value,dl
The problem with XORing (and with many other encryption
methods), is that the part of the code that calls the encryption
routine cannot be itself encrypted. You'll somewhere have, "in
clear" the encryption key.
The protectionist do at times their best to hide the
decrypting routine, here are some common methods:
-----> JUNK FILLING, SLIDING KEYS AND MUTATING DECRYPTORS
These are the more common protection method for the small
decryption part of the program code. This methods, originally
devised to fool signature virus scanners, have been pinched from
the polymorphic virus engines of our fellows viriwriters, and are
still in use for many simple decryption protection schemes. For
parts of the following many thanks go to the [Black Baron], it's
a real pity that so many potential good crackers dedicate so much
time to useless (and pretty repetitive) virus writing instead of
helping in our work. This said, virus studying is VERY important
for crackers coz the code of the viri is
* ULTRAPROTECTED
* TIGHT AND EFFECTIVE
* CLOAKED AND CONCEALED.
Let's show as example of the abovementioned protection tactics
the following ultra-simple decryptor:
MOV SI,jumbled_data ;Point to the jumbled data
MOV CX,10 ;Ten bytes to decrypt
mn_loop: XOR BYTE PTR [SI],44 ;XOR (un_scramble!) a byte
INC SI ;Next byte
LOOP mn_loop ;Loop the 9 other bytes
This small program will XOR the ten bytes at the location pointed
to by SI with the value 44. Providing the ten bytes were XORed
with 44 prior to running this decryptor the ten bytes will be
restored to their original state.
In this very simple case the "key" is the value 44. But there are
several tricks involving keys, the simplest one being the use of
a "sliding" key: a key that will be increased, or decreased, or
multiplied, or bit-shifted, or whatever, at every pass of the
loop.
A possible protection can also create a true "Polymorph"
decryptor, a whole decryptor ROUTINE that looks completely
different on each generation. The trick is to pepper totally
random amounts of totally random instructions, including JUMPS
and CALLS, that DO NOT AFFECT the registers that are used for the
decryption. Also this kind of protection oft uses a different
main decryptor (possibly from a selection of pre-coded ones) and
oft alters on each generation also all the registers that the
decryptor uses, invariably making sure that the JUNK code that
it generates doesn't destroy any of the registers used by the
real decryptor! So, with these rules in mind, here is our simple
decryptor again:
MOV DX,10 ;Real part of the decryptor!
MOV SI,1234 ;junk
AND AX,[SI+1234] ;junk
CLD ;junk
MOV DI,jumbled_data ;Real part of the decryptor!
TEST [SI+1234],BL ;junk
OR AL,CL ;junk
mn_loop: ADD SI,SI ;junk instr, but real loop!
XOR AX,1234 ;junk
XOR BYTE PTR [DI],44 ;Real part of the decryptor!
SUB SI,123 ;junk
INC DI ;Real part of the decryptor!
TEST DX,1234 ;junk
AND AL,[BP+1234] ;junk
DEC DX ;Real part of the decryptor!
NOP ;junk
XOR AX,DX ;junk
SBB AX,[SI+1234] ;junk
AND DX,DX ;Real part of the decryptor!
JNZ mn_loop ;Real part of the decryptor!
As you should be able to see, quite a mess! But still executable
code. It is essential that any junk code generated by the
Polymorph protection is executable, as it is going to be peppered
throughout the decryptor. Note, in this example, that some of the
junk instructions use registers that are actually used in the
decryptor! This is fine, providing the values in these
registers aren't destroyed. Also note, that now we have random
registers and random instructions on each generation. So, a
Polymorph protection Engine can be summed up into three major
parts:
1 .. The random number generator.
2 .. The junk code generator.
3 .. The decryptor generator.
There are other discrete parts but these three are the ones where
most of the work goes on!
How does it all work? Well a good protection would
* choose a random selection of registers to use for the
decryptor and leave the remaining registers as "junk" registers
for the junk code generator.
* choose one of the compressed pre-coded decryptors.
* go into a loop generating the real decryptor, peppered with
junk code.
From the protectionist's point of view, the advantages of this
kind of method are mainly:
* the casual cracker will have to sweat to find the decryptor.
* the casual cracker will not be able to prepare a "patch" for
the lamers, unless he locates and patches the generators, (that
may be compressed) coz otherwise the decryptor will vary every
time.
To defeat this kind of protection you need a little "zen" feeling
and a moderate knowledge of assembler language... some of the
junk instructions "feel" quite singular when you look at them
(->see lesson B). Besides, you (now) know what may be going on
and memory breakpoints will immediately trigger on decryption...
the road is open and the rest is easy (->see lessons 3-5).
-----> Starting point number magic
For example, say the encrypted code started at address 10h, the
following could be used to index this address:
MOV SI,10h ;Start address
MOV AL,[SI] ;Index from initial address
But sometimes you'll instead find something like the following,
again based on the encrypted code starting at address 10h:
MOV DI,0BFAAh ;Indirect start address
MOV AL,[DI+4066h) ;4066h + 0BFAAh = 10010h (and FFFF = 10h)!!
The possible combinations are obviously infinite.
[BIG KEYS] (Complicated encryption methods)
Prime number factoring is the encryption used to protect
sensible data and very expensive applications. Obviously for few
digit keys the decoding is much easier than for, say, 129 or 250
digit keys. Nevertheless you can crack those huge encryption too,
using distributed processing of quadratic sieve equations (which
is far superior for cracking purpose to the sequential processing
methods) in order to break the key into prime numbers. To teach
you how to do this sort of "high" cracking is a little outside
the scope of my tutorial: you'll have to write a specific short
dedicated program, linking together more or less half a thousand
PC for a couple of hours, for a 250 bit key, this kind of things
have been done quite often on Internet, were you can also find
many sites that do untangle the mysteries (and vagaries) of such
techniques.
As References I would advocate the works of Lai Xueejia, those
swiss guys can crack *everything*. Begin with the following:
Xuejia Lai, James Massey, Sean Murphy, "Markov Ciphers and
Differential Cryptanalysis", Advances in Cryptology,
Eurocrypt 1991.
Xuejia Lai, "On the Design and Security of Block Ciphers",
Institute for Signal and Information Processing,
ETH-Zentrum, Zurich, Switzerland, 1992
Factoring and primality testing is obviously very important for
this kind of crack. The most comprehensive work I know of is:
(300 pages with lengthy bibliography!)
W. Bosma & M. van der Hulst
Primality Testing with Cyclotomy
Thesis, University of Amsterdam Press.
A very good old book you can incorporate in your probes to build
very effective crack programs (not only for BBS accesses :=) is
*the* "pomerance" catalog:
Pomerance, Selfridge, & Wagstaff Jr.
The pseudoprimes to 25*10^9
Math. Comp. Vol 35 1980 pp. 1003-1026
Anyway... make a good search with Lykos, and visit the relevant
sites... if encryption really interests you, you'll be back in
two or three (or thirty) years and you'll resume cracking with
deeper erudite knowledge.
[PATENTED PROTECTION SYSTEMS]
The study of the patented enciphering methods is also *quite*
interesting for our aims :=) Here are some interesting patents,
if you want to walk these paths get the complete texts:
[BEST] USPat 4168396 to Best discloses a microprocessor
for executing enciphered programs. Computer programs which have
been enciphered during manufacture to deter the execution of the
programs in unauthorized computers, must be decrypted before
execution. The disclosed microprocessor deciphers and executes
an enciphered program one instruction at a time, instead of on
a continuous basis, through a combination of substitutions,
transpositions, and exclusive OR additions, in which the address
of each instruction is combined with the instruction. Each unit
may use a unique set of substitutions so that a program which can
be executed on one microprocessor cannot be run on any other
microprocessor. Further, Best cannot accommodate a mixture of
encrypted and plain text programs.
[JOHNSTONE] USPat 4120030 to Johnstone describes a
computer in which the data portion of instructions are scrambled
and in which the data is of necessity stored in a separate
memory. There is no disclosure of operating with instructions
which are completely encrypted with both the operation code and
the data address portion being unreadable without a corresponding
key kernel.
[TWINPROGS] USPat 4183085 describes a technique for
protecting software by providing two separate program storages.
The first program storage is a secure storage and the second
program storage is a free storage. Security logic is provided to
check whether an output instruction has originated in the secure
store and to prevent operation of an output unit which receives
output instructions from the free storage. This makes it
difficult to produce information by loading a program into free
storage.
[AUTHENTICATOR] USPat 3996449 entitled "Operating System
Authenticator," discloses a technique for authenticating the
validity of a plain text program read into a computer, by
exclusive OR'ing the plain text of the program with a key to
generate a code word which must be a standard recognizable code
word which is successfully compared with a standard corresponding
code word stored in the computer. If there is a successful
compare, then the plain text program is considered to be
authenticated and is allowed to run, otherwise the program
is not allowed to run.
ELEMENTS OF [PGP] CRACKING
In order to try to crack PGP, you need to understand how these
public/private keys systems work. Cracking PGP seems extremely
difficult, though... I have a special dedicated "attack" computer
that runs 24 hours on 24 only to this aim and yet have only begun
to see the light at the famous other end of the tunnel. It's
hard, but good crackers never resign! We'll see... I publish here
the following only in the hope that somebody else will one day
be able to help...
In the public key cryptosystems, like PGP, each user has an
associated encryption key E=(e,n) and decryption key D=(d,n),
wherein the encryption keys for all users are available in a
public file, while the decryption keys for the users are only
known to the respective users. In order to maintain a high level
of security a user's decoding key is not determinable in a
practical manner from that user's encoding (public) key. Normally
in such systems, since
e.multidot.d.ident.1 (mod(1 cm((p-1),(q-1)))),
(where "1 cm((p-1),(q-1))" is the least common multiple of the
numbers p-1 and q-1)
d can be determined from e provided p and q are also known.
Accordingly, the security of the system is dependent upon the
ability to determine p and q which are the prime factors of n.
By selecting p and q to be large primes, the resultant composite
number n is also large, and correspondingly difficult to factor.
For example, using known computer-implemented factorization
methods, on the order of 10.sup.9 years is required to factor a
200 digit long number. Thus, as a practical matter, although a
user's encryption key E=(e,n) is public, the prime factors p and
q of n are effectively hidden from anyone due to the enormous
difficulty in factoring n. These aspects are described more fully
in the abundant publications on digital signatures and Public-Key
Cryptosystems. Most public/private systems relies on a message-
digest algorithm.
A message-digest algorithm maps a message of arbitrary length
to a "digest" of fixed length, and has three properties:
Computing the digest is easy, finding a message with a given
digest "inversion" is hard, and finding two messages with the
same digest "collision" is also hard. Message-digest algorithms
have many applications, not only digital signatures and message
authentication. RSA Data Security's MD5 message-digest algorithm,
developed by Ron Rivest, maps a message to a 128-bit message
digest. Computing the digest of a one-megabyte message takes as
little as a second. While no message-digest algorithm can yet
be secure, MD5 is believed to be at least as good as any other
that maps to a 128-bit digest.
As a final gift, I'll tell you that PGP relies on MD5 for a
secure one-way hash function. For PGP this is troublesome, to say
the least, coz an approximate relation exists between any four
consecutive additive constants. This means that one of the design
principles behind MD4 (and MD5), namely to design a collision
resistant function, is not satisfied. You can construct two
chaining variables (that only differ in the most significant bit
of every word) and a single message block that yield the same
hashcode. The attack takes a few minutes on a PC. From here you
should start, as I did.
[DOS 4GW] cracking - This is only a very provisory part of this
tutorial. DOS 4GW cracking will be much better described as soon
as [Lost soul] sends his stuff, if he ever does. For (parts of)
the following I thank [The Interrupt].
Most applications of every OS, and also of DOS 4GW, are
written in C language, coz as you'll have already learned or,
either, you'll learn, only C allows you to get the "guts" of a
program, almost approaching the effectiveness of assembler
language.
C is therefore the LANGUAGE OF CHOICE for crackers, when you
prepare your tools and do not directly use assembler routines.
Besides... you'll be able to find VERY GOOD books about C for
next to nothing in the second hand bookshops. All the lusers are
throwing money away in spades buying huge, coloured and
absolutely useless books on unproductive "bloated" languages like
Visual basic, C++ and Delphy. Good C new books are now rare
(books on assembler language have always been) and can be found
almost exclusively on the second hand market. Find them, buy
them, read them, use them for your/our aims. You can find a lot
of C tutorials and of C material on the Web, by all means DO IT!
Be a conscientious cracker... learn C! It's cheap, lean, mean and
very productive (and creative) :=)
Back to the point: most stuff is written in C and therefore
you need to find the "main" sub-routine inside the asm. With
DOS/4GW programs, search the exe file for "90 90 90 90", almost
always it'll be at the start of the compiled code. Now search for
an INT_21 executed with 4C in AH, the exec to dos code (if you
cannot "BPINT 21 AH=4C" with your tool, then search for the
sequence "b4 4c cd 21". This is the equivalent to [mov AH,4C &
int 21]: it's the most direct call, but as you'll have already
learned, there are half a dozen ways to put 4C in AX, try them
all in the order of their frequency).
A few bytes above the INT_21 service 4C, you'll find the
call to the "main" subroutine: "E8 xx xx". Now place a "CC" byte
a few bytes above the call in the exe and run the exe under a
debugger. When the computer tries to execute the instruction
you'll be throw back in the debugger coz the "CC" byte acts as
INT_01 instruction. Then proceed as usual.
[THE "STEGONATED" PASSWORD HIDEOUT]
A last, very nice trick should be explained to every wannabe
cracker, coz it would be embarrassing to search for passwords or
protection routines that (apparently) are not there. They may be
hidden INSIDE a picture (or a *.waw file for that matter). This
is steganography, a method of disguising messages within other
media.
Depending on how many shades of grey or hues of colour you want
to have, a pixel can be expressed using 8. 16, 32 or even more
bits. If the least significant bit is changed. the shade of the
pixel is altered only one-256th, one-65,OOOth or even less. No
human eye could tell the difference.
What the protectionist does, is hijack the least significant
bit in each pixel of a picture. It uses that bit to store one bit
of a protection, or of a password (or of a file, or of a secret
message). Because digitized pictures have lots of pixels, it's
possible to store lots of data in a single picture. A simple
algorithm will transfer them to the relevant parts of the program
when it needs be, and there we'll intercept them. You'll need to
learn very well the zen-cracking techniques to smell this kind
of stuff though (-> see lesson B).
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the OTHER missing lessons IF AND ONLY IF you
mail me back (via anon.penet.fi) with some tricks of the trade
I may not know that YOU discovered. Mostly I'll actually know
them already, but if they are really new you'll be given full
credit, and even if they are not, should I judge that you
"rediscovered" them with your work, or that you actually did good
work on them, I'll send you the remaining lessons nevertheless.
Your suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
an526164@anon.penet.fi (+ORC)
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 8.1: How to crack Windows, an approach
---------------------------------------------------------------------------
[WINPGP.EXE]
--------------------------------------
--------------------------------------------------------
SPECIAL NOTE: Please excuse the somehow "unshaven"
character of the windows lessons... I'm cracking the
newest Windows '95 applications right now, therefore
at times I had to add "on the fly" some corrections to
the older Windows 3.1 and Windows NT findings.
"homines, dum docent, discunt".
---------------------------------------------------------
-> 1st THING TO REMEMBER
The NE format does give every windows executable the equivalent
of a debug symbol table: A CRACKER BLISS!
-> UNDOCUMENTED DEBUGGING
One of the many feature of Windows based on undocumented
foundations is the "ability to debug".
A word about undocumented functions in the MS-Operating Systems:
Microsoft manipulates its rule and domination of the operating
systems in use to day (MS-DOS, Windows, Windows '95) with two
main wicked aims:
1) getting the concurrence completely bankrupt (that's the
scope of all the using of undocumented functions and
CHANGING them as soon as the concurrence uses them). The
battle against Borland was fought in this way.
2) getting all future "programmers" to use windows as a "black
box" that only Microsoft engineers (if ever) can master, so
that everybody will have to sip the ill-cooked abominations
from Microsoft without ever having a chance to alter or
ameliorate them.
Strange as it may seem, only the sublime cracker community fights
against these intolerable plans. All stupid governments and
lobbies -on the contrary- hide behind the fig-leaf of the
"market" "freedom" in order to ALLOW such heinous developments
(I'm speaking as if they were capable to opposing them even if
they wanted, which they do not. Be assured, they couldn't anyway,
"Governments" are deliberately MADE to serve Gates and all the
remaining suckers, and lobbies are the shield of feudalism. You
can forget "democracy", the only rule existing is a malevolent
oligarchy based on money, personal connections, defect of
culture, lack of knowledge and dictatorship of bad taste through
television in order to keep the slaves tamed... enough now...)
The windows situation is particularly reminiscent of the older
situation in DOS, where for years the key "load but don't
execute" function, used by debuggers, such as [DEBUG], [SYMDEB]
and [CODEVIEW], was "reserved" by Microsoft.
The windows debugging library, WINDEBUG.DLL, a number of
undocumented functions and even the interface it provides are
undocumented! The WinDebug() function is used by all available
windows debuggers, including [CVW] (CodeView for Windows), [TDW]
(TurboDebugger for Windows), [Multiscope] and [Quick C for
Windows] (the last two are GUI, not text debuggers. The use of
WinDebug() doesn't show up in MAPWIN output 'coz debuggers link
to it at run-time via the amazing GetProcAddress() function.
WinDebug() is a hacked 32-bit version, for the old Windows
3.0, of the poorly documented DOSPTrace() function from OS/2 1.x
(study these older Operating Systems! Studying the past you'll
understand EVERYTHING! Sometime I think that the only way to hack
and crack correctly is to be more a software historian than a
programmer... fac sapias et liber eris!). DOSPTrace is, in turn,
based on the ptrace() function in Unix.
Like DosPTrace(), WinDebug() takes commands such as Go,
Single-Step, Write&Read Registers, Write&Read Memory. It returns
to its caller either when the command completes or when a
breakpoint occurs (or a DLL load). These commands and
notifications appear in a large structure whose address is passed
in WinDebug().
WinDebug() was renamed CVWIN.DLL (and TDWIN.DLL) for Windows
3.1., all crackers should study it and get the maximum possible
documentation about it. As you will see in the following, it is
worth to study also TOOLHELP.DLL (what Microsoft would like you
to fiddle with) and INT_41h (the real debugging interface).
Interrupt handling under Windows
Interrupt handling under Windows can be tricky: you need to
use Toolhelp (a rather scaring lobotomy for your programs) or to
have special code for Standard vs. Enhanced modes, because the
information on the stack of an interrupt or exception handler
differs between the two windows modes. In addition, some handlers
would be installed using INT_21h, while others are set up using
DPMI services. Toolhelp has quite a bit of internal code that
"cooks" the interrupts and sends them to you in an easily
digestible form.
Remember that Windows uses GP faults as a "hacker" method
of doing ring transitions that are not allowed with legal 80x86
instructions: the virtual memory system of Enhanced mode is
implemented via the page fault.
Some tools for cracking windows (-> see lesson 9)
----------------- DEBUGGERS
CVW and TDW (you have to know the function's
segment:offset address beforehand in order
to crack a function)
WCB [Windows Codeback] by Leslie Pusztai (it's
a really cool tool!)
WDEB386 Microsoft's WDEB386 (clumsy, and requires a
second monitor)
Soft-Ice/Windows best (BY FAR!) windows debugger! NuMega is
so good I am at times really sorry to crack
their products! [WINICE] is the single,
absolutely essential debugger and snooping
utility for windows crackers. Get it!
----------------- POST MORTEM INSPECTORS
CORONER, etc. (a lot of shareware)
MS-DrWatson Old and clumsy
Borland's Winspector THE BEST! It has the BUILDSYM utility
that allows the creation of a debug
.SYM file from an .EXE without debug
information.
----------------- INSPECTORS
MS-Spy Old
Borland's WinSight (Best one, select "Other")
MicroQuill's Windows DeMystifiers (from Jeff Richter):
VOYEUR (hold SHIFT picking Message Selection), COLONEL,
MECHANIC and ECOLOGIST
----------------- SNOOPERS
[INFSPY.EXE], 231.424 bytes, version 2.05 28/8/1994 by Dean
Software Design, may be the more complete one.
[SUPERSPY.EXE], 24.576 bytes, 10,6,1994, quite handy for quick
informations.
[WINVIEW.EXE], 30.832 bytes, Version 3.00 by Scott McCraw, MS(c)
1990-1992, this is the old MS-Spy, distributed by MS
[TPWSPY.EXE], 9.472 bytes, quite primitive, but you get the
pascal source code with it.
-> INSIDE A WINDOWS '95 DEBUGGER
You can debug a program at the assembly-language level
without any debugging information. The DOS [DEBUG] program does
that, allowing breakpoints and single-stepping, all of which
implies that the hardware must be cooperating. Back in the time
of the 4-MHz Z-80s, you used a debugger that plugged interrupt
op codes into the instruction stream to generate breakpoints.
Nothing has changed. That's how you debug a program on a
80586 (=Pentium). The x86 architecture includes software
interrupts. The 1-byte op code xCC is the INT_03 instruction,
reserved for debuggers. You can put the INT_03 op code in place
of the program instruction op code where the break is to occur
and replace the original op code at the time of the interrupt.
In the 80386 and later, you can set a register flag that tells
the processor to generate a not-intrusive INT_01 instruction for
every machine instruction executed. That device supports single
stepping.
The Win32SDK (Windows '95 software developer's kit) includes
functions that allow one program to launch another program and
debug it. The SDK's debug API takes care of how the interrupts
and interrupt vectors get managed. The logical consequence of
such an approach is that fewer and fewer people will be able to
know what's going on inside an application. The bulk of the
programmers -in few years time- will not be able any more to
reverse engineer an application, unless the few that will still
understand assembler-language do offer them the tools to do it.
Microsoft -it is evident- would like the programmers to use a
"black box" approach to programming, writing nice little "hallo
world" application and leaving to the engineers in Microsoft
alone the capacity to push forward (and sell) real programs that
are not toy application.
The Win32 documentation seems vast, almost luxurious, until
you begin serious work and you discover its shortcomings, like
the fact that extended error codes are not documented, and
numerous APIs are documented either incorrectly or so poorly that
you must burn precious time testing them. What we definitely need
is to find some secret fellows inside Microsoft (like good old
Prometeus) that smuggles to the outside the real documentation
that the Microsoft engineers have reserved for themselves. If you
are reading this and do work for Microsoft, consider the
possibility of double-crossing your masters for the sake of
humanity and smuggle us the secret information.
In windows '95 a debugger program launches a program to be
debugged by calling the _CreateProcess function, specifying in
an argument that the program is to be debugged. Then the debugger
program enters a loop to run the program. At the top of the loop
the debugger calls _WaitForDebugEvent.
Each time _WaitForDebugEvent returns it sets indicators that
tell about the vent that suspended the program being debugged.
This is where the debugger traps breakpoints and single-step
exceptions. _WaitForDebugEvent fills in an event structure that
contains among other things the address that was interrupted end
the event that caused the interrupt.
The debugger calls _GetThreadContext to get the running
context of the debugged program, including the contents of the
registers. The debugger can, as the result of cracker
interaction, modify these values and the contents of the debugged
program's memory.
The debugger sets breakpoints by saving the op code at the
instruction to be intercepted and putting the INT_03 op code at
its place, it's always the same old marmalade. When the
breakpoint occurs, the debugger replaces the original op code in
the program's instruction memory, and decrements the interrupted
program counter in the saved context so that execution resumes
at the instruction that was broken.
To single-step a program, the debugger sets a bit in the
context's flags register that tells the processor to generate an
INT_01 for every instruction cycle. When that interrupt occurs,
the debugger checks to see if the interrupted address is at a new
source-code line number. If not, the debugger continues
execution. Otherwise, the debugger displays the new line in the
IDE and waits for the cracker to take an action that resumes the
program.
While the debugged program is suspended, the debugger
interacts with the cracker and provides full access to the
debugged program's context and memory. This access permits the
cracker to examine and modify part of the code.
To resume the debugged program, the debugger resets the
program's context by calling _SetThreadContext and calls
_ContinueDebugEvent. Then, the debugger returns to the top of the
loop to call _WaitForDebugEvent again.
To extract debug information from a Win32 executable file,
you must understand the format of that file (best thing to do,
to practice yourself, would be to reverse engineer small
programs). The executable file has two sections not found in
other executable files: ".stab" and ".stabstr". How nice that
they used names that suggest their purpose (nomen est omen).
You'll find them inside a table of fixed-length entries that
include entries for .text, .bss, .data and .idata. Inside these
sections the compilers put different parts of a program.
There are several different formats for encoding debug
information in an executable file. Borland's Turbo Debugger one
format. Microsoft's CodeView another. The gnu-win32 port from
Cygnus the stab format, an acronym meaning "symbol table",
although the table contains much more than just symbol
information.
The .stab section in a portable executable file is a table
of fixed-length entries that represent debugging information in
the stab format. The .stabstr section contains variable-length,
null terminated strings into which the .stab table entries point.
The documentation for the stab format is available in text
format on the Cygnus ftp site (ftp.cygnus.com//pub/gnu-win32).
Stabs contain, in a most cryptic format, the names and
characteristics of all intrinsic and user-defined types, the
memory address of every symbol in external memory and on the
stack, the program counter address of every function, the program
counter address where every brace-surrounded statement block
starts and ends, the memory address of line numbers within
source-code files, and anything else that a debugger needs. The
format is complex and cryptic because it is intended to support
any source-code language. It is the responsibility of a debugger
program to translate the stab entries into something meaningful
to the debugger in the language being debugged.
Windows '95 invokes dozens of INT_21 services from 32-bit
code, including KERNEL32.DLL and possess Krn32Mutex, which
apparently controls access to certain parts of the kernel. Some
of the functions in KERNEL32 can be blocked by the Win16Mutex,
even though Microsoft says this isn't the case.
SO, I WANNA CRACK, WHAT SHOULD I DO?
I'll show you a simple windows crack, so easy it can be done
without WINICE: let's take [WINPGP4.1.] (front-end for PGPing in
windows, by Geib - I must thank "Q" for the idea to work on this
crack).
Using WCB you'll find out quickly that the "CONGRATULATIONS
your registration number is OK" and the "SORRY, your registration
number is not correct" data blocks are at the block starting at
36.38B8 (respectively at 36.38D5 and 36.3937), that relocs to
13.081B.
Looking at 13.0000 and following code, you'll find a push
38D5 (68D538) and a push 3937 (683739) at 13.064D and 13.06AE.
The road to the crack is now open, you just need to find and
"fool" the calling routines. You'll learn the exact procedures
for this kind of WINcracks in part 2 and 3 of -> Lesson 8. Let's
now have a look at the protection scheme (disassembly from WCB):
...
13.0E88 660FBF46F8 movsx eax, word ptr [bp-08]
13.0E8D 668946F4 mov [bp-0C], eax
13.0E91 668B46F4 mov eax, [bp-0C]
13.0E95 6669C00A000300 imul eax, 0003000A
13.0E9C 668946F0 mov [bp-10], eax
13.0EA0 668B4606 mov eax, [bp+06]
13.0EA4 663B46F0 cmp eax, [bp-10]
13.0EA8 7505 jne 0EAF <- beggar_off
13.0EAA B80100 mov ax, 0001 <- flag 1 = "Right!"
13.0EAD EB04 jmp 0EB3 <- and go on
beggar_off:
13.0EAF 33C0 xor ax,ax <- flag 0 = "Nope!"
13.0EB1 EB00 jmp 0EB3 <- and go on
I want you to have a good look at this protection scheme.
IT'S THE SAME OLD SOUP! You do remember lesson 3 and the
protection schemes of the old DOS stupid games of the '80s, don't
you? IT'S THE SAME OLD SOUP! In this "up-to-date" "new" windows
application, in WINPGP version 4.1 of 1995/1996, exactly the same
kind of protection is used to "conceal" the password!
A) compare user input with memory echo
B) beggar off if not equal with AX=0
C) go on if equal with AX=1... how boring!
Besides, look at all the mov eax, and eax, moves preceding
the compare! That's a typical pattern for these "number_password"
protections! I wrote (years ago) a little crack utility that
searches for code blocks with a "66" as first instruction_byte
repeating in four or more consecutive instructions and it still
allows me to crack more than half of these windows password smuts
in less than three seconds flat. The IMUL instruction creates the
"magic" number, and if you give a closer look at the mathematical
part of the "conceal" routine, it could help you to crack
analogous schemes used in order to protect the "Instant access"
(c) & (tm) time_crippled software :=)
Now you could crack the above code in 101 different ways,
the most elegant one would probably substitute je 0EAF (or jZ
0EAF, that's the same) to the jne 0EAF at 13.0EA8. You just write
a 74 at the place of the 75, like you did for the cracks in
1978... how boring: it's really the same old soup! (But you'll
see some new tricks in the next lessons).
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC 526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 8.2: How to crack Windows, a deepr approach
---------------------------------------------------------------------------
[SNAP95] [WINZIP] [WINCAT]
--------------------------------------
SPECIAL NOTE: Please excuse the somehow "unshaven"
character of the windows lessons... I'm cracking the
newest Windows '95 applications right now, therefore
at times I had to add "on the fly" some corrections to
the older Windows 3.1 and Windows NT findings.
"homines, dum docent, discunt".
---------------------------------------------------------
-> 1st THING TO REMEMBER
If you thought that DOS was a mess, please notice that windows
3.1 is a ghastly chaos, and windows 95 a gruesome nightmare of
ill-cooked spaghetti code. Old Basic "GOTO" abominations were
quite elegant in comparison with this concoction... One thing is
sure: This OS will not last... it's way too messy organised,
impossible to consolidate, slow and neurotic (but I must warn
you... I thought exactly the same things about DOS in 1981).
The most striking thing about windows 95 is that it is neither
meat not fish: neither 16 nor 32... you could call it a "24 bit"
operating system.
We'll never damage Microsoft interests enough to compensate for
this moronic situation... where you have to wait three minutes
to get on screen a wordprocessor that older OS (and even old DOS)
kick up in 5 seconds. I decide therefore, hic et nunc, to add an
ADDENDUM to this tutorial: Addendum 1 will be dedicated to teach
everybody how to crack ALL Microsoft programs that do exist on
this planet. I'll write it this sommer and give it away between
the "allowed" lessons.
Anyway you can rely on good WINICE to crack everything, you'll
find it on the web for free, I use version 1.95, cracked by [The
Lexicon] (do not bother me for Warez, learn how to use the search
engines on the web and fish them out yourself). Learn how to use
this tool... read the whole manual! Resist the temptation to
crack immediatly everything in sight... you 'll regret pretty
soon that you did not wanted to learn how to use it properly.
A little tip: as Winice is intended more for software developers
than for crackers, we have to adapt it a little to our purposes,
in order to make it even more effective: a good idea is to have
in the *.DAT initialization file following lines:
INIT = "CODE ON; watchd es:di; watchd ds:si;"
TRA = 92
This way you'll always have the hexadecimal notation on, two very
useful watch windows for passwords deprotection and enough buffer
for your traces.
WINDOWS 3.1. basic cracking: [ALGEBRAIC PROTECTIONS]
The most used windows protections are "registration codes",
these must follow a special pattern: have a "-" or a "+" in a
predetermined position, have a particular number in particular
position... and so on.
For the program [SHEZ], for instance, the pattern is to have a
14 bytes long alphanumeric sequence containing CDCE1357 in the
first 8 bytes.
The second level of protection is to "connect" such a
pattern to the alphanumeric contents of the NAME of the user...
every user name will give a different "access key". This is the
most commonly used system.
As most of these protections have a "-" inside the answering
code, you do not need to go through the normal cracking procedure
(described in the next lesson):
* load WINICE
* hwnd [name_of_the_crackanda_module]
* choose the window Handle of the snap, i.e, the exact
"FIELD" where the code number input arrives... say 091C(2)
* BMSG 091C WM_GETTEXT
* Run anew
* Look at the memory location(s)
* Do the same for the "Username" input FIELD. (Sometimes
linked, sometimes not, does not change much, though)
* BPR (eventually with TRACE) on the memory locations (these
will be most of the time FOUR: two NUMBERCODES and two
USERNAMES). The two "mirrored" ones are the most important
for your crack. At times there will be a "5th" location,
where the algebraic play will go on...
* Look at the code that performs algebraic manipulations on
these locations and understand what it does...
* Disable the routine or jump over it, or reverse it, or
defeat it with your own code... there are thousand
possibilities...
* Reassemble everything.
Uff... quite a long cracking work just to crack some miserable
program... isn'there a quicker way? OF COURSE THERE IS! Actually
there are quite a lot of them (see also the crack of Wincat Pro
below): Look at the following code (taken from SNAP32, a screen
capture utility for Windows 95, that uses a pretty recent
protection scheme):
XOR EBX,EBX ; make sure EBX is zeroed
MOV BL, [ESI] ; load input char in BL
INC ESI ; point at the next character
MOV EDI,EBX ; save the input character in EDI
CMP EBX,+2D ; input char is a "-" ?
JZ ok_it's_a_+_or_a_-
CMP EBX,+2B ; input char is a "+" ?
JNZ Jesus_it's_neither_a_minus_nor_a_plus_let's_check_it
:ok_it's_a_+_or_a_-
XOR EBX,EBX ; EBX is zeroed
MOV BL,[ESI] ; recharge BL
INC ESI ; point to next char (do not check - or +)
:Jesus_it's_neither_a_minus_nor_a_plus_let's_check_it
XOR EBP,EBP ; zero EBP
CMP DWORD PTR [boguschecker], +01
...
even if you did not read all my precedent lessons, you do not
need much more explications... this is a part of the algebraic
check_procedure inside the SNAP32 module... you could also get
here through the usual
USER!BOZOSLIVEHERE
KERNEL!HMEMCPY
USER!GLOBALGETATOMNAME
Windows wretched and detestable APIs used for copy protections,
as usual with WINICE cracking, and as described elsewhere in my
tutorial.
The above code is the part of the routine that checks for the
presence of a "+" or a "-" inside the registration number (many
protections scheme requires them at a given position, other need
to jump over them).
Now sit down, make yourself comfortable and sip a good Martini-
Wodka (invariably very useful in order to crack... but be aware
that only Moskowskaia russian Wodka and a correct "Tumball" glass
will do, do not forget the lemon)... what does this "-" stuff
mean for us little crackers?
It means that we can search directly for the CMP EBX,+2B
sequence inside any file protected with these schemes... and
we'll land smack in the middle of the protection scheme! That's
amazing... but you will never underrate enough the commercial
programmers... the only really amazing thing is how simpleton the
protectionists are! You don't believe me? Try it... you 'll get
your crack at least 4 out of 5 times.
Yes I know, to find this code is not yet to crack it... but for
this kind of copy protection (that's the reason it is so
widespread) there is no single solution... each makes a slightly
different algebraic manipulation of the alphanumeric and of the
numeric data. It's up to you to crack the various schemes... here
you can only learn how to find them and circumvene them. I'll not
give you therefore a "debug" crack solution. You'll find it
yourself using my indications (see the crack of the Wincat Pro
program below).
WHERE ARE THE CODES? WHERE ARE THE MODIFIED FILES? WHERE DO THE
PROTECTIONS KEEP COUNT OF THE PASSING DAYS?
Most of the time the protection schemes use their own *.ini files
in the c:\WINDOWS directory for registration purposes... at time
they even use the "garbage sammler" win.ini file. Let's take as
example WINZIP (versions 5 and 5.5), a very widespread program,
you'll surely have one shareware copy of it somewhere between
your files.
In theory, winzip should be registered per post, in order to
get a "NEW" copy of it, a "registered" copy.
This scares most newby crackers, since if the copy you have
it's not full, there is no way to crack it and make it work,
unless you get the REAL stuff. The youngest among us do not
realize that the production of a real "downsized" demo copy is
a very expensive nightmare for the money-infatuated commercial
programmers, and that therefore almost nobody does it really...
nearly all "demos" and "trywares" are therefore CRIPPLED COMPLETE
PROGRAMS, and not "downsized" demos, independently of what the
programmers and the protectionists have written inside them.
Back to Winzip... all you need, to crack winzip, is to add a
few lines inside the win.ini file, under the heading [WinZip],
that has already been created with the demo version, before the
line with "version=5.0".
I will not help you any further with this... I'll leave it to
you to experiment with the correct sequences... inside win.ini
you must have following sequence (these are only template to
substitute for your tries inside WINICE... you'll get it, believe
me):
[WinZip]
name=Azert Qwerty
sn=########
version=5.5
The *important* thing is that this means that you DO NOT NEED
to have a "new registered version" shipped to you in order to
make it work, as the protectionist sellers would like you to
believe. The same applies most of the time... never believe what
you read in the read.me or in the registration files...
This brings me to a broader question: NEVER believe the
information they give you... never believe what television and/or
newspapers tell you... you can be sure that the only reason they
are notifying you something is to hinder you to read or
understand something else... this stupid_slaves_society can only
subsist if nobody thinks... if you are really interested in what
is going on, real information can be gathered, but surely not
through the "conventional" newspapers and/or news_agencies (and
definitely NEVER through television, that's really only for the
stupid slaves)... yes, some bit of information can be
(laboriously) gathered... it's a cracking work, though.
HOW TO CRACK INFORMATION [WHERE WHAT]
* INTERNET
In the middle of the hugest junk collection of the planet, some
real information can be laboriously gathered if you do learn how
to use well the search engines (or if you do build your ones...
my spiders are doing most of the work for me... get your robots
templates from "Harvest" or "Verify" and start your "spider
building" activity beginning from Martijn Koster's page). As
usual in our society, in the Internet the real point is exactly
the same point you'll have to confront all your life long: HOW
TO THROW AWAY TONS OF JUNK, HOW TO SECLUDE MYRIADS OF USELESS
INFORMATION and HOW TO FISH RARE USEFUL INFORMATION, a very
difficult art to learn per se. Internet offers some information,
though, mainly BECAUSE it's (still) unregulated. You want a
proof? You are reading it.
* SOME (RARE) NEWSPAPERS.
The newspaper of the real enemies, the economic powers that
rule this slaves world, are paradoxically most of the time the
only ones worth studying... somewhere even the real rulers have
to pass each other some bits of real information. The "Neue
Zuercher Zeitung", a newspaper of the Swiss industrials from
Zuerich, is possibly the best "not_conformist trend analyzer"
around that you can easily find (even on the web). These
swissuckers do not give a shit for ideology, nor preconcerted
petty ideas, the only thing they really want is to sell
everywhere their ubiquitous watches and their chocolates... in
order to do it, a land like Switzerland, with very high salaries
and a good (and expensive) social system, must use something
brilliant... they found it: a clear vision of the world... as a
consequence this newspaper is very often "against" the trend of
all the other medias in the world, the ones that are used only
in order to tame the slaves... If the only language you know is
english (poor guy) you could try your luck with the weekly
"Economist"... you'll have to work a lot with it, coz it has been
tailored for the "new riches" of the Tatcher disaster, but you
can (at times) fish something out of it... they do a lot of
idiotic propaganda, but are nevertheless compelled to write some
truth. American newspapers (at least the ones you can get here
in Europe) are absolute shit... one wonders where the hell do the
americans hyde the real information.
On the "non-capitalistic" side of information there is a
spanish newspaper "El Pais" that seems to know about what's going
on in South America, but it's so full of useless propaganda about
irrelevant Spanish politics that it's not really worth reading.
The monthly "Le Monde diplomatique" offers something too... this
one exaggerates a little on the pauperistic "third world" side,
but has a lot of useful information. See what you can do with all
this information (or disinformation?)
[BELIEVE THE COUNTRARY]
Another good rule of thumb in choosing your medias is the
following... if all medias around you assure, for instance, that
"the Serbians are evil"... the only logical consequence is that
the Serbians are not so evil at all and that "the Croats" or some
other Yugoslavian shits are the real culprits. This does not mean
at all that the Serbians are good, I warn you, it means only what
I say: something is surely hidden behind the concerted propaganda
you hear, the best reaction is to exaggerate in the other
direction and believe the few bit of information that do say the
countrary of the trend. This rule of thumb may be puerile, but
it works somehow most of the time... if somewhere everybody
writes that the commies are bad then THERE the commies must not
be so bad at all and, conversely, if everybody in another place
writes that the commies are all good and nice and perfect (like
the Soviet propaganda did) then THERE the commies are surely not
so good... it's a matter of perspective, much depends on where
you are, i.e. whose interests are really at stake. There is NEVER
real information in this society, only propaganda... if you still
do not believe me do yourself a little experiment... just read
the media description of a past event (say the Vietnam war) as
written AT THE MOMENT of the event and (say) as described 10
years later. You'll quickly realize how untrustworthy all
newspapers and medias are.
* SEMIOTICS You'll have to study it (as soon as you can) to
interpret what they let you believe, in order to get your
bearings. A passing knowledge of ancient RHETORIC can help quite
a lot. Rhetoric is the "Softice" debugger you need to read
through the propaganda medias: concentrate on Periphrasis,
Synecdoche, Antonomasia, Emphasis, Litotes and Hyperbole at the
beginning... you'll later crack higher with Annominatio,
Polyptoton, Isocolon and all the other lovely "figurae
sententiae".
Enough, back to software cracking.
HOW A REGISTRATION CODE WORKS [WINCAT]
Let's take as an example for the next crack, a Username-
algebraic registration code, WINCAT Pro, version 3.4., a 1994
shareware program by Mart Heubel. It's a good program, pretty
useful to catalogue the millions of files that you have on all
your cd-roms (and to find them when you need them).
The kind of protection Wincat Pro uses is the most utilized
around: the username string is manipulated with particular
algorithms, and the registration key will be made "ad hoc" and
depends on the name_string. It's a protection incredibly easy to
crack when you learn how the relevant procedures work.
[WINCAT Pro] is a good choice for cracking studies, coz you
can register "over your registration" one thousand times, and you
can herefore try for this crack different user_names to see all
the algebrical correspondences you may need to understand the
protection code.
In this program, when you select the option "register", you
get a window where you can input your name and your registration
number (that's what you would get, emailed, after registering
your copy). If you load winice and do your routinely hwnd to
individuate the nag window, and then breakpoint on the
appropriate memory ranges you'll peep in the working of the whole
bazaar (this is completely useless in order to crack these
schemes, but it'll teach you a lot for higher cracking, so you
better do it also with two or three other programs, even if it
is a little boring): a series of routines act on the input (the
name) of the user: the User_name_string (usn). First of all the
usn_length will be calculated (with a REPNZ SCASB and a following
STOSB). Then various routines store and move in memory the usn
and the registration_number (rn) and their relative lengths. In
order to compare their lengths and to check the correct
alphanumeric correspondence between usn and rn, the program first
uppercases the usn and strips all eventual spaces away.
Here the relevant code (when you see an instruction like
SUB AL,20 you should immediately realize that you are in a
uppercasing routine, which is important for us, since these are
mostly used for password comparisons)... here the relevant Winice
unassemble and my comments:
253F:00000260 AC LODSB <- get the usn chars
253F:00000261 08C0 OR AL,AL <- check if zero
253F:00000263 740F JZ 0274 <- 0: so usn finished
253F:00000265 3C61 CMP AL,61 <- x61 is "a", man
253F:00000267 72F7 JB 0260 <- not a lower, so loop
253F:00000269 3C7A CMP AL,7A <- x7A is "z", what else?
253F:0000026B 77F3 JA 0260 <- not a lower, so loop
253F:0000026D 2C20 SUB AL,20 <- upper it if it's lower
253F:0000026F 8844FF MOV [SI-01],AL<- and hyde it away
253F:00000272 EBEC JMP 0260 <- loop to next char
253F:00000274 93 XCHG AX,BX
...
The instruction MOV [SI-01],AL that you see here is important
at times, coz it points to the location of the "pre-digested"
usn, i.e. the usn formatted as it should be for the number
comparison that will happen later. In some more complicated
protection schemes the reasoning behind this formatting is the
following: "Stupid cracker will never get the relation algorhitm
usn <-> rn, coz he does not know that usn AND rn are slightly
changed before comparing, ah ah... no direct guessing is
possible". Here is only "polishing": you have to "polish" a
string before comparing it in order to concede some mistakes to
the legitimate user (too many spaces in the name, upper-lower
case mismatch, foreign accents in the name etc.) You just need
to know, for now, that this checking is usually still 5 or 6
calls ahead of the real checking (it's what we call a "green
light").
You should in general realize that the real checking of the
algebrical correspondence follows after a whole series of memory
operations, i.e.: cancelling (and erasing) the previous (if ever)
attempts; reduplicating the usn and the rn somewhere else in
memory; double checking the string lengths (and saving all these
values somewhere... be particularly attentive when you meet stack
pointers (for instance [BP+05]): most of the programs you'll find
have been written in C (what else?). C uses the stack (SS:SP) to
pass parameters or to create local variables for his procedures.
The passwords, in particular, are most of the time compared to
data contained within the stack. If inside a protection a BP
register points to the stack you have most of the time fished
something... remember it pupils: it will spare you hours of
useless cracking inside irrelevant routines. Back to our CATWIN:
another little check is about the "minimal" length allowed for
a user name, in our babe, for instance, the usn must have at
least 6 chars:
230F:00003483 3D0600 CMP AX,0006
230F:00003486 730F JAE 3497 <- go to nice_name
:too_short
230F:00003488 BF9245 MOV DI,4592 <- no good: short
After a lot of other winicing you'll finally come across
following section of the code:
2467:00000CA3 B90100 MOV CX,0001
2467:00000CA6 03F1 ADD SI,CX
2467:00000CA8 2BC1 SUB AX,CX
2467:00000CAA 7213 JB 0CBF
2467:00000CAC 40 INC AX
2467:00000CAD 368B4F04 MOV CX,SS:[BX+04] <- here
2467:00000CB1 0BC9 0R CX,CX
2467:00000CB3 7D02 JGE 0CB7
2467:00000CB5 33C9 XOR CX,CX
2467:00000CB7 3BC1 CMP AX,CX
2467:00000CB9 7606 JBE 0CC1
2467:00000CBB 8BC1 MOV AX,CX
2467:00000CBD EB02 JMP 0CC1
2467:00000CBF 33C0 XOR AX,AX
2467:00000CC1 AA STOSB <- and here
2467:00000CC2 8BC8 MOV CX,AX
2467:00000CC4 F3A4 REPZ MOVSB <- and here!
2467:00000CC6 8EDA MOV DS,DX
2467:00000CC8 FC RETF 0008
This is obviously the last part of the checking routine
(I'll not delve here with the mathematical tampering of it, if
you want to check its workings, by all means, go ahead, it's
quite interesting, albeit such study is NOT necessary to crack
these schemes). The important lines are obviously the MOV
CX,SS:[BX+04], the STOSB and the REPZ MOVSB (as usual in password
protection schemes, you do remember lesson 3, don't you?).
You should be enough crack-able :=) by now (if you have read
all the precedent lessons of my tutorial), to find out easily,
with these hints, how the working of the protection goes and
where dwells in memory the ECHO of the correct rn (passkey) that
matches the name you typed in. Remember that in these kind of
cracks the ECHO is present somewhere (90% of the cases). There
are obviously one thousand way to find such ECHOs directly,
without going through the verificayions routines... for instance
you could also find them with a couple of well placed
snap_compares, it's a "5 minutes" cracking, once you get the
working of it. I leave you to find, as interesting exercise, the
routine that checks for a "-" inside the rn, a very common
protection element.
In order to help you understand the working of the protection
code in [Wincat Pro] I'll give you another hint, though: if you
type "+ORC+ORC+ORC" as usn, you'll have to type 38108-37864 as
rn, if you usn as usn "+ORC+ORC" then the relative rn will be
14055-87593. But these are my personal cracks... I have offered
this information only to let you better explore the mathematical
tampering of this specific program... you'll better see the
snapping mechanism trying them out (going through the routines
inside Winice) alternatively with a correct and with a false
password. Do not crack Wincat with my combination! If you use a
different usn than your own name to crack a program you only show
that you are a miserable lamer... no better than the lamers that
believe to "crack" software using huge lists of serial numbers...
that is really software that they have stolen (Yeah: stolen, not
cracked). You should crack your programs, not steal them...
"Warez_kids" and "serial#_aficionados" are only useless zombies.
I bomb them as soon as I spot them. YOU ARE (gonna be) A CRACKER!
It makes a lot of a difference, believe me.
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
"If you give a man a crack he'll be hungry again
tomorrow, but if you teach him how to crack, he'll
never be hungry again"
E-mail +ORC
an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson 9 (1): How to crack Windows, Hands on
---------------------------------------------------------------------------
[Winformant][Snap32]
--------------------------------------
THE [DATA_CONSTRAINT] TRICK - [WINFORMANT 4]
I have chosen an older windows application for Win 3.1.
(WIN4MANT.EXE, 562271 bytes, Version 1.10, by Joseph B. Albanese;
you'll find it searching the web with the usual tools, see how
to do it at the end of this lesson), in order to show you how to
use a nice little trick, at times really useful in cracking
password protected programs: [data_constraint]. Inside almost all
protection routines, as you have already learned, there is a
moment when on the stack the ECHO of the real, "correct"
passnumber or password appears. The location of this ECHO varies,
but most of the time it'll be in a range of +- 0x90 bytes from
one of the locations where the user input dwells. This is due to
datadump windows constraints inside the tools used by the
protectionists... but this use is bound to diminish... especially
after this lesson :=)
[WINFORMANT CRACKING]
This application is -per se- crappy, I doubt you'll ever use
it... but its curious (and pretty rare) "deactivate" mode is
nevertheless very interesting for us: you can "unregister"
Winformant on the fly if you feel the need to.
This feature is pretty useful for scholars that like to
investigate password algorithms with valid and invalid codes
without having to reinstall every time to delete a valid code.
For your cracking exercises choose programs that have
"REVERSIBLE" protections (rare) or that can be re-registered a
billion times (more frequent). Programs that keep the valid
registration on *.ini or special files will also do the job: you
just change a couple of lines to "unregister" them.
The trick of this lesson: [data_constraint], or "password
proximity", bases on the protectionist's need to keep an eye on
the protection "working" when he assembles it. He must "see" the
relationships between USER INPUT NUMBER, USER INPUT TRANSFORMED
and the CORRECT NUMBER ANSWER (in our jargon: the "Bingo"). These
relationships must be constantly checked In order to debug the
protection code. Mostly they will dwell TOGETHER inside a small
stack area, allowing them to be "seen" in the SAME watchwindow.
Most of the time, therefore, the "ECHO" will "materialize"
shortly not very far away from one of the locations of the USER
INPUT. Let's crack:
* Fire Winice and then Winformant
* Choose HELP and then choose REGISTRATION
* Fill the registration fields with "+ORC+ORC" as "Registrant"
and "12121212" as "Activation" code (use whatever you fancy).
CTRL+D ;switch to Winice
:task ;let's see what's the name of this crap
TaskName SS:SP StackTop StackBot StackLow TaskDB hQueue Events
WINWORD 1AD7:85F2 4A52 8670 7532 1247 122F 0000
PROGMAN 1737:200A 0936 2070 1392 066F 07F7 0000
DISKOMAT *2C5F:6634 1D3C 6AC6 5192 2CB7 2C9F 0000
:hwnd DISKOMAT ;which window is getting the input?
WinHandle Hqueue QOwner Class Name Window Procedure
0EB4(0) 2C9F DISKOMAT #32769 04A7:9E6B
0F34(1) 2C9F DISKOMAT #32768 USER!BEAR306
365C(1) 2C9F DISKOMAT #32770 2C3F:0BC6
36BC(2) 2C9F DISKOMAT Button 2C3F:1CEA
3710(2) 2C9F DISKOMAT Edit 2C3F:24BE
... and many more irrelevant windows.
Let's pinpoint the code, here the relevant window is the first
"Edit" one, for obvious reasons (more on this later).
:bmsg 3710 wm_gettext ;set breakpoint
CTRL+D ;run the babe until you get:
Break Due to BMSG 3710 WM_GETTEXT C=01
Hwnd=3710 wParam=0050 lParam=2C5F629A msg=000D WM_GETTEXT
2C3F:000024BE B82F2C MOV AX,2C2F
So! Now we have "pinpointed" the babe (more on "pinpointing"
later). Let's snoop around a little: look at the stack to fetch
your babe's last call (if it does not show immediately, just keep
pinpointing, for instance on GetWindowText() or do a BPRW
diskomat (very useful), and then try and retry the stack...
should this too fail to work, search for your input in memory (in
the 30:0 lffffffff selector, as usual) and breakpoint range on
it with ReadWrite, and then stack, stack, stack... until you get
the "real" list of calls coming from your babe's protection.
:stack ; let's see
USER(19) at 073F:124C [?] through 073F:1239
CTL3D(02) at 2C3F:0D53 [?] through 2C3F:0D53
DISKOMAT(01) at 2C97:20B9 [?] through 2C97:20B9
DISKOMAT(01) at 2C97:3D94 [?] through 2C97:3D94
DISKOMAT(01) at 2C97:49E2 [?] through 2C97:4918
DISKOMAT(04) at 2C7F:EA20 [?] through 2C7F:EA20
USER(01) at 04A7:19BE [?] through USER!GETWINDOWTEXT
== CTL3D(02) at 2C3F:24BE [?] through 04A7:3A3C<33>
Beautiful stack fishing! Do immediately a BPX on babe:EA20.
2C7F:EA35 9A25ABA704 CALL USER!GETWINDOWTEXT
2C7F:EA3A 8D46AE LEA AX,[BP-52] ;load ptr "+ORC+ORC"
2C7F:EA3D 16 PUSH SS ;save pointer segment
2C7F:EA3E 50 PUSH AX ;save pointer offset
2C7F:EA3F 9A768D872C CALL 2C87:8D76; get strlen "ORC+ORC"
2C7F:EA44 83C404 ADD SP,+04
2C7F:EA47 3D2800 CMP AX,0028
2C7F:EA4A 762C JBE EA78
...
2C7F:EA97 8D46AE LEA AX,[BP-52] ;load ptr "+ORC+ORC"
2C7F:EA9A 16 PUSH SS ;various algors on input
2C7F:EA9B 50 PUSH AX ;follow here, we do not
... ;need to care
2C7F:EAB2 0F851101 JNE EBC7
2C7F:EAB6 8D8E5CFF LEA CX,[BP+FF5C] ;ptr "12121212"
2C7F:EABA 16 PUSH SS
2C7F:EABB 51 PUSH CX
2C7F:EABC 9A768D872C CALL 2C87:8D76 ;get strlen "12121212"
2C7F:EAC1 83C404 ADD SP,+04
2C7F:EAC4 50 PUSH AX
2C7F:EAC5 8D865CFF LEA AX,[BP+FF5C] ;ptr "12121212" HERE!
2C7F:EAC9 16 PUSH SS
2C7F:EACA 50 PUSH AX
...etc, various algors on input follow here
OK, it's enough: now obviously follows the code that
"algorithmize" the number string, and then, somewhere, you'll
have the hideous compare that divides good guys and bad crackers.
You could examine, and crack, and search...
BUT NOW IT'S THE "MAGIC MOMENT" OF THE ECHO! We know and *feel*
it: The echo must be somewhere... how do we find it? Searching
"12121212" in memory fishes at least 10 different locations...
:s 30:0 lffffffff '12121212'
Pattern Found at 0030:0005AD6A
.... (7 more)
Pattern Found at 0030:80509D6A
Pattern Found at 0030:8145AD6A
Should we look for all occurrences of string '12121212',
starting with the two at 80000000, dumping +-0x90 around it...
until we find the echo? We could, and it would work, but that's
not zen... that's boring! In other protections these locations
could proliferate on purpose, to deter the casual cracker. There
must be some other way... And lo and behold! YES! There is a
quicker way... THE LAST loading of the numeric input string in
the code (the one after the strlen count) is the "right" one for
our cracking purposes, coz protections follow (mostly) this
pattern (remember: we are inside a "stack-heavy" section of the
code... if you want to crack higher I suggest you read some good
literature about stack working, stack tricks and stack magics
with the Intel processors):
LOAD NAMEString - COUNT NAMEStringLen
LOAD NAMEString - TRANSFORM NAMEString
LOAD CODEString - COUNT CODEStringLen
LOAD CODEString
*ECHO must be here*
TRANSFORM CODEString
*ECHO must be here*
COMPARE TRANSFORMED_NAMEString WITH TRANSFORMED_CODEString
This means that at line
2C7F:EAC5 8D865CFF LEA AX,[BP+FF5C] ;ptr "12121212"
you'll already have your echo somewhere... just dump the memory
around the pointer [BP+FF5C]:
:d 2c5f:61e8 ;these numbers will differ in your computer
02 62 2F 06 02 00 26 2E-A3 4E A3 4E 01 00 38 30 .b/...&..N.N..80
33 37 2D 36 34 36 2D 33-38 33 36 00 01 06 02 00 37-646-3836.....
2F 06 75 62 C3 2E B7 04-F2 24 2F 06 CE 6E 2F 06 /.ub.....$/..n/.
49 00 5A 00 01 00-04 2C 2F 06 AE 24 36 62 00 00 I.Z......,/..$6b
74 62 7A 2E B7 04 36 62-01 00 C2 62 2F 2C 26 2E tbz...6b...b/,&.
03 01 BA 0F AE 24 5F 02-C9 01 5E 02 BA 01 5F 02 .....$_...^..._.
31 32 31 32 31 32 31 32-00 0C 00 BC 02 00 00 00 12121212........
00 49 00 BA 0F-AE 24 F2 24 2F 06 00 00 00 00 00 ....I....$.$/...
AF 17 00 E2 5F-7A 62 FE FF 79 1B BA 0F 00 00 00 ......._zb..y...
96 0B 01 00 02 4E 00-37 01 8A 62 D2 0F 8F 17 00 .....N..7..b....
2F 06 00 37 01-98 62 20 10 16 03 2F 06 00 00 00 /.....7..b .../.
C2 62 2B 4F 52 43 2B 4F-52 43 00 0D AE 24 2F 06 .b+ORC+ORC......
Look at this dump: everybody is there! The stack pointers points
in the middle, at string "12121212". 0x50 bytes before it you'll
find our good old ECHO (i.e. the CORRECT passnumber) and 0x50
bytes afterwards you'll see your handle: here "+ORC+ORC".
It's cracked! The code for my "+ORC+ORC" is 8037-646-3836...
Now begin your assignments: if you rally want to learn cracking:
- "Unregister" and find anew your own code for your own
handle. *DO NOT* use serial numbers with any other name
that your own handle, that's miserable stealing, not
cracking. I'll begin to punish the serial#_aficionados on
the Web, coz I like real outlaws, but I detest stupid
pickpockets.
- Study the two coding algorithms, the one for the input name
and the one for the input number, this will be very useful
for your future cracking sessions.
- Find the "Compare", i.e. the code that sets the two usual
flags "good guy, you may move on" and "bad cracker, beggar
off", and
- Create a "real" crack for this protection, that will allow
anybody you think deserves it, with any name and any
password number, to get through.
[CRACKING SNAP 32]
Snap 32 (SNAP32.EXE 356.352 bytes, 24/11/95, Version 2.54,
by Greg Kochaniak) is a "snapshot" shareware program for Windows
95, that allows users to save the screen, parts of it, or a
single window. It's a very common 'try before you buy' program,
limited to 30 days use. You'll find it everywhere on the Web. If
you do not know how to search the Web (poor guy!), learn at the
end of this lesson the correct procedure to find all the files
you need on the Net and get them automatically emailed to you
(that's something you should learn: SEARCHING! It's even more
important than cracking!).
Snap32 is not very interesting (I don't think I used it more
than a couple of times), but its protection is: in order to (try
to) deter casual crackers it does not compare strings, it
compares a "magic" sum (from Namestring) with another magic sum
(from Numberstring). And:
* SUMS magics inside the GDI, not inside its own code;
* USES a look_up table for input validation instead of
"plain" code;
* COMPARES the "magic" manipulation from input NUMBER with
the "magic" manipulation from input NAME.
The cracking procedure for most of these windows programs is
pretty simple and relatively straightforward:
1) SEE THE NAME OF YOUR BABE AND ITS QUEUE SELECTOR
:task ;This is the Winice95 command you type after firing
snap32 and getting at the "Enter License" nag window:
TaskName SS:SP StckTp StckBt StckLw TaskDB Hqueue Events
Snap32 0000:0000 006 AC000 006B0000 270E D27 0000
OK, the babe is Snap32,it's HQUEUE is 0xD27, it's TaskDB is
0x27OE, orright.
2) SEE THE MODULES OF YOUR BABE:
:map32 snap32 ;Your command
Owner Obj Name Obj# Address Size Type
SNAP32 .text 0001 0137:00401000 00043000 CODE RO
SNAP32 .rdata 0002 013F:00444000 00002E00 IDATA RO
SNAP32 .data 0003 013F:00447000 00009000 IDATA RW
SNAP32 .idata 0004 013F:00471000 00001C00 IDATA RW
SNAP32 .rsrc 0005 013F:00473000 00001600 IDATA RO
SNAP32 .reloc 0006 013F:00475000 00004C00 IDATA RO
OK, so the code is in selector 137:(as usual), and you have there
43000 bytes of code from 401000 to 401000+43000; the DATA,
ReadWrite and ReadOnly, are in selector 13F: (as usual).
3) SEE THE HANDLE OF THE PROTECTION "NAG" WINDOW
:hwnd snap32 ;Your command
Window Handle Hqueue SZ Qowner Class Name Window Procedure
0350(1) 0D27 32 SNAP32 #02071 144F:0560
0354(2) 0D27 32 SNAP32 #02071 17CF:102E
... and many more windows that we do not care of.
OK, so, for our cracking purposes, it's Handle 0x350. Most of
the times the "nag" window you want to crack will be the first
one in the hwnd listing (coz it was the last one to appear).
Watch the number in parentheses that follows the Whandle: (1) is
a mother, (2) are "children" windows. At times you'll find under
"Class Name" something like "Edit" (see before the Winformant
cracking)... SNIFF THERE! At times the "Window Procedure" code
location in a list of more than twenty, will be slightly
different for one or two windows... SNIFF THERE!
4) BREAKPOINT MESSAGE WM_GETTEXT (or any other WM_ that you can
think of in order to "pinpoint" the code of our babe).
"Pinpointing" the code is extremely important in windows
cracking... this idiotic OS moves code, data and stack out and
inside the pages all the time... so you'll keep getting on
"INVALID" sections without a correct pinpointing. Good
Pinpointing points are in general:
BMSG xxxx WM_GETTEXT (good for passwords)
BMSG xxxx WM_COMMAND (good fro OK buttons)
BPRW *your babe* TW (good for tracking)
u USER!GETWINDOWTEXT (u and then BPX inside the code)
u GETDLGITEM (for the Hwnd of an Item inside a
Dialog Box)
CSIP NOT GDI (if you have too many interferences)
u USER!SHOWWINDOW (bpx with counter occurrence to get to
the "right" window)
u GETSYSTEMTIME (for "time-crippled" software)
and many others pinpointing points you'll learn. If you are
really desperate for pinpointing, just do a BMSG xxxx WM_MOVE and
then move the nag window, this will always work. Let's go on:
:bmsg 350 wm_gettext ;Your command
OK, so the code is ready to be pinpointed.
5)RUN THE PROGRAM TO THE BREAKPOINT:
CTRL+D ;Your command to exit Winice and run
until it pops out at breakpoint
OK, now you pop out inside Winice somewhere... (look at the stack
to know where) so the code has been pinpointed.
6) SEARCH THE DATA AREA for your input string (4 Gigabytes from
30:0... remember that DATA are *always* in 30:0 to 30:FFFFFFFF
and CODE is *always* in 28:0 to 28:FFFFFFFF). In most protection
the "registration_number" string must match the "username"
string, which cannot be constrained, in order to allow users to
choose whatever stupid name they fancy. Some protections requires
fixed symbols inside the "username" string, though... in these
rare eventualities, just apply to the "username" string what
we'll do here with the "registration_number" string. The point
to remember is: begin always with the protection fumbling your
number, crack only if necessary the protection that fumbles your
name. Let's search now.
:s 30:0 lffffffff '12121212' ;Your command
Pattern Found at 0030:80308612
80000000 is good. Lower era videos, mirrors and BIOS, higher
(around C0000000) you have the OS dustbins... the point to
remember is: investigate always FIRST the 80000000 locations.
7) BREAKPOINT ON MEMORY RANGE ON THIS STRING.
By the way: prepare a watch window dex 3 es:di, you'll soon see
how useful such an automated watchwindow is in password cracking.
:bpr 30:80308612 30:80308612+8 RW ;Your command
OK Now we'll begin to dig out the relevant parts of the code.
Remember that you must breakpoint *every* copy of the string that
protection generates. A typical copy routine, very frequently
used in windows copy protection schemes, dwells inside
KERNEL!HMEMCPY (+0076):
0117:9E8E 66C1E902 SHR ECX,02
0117:9E92 F36766A5 REPZ MOVSD ;makes a copy in es:di
0117:9E96 6659 POP ECX
0117:9E98 6683E103 AND ECX,+03
0117:9E9C F367A4 REPZ MOVSB
0117:9E9F 33D2 XOR DX,DX
In fact, this piece of copying code is so often used for password
verifications that sometimes you just need to bpx on 0117:9E92
to get the correct stack sequence... but let's, for now, continue
without such little tricks: just keep on BPRring (Breakpoint on
memory range) all copies that protection makes.
8) LET THE BABE RUN, it will breakpoint on all manipulations of
your input string. One of them will lead to the magic.
8.1.) VALIDATION phase
There are many routines that check and "validate" your inputs.
The most common ones check that your numbers ARE really numbers,
i.e. in the range 0x30-0x39. Usually this is done with:
CMP EAX,+30
JB no_number
CMP EAX,+39
JA no_number
At times the protectionists use TABLES instead... The number
itself is used as a pointer to a "ready made" table where the
relevant magic can be used as a protection. Imagine that a number
4 in your input points to a code section that throws you
immediately outside the validation routine... or imagine that a
number 7, if found in your input, fetches a magic code that
removes the whole program from your harddisk (or worse): "Ah, ah!
Stupid cracker will never know that he should not have used
number 4... and definitely not number 7! Next time he'll
learn..." Yes, tables have been used for such nasty tricks.
Here the relevant code for the "validation" part of our
protection (still checking my favourite input string '12121212'):
:check_if_valid
0137:4364AE 8A16 MOV DL,[ESI] ;load license number
0137:4364B0 33C0 XOR EAX,EAX ;zero AX
0137:4364B2 668B0451 MOV AX,[ECX+2*EDX] ;look table for 84
0137:4364B6 83E008 AND EAX,+08 ;OK if AND'S TO zero
0137:4364B9 85C0 TEST EAX,EAX ;and therefore
0137:4364BB 7403 JZ 004364C0 ;go on
0137:4364BD 46 INC ESI ; ready for next number
0137:4364BE EBCD JMP 0043648D
:strip_-_&_+_signs
0137:4364C0 33DB XOR EBX,EBX ;clean BX
0137:4364C2 8A1E MOV BL,[ESI] ;load license number
0137:4364C4 46 INC ESI ;ready for next
0137:4364C5 8BFB MOV EDI,EBX ;save copy
0137:4364C7 83FB2D CMP EBX,+2D ;is it a "-"?
0137:4364CA 7405 JZ 004364D1
0137:4364CC 83FB2B CMP EBX,+2B ;is it a "+"?
8.2.) MANIPULATION (summing magic numbers)
Your wisely set breakpoints on memory range for the occurrence
of the string "12121212" will pop you out, inter alia, inside
following piece of code (note how this part of protection dwells
inside GDI, and NOT inside the code selector of snap32):
0557:11BD 33C0 XOR EAX,EAX ;zero AX
0557:11BF 66648B06 MOV AX,FS:[ESI] ;load number
0557:11C3 83C602 ADD ESI,+02 ;point to next
0557:11C6 66833C4700 CMP WORD PTR [EDI+2*EAX],+00
0557:11CB 0F8424010000 JE 000012F5
0557:11D1 668B0442 MOV AX,[EDX+2*EAX] ;load from magic table
0557:11D5 03D8 ADD EBX,EAX ;save sum in EBX
0557:11D7 49 DEC ECX ;till we are done
0557:11D8 75E5 JNZ 000011BF ;loop along
Interesting, isn't it? Protection is using this GDI routine to
create a SUM (through pointers to another table) that depends on
your very input numbers. We are now very near to the crack... can
you *feel* it? If not, prepare yourself a good Martini Vodka!
This is the correct way to do it:
* Get a "highball" glass;
* Put some ice cubes inside it (2 or 3);
* Add Martini Dry (From Martini & Rossi). Fill to 1/3;
* Add Moskowskaja Wodka (the only real Vodka). Fill to 2/3;
* Add a zest of lemon (From Malta or Southern France);
* Add a green "sound" olive (from Italy or Israel);
* Add Schweppes Indian Tonic. Fill to the brim.
Sit deeper and relax, sip slowly and *feel* where the code of the
protection scheme you are cracking "moves"... It's like a
current... a slow tide. If you still do not believe me, just try
it.
We'll now find out where protection stores the "magic" sum (and
now you'll pop out inside the very own snap32 code, this is the
"real" protection part):
8.3.) The ludicrous "HIDING" of the magic sum
0137:40437E 83C404 ADD ESP,+04
0137:404381 8B4DE8 MOV ECX,[EBP-18]
0137:404384 8945F0 MOV [EBP-10],EAX ;***HERE!***
0137:404387 68FF000000 PUSH 000000FF
0137:40438C 8D8574FBFFFF LEA EAX,[EBP+FFFFFB74] ;load string
0137:404392 50 PUSH EAX ;push it
0137:404393 E886410100 CALL 0041851E ;manipulate
0137:404398 8D8574FBFFFF LEA EAX,[EBP+FFFFFB74] ;load string
0137:40439E 50 PUSH EAX ;push it
0137:40439F E88C210300 CALL 00436530 ;manipulate
As you can see, the protection is very simple: The "magic" sum
is hidden only two lines before the further manipulations of the
input string. We have found location 137:404384, here, in the
CORRECT way, through bprring of the string that has been
manipulated in the GDI, but actually, we could have found it
quickly just checking superficially what's happening "around" all
manipulations of the input string. Do we really need to follow
all manipulations of our registration_number and eventually also
all manipulation of our username? NO, not at all: we just set a
BPR on the stack location where protection hides the sum [EBP-10]
and we'll see what happens: 90% of these protections just create
two sums, a sum from your username and a sum from your
registration_number... somewhere there will be a compare that
must use this location (or a copy of it... we'll see).
8.4.) COMPARING THE MAGICS FROM THE TWO INPUT STRING
Breakpoint on memory range on the sum location [EBP-10] that you
saw in the previous code and you'll land at this piece of code:
0137:404412 E82F050000 CALL 00404946
0137:404417 83C40C ADD ESP,+0C
0137:40441A 3B45F0 CMP EAX,[EBP-10] ;comp AX & magicsum
0137:40441D 740F JZ 0040442E
0137:40441F 68C0874400 PUSH 004487C0
0137:404424 E8149E0000 CALL 0040E23D
0137:404429 83C404 ADD ESP,+04
0137:40442C EB5B JMP 00404489
0137:40442E 893DA0714400 MOV [004471A0],EDI
0137:404434 85FF TEST EDI,EDI
That's it, you have made it! We found the compare between the
"username" magic number (for my "+ORC+ORC" string that's here
0x7C25621B) in AX (we do not need to know how this landed
there... it's irrelevant!) and the "license_number" '12121212'
(whose magic is here 0x00B8F47C) stored in [pointer-10.] How do
we find now the correct INPUT number for +ORC+ORC? Well, it's
easy... the "magic number" must be the same... therefore:
Cracked=Dec(0x7C25621B)
Cracked=2082824731
That was it. Old Snap32 has been cracked. You could now
prepare a crack in order to distribute this program around
without its simple protection. Good cracked applications should
be given free (i.e. cracked) to all the people that NEED them and
do not have the money to buy them. Don't forget that in this
intolerable society the 0,5% of the citizens own the 56% of the
industrial capital and the 63% of the propaganda machines (data
from US researchers... therefore suspect... the real situation
is probably even worser) effectively conditioning the destiny of
millions of slaves, moronized by television watching. So crack
the applications and give them to the people you care and the
peolple that need them, but for the others... just EXPLAIN
everybody how you did it... this is real help: giving knowledge,
not wares. DO NOT use my handle and my codes to crack this
program, get yours, I gave you mine only as an help for this
cracking lesson. I have showed you the way enough... THIEFS, not
crackers, use the codes that others have found. You are (gonna
be) CRACKERS! Remember it, look straight ahead, crack accurately
and keep your tommy in.
HOW TO SEARCH THE INTERNET FOR FILES WITHOUT MOVING A FINGER
It's amazing: most of the people roaming around inside Internet
DO NOT know how to use effectively the web. I'll be very
altruistic and explain how to fetch the very example of Snap32,
the babe we cracked in this lesson.
1) Choose an archie from this list (I will not explain you what
an archie is, you should know it... if you do not, be ashamed):
archie.univie.ac.at 131.130.1.23 Austria
archie.belnet.be 193.190.248.18 Belgium
archie.funet.fi 128.214.6.102 Finland
archie.univ-rennes1.fr 129.20.254.2 France
archie.th-darmstadt.de 130.83.22.1 Germany
archie.ac.il 132.65.16.8 Israel
archie.unipi.it 131.114.21.10 Italy
archie.uninett.no 128.39.2.20 Norway
2) Email a message to your archie:
To: archie.univie.ac.at (for instance)
Subject: (nothing on this field)
Body: set search sub (substrings too)
set maxhits 140 (max 140 hits)
set maxhitspm 9 (not the same file all over)
find snap32 (we want this)
3) After a while you'll get (per email) your answer: Here the
answer from the Austrian archie
Host ftp.wu-wien.ac.at (137.208.8.6)
Last updated 17:48 9 Aug 1995
Location: /pub/systems/windows.32/misc
FILE -rw-r----- 128957 bytes 15:59 16 Jun 1995 snap32.zip
Host space.mit.edu (18.75.0.10)
Last updated 00:45 4 Mar 1996
Location: /pub/mydir
FILE -rw-r--r-- 407040 bytes 11:55 28 Nov 1995 snap32.exe
4) ftpmail your file (Browsing is no good: too busy and lame).
Again, I will not explain you what an FTPMAIL server is: learn
it by yourself... choose a good one from this list (there are
many more... you'll learn):
bitftp@vm.gmd.de (Germany)
ftpmail@ieunet.ie (Ireland)
bitftp@plearn.edu.pl (Poland)
ftpmail@ftp.sun.ac.za (South Africa)
ftpmail@ftp.sunet.se (Sweden)
ftpmail@ftp.luth.se (Sweden)
ftpmail@src.doc.ic.ac.uk (United Kingdom)
To: ftpmail@ftp.sun.ac.za. (for instance)
Subject: (leave blank)
Body: open space.mit.edu (the last occurrence that
the archie sent)
cd/pub/mydir (get the correct subdir)
bin (prepare for BINARY)
get snap32.exe (I want this)
quit (bye)
5) Your FTPMAIL server will first notice you a receipt:
FTP EMAIL response...
ftpmail has received the following job from you:
reply-to +ORC
open space.mit.edu +ORC@now.here
get snap32.exe
ftpmail has queued your job as: 1834131821.5514
Your priority is 1 (0 = highest, 9 = lowest)
Requests to sunsite.doc.ic.ac.uk will be done before other jobs.
There are 14 jobs ahead of this one in the queue.
4 ftpmail handlers available.
To remove send a message to ftpmail containing just:
delete 1834131821.5514
After a while you'll get a second message, with your file
uuencoded inside... everything has been done.
YESSIR! there is absolutely no need to loose time on the WWW,
"surfing" idiotically from a junk site to the next or waiting
hours to download some slow file from an instable server! Wasting
time of your own LIFE, that you could use to read poetry, to make
love, to look at the stars, to sail slowly between the Aegean
islands or to start a nice cracking session. What's the point of
wasting your time when machines can perform all the searches you
need better, more productively and faster than you ever could...
YESSIR! You can get *everything* on the Web, and without paying
your Internet provider more than a couple of dimes... Nice, isn't
it?
By now, if you have followed all my lessons, you should be able
to crack relatively quickly "normal" applications. There are some
new projects for 1997: a cracking "university", that will allow
us to prepare for the divine war against Microsoft repulsive
dominion. If you do not have already chosen your handle (your
"cracker" name, that's it), you may consider choosing an handle
with a "+" somewhere inside it or, eventually, add a "+" to your
handle. This sign is used by me and by friends that have studied
and/or contributed. But a "+" in your handle ("official +ORC
cracker") will mean even more:
1) allows support from me personally (on a "do ut des" basis)
2) allows pupils to identify each other (good for joining
forces)
3) will open you (eventually) the doors to the "higher"
cracking university I'll set up on the Web in 1997.
(I'm not getting megalomaniac... In reality I only need a "quick"
method to know on which (anonymous) people I can count on for the
next phase).
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
Lesson A.1: Advanced Cracking: Internet Cracking (Unix)
---------------------------------------------------------------------------
-------------> INTERNET CRACKING: FIREWALLS
With each new company that connects to the "Information
Superhighway" new frontiers are created for crackers to explore.
Site administrators (Siteads) have implemented various security
measures to protect their internal networks. One of these is
xinetd, covered later. A more general solution is to construct
a guarded gateway, called a [Firewall], that sits between a
site's internal network and the wild and woolly Internet where
we roam. In fact only one third of all Internet connected
machines are already behind firewalls. Most information services
have to deal with the same problem we have: getting OUT through
a local firewall or GETTING INTO a service through their
Firewall. There lays also the crack_solution.
------------> What is a Firewall?
The main purpose of a Firewall is to prevent unauthorized
access between networks. Generally this means protecting a site's
inner network from the Internet. If a site has a firewall,
decisions have been made as to what is allowed and disallowed
across the firewall. These decisions are always different and
always incomplete, given the multiplicity of Internet, there are
always loopholes where a cracker can capitalize on.
A firewall basically works by examining the IP packets that
travel between the server and the client. This provides a way to
control the information flow for each service by IP address, by
port and in each direction.
A firewall embodies a "stance". The stance of a firewall
describes the trade-off between security and ease-of-use. A
stance of the form "that which is not expressly permitted is
prohibited" requires that each new service be enabled
individually and is seldom used, coz very slow and annoying.
Conversely, the stance "that which is not expressly prohibited
is permitted" has traded a level of security for convenience. It
will be useful to guess the stance of the firewall you are
cracking when making probe decisions.
A firewall has some general responsibilities:
* First and foremost if a particular action is not allowed by
the policy of the site, the firewall must make sure that all
attempts to perform the action will fail.
* The firewall should log suspicious events
* The firewall should alert internal administration of all
cracking attempts
* Some firewall provide usage statistics as well.
------------> Types of Firewall
In order to avoid head-scratching, it's a good idea to know
the TOPOLOGY of "your" firewall -and its limitations- before
attempting to get through it. Discussed below are two popular
firewall topologies. Although other types exist, the two below
represent the basic forms; most other firewalls employ the same
concepts and thus have -luckily- the same limitations.
1) THE DUAL-HOMED GATEWAY
A dual-homed Gateway is a firewall composed of a single
system with at least two network interfaces. This system is
normally configured such that packets are not directly routed
from one network (the Internet) to the other (the internal net
you want to crack). Machines on the Internet can talk to the
gateway, as can machines on the internal network, but direct
traffic between nets is blocked.
In discussing firewalls, it's generally accepted that you
should think of the inner network as a medieval castle. The
"bastions" of a castle are the critical points where defence is
concentrated. In a dual-homed gateway topology, the dual-homed
host itself is called the [BASTION HOST].
The main disadvantage of a dual-homed gateway, from the
viewpoints of the users of the network and us crackers alike, is
the fact that it blocks direct IP traffic in both directions. Any
programs running on the inner network that require a routed path
to external machines will not function in this environment. The
services on the internal network don't have a routed path to the
clients outside. To resolve these difficulties, dual-homed
gateways run programs called [PROXIES] to forward application
packets between nets. A proxy controls the conversation between
client and server processes in a firewalled environment. Rather
than communicating directly, the client and the server both talk
to the proxy, which is usually running on the bastion host
itself. Normally the proxy is transparent to the users.
A proxy on the bastion host does not just allow free rein
for certain services. Most proxy software can be configured to
allow or deny forwarding based on source or destination addresses
or ports. Proxies may also require authentication of the
requester using encryption- or password-based systems.
The use of proxy software on the bastion host means that the
firewall administrator has to provide replacements for the
standard networking clients, a nightmare in heterogeneous
environments (sites with many different operating systems
platforms, PC, Sun, IBM, DEC, HP...) and a great burden for
administrator and users alike.
2) THE SCREENED HOST GATEWAY
A screened host gateway is a firewall consisting of at least
one router and a bastion host with a single network interface.
The router is typically configured to block (screen) all traffic
to the internal net such that the bastion host is the only
machine that can be reached from the outside. Unlike the dual-
homed gateway, a screened host gateway does not necessarily force
all traffic through the bastion host; through configuration of
the screening router, it's possible to open "holes" in the
firewall to the other machines on the internal net you want to
get into.
The bastion host in a screened host firewall is protected
from the outside net by the screening router. The router is
generally configured to only allow traffic FROM SPECIFIC PORTS
on the bastion host. Further, it may allow that traffic only FROM
SPECIFIC EXTERNAL HOSTS. For example the router may allow Usenet
news traffic to reach the bastion host ONLY if the traffic
originated from the site's news provider. This filtering can be
easily cracked: it is relying on the IP address of a remote
machine, which can be forged.
Most sites configure their router such that any connection
(or a set of allowed connections) initiated from the inside net
is allowed to pass. This is done by examining the SYN and ACK
bits of TCP packets. The "start of connection" packet will have
both bits set. If this packets source address is internal... or
seems to be internal :=) the packet is allowed to pass. This
allows users on the internal net to communicate with the internet
without a proxy service.
As mentioned, this design also allows "holes" to be opened
in the firewall for machines on the internal net. In this case
you can crack not only the bastion host, but also the inner
machine offering the service. Mostly this or these machine/s will
be far less secure than the bastion host.
New services, for instance recent WEB services, contain a
lot of back doors and bugs, that you'll find in the appropriate
usenet discussion groups, and that you could use at freedom to
crack inner machines with firewall holes. Sendmail is a good
example of how you could crack in this way, read the whole
related history... very instructive. The rule of thumb is "big
is good": the bigger the software package, the more chance that
we can find some security related bugs... and all packages are
huge nowadays, 'coz the lazy bunch of programmers uses
overbloated, buggy and fatty languages like Visual Basic or
Delphy!
Finally, remember that the logs are 'mostly) not on the bastion
host! Most administrators collect them on an internal machine not
accessible from the Internet. An automated process scan the logs
regularly and reports suspicious information.
3) OTHER FIREWALL TOPOLOGIES
The dual-homed gateway and the screened host are probably the
most popular, but by no mean the only firewall topologies. Other
configurations include the simple screening router (no bastion
host), the screened subnet (two screening routers and a bastion
host) as well as many commercial vendor solutions.
------------> Which software should we study?
Three popular unix software solutions allow clients inside a
firewall to communicate with server outside: CERN Web server in
proxy mode, SOCKS and the TIS Firewall toolkit.
1) The CERN Web server handles not only HTTP but also the other
protocols that Web clients use and makes the remote connections,
passing the information back to the client transparently. X-based
Mosaic can be configured for proxy mode simply by setting a few
environment variables.
2) The SOCKS package (available free for anonymous ftp from
ftp.nec.com in the file
/pub/security/socks.cstc/socks.cstc.4.2.tar.gz
includes a proxy server that runs on the bastion host of a
firewall. The package includes replacements for standard IP
socket calls such as connect(), getsockname(), bind(), accept(),
listen() and select(). In the package there is a library which
can be used to SOCKSify your crack probes.
3) The Firewall Toolkit
The toolkit contains many useful tools for cracking firewall and
proxy server. netacl can be used in inetd.conf to conceal
incoming requests against an access table before spawning ftpd,
httpd or other inetd-capable daemons. Mail will be stored in a
chroot()ed area of the bastion for processing (mostly by
sendmail).
The Firewall toolkit is available for free, in anonymous ftp from
ftp.tis.com in the file
/pub/firewalls/toolkit/fwtk.tar.Z
The popular PC firewall solution is the "PC Socks Pack", for MS-
Windows, available from ftp.nec.com It includes a winsock.dll
file.
The cracking attempts should concentrate on ftpd, normally
located on the bastion host. It's a huge application, necessary
to allow anonymous ftp on and from the inner net, and full of
bugs and back doors. Normally, on the bastion host, ftpd is
located in a chroot()ed area and runs as nonprivileged user. If
the protection is run from an internal machine (as opposing the
bastion host), you could take advantage of the special inner-net
privileges in hostp.equiv or .rhosts. If the internal machine
"trusts" the server machine, you'll be in pretty easily.
Another good method, that really works, is to locate your
PC physically somewhere along the route between network and
archie server and "spoof" the firewall into believing that you
are the archie server. You'll need the help of a fellow hacker
for this, though.
Remember that if you gain supervisor privileges on a machine
you can send packets from port 20, and that in a screened host
environment, unless FTP is being used in proxy mode, the access
filters allow often connections from any external host if the
source port is 20 and the destination port is greater than 1023!
remember that NCSA Mosaic uses several protocols, each on
a different port, and that -if on the firewall no proxy Web
server is operating- each protocol must be dealt with
individually, what lazy administrators seldom do.
Be careful for TRAPS: networking clients like telnet and ftp
are often viciously replaced with programs that APPEAR to execute
like their namesake, but actually email an administrator. A
fellow cracker was almost intercepted, once, by a command that
simulated network delays and spat out random error messages in
order to keep me interested long enough to catch me. Read the
(fictions) horror story from Bill Cheswick: "An evening with
Berferd in which a cracked is lured, endured and studied",
available from ftp.research.att.com in
/dist/internet_security/berferd.ps
As usual, all kind of traps can be located and uncovered by
correct zen-cracking: you must *FEEL* that some code (or that
some software behaviour) is not "genuine". Hope you believe me
and learn it before attempting this kind of cracks.
------------> How do I crack Firewalls?
Some suggestions have been given above, but teaching you how
to crack firewalls would take at least six complete tutorial
lessons for a relatively unimportant cracking sector, and you
would almost surely get snatched immediately, 'coz you would
believe you can crack it without knowing nothing at all. So, for
your sake, I'll teach you HOW TO LEARN IT, not HOW TO DO IT
(quite a fascinating difference): First Text, then the software
above. For text, start with Marcus Ranum's paper "Thinking about
Firewalls", available from ftp.tis.com in the file/pub/firewalls/firewalls.ps.Z
and do an archie search for newer literature.
Join the firewall discussion list sending a message to
majordomo@greatcircle.com, you'll get a message with
instructions, as usual, lurk only... never show yourself to the
others.
You can find for free on the web quite a lot of early
versions of proxy software. Study it, study it and then study it
again. The cracking efforts on your copies, and your machines,
before attempting anything serious, are MANDATORY if you do not
want to be immediately busted on the Internet. When you feel
ready to try serious cracking, you must OBLIGATORY start with a
small BBS which uses a firewall version you already studied very
well (sysops are not firewall administrators, and many of them
do not know nothing about the software they use). As soon as you
gain access to the bastion host, remember to subvert entirely the
firewall itself before entering the inner net.
If you feel ready and everything went well so far, if your zen-
cracking abilities are working well... then take a moment for
yourself... prepare yourself a good Martini-Wodka (you should
only use Moskovskaia), take a deep breath and by all means go
ahead! You will then be able to try your luck on the Cyberspace
and get quickly busted (if you did not follow my admonitions and
if you cannot zen-crack) or, may be, fish quite a lot of
jewels... :=)
-------------> INTERNET CRACKING: XINETD
[Xinetd] a freely available enhanced replacement for the
internet service daemon inetd, allows just those particular users
to have FTP or Telnet access, without opening up access to the
world. Xinetd can only protect the system from intrusion by
controlling INITIAL access to most system services and by logging
activities so that you can detect break-in attempts. However,
once a connection has been allowed to a service, xinetd is out
of the picture. It cannot protect against a server program that
has security problems internally. For example, the finger server
had a bug several years ago that allowed a particularly clever
person to overwrite part of its memory. This was used to gain
access to many systems. Even placing finger under the control of
xinetd wouldn't have helped.
Think of the secured firewall system as a fortress wall:
each service that is enabled for incoming connections can be
viewed as a door or window in the walls. Not all these doors have
secure and reliable locks. The more openings are available, the
more opportunities are open for us.
-------------> What xinetd does
Xinetd listens to all enabled service ports and permits only
those incoming connection request that meet authorization
criteria.
- Accept connections from only certain IP addresses
- Accept connections only from authorized users
- Reject connections outside of aithorized hours
- Log selected service when connections are accepted or
rejected, capturing following informations:
* Remote Host Address
* User ID of remote user (in some cases)
* Entry and Exit time
* Terminal type
Support login, shell, exec and finger
-------------> SERVICES TO CRACK &
UNWITTING INSIDE COMPLICES
In this order the easy services:
FTP TELNET LOGIN (rlogin) SHELL (rcmd) EXEC
In this order the more difficult ones:
MOUNT TFT FINGER NFS(Network File System)
DNS(Domain Name Service)
Remember that sendmail (SMTP), by default, accepts a message from
any incoming connection. The "sender" of such a message can
appear to have originated anywhere, therefore your claim of
identity will be accepted! Thus you can forge a message's
originator. Most of the recipients inside the protected
(firewalled) net will take your claim at face value and send you
(to the "return address" you provide) all the sensitive
information you need to crack the system. Finding unwitting
inside complices is most of the time pretty easy.
By far the best method, for entering xinetd, is to get the
real version from panos@cs.colorado.edu, modify the system files
in order to have some backdoors, and then distribute them to the
mirror servers on the WEB. Each time a new administrator will
download "your" version of xinetd, you'll have an easy access to
the "protected" system.
On the Nets, it's important to conceal your identity (they
will find you out pretty quickly if you do not). The best method
is to obtain the IP address of a legitimate workstation during
normal hours. Then, late at night, when the workstation is known
to be powered-off or disconnected from a dialup PPP link, a
different node on the network can be configured to use the
counterfeit IP address. To everyone on the network, it will
appear that the "legitimate" user is active. If you follow this
strategy, you may want to crack somehow more negligently... the
search for the cracker will go on -later- in the false confidence
that a sloppy novice (the legitimate user) is at work, this will
muddle the waters a little more.
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
LESSON C (1) - How to crack, Cracking as an art
---------------------------------------------------------------------------
[BARCODES] [INSTANT ACCESS]
--------------------------------------
[BARCODES]
First of all, let me stress the importance of cracking in
our everyday life. Cracking it's not just about software, it's
about information, about all patterns of life. To crack is to
refuse to be controlled and used by others, to crack is to be
free. But you must also be yourself free from petty conventions
in order to crack properly.
You must learn to discerne cracking possibilities all around
yourself, and believe me, the development of this ghastly society
brings every day new codes, protections and concealing
mechanismes.
All around us grows a world of codes and secret and not so
secret patterns. Codes that are at times so familiar and common
that we do not even notice them any more... and yet they are
there to fool us, and yet they offer marvellous cracking
possibilities.
Let's take as an striking example BARCODES... those little
lines that you see on any book you buy, on any bottle you get,
on any item around you... do you know how they work? If you do
not you may be excused, but you cannot be excused if you never
had the impulse to understand them... crackers are curious by
nature... heirs of an almost extinct race of researchers that has
nothing in common with the television slaves and the publicity
and trend zombies around us. Cracker should always be capable of
going beyond the obvious, seek knowledge where others do not see
and do not venture.
[BARCODE HISTORY]
Let's begin with a little history. Universal Product Code
(UPC) was adopted for commercial use by the grocery industry in
the USA. Among the advantages were a rapid, accurate and reliable
way of entering stock information into a computer and the
possibility to sack a lot of workers and to do more profit. The
early success led to the development of the European Article
Numbering System (EAN), a symbology similar to UPC, that is
widely used in Europe and in the rest of the World. I'll teach
you to crack this one, since I do not -fortunately- live in the
States. Keep in mind, anyway, that there are different barcode
symbologies, each with its own particular pattern of bars. The
UPC/EAN code used on retail products is an all-numeric code; so
is the Interleaved 2 of 5 Code. Code 39 includes upper case
letters, digits, and a few symbols. Code 128 includes every
printable and unprintable ASCII character code. The most new one
is a 2-D code. These are special rectangular codes, called
stacked barcodes or matrix codes. They can store considerably
more information than a standard barcode. They require special
readers which cost more than a standard scanner. The practical
limit for a standard barcode depends on a number of factors, but
20 to 25 characters is an approximate maximum. For applications
that need more data, matrix codes are used. For example, the next
time you receive a package from United Parcel Service look for
a small square label with a pattern of dots and a small bullseye
in the centre. This is a MaxiCode label, and it is used by UPS
for automatic destination sortition.
The manufacturer's ID number on the barcode uniquely
identifies products. These numbers are managed by the Uniform
Code Council in Dayton, Ohio for the States and Canada and by the
EAN authority (Internationale Article Numbering Association) in
Bruxelles, for Europe and the rest of the World. The
manufacturer's ID number accounts for some digits of the code,
which leaves other digits to be assigned in any way the producer
wants. He provides retail outlets with a list of his products and
their assigned codes so that they can be entered in the cash
register system. Many codes are NOT on the products and are added
by the supermarkets on the fly, using an internal code schema
that may be non standard. Now it's enough... let's crack.
BARCODES are the only thing an automated casher needs to see
on a product to calculate its price and automatically catalogate
the sold merchandise... imagine (just imagine it :=) coz it would
be extremely illegal to act in this way) somebody would fasten
an adhesive home-made codebar label direct on the top of the
supermarket/mall/retail store label, say on a bottle of Pomerol
(that's a very good but unfortunately very expensive french
wine).
The new label would mean for the casher something like
"cheap wine from Bordeaux, France, cost so and so, everything
it's OK, do not worry"... do you think that anybody would come
to the idea that there is something wrong with the label, with
the bottle or with you? I have been codebaring for years and had
only once a problem, coz my printer was running out of ink and
the scanner in the supermarket could not read it... so what? Act
uninterested, always wear jackets of the utmost quality, shetland
pullovers and beautiful expensive shoes... (all articles that you
may codebar too, by the way), in this society appearance and look
count much more than substance and knowledge... LET'S USE THIS
TO OUR ADVANTAGE! Nobody will ever come to the idea that you may
actually really know the working of the scheme... coz codebar is
pretty complicated and not exactly exceptionally public. On the
Web there are a lot information about it, but most of them are
useless, unless you know how to search most of the time you'll
find only sentences like this one:
"The calculated check digit is the twelfth and final
digit in the U.P.C.code. It is calculated based on a
specific algorithm, and is necessary to ensure that
the number is read or key-entered correctly."
But good +ORC will now explain you everything you need to crack:
[THE 13 BAR "CODES"]
Each barcode label has 13 values, from #0 to #12 (that's the EAN
code, the UPC american one has only 12, from #0 to #11).
#0 and #1 indicate the origin of the product.
#2 to #11 give the article code
#12 (the last and 13th one) is a checksum value, that
verifies the validity of all the other numbers.
How is it calculated? #12 is calculated in 4 steps
VALUE A: You sum odd position numbers (#0+#2+#4+#6+#8+#10)
VALUE B: You sum even position numbers and multiply by 3
((#1+#3+#5+#7+#9+#11)*3)
VALUE C: You sum value A and value B
VALUE D: You mod value C (you divide by 10 and only keep
the remaining units, a very widespread checking scheme as
you'll see in the software part of this lesson)
If the result is not zero, you subtract it from 10.
Now look at a barcode label, get some books or other barcoded
items and *watch* it...
Bar codes are supposed to have "quiet zones" on either side of
the symbol. Quiet zones are blank areas, free of any printing or
marks,typically 10 times the width of the narrowest bar or space
in the bar code. Failure to allow adequate space on either side
of the symbol for quiet zones can make it impossible to read the
bar code.
On the barcode there are two "borders", left and right, and a
"middle" longer line. These three lines are longer than the
others and are used to "regulate" the scanner to whatever
dimension has been used for the barcode.
#0 dwells left of the first (left) border and has a special
meaning, the other 12 numbers are written "inside" the code and
are divided in two "groups" by the middle bar.
Each value is coded through SEVEN bars: black=1 and White=0.
These form two couples of "optic" bars of different widths.
We come now to the "magic" part: In order to bluff the
simpletons, barcode uses three different SETS of characters to
represent the values 0-9. This should make it impossible for you
to understand what's going on, as usual, in this society, slaves
should not need to worry with the real functioning of things.
Here are the graphic codes of the three graphic sets:
CODE A CODE B (XOR C) CODE C (NOT A)
0: 0001101 (13) 0100111 (39) 1110010 (114)
1: 0011001 (25) 0110011 (51) 1100110 (102)
2: 0010011 (19) 0011011 (27) 1101100 (108)
3: 0111101 (61) 0100001 (33) 1000010 (066)
4: 0100011 (35) 0011101 (29) 1011100 (092)
5: 0110001 (49) 0111001 (57) 1001110 (078)
6: 0101111 (47) 0000101 (05) 1010000 (080)
7: 0111011 (59) 0010001 (17) 1000100 (068)
8: 0110111 (55) 0001001 (09) 1001000 (072)
9: 0001011 (11) 0010111 (23) 1110100 (116)
Borders: 101
Centre: 01010
- The C graphic set is a "NOT A" graphic set.
- The B graphic set is a "XOR C" graphic set.
- each value has two couples of bars with different widths
Now watch some labels yourself... see the difference between the
numbers left and the numbers right? The first "half" of the
barcode is coded using sets A and B, the second "half" using set
C. As if that were not enough, A and B are used inside the first
"half" in a combination that varies and depends from value #0,
following 10 different patterns:
#1 #2 #3 #4 #5 #6
0 A A A A A A
1 A A B A B B
2 A A B B A B
3 A A B B B A
4 A B A A B B
5 A B B A A B
6 A B B B A A
7 A B A B A B
8 A B A B B A
9 A B B A B A
"Ah! Stupid buyer will never understand why the same values gives
different bars! Nothing is as reliable as barcodes!" :=)
Let's take as example the codebar for Martini Dry:
BARCODE: 8 0 00570 00425 7
Let's see: we have a 8 0 0 = booze
Then a 000570 as ABABBA and a 004257 as C
"Even" sum: 8+0+5+0+0+2 = 15 (even sum)
Then a 0+0+7+0+4+5= 16 and 16 *3 = 48 (odd sum)
Then a 15+48=63
63 === 3
10 - 3 = 7 = checksum
Pattern = 8 = ABABBA CCCCCC
OK, one more example: Osborne Windows programming series Volume
2 General purpose API functions (always here on my table)...
BARCODE: 9 7 80078 81991 9
Let's see: we have a 9 7 8 = book
Then a 780078 as ABBABA and a 819919 as C
"Even" sum: 9+8+5+8+8+4 = 42 (even sum)
Then a 7+1+5+2+4+4= 23 and 23 * 3 = 69 (odd sum)
Then a 42+69=111
111 === 1
10 - 1 = 9 = checksum
Pattern = 9 = ABBABA
Well... what's the point of all this?
The point, my pupils, is that who DOES NOT KNOW is taken along
on a boat ride, who KNOWS and LEARNS can use his knowledge in
order to try to beat blue and black the loathsome consumistic
oligarchy where we are compelled to live. Try it out for
yourself... if you crack correctly and wisely your supermarket,
mall and library bills will be cut to almost zero.
Write a small program to print whichever codebar you fancy
(or whichever your mall uses) in whichever size on whichever sort
of label you (or better your targets) fancy... it's quickly done
with Visualbasic or Delphy... but you'll not find much on the Web
Alternatively you could also write, as I did long ago, a short
c program in dos, using a modified upper char set... and there
you are, have labels... see the world.
A small word of caution... crack only ONE item at time and
try it out first with the SAME label for the same product... i.e.
the correct code for that item, but on your own label. If it goes
through your program works good, if not, nobody will ever be able
to harm you. Anyway it never happens anything, never: the bar
code reading equipments have great tolerance, coz the scanners
must be able to recognize barcodes that have been printed on many
different medias. You should choose labels similar to the ones
effectively used only in order not to arise human suspects, coz
for all the scanner itself cares, your label could be pink with
green stripes and with orange hand-written, numbers. Mind you,
we are still just academically imagining hypothetical situations,
coz it would be extremely illegal to act in such an inconsiderate
manner.
CRACKING POWER! It's true for barcodes, for Telecom bills,
for Compuserve accounts, for Amexco cards, for banking cheques
(do you know what MICR is? Magnetic Ink Character Recognition...
the stylized little printing on the lower left of new cheques...
there is a whole cracking school working on it), for registration
numbers... you name it, they develope it, we crack it...
Begin with barcodes: it's easy, nice and pretty useful! Live
in opulence, with the dignity and affluence that should always
distinguish real crackers. Besides... you should see the
assortment of 'Pomerols' in my "Cave-a-vin" :=)
[INSTANT ACCESS]
The (c) Instant access routines are a commercial protection
scheme used to "unlock" complete commercial applications that
have been encrypted on CD-
ROMs which are distributed (mostly) through reviews.
This is an ideal cracking target: it's commercial software,
complete, uncrippled and of (relatively) prominent quality, that
you can get in tons for the price of a coke. Obviously this kind
of protection represents an ideal subject for our lessons. This
fairly intricate protection scheme has not yet been cracked by
anybody that I am aware of, anyway not publicly, therefore it's
an ideal candidate for a "strainer" to my university. I'll teach
you here how to crack it in three lessons, C.1, C.2 and C.3. I warn
you... it's a difficult cracking session, and this protection
represents quite an intellectual challenge. But if you are
seriously interested in our trade you will enjoy these lessons
more than anything else.
This cracking is intended as an "assignment" for my +HCU
"cracking university": you'll find inside lessons C.1 and C.2 a
relatively deep "introduction" to Instant access cracking. This
will teach you a lot anyway, and spare you hours of useless
roaming around, bringing you straight to the cracking point. But
I'll release the third part of this session, with the complete
solution (lesson C.3) on the Web only in october 1996, not a day
before. All the students that would like to apply to the Higher
Cracking University, opening on the web 01/01/1997, should work
in July, August and September (three months is more than enough
time) on this assignment. They should crack completely the
instant access scheme and send me their solutions, with a good
documentation of their cracking sessions, before 30/09/1996
(WATCH IT! You can crack this scheme in -at least- three
different paths, be careful and choose the *best* one. WATCH IT!
Some of the informations) in lesson C.1 and C.2 are slightly incorrect:
check it!).
There are four possibilities:
1) The candidate has not found the crack or his solution is
not enough documented or not enough viable... the candidate
is therefore not (yet) crack-able, he will not be admitted
to the +HCU 1997 curses, better luck in 1998;
2) The cracking solution proposed by the candidate is not as
good as mine (you'll judge for yourself in october) but it
works nevertheless... he'll be admitted at the 1997
courses;
3) The cracking solution of the candidate is more or less
equal to mine, he'll be admitted, personally monitored, and
he'll get all the material he needs to crack on higher
paths;
4) The cracking solution of the candidate is better than mine,
he'll be admitted, get all the material he wishes and asked
to teach us as well as study with us: "homines, dum docent,
discunt".
[Cracking Instant access]
The user that wants to "unlock" a software application
protected with (c) Instant Access must enter first of all a
REGISTRATION number string, which through a series of
mathematical manipulations gives birth to a special "product"
code. On the basis of this "product code" the user is asked to
phone the commercial protectors (and pay) in order to get a
special "unlock code" that will allow him to decrypt the relevant
software.
This kind of "passnumber" protection routines are widely
used for software unlocking, BBS access, server access, backdoor
opening and many other protection schemes. We have already seen
password cracks in different lessons of this tutorial (in
particular Lessons 3.1 and 3.2 for DOS and Lessons 8.1, 8.2 and
9.1 for WIN) albeit on a more simplistic scale: there it did
mostly not matter very much *HOW* you passed the protection: once
passed, you could have access to the application. This is not the
case with (c) Instant Access. Face it: it's a little boring, but
important that you learn how to defeat intricate protection
routines (you'll meet them often in the next years) and I believe
that the following example will give you a "feeling" for the
right cracking approach.
In this case we must not only "crack" this protection scheme
but also study it thoroughly in order to achieve our blessed
aims. This is a very good exercise: reverse disassembling will
teach you a lot of little tricks that you'll be able to use in
your other future cracking sessions.
Instant access (c) is a exceptionally widespread protection
scheme, and it should be relatively easy for you to gather some
encrypted software that has been protected with this method...
*DO IT QUICKLY!!* After the Web publishing of this lessons (I am
sending C.1 to 8 pages and 4 usenet groups on 25/06/1996) this
protection is obviously as dead as a Dodo. The "Accessors" guys
will have to conceive something smarter if they want to keep
selling "protections" to the lamer producers of "big" software.
BTW, if you are reading this and are working for some
commercial "protection" company, consider the possibility to
double cross your masters! Deliver me anonymously all the future
projects you are working on! That will amuse me, speed up the
advent of a true altruistic society and earn you the respect of
the better part of humanity.
As I said, many "huge" application are still protected with
this "Instant access" system. I have personally bought at least
7 or 8 "second hand" CD-ROMs packed full with Microsoft, Lotus,
Norton, Symantec, you name it, applications all "protected"
through this crap. The cost of this bunch of CD-ROMs was the
equivalent of a bottle of Dry Martini, maybe less. The same
software is sold, unlocked, to zombies and lusers for ludicrous
amounts of money.
Never buy CD-ROMs magazines when they appear! Be cool! Buy
them two or three months after the publishing date! Buy
"remainders" or "second hand" CD-ROM magazines "at kilo price"...
Come to think of it, never buy *anything* when it appears or when
some (paid) advertiser tells you to... remember that "trends",
"vogues", "fashions" and "modes" are only different names for the
whips that drill and chain the dull-witted slaves of this
loathsome society: "clever crackers consider cool, crack cheap,
cheat customary culture" (a rhetorical figure: an "Alliteration".
To defend yourself learn rhetoric... it's a more powerful and
more useful weapon than Kung-fu).
The "triple" password protection routine in (c) Instant
Access is very interesting from a cracker point of view. It's a
relatively complex scheme: I'll teach you to crack it in two
phases: First of all you must find the "allowed" registration
code, the one that "ignites" the "product code". We must crack
and understand this re_code first if we want to crack the rest.
Just for the records, I am cracking here (c) Action Instant
access version 1.0 (CD-ROM found on a old copy of "Personal
Computer World" of August 1994, packed full with encrypted Lotus,
Symantec, Claris and Wordperfect applications. Just to be sure
I crosschecked my results with another CD-ROM which also has
applications protected with (c) Instant Access: Paragon
Publishing's PC OFFICE: the protection scheme remains the same).
I am focusing for this lesson on the cracking of the specific
protection for the encrypted Symantec's Norton Utilities v.8.0.
Please refer to the previous lessons for the basic
techniques used in order to find the protection routine inside
our babe... for "low" cracking purposes you -basically- type a
number (in this case, where the input gets 10 numbers, we'll use
"1212-1212-12"), do your search inside the memory (s 30:0
lffffffff "your_string") and then set memory breakpoints on all
the relevant memory locations till winice pops (I know, I know,
buddies... there are more effective ways... but hold your mouth:
for now we'll keep them among us: let's make things a little
harder for the protectionists who read this... Besides: the old
approach works here flawlessly). After getting the Registration
window on screen the Winice standard procedure is:
:task ; how
:heap IABROWSE ; where & what
:hwnd IABROWSE ; get the Winhandle
:bpx [winhandle] WM_GETTEXT ; pinpoint code
:bpx GetProcAddress ; in case of funny routines
:dex 0 ds:dx ; let's see their name
:gdt ; sniff the selectors
:s 30:0 lffffffff "Your_input_string" ; search in 4 giga data
:bpr [all memory ranges for your string that are above 80000000]
and so on. (continued in lesson C.2)
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you rediscovered them
with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
HOW TO CRACK, by +ORC, A TUTORIAL
---------------------------------------------------------------------------
LESSON C (2) - How to crack, Cracking as an art
---------------------------------------------------------------------------
[INSTANT ACCESS]
--------------------------------------
cracking Instant Access (2) - strainer for the +HCU
[SEE LESSON C.1 for the first part of this cracking session]
Here follow the relevant protection routines for the first
(The "Registration") number_code of Instant Access, with my
comments: you have to investigate a little the following code.
Later, when you'll crack on your own, try to recognize the
many routines that fiddle with input BEFORE the relevant (real
protection) one. In this case, for instance, a routine checks the
correctness of the numbers of your input:
This_loop_checks_that_numbers_are_numbers:
1B0F:2B00 C45E06 LES BX,[BP+06] ; set/reset pointer
1B0F:2B03 03DF ADD BX,DI
1B0F:2B05 268A07 MOV AL,ES:[BX] ; get number
1B0F:2B08 8846FD MOV [BP-03],AL ; store
1B0F:2B0B 807EFD30 CMP BYTE PTR [BP-03],30
1B0F:2B0F 7C06 JL 2B17 ; less than zero?
1B0F:2B11 807EFD39 CMP BYTE PTR [BP-03],39
1B0F:2B15 7E05 JLE 2B1C ; between 0 & 9?
1B0F:2B17 B80100 MOV AX,0001 ; no, set flag=1
1B0F:2B1A EB02 JMP 2B1E ; keep flag
1B0F:2B1C 33C0 XOR AX,AX ; flag=0
1B0F:2B1E 0BC0 OR AX,AX ; is it zero?
1B0F:2B20 7507 JNZ 2B29 ; flag NO jumps away
1B0F:2B22 8A46FD MOV AL,[BP-03] ; Ok, get number
1B0F:2B25 8842CC MOV [BP+SI-34],AL ; Ok, store number
1B0F:2B28 46 INC SI ; inc storespace
1B0F:2B29 47 INC DI ; inc counter
1B0F:2B2A C45E06 LES BX,[BP+06] ; reset pointer
1B0F:2B2D 03DF ADD BX,DI ; point next number
1B0F:2B2F 26803F00 CMP BYTE PTR ES:[BX],00 ; input end?
1B0F:2B33 75CB JNZ 2B00 ; no:loop next num
You now obviously understand that the "real" string is
stored inside memory location [BP+SI-34]... set a memory
breakpoint on this area to get the next block of code that
fiddles with the transformed input. Notice how this routine
"normalizes" the input, strips the "-" off and puts the 10
numbers together:
user input: 1 2 1 2 1 2 1 2 1 2 End
1E7F:92E2 31 32 31 32 31 32 31 32 31 32 00 45 AF 1F 70 9B
Stack ptr: 0 1 2 3 4 5 6 7 8 9 A B C D E F
Let's now look at the "real" protection routine: the one
that checks these numbers and throw you out if they are not
"sound". Please pay attention to the following block of code:
check_if_sum_other_9_numbers_=_remainder_of_the_third_number:
:4B79 8CD0 MOV AX,SS ; we'll work inside the stack...
:4B7B 90 NOP
:4B7C 45 INC BP
:4B7D 55 PUSH BP ; save real BP
:4B7E 8BEC MOV BP,SP ; BP = stackpointer
:4B80 1E PUSH DS ; save real Datasegment
:4B81 8ED8 MOV DS,AX ; Datasegment = stacksegment
:4B83 83EC04 SUB SP,+04
:4B86 C45E06 LES BX,[BP+06] ; BX points input_start
:4B89 268A07 MOV AL,ES:[BX] ; load first number
:4B8C 98 CBW ; care only for low
:4B8D C45E06 LES BX,[BP+06] ; reset pointer
:4B90 50 PUSH AX ; save 1st number
:4B91 268A4701 MOV AL,ES:[BX+01] ; load 2nd number
:4B95 98 CBW ; only low
:4B96 8BD0 MOV DX,AX ; 2nd number in DX
:4B98 58 POP AX ; get 1st number
:4B99 03C2 ADD AX,DX ; sum with second
:4B9B C45E06 LES BX,[BP+06] ; reset pointer
:4B9E 50 PUSH AX ; save sum
:4B9F 268A4707 MOV AL,ES:[BX+07] ; load 8th number
:4BA3 98 CBW ; only low
:4BA4 8BD0 MOV DX,AX ; 8th number in DX
:4BA6 58 POP AX ; old sum is back
:4BA7 03C2 ADD AX,DX ; sum 1+2+8
:4BA9 C45E06 LES BX,[BP+06] ; reset pointer
:4BAC 50 PUSH AX ; save sum
:4BAD 268A4703 MOV AL,ES:[BX+03] ; load 4rd number
:4BB1 98 CBW ; only low
:4BB2 8BD0 MOV DX,AX ; #4 in DX
:4BB4 58 POP AX ; sum is back
:4BB5 03C2 ADD AX,DX ; sum 1+2+8+4
:4BB7 C45E06 LES BX,[BP+06] ; reset pointer
:4BBA 50 PUSH AX ; save sum
:4BBB 268A4704 MOV AL,ES:[BX+04] ; load 5th number
:4BBF 98 CBW ; only low
:4BC0 8BD0 MOV DX,AX ; #5 in DX
:4BC2 58 POP AX ; sum is back
:4BC3 03C2 ADD AX,DX ; 1+2+8+4+5
:4BC5 C45E06 LES BX,[BP+06] ; reset pointer
:4BC8 50 PUSH AX ; save sum
:4BC9 268A4705 MOV AL,ES:[BX+05] ; load 6th number
:4BCD 98 CBW ; only low
:4BCE 8BD0 MOV DX,AX ; #6 in DX
:4BD0 58 POP AX ; sum is back
:4BD1 03C2 ADD AX,DX ; 1+2+8+4+5+6
:4BD3 C45E06 LES BX,[BP+06] ; reset pointer
:4BD6 50 PUSH AX ; save sum
:4BD7 268A4706 MOV AL,ES:[BX+06] ; load 7th number
:4BDB 98 CBW ; only low
:4BDC 8BD0 MOV DX,AX ; #7 in DX
:4BDE 58 POP AX ; sum is back
:4BDF 03C2 ADD AX,DX ; 1+2+8+4+5+6+7
:4BE1 C45E06 LES BX,[BP+06] ; reset pointer
:4BE4 50 PUSH AX ; save sum
:4BE5 268A4708 MOV AL,ES:[BX+08] ; load 9th number
:4BE9 98 CBW ; only low
:4BEA 8BD0 MOV DX,AX ; #9 in DX
:4BEC 58 POP AX ; sum is back
:4BED 03C2 ADD AX,DX ; 1+2+8+4+5+6+7+9
:4BEF C45E06 LES BX,[BP+06] ; reset pointer
:4BF2 50 PUSH AX ; save sum
:4BF3 268A4709 MOV AL,ES:[BX+09] ; load 10th #
:4BF7 98 CBW ; only low
:4BF8 8BD0 MOV DX,AX ; #10 in DX
:4BFA 58 POP AX ; sum is back
:4BFB 03C2 ADD AX,DX ; 1+2+8+4+5+6+7+9+10
:4BFD 0550FE ADD AX,FE50 ; clean sum to 0-51
:4C00 BB0A00 MOV BX,000A ; BX holds 10
:4C03 99 CWD ; only AL
:4C04 F7FB IDIV BX ; remainder in DX
:4C06 C45E06 LES BX,[BP+06] ; reset pointer
:4C09 268A4702 MOV AL,ES:[BX+02] ; load now # 3
:4C0D 98 CBW ; only low
:4C0E 05D0FF ADD AX,FFD0 ; clean # 3 to 0-9
:4C11 3BD0 CMP DX,AX ; remainder = pampered #3?
:4C13 7407 JZ 4C1C ; yes, go on good guy
:4C15 33D2 XOR DX,DX ; no! beggar off! Zero DX
:4C17 33C0 XOR AX,AX ; and FLAG_AX = FALSE
:4C19 E91701 JMP 4D33 ; go to EXIT
let's_go_on_if_first_check_passed:
:4C1C C45E06 LES BX,[BP+06] ; reset pointer
:4C1F 268A4701 MOV AL,ES:[BX+01] ; now load #2 anew
:4C23 98 CBW ; only low
:4C24 05D7FF ADD AX,FFD7 ; pamper adding +3
:4C27 A38D5E MOV [5E8D],AX ; save SEC_+3
:4C2A 3D0900 CMP AX,0009 ; was it < 9? (no A-F)
:4C2D 7E05 JLE 4C34 ; ok, no 0xletter
:4C2F 832E8D5E0A SUB WORD PTR [5E8D],+0A ; 0-5 if A-F
:4C34 C45E06 LES BX,[BP+06] ; reset pointer
:4C37 268A07 MOV AL,ES:[BX] ; load 1st input number
:4C3A 98 CBW ; only low
:4C3B 05C9FF ADD AX,FFC9 ; pamper adding +7
:4C3E A38F5E MOV [5E8F],AX ; save it in FIR_+7
:4C41 0BC0 OR AX,AX ; if #1 > 7
:4C43 7D05 JGE 4C4A ; no need to add 0xA
:4C45 83068F5E0A ADD WORD PTR [5E8F],+0A ; FIR_+7 + 0xA
now_we_have_the_sliders_let's_prepare_for_loop:
:4C4A C45E0E LES BX,[BP+0E] ; Set pointer to E
:4C4D 26C747020000 MOV WORD PTR ES:[BX+02],0000 ; 0 flag
:4C53 26C7070000 MOV WORD PTR ES:[BX],0000 ; 0 flag
:4C58 C706975E0900 MOV WORD PTR [5E97],0009 ; counter=9
:4C5E E99500 JMP 4CF6 ; Jmp check_counter
loop_8_times:
:4C61 C45E06 LES BX,[BP+06] ; reset pointer
:4C64 031E975E ADD BX,[5E97] ; add running counter
:4C68 268A07 MOV AL,ES:[BX] ; load # counter+1
:4C6B 98 CBW ; only low
:4C6C 50 PUSH AX ; save 10th number
:4C6D A18D5E MOV AX,[5E8D] ; ld SEC_+3 down_slider
:4C70 BA0A00 MOV DX,000A ; BX holds 0xA
:4C73 F7EA IMUL DX ; SEC_+3 * 0xA
:4C75 03068F5E ADD AX,[5E8F] ; plus FIR_+7 up_slider
:4C79 BAA71E MOV DX,1EA7 ; fixed segment
:4C7C 8BD8 MOV BX,AX ; BX = Lkup_val=(SEC_+3*10+FIR_+7)
:4C7E 8EC2 MOV ES,DX ; ES = 1EA7
:4C80 268A870000 MOV AL,ES:[BX+0000] ; ld 1EA7:[Lkup_val]
:4C85 98 CBW ; only low: KEY_PAR
:4C86 8BD0 MOV DX,AX ; save KEY_PAR in DX
:4C88 58 POP AX ; repops 10th number
:4C89 03C2 ADD AX,DX ; RE_SULT=KEY_PAR+#10
:4C8B 05D0FF ADD AX,FFD0 ; polish RE_SULT
:4C8E 99 CWD ; only low: RE_SULT
:4C8F 8956FC MOV [BP-04],DX ; save here KEY_PAR [9548]
:4C92 8946FA MOV [BP-06],AX ; save here RE_SULT [9546]
:4C95 0BD2 OR DX,DX ; KEY_PAR < 0?
:4C97 7C0F JL 4CA8 ; yes: KEY_PAR < 0
:4C99 7F05 JG 4CA0 ; no: KEY_PAR > 0
:4C9B 3D0900 CMP AX,0009 ; KEY_PAR = 0
:4C9E 7608 JBE 4CA8 ; no pampering if RE_SULT < 9
:4CA0 836EFA0A SUB WORD PTR [BP-06],+0A ; else pamper
:4CA4 835EFC00 SBB WORD PTR [BP-04],+00 ; and SBB [9548]
:4CA8 C45E0E LES BX,[BP+0E] ; reset pointer to E
:4CAB 268B4F02 MOV CX,ES:[BX+02] ; charge CX [958C]
:4CAF 268B1F MOV BX,ES:[BX] ; charge BX slider [958A]
:4CB2 33D2 XOR DX,DX ; clear DX to zero
:4CB4 B80A00 MOV AX,000A ; 10 in AX
:4CB7 9A930D2720 CALL 2027:0D93 ; call following RO_routine
This is the only routine called from our protection, inside the
loop (therefore 8 times), disassembly from WCB. Examining this
code please remember that we entered here with following
configuration: DX=0, AX=0xA, CX=[958C] and BX=[958A]...
1.0D93 56 push si ; save si
1.0D94 96 xchg ax, si ; ax=si, si=0xA
1.0D95 92 xchg ax, dx ; dx=0xA ax=dx
1.0D96 85C0 test ax, ax ; TEST this zero
1.0D98 7402 je 0D9C ; zero only 1st time
1.0D9A F7E3 mul bx ; BX slider! 0/9/5E/3B2...
1.0D9C >E305 jcxz 0DA3 ; cx=0? don't multiply!
1.0D9E 91 xchg ax, cx ; cx !=0? cx = ax & ax = cx
1.0D9F F7E6 mul si ; ax*0xA in ax
1.0DA1 03C1 add ax, cx ; ax= ax*0xA+cx = M_ULT
1.0DA3 >96 xchg ax, si ; ax=0xA; si evtl. holds M_ULT
1.0DA4 F7E3 mul bx ; ax= bx*0xA
1.0DA6 03D6 add dx, si ; dx= dx_add
1.0DA8 5E pop si ; restore si
1.0DA9 CB retf ; back to caller with two
parameters: DX and AX
Back_to_main_protection_loop_from_RO_routine:
:4CBC C45E0E LES BX,[BP+0E] ; reset pointer
:4CBF 26895702 MOV ES:[BX+02],DX ; save R_DX par [958C]
:4CC3 268907 MOV ES:[BX],AX ; save R_AX par [958A]
:4CC6 0346FA ADD AX,[BP-06] ; add to AX RE_SULT [9546]
:4CC9 1356FC ADC DX,[BP-04] ; add to DX KEY_PAR [9548]
:4CCC C45E0E LES BX,[BP+0E] ; reset pointer
:4CCF 26895702 MOV ES:[BX+02],DX ; save R_DX+KEY_PAR [958C]
:4CD3 268907 MOV ES:[BX],AX ; save R_AX+RE_SULT [958A]
:4CD6 FF0E8D5E DEC WORD PTR [5E8D] ; down_slide SEC_+3
:4CDA 7D05 JGE 4CE1 ; no need to add
:4CDC 83068D5E0A ADD WORD PTR [5E8D],+0A ; pamper adding 10
:4CE1 FF068F5E INC WORD PTR [5E8F] ; up_slide FIR_+7
:4CE5 A18F5E MOV AX,[5E8F] ; save upslided FIR_+7 in AX
:4CE8 3D0900 CMP AX,0009 ; is it over 9?
:4CEB 7E05 JLE 4CF2 ; no, go on
:4CED 832E8F5E0A SUB WORD PTR [5E8F],+0A ; yes, pamper -10
:4CF2 FF0E975E DEC WORD PTR [5E97] ; decrease loop counter
check_loop_counter:
:4CF6 833E975E03 CMP WORD PTR [5E97],+03 ; counter = 3?
:4CFB 7C03 JL 4D00 ; finish if counter under 3
:4CFD E961FF JMP 4C61 ; not yet, loop_next_count
loop_is_ended:
:4D00 C45E06 LES BX,[BP+06] ; reset pointer to input
:4D03 268A4701 MOV AL,ES:[BX+01] ; load 2nd number (2)
:4D07 98 CBW ; only low
:4D08 05D0FF ADD AX,FFD0 ; clean it
:4D0B BA0A00 MOV DX,000A ; DX = 10
:4D0E F7EA IMUL DX ; AX = SEC_*10 = 14
:4D10 C45E06 LES BX,[BP+06] ; reset pointer
:4D13 50 PUSH AX ; save SEC_*10
:4D14 268A07 MOV AL,ES:[BX] ; load 1st number (1)
:4D17 98 CBW ; only low
:4D18 8BD0 MOV DX,AX ; save in DX
:4D1A 58 POP AX ; get SEC_*10
:4D1B 03C2 ADD AX,DX ; sum SEC_*10+1st number
:4D1D 05D0FF ADD AX,FFD0 ; clean it
:4D20 99 CWD ; only low
:4D21 C45E0A LES BX,[BP+0A] ; get pointer to [9582]
:4D24 26895702 MOV ES:[BX+02],DX ; save 1st (1) in [9584]
:4D28 268907 MOV ES:[BX],AX ; save FINAL_SUM (15) [9582]
:4D2B 33D2 XOR DX,DX ; DX = 0
:4D2D B80100 MOV AX,0001 ; FLAG TRUE !
:4D30 E9E6FE JMP 4C19 ; OK, you_are_a_nice_guy
EXIT:
:4D33 59 POP CX ; pop everything and
:4D34 59 POP CX ; return with flag
:4D35 1F POP DS ; AX=TRUE if RegNum OK
:4D36 5D POP BP ; with 1st # in [9584]
:4D37 4D DEC BP ; with FINAL_SUM in [9582]
:4D38 CB RETF
Let's translate the preceding code: first of all the pointers:
At line :4B86 we have the first of a long list of stack ptrs:
LES BX,[BP+06]
This stack pointer points to the beginning of the input string,
which, once polished from the "-", has now a length of 10 bytes,
concluded by a 00 fence. At the beginning, before the main loop,
9 out of our 10 numbers are added, all but the third one.
Notice that protection has jumped # 3 (and added # 8 out of the
line). The rest is straightforward. Now, at line :4BFD we have
our first "cleaning" instruction. You see: the numbers are
hexadecimal represented by the codes 0x30 to 0x39. If you add
FE50 to the minimum sum you can get adding 9 numbers (0x30*9 =
0x160) You get 0. The maximum you could have adding 9 numbers,
on the contrary is (0x39*9=0x201), which, added to FE50 gives
0x51. So we'll have a "magic" number between 0x0 and 0x51 instead
of a number between 0x160 and 0x201. Protection pampers this
result, and retains only the last ciffer: 0-9. Then protection
divides this number through 0xA, and what happens? DX get's the
REMAINDER of it.
If we sum the hexcodes of our (1212-1212-12) we get 0x1BE (we
sum only 9 out of then numbers: the third "1" -i.e. "31"- does
not comes into our count); 0x1BE, cleaned and pampered gives E.
Therefore (0xE/0xA = 1) We get 1 with a remainder of 4.
You may observe that of all possible answers, only sums
finishing with A, B, C, D, E or F give 1 (and rem=0,1,2,3,4 or
5). Sums finishing 0 1 2 3 4 5 6 7 8 or 9 give 0 as result and
themselves as reminder. The chance of getting a 0,1,2,3 or 4 are
therefore bigger as the chance of getting a 5, 6, 7, 8 or 9. We
are just observing... we do not know yet if this should play a
role or not.
Now this remainder is compared at :4C11 with the third number
polished from 0x30-0x39 to 0-9. This is the only protection check
for the registration number input: If your third number does not
match with the remainder of the sum of all the 9 others numbers
of your input you are immediately thrown out with FLAG AX=FALSE
(i.e. zero).
To crack the protection you now have to MODIFY your input string
accordingly. Our new input string will from now on be "1242-1212-
12": we have changed our third number (originally a "2") to a "4"
to get through this first strainer in the correct way. Only now
protection starts its mathematical part (We do not know yet why
it does it... in order to seed the random product number? To
provide a check for the registration number you'll input at the
end? We'll see).
- Protection saves the second number of your input (cleaned
with FFD7) in SEC_+3 [5E8D], pampering it if it is bigger
than 9 (i.e. if it is 0xA-0xF). Here you'll have therefore
following correspondence: 0=7 1=8 2=9 3=0 4=1 5=2 6=3 7=4
8=5 9=6. The second number of your input has got added +3.
This is value SEC_+3. In (lengthy) C it would look like
this:
If (RegString(2)is lower than 7) RegString(2) = RegString(2)+3
Else Regstring(2) = ((RegString(2)-10)+3)
- Protection saves your first number in FIR_+7 [5E8F] with a
different cleaning parameter (FFC9). The next pampering
adds 0xA if it was not 7/8/9 therefore you have here
following correspondence 7=0 8=1 9=2 0=3 1=4 2=5 3=6 4=7
5=8 6=9). This is value FIR_+7. In (lengthy) C it would
look like this:
If (RegString(1) is lower than 3) RegString(1) = RegString(1)+7
Else Regstring(1) = ((RegString(1)-10)+7)
So protection has "transformed" and stored in [5E8D] and [5E8F]
the two numbers 1 and 2. In our RegString: 1242-1212-12 the first
two numbers "12" are now stored as "94". These will be used as
"slider" parameters inside the main loop, as you will see.
Only now does protection begin its main loop, starting from the
LAST number, because the counter has been set to 9 (i.e. the
tenth number of RegString). The loop, as you'll see, handles only
the numbers from 10 to 3: it's an 8-times loop that ends without
handling the first and second number. What happens in this
loop?... Well, quite a lot: Protection begins the loop loading
the number (counter+1) from the RegString. Protection then loads
the SEC_+3 down_slider parameter (which began its life as second
number "transformed"), multiplies it with 0xA and then adds the
up_slider parameter FIR_+7 (at the beginning it was the first
number transformed).
This sum is used as "lookup pointer" to find a parameter
inside a table of parameters in memory, which are all numbers
between 0 and 9. Let's call this value Lkup_val.
Protection looks for data in 1EA7:[Lkup_val]. In our case (we
entered 1242-1212-12, therefore the first SEC_+3 value is 9 and
the first FIR_+7 value is 4): [Lkup_val] = 9*0xA+4; 0x5A+4 =
0x5E. At line :4C80 therefore AL would load the byte at 1EA7:005E
(let's call it KEY_PAR), which now would be ADDED to the #
counter+1 of this loop. In our case KEY_PAR at 1EA7:005E it's a
"7" and is added to the pampered 0x32=2, giving 9.
Let's establish first of all which KEY_PAR can possibly get
fetched: the maximum is 0x63 and the minimum is 0x0. The possible
KEY_PARs do therefore dwell in memory between 1EA7: and
1EA7:0063. Let's have a look at the relative table in memory,
where these KEY_PARs are stored ("our" first 0x5Eth byte is
underlined):
1EA7:0000 01 03 03 01 09 02 03 00-09 00 04 03 08 07 04 04
1EA7:0010 05 02 09 00 02 04 01 05-06 06 03 02 00 08 05 06
1EA7:0020 08 09 05 00 04 06 07 07-02 00 08 00 06 02 04 07
1EA7:0030 04 04 09 05 09 06 00 06-08 07 00 03 05 09 00 08
1EA7:0040 03 07 07 06 08 09 01 05-07 04 06 01 04 02 07 01
1EA7:0050 03 01 08 01 05 03 03 01-02 08 02 01 06 05 07 02
1EA7:0060 05 09 09 08 02 09 03 00-00 04 05 01 01 03 08 06
1EA7:0070 01 01 09 00 02 05 05 05-01 07 01 05 08 07 01 09
1EA7:0080 08 07 07 04 04 08 03 00-06 01 09 08 08 04 09 09
1EA7:0090 00 07 05 02 03 01 03 08-06 05 07 06 03 07 06 07
1EA7:00A0 04 02 02 05 02 04 06 02-06 09 09 01 05 02 03 04
1EA7:00B0 04 00 03 05 00 03 08 07-06 04 08 08 02 00 03 06
1EA7:00C0 09 00 00 06 09 04 07 02-00 01 01 01 01 00 01 FF
1EA7:00D0 00 FF FF FF FF 00 FF 01-00 00 00 00 00 00 00 00
An interesting table, where all the correspondences are
between 0 and 9... are we getting some "secret" number here? But,
hey, look there... funny, isn't it? Instead of only 0-0x63 bytes
we have roughly the DOUBLE here: 0-0xC8 bytes (the 01 sequence
starting at CA "feels" like a fence). We'll see later how
important this is. At the moment you should only "perceive" that
something must be going on with a table that's two time what she
should be.
As I said the result of KEY_PAR + input number is polished
(with a FFDO) and pampered (subtracting, if necessary, 0xA).
Therefore the result will be the (counter+1) input number +
KEY_PAR (let's call it RE_SULT], in our case, (at the beginning
of the loop) a 9. Now (DX=0 because of the CWD instruction) DX
will be saved in [9548] and RE_SULT in [9546].
Now Protection prepares for the RO_routine: resets its pointer
and charges CX and BX from [958C] and from [958A] respectively,
charges AX with 0xA and sets DX to zero.
The routine performs various operations on AX and DX and saves
the results in the above mentioned locations [958A] and [958C].
Now KEY_PAR and RE_SULT are added respectively to the DX and AX
value we got back from the RO_routine call, and saved once more
in the last two locations: AX+RE_SULT in [958A] and DX+KEY_PAR
in [958C]
Now the value in SEC_+3 is diminished by 1 (if it was 9 it's now
8, if it was zero it will be pampered to 9). It's a "slider"
parameter (in this case a down_slider), typically used in
relatively complicated protections to give a "random" impression
to the casual observer. The value in FIR_+7, on the contrary, is
augmented by one, from 4 to 5... up_sliding also.
Protection now handles the next number of your input for the
loop. In our case this loop uses following protection
configuration with our "sliding" parameters:
Input # pamp_2nd pamp_1st Lookup value KEY_PAR # RE_SULT
# 10 = 2, SEC_+3= 9, FIR_+7= 4, Lkup_val = 0x5E, KEY=7 +2 = 9
# 9 = 1, SEC_+3= 8, FIR_+7= 5, Lkup_val = 0x55, KEY=3 +1 = 4
# 8 = 2, SEC_+3= 7, FIR_+7= 6, Lkup_val = 0x4C, KEY=4 +2 = 6
# 7 = 1, SEC_+3= 6, FIR_+7= 7, Lkup_val = 0x43, KEY=7 +1 = 7
# 6 = 2, SEC_+3= 5, FIR_+7= 8, Lkup_val = 0x3A, KEY=0 +2 = 2
# 5 = 1, SEC_+3= 4, FIR_+7= 9, Lkup_val = 0x31, KEY=4 +1 = 5
# 4 = 2, SEC_+3= 3, FIR_+7= 0, Lkup_val = 0x1E, KEY=5 +2 = 7
# 3 = 4, SEC_+3= 2, FIR_+7= 1, Lkup_val = 0x15, KEY=2 +4 = 5
Notice how our "regular" input 21212124 has given an "irregular"
94672575.
You may legitimately ask yourself what should all this mean:
what are these RE_SULTs used for? Well they are used to slide
another parameter: this one inside the called routine... this is
what happens to AX and DX inside the routine, and the lines after
the called routine:
:4CBF 26895702 MOV ES:[BX+02],DX ; save R_DX par [958C]
:4CC3 268907 MOV ES:[BX],AX ; save R_AX par [958A]
:4CC6 0346FA ADD AX,[BP-06] ; add to AX RE_SULT [9546]
:4CC9 1356FC ADC DX,[BP-04] ; add to DX KEY_PAR [9548]
:4CCC C45E0E LES BX,[BP+0E] ; reset pointer to E
:4CCF 26895702 MOV ES:[BX+02],DX ; save R_DX+KEY_PAR [958C]
:4CD3 268907 MOV ES:[BX],AX ; save R_AX+RE_SULT [958A]
:4CC6 :4CC9 :4CCF Odd_DX :4CD3 slider_sum
RE_SULT [958A] [958C] [958C] [958A]
0 0 0 0 0
9 5A 0 0 9
4 3AC 0 0 5E
6 24F4 0 0 3B2
7 71CE 1 1 24FB
2 7220 4 E 71D0
5 7572 4 90 7225
7579
Now the loops ends, having handled the input numbers from tenth
to third. Protection loads the second number and multiplies it
by 10 (let's call this result SEC_*10), in our case 2*0xA=14.
Protection loads the first number and adds it to the
multiplication, in our case 1+0x14=0x15 (FINAL_SUM].
Now everything will be added to FFDO to "clean" it.
Pointer will now be set to the end of the input number.
DX, zeroed by CDW, will be saved as parameter in [9584] and the
cleaned and pampered sum will be saved in [9582].
FLAG is set to true and this routine is finished! No parameter
are passed and the only interesting thing is what actually
happens in the locations [9582], [9584], [958A] and [958C], i.e.:
FINAL_SUM, 0, slider_sum, odd_dx.
In the next lesson we'll crack everything, but I'll give you
already some hints here, in case you would like to go ahead on
your own: we'll see how the scheme used for the third (the
registration) number show analogies and differences with the
scheme we have studied (and cracked) here for the first number.
Our 3434-3434-3434-3434-34 input string for the registration
number will be transformed in the magic string
141593384841547431, but this will not work because the "magic"
12th number: "1" will not correspond to the remainder calculated
inside this check through the previous locations of the other
checks.
Here the things are more complicated because every little
change in your input string transforms COMPLETELY the "magic"
string... therefore in order to pass the strainer you'll have to
change 3434-3434-3434-3434-34 in (for instance) 7434-3434-3434-
3434-96. The "magic" string 219702960974498056 that this
registration input gives will go through the protection strainer.
Only then we'll be able to step over and finally crack the whole
protection... it's a pretty complicated one as I said. Now crack
it pupils... you have three months time. From this crack depends
your admission to the Uni, there will be no other admission text
till summer 1997 (it's a hell of work to prepare this crap)...
work well.
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) some tricks of the trade I may not
know but YOU've discovered. I'll probably know most of them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
E-mail +ORC
+ORC an526164@anon.penet.fi
Reference in New Issue Copy Permalink