What The Hack

Lesson 4 : Time protections - A short history of time

2004-05-09T15:38:00.000-08:00

(Best viewed with good old Courier).

Time protections in Windows,

For 'time protections' we intend a serie of protection schemes
which are aimed to restrict the use of an application
ONE
-to a predetermined amount of days, say 30 days, starting with
the first day of installation... 'CINDERELLA' TIME PROTECTIONS
TWO
-to a predetermined period of time (ending at a specific fixed
date) independently from the start date... 'BEST_BEFORE' TIME
PROTECTIONS
THREE
-to a predetermined amount of minutes and/or seconds each time
you fire them... 'COUNTDOWN' TIME PROTECTIONS
FOUR
-to a predetermined amount of 'times' you use them, say 30
times. Strictly speaking these protections are not 'time'
dependent, but since their schemas are more or less on the
same lines as in the cases ONE, TWO and THREE, we will examine
them inside this part of my tutorial. Let's call them 'QUIVER'
protections since, as with a quiver, you only have a
predetermined amount of 'arrows' to shoot (and if you never
went fishing with bow and arrows, on a mountain river, you do
not know what's real zen... the fish springs out suddendly, but
you 'knew' it, and your fingers had already reacted... a lot of
broken arrows on the rocks, though :=)

As first example I have chosen a double protected
application: it has a time protection (of the 'Cinderella' type,
limited to 90 days) as well as a 'quiver' protection
scheme, which is the other -not time bounded- current variante
of the shareware protections... i.e. you should use this program
only 25 times before a protection lock.
It's a relatively 'old' windows protection (april 1995). I found
the program on a cheap cd-rom, which I bought (in a bunch with
9 others) a month ago: 6000 megabytes of bad protected software
for the price of a good glass of wine! PCPLUS SUPER CD n°13,
originally edited in July 1995. I believe it should be pretty
easy to find it or to find this program on the Web if you do not
already have it inside your collection of cheap CD-ROM. Another
advantage of this program, from our perspective, is that the
whole PCFILE.EXE represents de facto the protection scheme
itself... not excessively overbloated: only 8912 bytes, when the
'real' application works inside the (huge and overbloated)
pcf.dll, which will be called only if the user passes the
protection. You can easily print the WHOLE disassembled listing
of PCFILE.EXE (46 Wordperfect pages), that you'll quickly get
through wcb (for instance). For once you'll have a COMPLETE and
COMPLICATED protection scheme under your eyes.
Basically we'll study here the 'beginning' of more complex
time protection schemes, the ones we'll crack with our later
lessons. Some protection elements are here still 'naïv', but the
protectionists have -at least- worked a little against easy
cracks... which makes this protection even more interesting for
us :=)
This program shows even a 'nasty' behaviour: should you use
it after the locking snapped, it will obliterate the whole (main)
pcf.dll from your harddisk, without any warning. This obviously
does not mean anything at all here, but it's the secret to more
advanced (and nastier) protection schemes, so you better have a
look at it too. Nice, enough let's start now.
[PCFILE] (aka the 'dll counter' method)
PCFILE, version 8, (PCFILE.EXE, 8912 bytes, 17 apr 1995, Atlantic
Coast software) is a database program which will be disabled
after having 90 days from its first use or after having used it
25 times, whichever comes first.
We'll begin as usual: just use your wordprocessor search
capacities to search inside the whole directory (and
subdirectories) of PCFILE for words like 'demo' 'order' 'contact'
'expire' 'disabling' 'evaluation' and so on (alternatively, like
I do, you can write your own little C utility to do it even more
quickly and automatically on the whole 600 megabytes CD-ROM you
have inserted on your drive :=)... You'll see immediately that
only two of the PC-files can interest us: PCFILE.EXE and
PCFRES.DLL. A quick 'turbodumping' of PCFILE.EXE itself will
fetch all filenames and nagstrings we need to be happy from the
end of the file... here they are:
A) 010C PCF.DAT
B) 0114 PCF.DLL
1) 2.011C PC-FIle demo has been disabled...
2) 2.01A2 The PC-File demo program has reached the maximum
allowable 25 sessions...
3) 2.0298 This demo version of PC-File 8 is designed...
4) 2.035A The PC-File demo program has reached... 90 days
5) 2.0474 This is the last demo session...

When I see something like this I know that the crack is already
made... it's so easy I can't understand why they don't just give
their software away for free... money I suppose, people seem to
be obsessed with this prepuberal problem... how stupid, besides:
neminem pecunia divitem fecit.
Beside, snooping inside files can be graet fun! At times you find
some 'real' info inside them... Have a look at lotus Wordpro,
for instance, you'll read something like: 'You idiot! Can't flow
a partial paragraph!'; 'Yow! Need to SetFoundry() on this object!';
'Dude! I couldn't find myself!'; 'Ain't nothing to pop!' and many
other amenities which throw a crude light on the life (and possible
blunders) of commercial programmers and on the well know fact
that most application are throw out FULL of bugs just in order
to make money ('bugs for bucks').
OK, back to our cracking: let's just search for the above NUMBERS
inside the code of PCFILE:
1) PC-File has been disabled: 011C

1.1100 >C8040100 enter 0104, 00
1.1104 56 push si
1.1105 C70632060000 mov word ptr [0632], 0000
1.110B 6A00 push 0000
1.110D B81401 mov ax, 0114; THIS is PCF.DLL
1.1110 8946FE mov [bp-02], ax
1.1113 50 push ax
1.1114 9A2E0D0212 call 1:0D2E ;what happens here?
1.1119 83C404 add sp, 0004
1.111C 40 inc ax
1.111D 7532 jne 1151
1.111F 1E push ds
1.1120 681C01 push 011C ;HERE****
1.1123 8D86FCFE lea ax, [bp-0104]
1.1127 16 push ss
1.1128 50 push ax
1.1129 9A6E110000 call USER._WSPRINTF

Therefore this target will be disabled after a check at the
beginning of WinMain (1.1100) if ax, after having been
incremented is non zero. We should have a look at the routine at
1:0D2E to see what happens... but let's first check the other
nagstrings... no point in delving immediatly inside routines.

2) The PC-File demo has reached the maximum allowable 25
sessions... 01A2
1.11C9 >807EFC66 cmp byte ptr [bp-04], 66
1.11CD 7C0F jl 11DE
1.11CF 6AFF push FFFF
1.11D1 9A36120000 call USER.MESSAGEBEEP
1.11D6 6A00 push 0000
1.11D8 1E push ds
1.11D9 68A201 push 01A2 ; HERE ****
1.11DC EB62 jmp 1240
Therefore 25 sessions if byte ptr [bp-04] >= 66 (as you can see,
the protectionists did not use anything vaguely similar to 25dec,
which is 19hex).

3) This demo version of PC-File 8 is designed... : 0298

1.11DE >807EFC4D cmp byte ptr [bp-04], 4D
1.11E2 7518 jne 11FC
1.11E4 6A00 push 0000
1.11E6 1E push ds
1.11E7 689802 push 0298 ;HERE ****
1.11EA 1E push ds
1.11EB FF361000 push word ptr [0010]
1.11EF 6A00 push 0000
1.11F1 9A48120000 call USER.MESSAGEBOX
1.11F6 C70632060100 mov word ptr [0632], 1 ;Flag 632!
This 'Welcome nagged user' message appears therefore only THE
FIRST time you run, when our byte ptr [bp-04] has been set to 4D.
That figures: 66h - 4Dh = 19h, which are the 25 times allowed...
the programmers from Atlantic Coast must have thought something
like 'Stupid crackers will not fetch our nice clever protection:
he'll be searching for byte 19h! Ah!' Note the flag set in
location [632] if it's the first run :=)

4) The PC-File demo program has reached... 90 days : 035A
1.1211 833E320600 cmp word ptr [0632], 0000
1.1216 7565 jne 127D
1.1218 A13406 mov ax, [0634]
1.121B 8B163606 mov dx, [0636]
1.121F 2B062C06 sub ax, [062C]
1.1223 1B162E06 sbb dx, [062E]
1.1227 83FA76 cmp dx, 0076
1.122A 7251 jb 127D
1.122C 7705 ja 1233
1.122E 3D00A7 cmp ax, A700
1.1231 764A jbe 127D

1.1233 >6AFF push FFFF
1.1235 9A3C130000 call USER.MESSAGEBEEP
1.123A 6A00 push 0000
1.123C 1E push ds
1.123D 685A03 push 035A ; HERE!

There, location [634] in ax and location [636] in dx.
ax subtracts location [62C] and dx subtracts with carry location
[62E]. Is it more than 76h? (Which is 118 dec), Tell user he has
reached 90 days. Is it exactly 76h? Then have a look at ax, if
it is more than A700 then tell user the same.

5) This is the last demo session... : 0474

1.132D >56 push si
1.132E 9AFFFF0000 call KERNEL._LCLOSE
1.1333 807EFC66 cmp byte ptr [bp-04], 66
1.1337 7C19 jl 1352
1.1339 6AFF push FFFF
1.133B 9AFFFF0000 call USER.MESSAGEBEEP
1.1340 6A00 push 0000
1.1342 1E push ds
1.1343 687404 push 0474 ;HERE****
1.1346 1E push ds
1.1347 FF361000 push word ptr [0010]
1.134B 6A10 push 0010
1.134D 9AFFFF0000 call USER.MESSAGEBOX

1.1352 >1E push ds
1.1353 681401 push 0114 ;this is PCF.DLL
1.1356 6A01 push 0001
1.1358 9AFFFF0000 call KERNEL.WINEXEC ;exec PCF.DLL

And here, finally we have our good old [bp-04] -once more-
compared to 66h. Notice that there is no Jumpequal nor
jumpgreater check. This means that the program ALREADY KNOWS that
the user has reached here for the first time the fatidic 66. This
means (of course) that this code will be examined AFTER having
incremented the counter of the protection, which must therefore
happen somewhere between 1.123D and 1.132D (the end of routine
4 and the beginning of routine 5). If you have printed the whole
disassembled listing of PCFILE.EXE and if you have read my other
lessons about dead listing (-> 9.3 and 9.4) you do not need any
more to read the following part of this lesson. Choose your
armchair and sit there with a pen, your listing and a good
cocktail (may I suggest a good Martini-Wodka? Don't use anything
else but Moskowskaja). The moment to start 'feeling' the code has
come! You can do everything alone. Write colored arrows on your
listing! The first (or the fourth) simphony of Mahler on your CD!
Everything will appear!
Indeed, if you prefer to follow here, behold: at 1.12B2 we
have a call KERNEL._LOPEN wich opens the file PCF.DLL (0114):

1.12AD 681401 push 0114 ;want pcf.dll
1.12B0 6A01 push 0001
1.12B2 9AFFFF0000 call KERNEL._LOPEN ;open it

and at 1.12CD we have the exact point where, inside pcf.dll, a
byte will be modified (at 10AF8):

1.12C6 6A01 push 0001
1.12C8 68F80A push 0AF8
1.12CB 6A00 push 0000
1.12CD 9AFFFF0000 call KERNEL._LLSEEK

The only modification takes place therefore inside PCF.DLL, a
monstruosity of 1088832 bytes, where location 10af8 grows WITHOUT
any change in the date of the dll. You can easily check this:
* copy pcf.dll pcf.ded
* (run pcfile a couple of time)
* fc /b pcf.dll pcf.ded
fc /b is file compare /binary, good old (and quick) dos, duh?
And this is what you get...

Comparing files PCF.DLL and PCF.DED
00010AF8: 55 50

Et voila mesdames et messieurs, found the other way round, please
note that this more 'practical' method can also be used *before*
beginning the dead listing examination of the file (and would
have given you the '0AF8' string to search for).

Well, what did we learn? A lot: an hidden counter grows in
another file without leaving many traces. The 'quiver'
protection snaps after growing more than 66h, having started at
4Dh. The flag for first time user is inside [0632]. [0634] and
[0636] are used for the current date, [062C] and [062E] are the
original date against which they are checked in a funny way.
There are two different protections, therefore we'll need
two different cracks to deprotect this cram. Let's begin with the
easiest one.
Our FIRST crack, must destroy the counter that increases inside
pcf.dll (the '25' session allowance). This will be made cracking
following instruction:
1.12F3 FE46FC inc byte ptr [bp-04]
which is obviously the increasing instruction we are searching
for (BECAUSE it's the only 'inc byte ptr' in the whole stupid
program, AND because it is located short after the _LLSEEK, AND
because it's incrementing nobody else than our good old [bp-
04]... what do you want more, a neon green flashing arrow light
on the top of it?)
We'll very simply "noop" this instruction, transforming it, for
instance, in 40 90 48 (inc ax, nop, dec ax = do nothing). Well,
yes, that was it for the '25 sessions' lock protection, thankyou,
you may use the program a zillion times now. What now? Ah, yes,
the DATE lock, let's have a look once more at it:
1.1218 A13406 mov ax, [0634]
1.121B 8B163606 mov dx, [0636]
1.121F 2B062C06 sub ax, [062C]
1.1223 1B162E06 sbb dx, [062E]
1.1227 83FA76 cmp dx, 0076 ;118 (-90=1c)
1.122A 7251 jb 127D
1.122C 7705 ja 1233
1.122E 3D00A7 cmp ax, A700 ;(42572)
1.1231 764A jbe 127D

1.1233 >6AFF push FFFF
1.1235 9A3C130000 call USER.MESSAGEBEEP
1.123A 6A00 push 0000
1.123C 1E push ds
1.123D 685A03 push 035A ;HERE! 90 days!

Therefore, if location [636] is > than 76, the nag snaps.
This 76 is calculated through what SEEMS a simple comparison
between the actual date and the installation date.

1.1218 A13406 mov ax, [0634] ;load date ax
1.121B 8B163606 mov dx, [0636] ;load date dx
1.121F 2B062C06 sub ax, [062C] ;subtract first date
1.1223 1B162E06 sbb dx, [062E] ;subtract first date
1.1227 83FA76 cmp dx, 0076 ;allowed limit (?)
1.122A 7251 jb 127D ;ok: you may
1.122C 7705 ja 1233 ;beggar off
1.122E 3D00A7 cmp ax, A700 ;well, what's this
1.1231 764A jbe 127D ;then?

In the reality there are various mathematical checkings
going on here, as the second check on ax = A700 shows. This DOES
NOT need to concern us much (we'll crack this code, later,
changing the 'first time user' flag), but it's useful you have
a rough understanding of what goes on inside these schemes,
therefore let's delve a little inside it.
Basically, the good old dos function GetSystemDate (21/2A)
works like this: On entry: ah = 2a
On return:
al = day of the week (0 = Sunday, 1 = Monday...)
cx = year
dh = month
dl = day
Short before the 90 days check, the protection calls two
routines:
1:09B4 (GetSystemDate) and 1:0D64 (FetchInstallationCode)
The first one fetches the date (1.9D3-1.9D7) and the Time
(21/2C, at 1.9E2), get's ONCE MORE the system date (1.9F7)
subtracts the years against 1980 (1.A20: sub cx, 07BC) and then
makes quite a lot of maniuplation of these data (around 1.C7D,
where one year LESS than the current year will be stored in
[SI+03], in order to calculate the total amount of days). The
second one prepares the numbers for the sub ax and sbb dx of the
90 days check.
As I said all this does not need to concern you much, coz
the protectionists have mad a 'protecion blunder': they have made
every time snapping depending on a flag, the one in [0632].
What happens is: THE FIRST THING this program makes, smack
at the beginning of WinMain, is to set to zero (FALSE) the
abovementioned flag:
1.1105 C70632060000 mov word ptr [0632], 0000
Only in case of first time use, this flag will be set to TRUE at
1.11F6 C70632060100 mov word ptr [0632], 0001
knowing that, anyway, as soon as the program runs again this flag
will be reset to FALSE by Winmain.
And, as we saw, this flag is checked both for the 90 days snap:
1.1211 833E320600 cmp word ptr [0632], 0000
and for the 'This is your last day Cinderella' Warning:
1.1315 >833E320600 cmp word ptr [0632], 0000
A good fundamental crack will therefore be the 'automatical'
setting to TRUE of this flag by our Winmain:
1.1105 C70632060100 mov word ptr [0632], 0001
Everytime the program runs it will believe that's the first time
it does it.
I know, theoretically, having nooped the increase inside PCF.DLL,
the counter should remain always at 4D, which would set ANEW the
flag to true every run... but we do not want the first 'welcome'
nagscreen either, do we? Therefore:
****** Crack for PCFILE version 8, 1997 ***
psedit pcf.dll
search 4E 49 44 4D (4D only if you did not run it)
modify in 4E 49 44 50 (second time run)
psedit pcfile.exe
search 83 C4 06 FE 46 FC
modify in 83 C4 06 40 90 48 (nooped increase)
search C7 06 32 06 00 00
modify in C7 06 32 06 01 00 (flag always true)
*********************************************

As second example I have chosen a fairly interesting 'CINDERELLA'
protection scheme of a Window application which can be useful for
our purposes: Link Check (Version 5.1), an application written
in august 1996. I'll crack here the Windows 3.1 version, for
reasons explained in lesson 9.4, but you'll easily find the Win95
version on the net, whose protection scheme works on the same
lines.
Link Check is a suite of three (3) diagnostic programs which
allows the user to examine different areas of the system.
1) Link Check (WLCHECK.EXE) enables the user to view the links
between an executable file and the modules it requires to run on
the system.
2) Memory Check (WMCHECK.EXE) allows the user to view, load and
unload modules currently in memory.
3) Function Check (WFCHECK.EXE) allows the user to view actual
function calls inside modules.
WLCHECK EXE 40400 24/08/96 5:10
WMCHECK EXE 37104 18/08/96 5:10
WFCHECK EXE 45424 24/08/96 5:10
WLCCOMM DLL 46960 18/08/96 5:10
KSLHOOKS DLL 29568 15/08/96 1:00
The protection scheme inside this program allows a 21 days use
of the program, then 'disables' it. Even in the first 21
'allowed' days there are some functions that are disabled,
anyway. Another interesting feature of the protection scheme, is
that once you register, an 'electronic key' will be created and
sended to you in order to unlock Link Check for the full retail
version (which, as usual, means that the shareware version you
are using CAN be unlocked).
Therefore this application:
is TIME-LIMITED
has been CRIPPLED
has some DISABLED functions
can be UNLOCKED.
A wonderful world of cracking possibilities! Let's rub our hands!
So much to find! So much to learn! Thanks, Karri Software Ltd!
(100422.3521@compuserve.com)
For these protection schemes we must use both the 'Winice' live
approach and the 'dead listing' one. (both described elsewhere
in my tutorial).
Let's begin at the beginning, i.e. searching for strings inside
the WLCHECK.EXE we'll find nothing.
You'll soon realise that the protection scheme hides inside the
two *.dll WLCCOMM.DLL & KSLHOOKS.DLL... the real problem, with
this kind of protections, is that the 'modalities' to unlock it
are not known, i.e., that you cannot just crack the unlock
procedure itself, but you must reverse engineer the program long
enough to find the 'switch' that fires your cracked 'unlock'
procedure, in order to 'register' this program and in order to
be able to use it ad libitum.
What happens with time protections?
The first problem for the protectionists is the tampering with
the system date. Even a stupid user could set the system clock
backwards in order to use a program of the CINDERELLA sort.
Your target would be easily fooled by any stupid user if it did
just set a variable [START_DATE] and then simply check the system
time with something like
IF SystemTime > [START_DATE+30] then beggar off
ELSE OK
Therefore (almost) all this program use some sort of 'diode'
location. Like diodes, which let current through in only one
direction, these locations can only grow... i.e, if you set the
system time to 1 January 2000 and then run the program, it will
throw you off, as expected, but even when you go back to your
current year and date this will be 'remembered'...and the
protection will NOT allow you any more to use the program even
should you (theoretically) still have some free 'try me' days...
your setting at year 2000 screwed up your license for ever.
IF SystemTime > [START_DATE+30] then [MARK_HERE]
ELSE continue
If [MARK_HERE] = TRUE then beggar off
ELSE OK
Let's try altering the system date on our WLCHECK.EXE target...
Woa! As I said... it does not work anymore.

It's fairly easy to get at this part through Winice: Just bpx
WritePrivateProfileString (which is a very interesting function
indeed) and then have a good look at the pointers: You'll quick
find out that KSLHOOKS (Segment 0B) writes his own xCLSID value
inside system.ini. The block of KSLHOOKS.DLL's code responsable
for this is the following:
11.0569 9AE4013500 call 7:01E4 ;'Value' and 'SYSTEM.INI'
11.056E 83C408 add sp, 8 ;adjusting stack
11.0571 8D843901 lea ax, [si+0139]
11.0575 57 push di
11.0576 50 push ax ;pushing 'xCLSID'
11.0577 8D46FA lea ax, [bp-06]
11.057A 16 push ss
11.057B 50 push ax ;pushing 'Value'
11.057C 8D468A lea ax, [bp-76]
11.057F 16 push ss
11.0580 50 push ax ;pushing '{6178-0503...}'
11.0581 8D46EE lea ax, [bp-12]
11.0584 16 push ss
11.0585 50 push ax ;pushing 'SYSTEM.INI'
11.0586 9AFFFF0000 call KERNEL.WRITEPRIVATEPROFILESTRING
11.058B 33C0 xor ax, ax
11.058D 5E pop si
11.058E 5F pop di
11.058F C9 leave
11.0590 CB retf

The call to 7.01E4 fetches the strings 'Value' and 'SYSTEM.INI'
which are 'hardwired' there byte by byte, for instance, 'INI' is
fetched like this:
7.0234 26C6440749 mov byte ptr es:[si+07], 49 ;I
7.0239 26C644084E mov byte ptr es:[si+08], 4E ;N
7.023E 26C6440949 mov byte ptr es:[si+09], 49 ;I

What is really interesting in this part of the protection scheme,
is that the function WritePrivateProfileString is one of the MOST
COMMON functions used for this kind of protections, being the
function normally used in order to 'keep track' inside an 'INI'
file of the particular configuration of an application that the
user has chosen... as a matter of fact this program creates an
hidden WLCHECK.SWL file inside c:\windows where it writes its
data, it also writes, through the above code,

[xCLSID]
Value={0000006236-0017105173-6326000000}
inside system.ini

and then it writes ANOTHER string inside the reg.dat 'register'
of the windows directory. A short digression, about registrations
in the reg.dat of the Windows directory. If you never had a look
at the reg.dat file (wich you should not have only firing
regedit.exe, but using the switch /v TROUGH THE COMMAND LINE
run!) you are in for a big surprise. If you are used to install
and de-install programs as much as I do, you'll be able to see,
for instance, real BATTLES between big or widespread software
packages (for instance Coreldraw and PaintShopPro) fought
there... but you'll also find some cryptic messages like
WB_10=VMWB20
FILTER = 000000000e
OPTION = 0000000005
TAG = 0000001857
KEY = 0000184F
or, even more cryptic:
VxDSettings = {0000006178-0419758349-4326000000}
And this is actually our target, as you can see... the first
thing you should know is that some protection schemes hyde the
date checking part of their protection inside reg.dat.
The above value is the 'ID' of our target, and the ciffer in the
'middle' varies with the date and with the passing of the time.
As we said, once the protection snaps, there is no 'normal'
way to reinstall a working copy of the program, even substituting
ALL the files with fresh ones and deleting the 'secret'
WLCHECK.SWL will not help... in order to reinstall this program
or to use it for the eternity (in 21 days chunks) you would have
to do the following every time the limit snaps:
A) regedit /v
delete key VxD
B) edit system.ini
manually delete the block
"[xCLSID]
Value={0000006236-0017105173-6326000000}"
C) attrib c:\windows\wlcheck.swl -r -s -h
del c:\windows\wlcheck.swl
D) reinstall everything anew and run 21 more days... clearly not
a satisfactory solution, exspecially given the fact that some
routines are disabled... therefore let's delve a little more
inside this protection scheme... we'll find a much neater crack,
you'll see... :=)
Since the 'legitimate' user will get 'an electronic key' from the
protectionists, there must exist, somewhere, a small menu of the
kind 'Enter your electronic key, legitimate sucker'... we could
find it searching with a little imagination (and/or zen) inside
our listings, but in these cases, it's much more quicker a small
run with WRT (Windows Resource Toolkit) by borland. Since we are
already inside KSLHOOKS.DLL, let's begin with this one.
Wrt loads kslhooks.dll and shows you immediatly that there are
only three dialog items, the last one, tagged as 'dialog 503'
represents the 'Unlock' little window: ('Please enter your key'),
which has two buttons: OK (1) and Cancel (2). Let's use WRT
'ID_tagging' option: we'll immediatly fetch the ID number of the
'Please enter your key' field: 2035.
2035 dec is 7F3 hex, therefore we now just need to search 07F3
inside our listing... and we land immediatly here:
6.00DE >8B760A mov si, [bp+0A]
6.00E1 FF760E push word ptr [bp+0E]
6.00E4 6A08 push 0008
6.00E6 9AFFFF0000 call USER.GETWINDOWLONG
6.00EB 8946FC mov [bp-04], ax
6.00EE 8956FE mov [bp-02], dx
6.00F1 83FE01 cmp si, 0001
6.00F4 7556 jne 014C
6.00F6 FF760E push word ptr [bp+0E]
6.00F9 68F307 push 07F3 ;HERE! ****
6.00FC 9AFFFF0000 call USER.GETDLGITEM
6.0101 50 push ax
6.0102 8D4698 lea ax, [bp-68]
6.0105 16 push ss
6.0106 50 push ax
6.0107 6A63 push 0063
6.0109 9AFFFF0000 call USER.GETWINDOWTEXT
6.010E 8D4698 lea ax, [bp-68]
6.0111 16 push ss

This block of code is part of an Exported function from
kslhooks.dll: KSLHOOKPROC4 - Ord:0006h
Here is the whole sequence:
:CALL_PLEASE_ENTER_ELECTROKEY
6.00DE >8B760A mov si, [bp+0A]
...
6.00F9 68F307 push 07F3 ;HERE ***
is called (being at 6.00DE) from
:ENTER 68
6.0082 C8680000 enter 0068, 00
...
6.009B 7441 je 00DE ;HERE ***
which (being at 6.00082) is called from
:PUSH_82
6.000F 68FFFF push selector KSLHOOKPROC4
6.0012 688200 push 0082 ;HERE ***
6.0015 FF36200C push word ptr [0C20]
6.0019 9AFFFF0000 call KERNEL.MAKEPROCINSTANCE
Much interesting, but we are not yet there...
let's see if we have other occurrences of our 7F3h instance
(which, as we saw through WRT, corresponds to the 'Enter your
Key' field of the 'Unlock' window). Yes, we have one more
occurrence (always inside KSLHOOKS.DLL):

4.030A >81FEF307 cmp si, 07F3 ;HERE ***
4.030E 7515 jne 0325 ;don't care if not unlock
4.0310 FF760E push word ptr [bp+0E] ;nID
4.0313 56 push si ;=7F3, =unlock, =hDlg
4.0314 9AFFFF0000 call USER.ISDLGBUTTONCHECKED
4.0319 0BC0 or ax, ax ;mashed button?
4.031B 7408 je 0325 ;Yeah, jump...
4.031D C45EFC les bx, [bp-04]
4.0320 2689B7B104 mov es:[bx+04B1], si
4.0325 >83FE02 cmp si, 0002 ;...here

Now, IsDlgButtonChecked is a 'typical' windows function with
following structure:
UINT IsDlgButtonChecked(HWND hFlg, int nID)
where the handle of the dialog box contaning the button control
is specified in hDlg. The ID value of the desired button is
passed in nID. For two-state buttons this function returns zero
if the button is unchecked and non zero if it is checked, -1 if
an error occurs.
What else can we do?
Let's search for the limit (21 days, that corresponds to 15h)
inside our code. Well, we'll find two interesting occurrences
inside the OTHER dll module: WLCCOMM.DLL:
:OCCURRENCE_1_OF_21_DAYS_LIMIT
1.3E25 >80BEFFFE15 cmp byte ptr [bp-0101], 15 ;here***
1.3E2A 7403 je 3E2F ;Please restart...
1.3E2C E9B900 jmp 3EE8 ;xor ax and retf
and now, look what we have immediately afterwards...
1.3E2F >FF760E push word ptr [bp+0E]
1.3E32 1E push ds
1.3E33 681306 push 0613 ;Please restart...
1.3E36 1E push ds
1.3E37 68EE05 push 05EE ;Retail version...
1.3E3A 6A40 push 0040
1.3E3C 9A90080000 call USER.MESSAGEBOX
1.3E41 FF760E push word ptr [bp+0E]
1.3E44 6A01 push 0001
1.3E46 9AE03E0000 call USER.ENDDIALOG
1.3E4B E99A00 jmp 3EE8 ;xor ax and retf

Now, string 0613 is
"Please restart the program for the reatil version to take
effect"
and string 05EE is
"Retail version successfully unlocked"
...clearly we have found the part of the code where the user gets
the appropriate message once he has digited the correct key
inside the unlock window in KSLHOOKS.
But let's use a little more our 'new' WRT approach. Examining the
'dialog' items through WRT, we'll see that inside WLCCOMM.DLL
there are 'two' About Link check templates, a 'nice' one (for
registered users) and a 'nag' one (for Cinderella's users).
The nice one is WLCCOMM.DIALOG 130, and its second part reads
'This copy of Link check is licensed to'
FIELD 1 = 603 (25bh)
FIELD 2 = 604 (25Ch)
The 'nag' one is WLCCOMM.DIALOG 131 and its second part reads
'UNREGISTERED Shareware notice...' with two buttons:
'How do I register' which is 601 (259h) and
What do I get for it which is 602 (25ah).
Well... let's have a look around our code... and here is
(obviously) the relevant part of it inside WLCCOMM.DLL:

1.3C60 >8B760E mov si, [bp+0E]
1.3C63 FF7606 push word ptr [bp+06]
1.3C66 6AF4 push FFF4
1.3C68 9A8A1D0000 call USER.GETWINDOWWORD
1.3C6D 56 push si
1.3C6E 685B02 push 025B ;here***
1.3C71 9A803C0000 call USER.GETDLGITEM
1.3C76 394606 cmp [bp+06], ax
1.3C79 7421 je 3C9C
1.3C7B 56 push si
1.3C7C 685C02 push 025C ;here***
1.3C7F 9ADA3C0000 call USER.GETDLGITEM
1.3C84 394606 cmp [bp+06], ax
1.3C87 7413 je 3C9C
1.3C89 FF760A push word ptr [bp+0A]
1.3C8C FF7608 push word ptr [bp+08]
1.3C8F FF7606 push word ptr [bp+06]
1.3C92 6A01 push 0001
1.3C94 9A08039E3D call KSLCONTROLCOLOR
1.3C99 E94E02 jmp 3EEA

Whereby, here is the part for the shareware user:
1.3EA6 >81FE5902 cmp si, 0259 ;How do I register?
1.3EAA 7513 jne 3EBF
1.3EAC FF760E push word ptr [bp+0E]
1.3EAF 1E push ds
1.3EB0 688B06 push 068B
1.3EB3 6A01 push 0001
1.3EB5 6A00 push 0000
1.3EB7 687217 push 1772
1.3EBA 9AD43E0000 call USER.WINHELP
1.3EBF >81FE5A02 cmp si, 025A ;What do I get for it?
1.3EC3 7523 jne 3EE8
1.3EC5 FF760E push word ptr [bp+0E]
1.3EC8 1E push ds
1.3EC9 689706 push 0697
1.3ECC 6A01 push 0001
1.3ECE 6A00 push 0000
1.3ED0 687117 push 1771
1.3ED3 9AFFFF0000 call USER.WINHELP
1.3ED8 EB0E jmp 3EE8

and as you can easily see, here lays the 'working' for the two
mushbuttons of the shareware version.
Shareware starts at 1.3EA6 and will be called from here
1.3DB9 >81FE5802 cmp si, 0258
1.3DBD 7403 je 3DC2
1.3DBF E9E400 jmp 3EA6

Unlocked version starts at 1.3C60 and will be called from here:

1.3C3E C8FE0400 enter 04FE, 00
1.3C42 57 push di
1.3C43 56 push si
1.3C44 1E push ds
1.3C45 B87938 mov ax, selector 2:0000
1.3C48 8ED8 mov ds, ax
1.3C4A 8B460C mov ax, [bp+0C]
1.3C4D 2D1900 sub ax, 0019
1.3C50 740E je 3C60 ;***here! UNLOCKED
1.3C52 2DF700 sub ax, 00F7
1.3C55 7465 je 3CBC ;copyright, 1st part
1.3C57 48 dec ax
1.3C58 7503 jne 3C5D ;(jmp 3EE8) out
1.3C5A E94901 jmp 3DA6

Well... if [bp+0C] is 19 (dec25) then we'll jump to our unlocked
routine?

Lesson 3 : hands on, paper protections P-2

2004-04-08T09:42:00.000-08:00

[TOP.EXE] [F19.EXE] [POPULOUS.EXE] [MAP.EXE]

You have seen in the previous lesson that the use of a passwordprotection, independently of the coding and hiding methods usedto store them in memory, implies the use of a comparing procedurewith the password that the user types in. You therefore have manyoptions 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 jumpjust to name the more obvious ones. In order to make things moredifficult for us crackers, the protectionists have devised manycounter-strategies, the more obvious ones being:-    keeping the various part of the store/compare/hide routineswell apart in code (no match for zen-cracking);-    filling these routines with "bogus" compares, bogus jumpsand bogus variables, in order to make things more difficult forthe crack (no match for decent crackers);-    disseminating the code with anti-debugger tricks, like INT_3instructions or jumps in and out protected mode (no match for ourbeloved [Soft-Ice]);-    trying to eliminate the need for passwords altogetherletting the user input "one letter" or "one number" or "oneimage" as answer to some variable question. In this lesson I'llteach you how to crack these "passletters" protection techniques.Let's first resume the "uses" of a password protection:PASSWORDS AS PERMISSION TO ACCESSThese passwords serve to acknowledge that a legitimate user isusing the program. This is the type of password that you'll find,for example, protecting your user account on Compuserve, onNetworks or even in ATM machines used by banks or corporations.These require a little hardwiring to crack: ATM passnumberprotection schemes rely on an answer from the central computer(they do NOT verify only the three magnetic areas in the magneticstrip on the card). The lines between ATM's & their hosts areusually 'weak' in the sense that the information transmitted onthem is generally not encrypted in any way. (Some banks useencrypted information, but this is fairly easy to crack too).So for ATMs you should do the following 1) cross over thededicated line between the ATM and the host; 2) insert yourcomputer between the ATM and the host; 3) Listen to the "normal"messages and DO NOT INTERFERE YET; 4) Try out some operationswith a legal card, make some mistakes, take note of the variouscodes; 5) When you are ready insert a fraudulent card into theATM. Now the following happens: -    the ATM sends a signal to the host, saying "Hey! Can I givethis 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 sakedon't spit out any money on the street!" signal to the ATM;-    the microcomputer intercepts this signal (again), throws itaway (again), and sends the "Wow! That guy is like TOO rich! Givehim as much money as he wants. In fact, he's so loaded, give himALL 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 hasnot much to do with cracking, unless there is a special softwareprotection on the line... so if you want to work on ATMs contactour fellow phreakers/hackers and learn their trade... andplease remember to hack only cash dispenser that DO NOT HAVE acontrol camera :=)PASSWORDS AS REGISTRATIONThis type of password is often used in shareware programs. Whenyou register the shareware program, you are sent a password thatyou use to upgrade your shareware program to a complete and morepowerful version. This method, used frequently for commercialapplications, has recently been used quite a lot by many windowsapplications that come "crippled" on the magazines cover CD-roms,requiring you to telephone a hot line (and paying) in order toget the "unique key" to unlock the "special protection". It's allbullshit: we'll learn in the "how to crack windows" lessons howeasy it is to disable the various routines that verify yourentry.PASSWORDS AS COPY PROTECTIONSThis type of password is often used for games and entertainmentsoftware. The password query does not usually appear any more atthe 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 calledan hardware key). A dongle is a small hardware device containinga password or checksum which plugs into either a parallel or aserial port. Some specially designed dongles even includecomplete program routines. Dongles can be cracked, but the amountof work involved is considerable and the trial and errorprocedure currently used to crack them via software is extremelytedious. It took me more than a week to crack MULTITERM,Luxembourger dongle protected program. The quickest method tocrack dongle protected programs, involves the use of prettycomplicated hardware devices that cannot be dealt with here. Imyself have only seldom seen them, and do not like at all tocrack dongles via software, coz it requires a huge amount of zenthinking and of luck and of time. If you want more informationon the hardware way to crack dongles, try to contact the olderones on the appropriate web sites, they may even answer you ifyou are nice, humble and really technically interested.     The obvious principle, that applies to the software passwordtypes mentioned above is the following: The better the passwordis hidden, and the better it is encrypted, the more secure theprogram 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" protectionschemes (used by many programmers that do not programthemselves):*    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     routineNow the lazy programmer that wants to "protect" his programsearches first the file where the password is stored, then loadsthe key, the password and the checksum. He uses a decryptprocedure to decrypt the password and a check_checksum procedureto check whether the password was modified. All this is obviouslycrackabe in few seconds.[PASSWORD ACCESS INSIDE THE SETUP]     Some computers have a password protected access INSIDE theSetup (at the beginning), the protection scheme does not allowa boot with a floppy and does not allow a setup modify. In thesecases 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 accessdenying, encryption and locking of the FAT tables, get from theweb, and study, the (very well written) code of a virus called"Monkey", that does exactly this kind of devastation. Virusstudying is, in general, very useful for cracking purposes, cozthe 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 theprotection schemes are very complicated! Most of the time theprotection used are incredibly ordinary: as a final example ofour paper protection schemes, let's take a program released notlong 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_sectorit'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_crackerNow let's quickly crack it:------------------------------------------------CRACKING TOP.EXEren top.exe top.dedsymdeb top.ded-    s (cs+0000):0 Lffff 8A 84 1C 12 3A 84xxxx:yyyy           (this is the answer of the debugger)-    e xxxx:yyyy+2  08 (instead of 1C)-    w-    qren 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 ofthe characters you typed in... no wonder that the ECHO doescompare 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 aparticular plane's silhouette. This kind of protection is usedin order to avoid the use of memory locations where the passwordsare 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 knowas "memory snuffing". The protected program, START.EXE, installitself first at location xxxx:0000 with a length of 6C62 bytes,but proceeds to a relocation of its modules (with some SMC, selfmodifying code parts) in different locations. What does all thismean? Well, this could mean quite many things... the mostimportant 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 progressivenumber of this plane in one memory location: (imc) 43CD:DADA.This brings us to the random triggering mechanism:E87FAF    CALL random_seed83C402    ADD  SP,028946E8    MOV  [BP-18],AX     and ds:(BP-18) is the location                              you are looking forNow, every time this random triggers, you get a different number(00-x14) in this location, corresponding to the different planethe user should choose.The random seed routine, evidently, comes back with the randomseed in AX... what we now need is to zero it: the user willalways have to choose the same plane: "plane 0", and he will havegiven the correct answer. Note how elegant all this is: we do notneed to interfere with the whole mouse pointing routines, norwith the actual choosing of the planes... the random seed maychoose whatever plane it wishes... the memory location for thischoice 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 filesymdeb 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 OSren 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, inorder to respect the previous ADD SP,+02).Well, nice. It's getting easier, isnt'it? Now let's take asexample a protection that has no "echo" in memory. (At thebeginning this was a smart idea: "the cracker won't find thecorrect password, 'coz it's not there, ah!". We'll now thereforecrack 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 nota password" can be found in [Populous.exe], from Bullfrog. It'sa very widespread program, and you'll surely be able to find acopy of it in order to follow this lesson. The program asks forthe identification of a particular "shield", a combination ofletters of various length: the memory location were the userpassword is stored is easily found, but there is (apparently) no"echo" of the correct password. You should be able, by now, tofind by yourself the memory location were the user password isstored. Set a breakpoint memory read & write on this area, andyou 'll soon come to the following section of code:F7AE4EFF  IMUL WORD PTR [BP+FF4E]       <- IMUL with magic_Nø40        INC  AX3B460C    CMP  AX, [BP+0C]7509      JNZ  beggar_off_ugly_copier8B460C    MOV  AX, [BP+0C]A3822A    MOV  [2A82], AXE930FE    JMP  nice_buyer817E0C7017CMP  WORD PTR[BP+0C],1770     <- beggar_offI don't think that you need much more now... how do you preferto 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_buyerinstruction at the place of the JNZ beggar_off? This solution hasless nops: remember that newer protection schemes smellNOPs_patches!). Yeah, let's do it this way:---------------------------------------------------CRACKING [Populous.exe]

ren populous.exe populous.ded      <- let's have a dead filesymdeb populous.ded                <- let's debug it-    s cs:O lffff F7 AE 4E FF      <- the imul magic_Nøxxxx:yyyy                          <- debugger's answer-    e xxxx:yyyy+4  EB [SPACE] 03  <- JMP anyway-    w                             <- modify ded-    q                             <- back to the OSren 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 alast application, a memory utility that is very widespread, verygood (the programmers at Clockwork software are Codemasters),very useful for our purposes (you'll use it later to crack a lotof TSR) and, unfortunately for Clockworkers, very easy to crackat the level you are now. But, Hey! Do not forget that you would have never done it withoutthis tutorial, so do the following: look toward east from yourwindow, sip a Martini-Wodka (Two blocks of ice first, 1/3 dryMartini from Martini & Rossi, 1/3 Moskovskaia Wodka, 1/3Schweppes indian tonic) and say three times: Thank-you +ORC!. [MAP.EXE]     Let's now go over to one of the best TOOLS for mapping yourmemory usage that exist: MAP.EXE (version 2) from the masters atClockwork software. The usage of this tool has been recommendedin Lesson 2, and you should learn how to crack it, coz it comeswith an annoying nag-screen ("Nigel" screen). In [Map.exe] thisubiquitous "Nigel" screen appears at random waiting for a randomamount of time before asking the user to press a key which variesevery time and is also selected at random.     The use of a single letter -mostly encrypted with some XORor SHR- as "password" makes the individuation of the relevantlocations using "snap compares" of memory much more difficult.But the crack technique is here pretty straightforward: justbreak in and have a good look around you.     The INT_16 routine for keyboard reading is called just afterthe loading of the nag screen. You 'll quickly find the relativeLODSB 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 forcealways the same passletter, in order to temperate the effects ofthe protection... but we crack deep!: let's do the job and trackback the caller! The previous routine is called from thefollowing 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: Ithink that unnecessary code segments (in this case protections)are somehow like little snakes moving under a cover: you cannoteasily say what's exactly going on yet, but you could bet thatthere is something fishy going on. Look at the code precedingyour LODSB routine call: you find two JUMPS there: a JZ ret, thatleaves a lot of pusha and popa aside, and a JAE after RET, thatdoes not take the previous ret. If you did smell something hereyou are thoroughly right: The first JZ triggers the NIGEL screenprotection, and the second JAE does THE SAME THING (as usual,there are always redundances, exactly as there are a lot ofpossibilities to disable a single protection). Now you know...you can disable this protection at different points: the twoeasiest 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 partof the code in order to change it, you won't have any luck: it'sa SMC (Self modifying code) part: it is loaded -partly- fromother sections of the code (here without any encryption). Youmust therefore first of all set a breakpoint on memory range;find out the LODSW routine; find out the real area; dump thatmemory 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) ren map.exe map.dedsymdeb map.ded-    s (cs+0000):0 Lffff 74 16 50 53 51 52 57xxxx:yyyy           <- this is the debugger's answer-    e xxxx:yyyy    EB-    w-    qren map.ded map.exe-------------------------------------------------Now you have done it, NIGEL has been cracked!

Lesson 3 : hands on, paper protections P1

2004-02-25T09:36:00.000-09:00

[UMS.EXE] [LIGHTSPD.EXE] [GENERAL.EXE]

SOME PROBLEMS WITH INTEL's INTThe INT instruction is the source of a great deal of theflexibility in the PC architecture, because the ability to getand set interrupt vectors means that system services (includedDOS itself) are infinitely extensible, replaceable andMONITORABLE. Yet the Int instruction is also remarkablyinflexible 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... unfortunatelymany high level language compilers compile interrupts into PUSHFand FAR CALL instruction sequences, rather than do an actual INT.Another method is to PUSH the address of the handler on the stackand do RETF to it. Some protection schemes attempt to disguise interrupt calls,1) camouflaging the code, 2) putting in substitute interruptinstructions which look harmless and modifying them "on the fly"or 3) replicating whole interrupt routines inside the code. Thisis particularly frequent in the various "disk access" protectionschemes that utilize INT_13 (the "disk" interrupt) and willtherefore be thoroughly explained in -> lesson 5. A LITTLE BASIC ASSEMBLERIn order to understand the protection schemes and to defeat them,you must acquire a passing knowledge of assembler, the "machinelanguage" code. You can find a lot of good, well explained codefor free: viruses are one of the best sources for good "tight andtricky" assembler code. You can find the source code of almostall viruses on the web: oddly all the would be hackers seem tohave an aberrant passion for this kind of stuff instead ofstudying cracking techniques. But there are millions of lines ofgood explained "commercial" assembler code on the net, just fishit out and study it: the more you know, the better you crack.I'll restrict myself to some observations, sprinkled throughoutthis tutorial. Let's start with some must_know:------------------------ STRINGS ----------------------------The string instructions are quite powerful (and play a great rolein password protection scheme). ALL of them have the propertythat:1) The source of data is described by the combination DS:SI2) The destination of data is described by the combination ES:DI3) 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 saysJNZ ero means what it saysJG 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 choiceCRACKING PASSWORD PROTECTED PROGRAMS Refer to lesson one in order to understand why we are usinggames instead of commercial applications as learn material: theyoffer the same protection used by the more "serious" applications(or BBS & servers) although inside files that are small enoughto be cracked without loosing too much time. A whole series of programs employ copy protection schemesbased upon the possess of the original manual or instructions.That's obviously not a very big protection -per se- coz everybodynowadays has access to a photocopier, but it's bothering enoughto motivate our cracks and -besides- you'll find the same schemeslurking 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 theoriginal manual, something like: "please type in the first wordof line 3 of point 3.3.2". Often, in order to avoid mistakes, theprogram indicates the first letter of the password... the usermust therefore only fill the remaining letters.Some examples, some cracks:---------------------------------------------------UMS (Universal Military Simulator) version 1by Dr Ezra SIDRAN(c) 1987 Intergalactic DevelopmentEuropean Union: Rainbird SoftwareUnited States: Firebird Software--------------------------------------------------- This very old EGA program is one of the first I cracked inmy youth, and it's very interesting coz it employs a very basilarprotection scheme (a "PRIMITIVE"! More than 80% of the protectionschemes used to day (January 1996) are directly derived from oneof the 12 primitives. The nag screen snaps at the beginning and keeps indefinitelyasking your answer, only the use of CTRL+C will bring you out ofit, 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 youtype in. So examine your memory map, find out where the programdwells in memory, do a snap save of these memory areas and aseries of snap compares as you type your password in. Strangely enough, in the case of UMS, as you type yourpassword there seems to be no difference at all in the memorylocations where this program dwells... yet the data must besomewhere... Usually such a situation is a clear sign that anhooked interrupt is used to hide the data. Checking the hooked vectors you find out the following:vecs 00, 02, 22 are hooked where needs bevecs 34-3D are hooked at xxxx:0vec 3E is hooked at xxxx:00CA Ha! Let's have a closer look at this bizarre 3E hook. Let'ssearch for some words used in the nag_screen and then let's dumpthe area where we find them (in UMS that will be at 3E_hookaddress + 7656) and loo! You'll see the content of the nag screenand, 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, forinstance, easily patch all the different passwords to (forinstance) "PASS", and this would work... it's a very primitiveprotection, as we said, nevertheless the use of a hooked vectoras 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, wewant to crack, here, not just to patch. Password protected programs (and access protection routinesfor server and BBS, for that matter) have quite a lot of weakpoints. The most obvious one (you 'll find out the other whenyou'll high crack) is that they MUST compare the password of theuser with the original one(s). So you do not need to steal apassword, you just need to "ear" the echo of the original one inthe memory locations used for the compare, or, and that's morecorrect, to crack the compare mechanism itself so as to make itlet you in even with a totally false password. The compare mechanism of UMS can be found setting abreakpoint on the memory range that covers the three locationswhere the password is stored (and you 'll find these with yoursearch 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 CXREPNZ SCASB Scan ES:DI (the user password)NOT CX Now CX holds the number of the character that the user typed inMOV DI,SI Real password offset to DILDS SI,[BP+0A] User password offset in SIREPZ 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 basiclevel... you look at the code that follows the CMPSB searchingthe "snapping schema"... here it is immediately afterwards(that's the case in most of the primitives). Remember: we sprungout of the CMPSB check at the first different char, OR at the endof 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_matchWell let's now look for the next JZ near (it's a "74" code) CS:IP 740D JZ location no_goodWait, let's continue a little... is there another check (oftenyou have a double check on DI)... yes there is! CS:IP 7590 JNZ location no_goodCracking such a schema is very easy: you just need to substitute75 to 74 and 74 to 75: transform your JZ in a JNZ and the JNZ ina 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 ren ums.exe ums.dedsymdeb 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 3Fxxxx:yyyy (this is the answer of the debugger)- e xxxx:yyyy 75- e xxxx:yyyy+17 74- w- qren ums.ded ums.exe------------------------------------------------- In the debug/symdeb crack above we use as search string thebytes comprising and following immediately the first JZ.I know, I know... we saw them in [Soft-ice] and we could havemodified them there, but I'm teaching also pupils who may nothave [Soft-ice]. Note that the program is x431A0 bytes long, and thereforehas a BX=4 sectors adding to the CX=31A0 in the initialregisters... that's the reason I wanted to examine all thesectors (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 firstsector you must search for it in the next sectors, till you findit, coz in many programs there may be MORE THAN ONE repetitionsof 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 passwordprotection 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 inmany access routines of remote servers (and this makes it veryinteresting indeed). Let's begin as usual, with our hooked vectors examinationand our snap compares.Hooked vectors: 00, 08, 1B, 22, 23: nothing particular.The snap_comparisons of the main memory area -as you type thepassword in- gives more than six pages of changing locations...that's clearly much too much to examine.What now? Sit down, Relaxe, meditate. Get the memory map of theprogram's layout. Start anew: snap_save (before typing anythingin). Type as password "ABCDE". Get the print of the snapcompares. Sit down, sip Martini Wodka, relax. You know that thecode for A is x41, for B x42, for C x43 and so on... and in thesnap_compares, that you made between letters, you 'll have onlysome locations with these values changing. Focus on these. You 'll soon enough find out that for LIGHTSPEED absolutelocation (in my computer) 404307, i.e.: relative locations (inmy computer) 30BE:F857 or 4043:0007 evoke the characters youtype, 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 absolutelocation 30C64 (imc) or relative location 30BE:F83E evokes theLAST 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'sgoing 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 willbe now copied in BX=F85A. What else can you do? Time to use alittle intuition: look for an instruction "CMP AX,000D", whichis the typical "IF the user hits ENTER then" instruction, coz"x1D" its the ENTER keystroke. This must be somewhere aroundhere. Ha! You 'll soon enough find the line CS:0073 3D0D00 CMP AX,000DAnd now the way is open to the crack. But YOU DO NOT NEED ALLTHIS! Since the password protection schemes are -as I told you-all more or less the same, I would suggest that you use first ofall following trick: in the largest part of the program (usememory 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 addresseswith this instruction: (pgsg=program main segment) pgsg:C6F9 pgsg:E5CA pgsg:E63E pgsg:EAB0There 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 lessthe same as in 1987'UMS (and do believe me: the same mechanismis still in use to day (1996)!B9FFFF MOV CX,FFFF charge Max in CXF2AE REPNZ SCASB this scans ES:DI (the original password)F7D1 NOT CX so many chars in the original pw2BF9 SUB DI,CX change DI for compareF3A6 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 lazybastards! Here the section is preceded by a small routine tolowercase the user password, coz the original muster is alwayslowercased. Now you would like, may be, to breakpoint at one of theselocations, in order to stop the program "in the snap area" andinspect the snap mechanism... that WILL NOT DO with a "fixed"breakpoint, coz these locations are called by the snap with adifferent segment:offset numeration as the one you found (that'sold dos magic). So you MUST first set a memory_read/writebreakpoint on these locations, and then get at them at the snap.Now you can find out the segment:offset used by the snap and onlynow you'll be able to set a fixed breakpoint (for instance on theNOT CX instruction). Now run the program and breakpoint in: have a dump of theES:DI and see the original password. How nice! We have now theoriginal password in extenso in our memory dump window. That'sthe "echo". By the way, there is a whole school of crackingdevoted to find and use these echoes... we work on differentpaths, nevertheless password fishing can be interesting: whereare the password stored? From which locations do they come from?A common practice of the protectionists is to hide them indifferent files, far away, or in hooked vectors, or in SMC parts.This is a program of 1990, that differs in respect to UMS: thepasswords are not "hidden" inside a hooked vector, coz that's apretty stupid protection: any hexdump utility would still permityou to see them. Here the passwords are encoded (albeit in a veryprimitive manner): looking for them (with memory rangebreakpoints) you'll quickly find a section of the program codethat looks like this:sg:0118 8C 91 9D 95 9B 8D 00 B8 EC 94 9B 8D 8F 8B 9Bsg:0128 94 9B 8D 00 AE EC 9C 9B 8A 9B 86 00 A9 EC 91This is a typical encoded matrix, with clear 00 fences betweenthe encoded passwords.Ha! If all codes where so easy to crack! This is no better thanchildren's crypt! It's a NEG matrix! And there is directcorrespondence: 91=6F="o"; 92=6E="n"; 93=6D="m" and so on... Ha! Let's now leave the "hidden" passwords and proceed with ourcracking... let's follow the snap procedure after the REPZ CMPSBinstruction looking for the "jump to OK" instruction...F3A6 REPZ CMPSB ; compares DS:SI with ES:DI 7405 JZ preserved_AX=0000 <--- Here the first JZ1BC0 SBB AX,AXADFFFF SBB AX,FFFF :preserved_AX=00008BF3 MOV SI,BX8BFA MOV DI,DX5D POP BPCB RETF....83C404 ADD SP,+040BC0 OR AX,AX7509 JNZ 0276 <------ And here it is! Now, remembering the UMS crack, you would probably want tochange the JZ instruction in a JNZ instruction (you tried it onthe fly INSIDE [Soft-Ice] and it did work!), the "74" with a"75" also. And then you would like to change the JNZ instructionin a JZ instruction... Please feel free to try it... it will NOTwork! (You will not even find the second JNZ in the programcode). You should always be aware of the SMC (self modifyingcode) protections: parts of the code my be decrypted "on thefly", as needs arise, by the program. The code you modify whilethe program is running may be different from the code of the"dead" program. Here we have a small "improvement" of the primitive: thesame instruction is used as "muster" for manipulation of otherparts of the program... if you do change it in a JNZ you get anoverlay message and the program pops out with instability! Youcannot easily modify the JNZ instruction either, coz the partafter the RETF will be compiled "on the fly" by lightspeed, andyou would therefore have to search the decryption mechanism andmodify the original encrypted byte somewhere... and may be theydo 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 theJZ, is the setting of the AX register to flag *FALSE* (AX=1...that's what the two SBB instructions do) if the snap went outwith 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, moreelegantly, let's have a INC AX, DEC AX, NOP, INC AX, DEC AXsequence instead of the two SBB! There is a good reason to usea sequence of working instructions instead of a series of NOPs:recent protection schemes "smell" patched nops inside the programand trash everything if they find more than -say- threeconsecutive NOPs! You should always try to choose THE LESSINTRUSIVE and MORE "CAMOUFLAGED" solution when you crack! Eliminating the two SBBs we get our crack! No need to botherwith the second JNZ either... the program will work as if you gotthe password if you have it AND if you do not (that's better asthe previous type of crack -seen for UMS- when you crack computeraccesses: 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 ren lightspd.exe lightspd.dedsymdeb lightspd.ded- s (cs+0000):0 Lffff 2B F9 F3 A6 74xxxx: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- qren 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'sanalyze, for instance, the protection scheme used in the firstversion of Perfect general I from QQP-White wolf, July 1992.When you break in, at the nag screen, you are in the middle ofthe BIOS procedures, coz the program expects your input (yourpassword, that's is). You 'll quickly find out (MAP MEMORYUSAGE!) that [General.exe] dwells in two main areas; Settingbreakpoints on memory write you 'll find out that the memory area"queried" by the protection mechanism is xxxx:1180 to xxxx:11C0where xxxx represents the second of the memory segments where theprogram dwells. Now do the following (a very common crackingprocedure):* 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 everythingIt's already done! Now it's your intuition that should work alittle: Here the last 9 traces (traces [!], not instructionsfollowing on a line) before the calling of the procedure sniffingyour 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_areaWell, the call to funny_procedure followed by a byte compare"feels" fishy from very far away, so let's immediately look atthis 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 noticeimmediately the inconsistency of the two successive instructionsMOV 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 withthe precedent MOV instruction... but the first JNZ jumps to thecompare WITHOUT putting the "2A" inside. And "2A" is nothing elseas the "*" symbol, commonly used by programmer as "OK"! Thisprotection works in the following way (this is the above codeexplained):- 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_buyerNow let's quickly crack it:------------------------------------------------CRACKING GENERAL.EXE ren general.exe general.dedsymdeb general.ded- s (cs+0000):0 Lffff 8C 11 75 0Exxxx:yyyy (this is the answer of the debugger)- e xxxx:yyyy+2 EB [SPACE] 09 - w- qren general.ded general.exe-------------------------------------------------And in this way you changed the JNZ to the cmp "*" instructionin a JMP to the mov "*" instruction. So no more nag screens, nomore protections... serene, placid, untroubled [general.exe].

Very Brief History of Hacking

2003-11-03T23:50:00.000-09:00

Prehistory of Hacking (before 1969)

In the beginning there was the phone company ? the brand-new Bell Telephone, to be precise. And there were nascent hackers. Of course in 1878 they weren't called hackers yet. Just practical jokers, teenage boys hired to run the switchboards who had an unfortunate predilection for disconnecting and misdirecting calls ("You're not my Cousin Mabel?! Operator! Who's that snickering on the line? Hello?"). Now you know why the first transcontinental communications network hired female operators.

Flash forward to the first authentic computer hackers, circa the 1960s. Like the earlier generation of phone pranksters, MIT geeks had an insatiable curiosity about how things worked. In those days computers were mainframes, locked away in temperature-controlled, glassed-in lairs. It cost megabucks to run those slow-moving hunks of metal; programmers had limited access to the dinosaurs. So the smarter ones created what they called "hacks" - programming shortcuts ? to complete computing tasks more quickly. Sometimes their shortcuts were more elegant than the original program.

Elder Days of Hacking (1970-1979)

In the 1970s the cyber frontier was wide open. Hacking was all about exploring and figuring out how the wired world worked. Around 1971 a Vietnam vet named John Draper discovered that the giveaway whistle in Cap'n Crunch cereal boxes perfectly reproduced a 2600 megahertz tone. Simply blow the whistle into a telephone receiver to make free calls; thanks for using AT&T.

Counterculture guru Abbie Hoffman (above) followed the captain's lead with The Youth International Party Line newsletter. This bible spread the word on how to get free phone service. "Phreaking" didn't hurt anybody, the argument went, because phone calls emanated from an unlimited reservoir. Hoffman's publishing partner, Al Bell, changed the newsletter's name to TAP, for Technical Assistance Program. True believers have hoarded the mind-numbingly complex technical articles and worshipped them for two decades.

The only thing missing from the hacking scene was a virtual clubhouse. How would the best hackers ever meet? In 1978 two guys from Chicago, Randy Seuss and Ward Christiansen, created the first personal-computer bulletin-board system. It's still in operation today.

The Golden Age of Hacking (1980-1991)

In 1981 IBM announced a new model ? a stand-alone machine, fully loaded with a CPU, software, memory, utilities, storage. They called it the "personal computer." You could go anywhere and do anything with one of these hot rods. Soon kids abandoned their Chevys to explore the guts of a "Commie 64" or a "Trash-80."

The 1983 movie War Games shone a flashlight onto the hidden face of hacking, and warned audiences nationwide that hackers could get into any computer system. Hackers gleaned a different message from the film. It implied that hacking could get you girls. Cute girls.

The territory was changing. More settlers were moving into the online world. ARPANET was morphing into the Internet, and the popularity of bulletin-board systems exploded. In Milwaukee a group of hackers calling themselves the 414's (their area code) broke into systems at institutions ranging from the Los Alamos Laboratories to Manhattan's Memorial Sloan-Kettering Cancer Center. Then the cops put the arm on them.

The Great Hacker War

To pinpoint the start of the "Great Hacker War," you'd probably have to go back to 1984, when a guy calling himself Lex Luthor founded the Legion of Doom. Named after a Saturday morning cartoon, the LOD had the reputation of attracting the best of the best ? until one of the gang's brightest young acolytes, a kid named Pier Optik, feuded with Legion of Doomer Erik Bloodaxe and got tossed out of the clubhouse. Phiber's friends formed a rival group, the Masters of Deception.

Starting in 1990, LOD and MOD engaged in almost two years of online warfare ? jamming phone lines, monitoring calls, trespassing in each other's private computers. Then the Feds cracked down. For Phiber and friends, that meant jail. It was the end of an era.

Crackdown on Hacking (1986-1994)

With the government online, the fun ended. Just to show that they meant business, Congress passed a law in 1986 called the Federal Computer Fraud and Abuse Act. Translation: A felony gets you five. Then along came Robert Morris with his Internet worm in 1988. Crashing 6,000 Net-linked computers earned Morris the distinction of being the first person convicted under the Act's computer-crime provision. Translation: a $10,000 fine and too many hours of community service.

Soon you needed a scorecard to keep up with the arrests. That same year Kevin Mitnick broke into the Digital Equipment Company's computer network; he was nabbed and sentenced to a year in jail. Then Kevin #2 ? Kevin Poulsen ? was indicted on phone-tampering charges. Kevin #2 went on the lam and avoided the long arm of the law for 17 months.

Operation Sundevil was the name the government gave to its ham-handed 1990 attempt to crack down on hackers across the country, including the Legion of Doom. It didn't work. But the following year Crackdown Redux resulted in jail sentences for four members of the Masters of Deception. Phiber Optik spent a year in federal prison.

Some people just couldn't learn from their mistakes, though. In February 1995 Kevin Mitnick was arrested again. This time the FBI accused him of stealing 20,000 credit card numbers. He sat in jail for more than a year before pleading guilty in April 1996 to illegal use of stolen cellular telephone numbers.

Zero Tolerance for Hacking (1994-1998)

Seeing Mitnick being led off in chains on national TV soured the public's romance with online outlaws. Net users were terrified of hackers using tools like "password sniffers" to ferret out private information, or "spoofing," which tricked a machine into giving a hacker access. Call it the end of anarchy, the death of the frontier. Hackers were no longer considered romantic antiheroes, kooky eccentrics who just wanted to learn things. A burgeoning online economy with the promise of conducting the world's business over the Net needed protection. Suddenly hackers were crooks.

In the summer of 1994 a gang masterminded by a Russian hacker broke into Citibank's computers and made unauthorized transfers totaling more than $10 million from customers' accounts. Citibank recovered all but about $400,000, but the scare sealed the deal. The hackers' arrests created a fraud vacuum out there in cyberspace.

Hack 2K (1999+)

As the millenium approached, general cyber-hysteria over the infamous Y2K bug was further inflamed by several serious hacker attacks. Well-documented by the media, these invasions were experienced directly (perhaps for the first time) by the growing masses of casual web surfers. In the second week of February 2000 some of the most popular Internet sites (CNN, Yahoo, E-Bay and Datek) were subject to "denial of service" attacks. Their networks clogged with false requests sent by multiple computers under the control of a single hacker, these commercial sites crashed and lost untold millions in sales. In May, a new virus appeared that spread rapidly around the globe. The "I Love You" virus infected image and sound files and spread quickly by causing copies of itself to be sent to all individuals in an address book.

Recent attacks on seemingly "secure" sites such as The White House, FBI and Microsoft.com have proven that despite massive public and private investment in cyber defense technology and methodology, hackers continue to pose a serious threat to the "information infrastructure."

Who are hackers, and what makes them tick?

Two experts in the field of cyber forensics and psychology have some answers to that question. One is Marc Rogers, a behavioral sciences researcher at the University of Manitoba in Winnipeg, Canada, and a former cyber detective. The other is Jerrold M. Post, a psychiatrist at George Washington University in Washington, D.C.

Rogers and Post have identified some basic behavioral trends for hackers who commit crimes. Rogers says one characteristic is that they tend to minimize or misconstrue the consequences of their activities, rationalizing that their behavior is really performing a service to society. (Some researchers call this the Robin Hood Syndrome). They may also tend to dehumanize and blame the victim sites they attack. Post says the same hackers share a sense of "ethical flexibility," which means that since human contact is minimized over the computer, hacking becomes like a game where the serious consequences can be easily ignored.

Not all hackers are criminals.

1. Old School Hackers: These are your 1960s style computer programmers from Stanford or MIT for whom the term hacking is a badge of honor. They're interested in lines of code and analyzing systems, but what they do is not related to criminal activity. They don't have a malicious intent, though they may have a lack of concern for privacy and proprietary information because they believe the Internet was designed to be an open system.

2. Script Kiddies, or Cyber-Punks: Most commonly what the media calls "hackers." These are the kids, like Mafia Boy, who most frequently get caught by authorities because they brag online about their exploits. As an age group, they can be between 12 and 30 years old, they're predominantly white and male, and on average have a grade 12 education. Bored in school, very adept with computers and technology, they download scripts or hack into systems with the intent to vandalize or disrupt systems.

3. Professional Criminals, or Crackers: These guys make a living breaking into systems and selling the information. They might get hired for corporate or government espionage. They may also have ties to organized criminal groups.

4. Coders and Virus Writers: Not a lot of research has been done on these guys. They like to see themselves as an elite. They have a lot of programming background and write code but won't use it themselves. They have their own networks to experiment with, which they call "Zoos." They leave it to others to introduce their codes into "The Wild," or the Internet.

Underlying the psyche of the criminal hacker may be a deep sense of inferiority. Consequently, the mastery of computer technology, or the shut down of a major site, might give them a sense of power. "It's a population that takes refuge in computers because of their problems sustaining real world relationships," says Post. "Causing millions of dollars of damage is a real power trip."

Hacker Hoax Reality

Jdbgmgr.exe Hoax (2002): An email instructs users to delete the file "Jdbgmgr.exe" (teddy bear icon), because it is a destructive virus spread through MSN Messenger.
The file is actually a vital system file for Windows.

WTC Survivor (2001): An email advises users to delete any message with the subject line "WTC Survivor" or else a virus will delete their entire C: drive.
This massive chain-letter hoax played on people's emotions following the Sept. 11, 2001, tragedy.

Kournikova (2001): In February, an email with an attached JPEG image of tennis star Anna Kournikova propagates in cyberspace.
The "JPEG" was a relatively harmless virus easily detected by anti-virus software. Thus, many companies were unwilling to admit whether it had affected their systems, resulting in a light sentence for the author of the virus.

Red Alert Virus(2000): An email alert claims a deadly computer virus will destroy any computer that visits Microsoft's Web site using the Internet Explorer browser.
Popular suspicion of Microsoft and its vulnerability to hackers contributed to the success of this hoax.

Good Times (1994): An email alert warns users to avoid messages with "Good Times" in the subject line, as the attached virus will erase a computer's entire hard drive.
Many corporate and academic email servers crashed throughout 1995 under the strain of this hoax chain letter. Frightened users forwarded the alert to "all," prompting others to hit the "Reply to All" button with questions or comments.

Michelangelo Virus (1992): In January, a major U.S. computer manufacturer announces it accidentally shipped 500 PCs carrying the "Michelangelo" virus. A media feeding frenzy implies the virus has spread to "millions" of computers.

Lesson 2: Tools and Tricks of the Trade

2003-06-13T10:06:00.000-08:00

[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 and study it at ease. It's
difficult to say how many hours of cracking it did spare me (you
should study the program, only 252 bytes long, and will have to
modify it a bit, coz it's pretty primitive, in the original
version, for instance, the redirection to the printer works only
if there is NO SPACE between "spray" and ">").

[VEXE.EXE]

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

[SNOOP UTILITIES --> KGB.EXE INTMON.EXE INTRSPY.EXE etc...]
[TRACE UTILITIES --> TRACE.EXE STEPDOS.EXE etc...]

A must to study the "calling hierarchy" of an unknown
program. KGB.EXE, a 1992 program by Petr Hor?k could 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
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?

Lesson 1 - The best way to learn cracking

2003-01-06T08:43:00.000-09:00

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)or peppered with "junk" instructions

(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 3C <- 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 3C 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

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.