Copy Link
Add to Bookmark
Report
+ORC Cracking Lesson 3.2: Hands on, paper protections (advanced)
You have seen in the previous lesson that the use of a password
protection, independently of the coding and hiding methods used
to store them in memory, implies the use of a comparing procedure
with the password that the user types in. You therefore have many
options to begin your cracking work:
- find the location of the user password
- find the "echo" in memory of the real password
- find the routine that compares both
- find the passwords hideout and encryption type
- find the go_ahead_nice_buyer exit or jump
- find the beggar_off_ugly_copier exit or jump
just to name the more obvious ones. In order to make things more
difficult for us crackers, the protectionists have devised many
counter-strategies, the more obvious ones being:
- keeping the various part of the store/compare/hide routines
well apart in code (no match for zen-cracking);
- filling these routines with "bogus" compares, bogus jumps
and bogus variables, in order to make things more difficult for
the crack (no match for decent crackers);
- disseminating the code with anti-debugger tricks, like INT_3
instructions or jumps in and out protected mode (no match for our
beloved [Soft-Ice]);
- trying to eliminate the need for passwords altogether
letting the user input "one letter" or "one number" or "one
image" as answer to some variable question. In this lesson I'll
teach you how to crack these "passletters" protection techniques.
Let's first resume the "uses" of a password protection:
PASSWORDS AS PERMISSION TO ACCESS
These passwords serve to acknowledge that a legitimate user is
using the program. This is the type of password that you'll find,
for example, protecting your user account on Compuserve, on
Networks or even in ATM machines used by banks or corporations.
These require a little hardwiring to crack: ATM passnumber
protection schemes rely on an answer from the central computer
(they do NOT verify only the three magnetic areas in the magnetic
strip on the card). The lines between ATM's & their hosts are
usually 'weak' in the sense that the information transmitted on
them is generally not encrypted in any way. (Some banks use
encrypted information, but this is fairly easy to crack too).
So for ATMs you should do the following 1) cross over the
dedicated line between the ATM and the host; 2) insert your
computer between the ATM and the host; 3) Listen to the "normal"
messages and DO NOT INTERFERE YET; 4) Try out some operations
with a legal card, make some mistakes, take note of the various
codes; 5) When you are ready insert a fraudulent card into the
ATM. Now the following happens:
- the ATM sends a signal to the host, saying "Hey! Can I give
this guy money, or is he broke, or is this funny card invalid?";
- the microcomputer intercepts the signal from the host,
discards it, sends on the "there's no one using the ATM" signal;
- the host gets the "no one using" signal and sends back its
"good, keep watching out if somebody comes by, and for God's sake
don't spit out any money on the street!" signal to the ATM;
- the microcomputer intercepts this signal (again), throws it
away (again), and sends the "Wow! That guy is like TOO rich! Give
him as much money as he wants. In fact, he's so loaded, give him
ALL the cash we have! He is a really valued customer." signal.
- the ATM obediently dispenses cash till the cows come home.
All this should be possible, but as a matter of fact it has
not much to do with cracking, unless there is a special software
protection on the line... so if you want to work on ATMs contact
our fellow phreakers/hackers and learn their trade... and
please remember to hack only cash dispenser that DO NOT HAVE a
control camera :=)
PASSWORDS AS REGISTRATION
This type of password is often used in shareware programs. When
you register the shareware program, you are sent a password that
you use to upgrade your shareware program to a complete and more
powerful version. This method, used frequently for commercial
applications, has recently been used quite a lot by many windows
applications that come "crippled" on the magazines cover CD-roms,
requiring you to telephone a hot line (and paying) in order to
get the "unique key" to unlock the "special protection". It's all
bullshit: we'll learn in the "how to crack windows" lessons how
easy it is to disable the various routines that verify your
entry.
PASSWORDS AS COPY PROTECTIONS
This type of password is often used for games and entertainment
software. The password query does not usually appear any more at
the start of the program, or as the program is loading. Instead,
the password query appears after one or more levels are completed
(this innovation was pioneered by "EOB I" and the "Ultima"
series) or when the user reloads a saved game or session.
DONGLE PASSWORDS
A few extremely expensive programs use a dongle (also called
an hardware key). A dongle is a small hardware device containing
a password or checksum which plugs into either a parallel or a
serial port. Some specially designed dongles even include
complete program routines. Dongles can be cracked, but the amount
of work involved is considerable and the trial and error
procedure currently used to crack them via software is extremely
tedious. It took me more than a week to crack MULTITERM,
Luxembourger dongle protected program. The quickest method to
crack dongle protected programs, involves the use of pretty
complicated hardware devices that cannot be dealt with here. I
myself have only seldom seen them, and do not like at all to
crack dongles via software, coz it requires a huge amount of zen
thinking and of luck and of time. If you want more information
on the hardware way to crack dongles, try to contact the older
ones on the appropriate web sites, they may even answer you if
you are nice, humble and really technically interested.
The obvious principle, that applies to the software password
types mentioned above is the following: The better the password
is hidden, and the better it is encrypted, the more secure the
program will be. The password may be
- encrypted and/or
- in a hooked vector and/or
- in an external file and/or
- in a SMC (Self modifying code) part
Let's finally inspect the common "ready_made" protection
schemes (used by many programmers that do not program
themselves):
* password read in
* letters added to a key to be entered
* complement of the letters formed xoring with 255
* saved key (1 char)
* saved password (256 chars)
* saved checksum (1 char), as protection, against simple
manipulations
* generating file PASSWORD.DAT with password, to be inserted
inside a different file than the one containing the calling
routine
Now the lazy programmer that wants to "protect" his program
searches first the file where the password is stored, then loads
the key, the password and the checksum. He uses a decrypt
procedure to decrypt the password and a check_checksum procedure
to check whether the password was modified. All this is obviously
crackabe in few seconds.
[PASSWORD ACCESS INSIDE THE SETUP]
Some computers have a password protected access INSIDE the
Setup (at the beginning), the protection scheme does not allow
a boot with a floppy and does not allow a setup modify. In these
cases the only possible crack is an old hack method:
* open the PC
* find on the motherboard a small jumper (bridge) with the
words "Pw"
* take it away
* PC on
* run the setup with F1 or Del (depending from the BIOS) (the
protection will not work any more)
* deactivate inside the setup the option password
* PC off
* put the small jumper (bridge) back again
* close the PC
* PC on, cracked (if you want to be nasty you could now use
the setup to set YOUR password)
If you want to know more about access refuse and access
denying, encryption and locking of the FAT tables, get from the
web, and study, the (very well written) code of a virus called
"Monkey", that does exactly this kind of devastation. Virus
studying is, in general, very useful for cracking purposes, coz
the virus'code is at times
- very well written (pure, tight assembly)
- using concealing techniques not much different from the
protection schemes (often far superior)
- using the most recent and best SMC (self modifying code)
tricks
But, and this is very important, do not believe that the
protection schemes are very complicated! Most of the time the
protection used are incredibly ordinary: as a final example of
our paper protection schemes, let's take a program released not
long ago (1994), but with a ridiculous protection scheme: TOP
(Tiger on the prowl) a simulation from HPS.
Here the cracking is straightforward:
- MAP(memory_usage) and find main_sector
- type "AAAA" as password
- (s)earch main_sector:0 lffff "AAAA"
- dump L80 "AAAA" location -40 (gives you a "wide" dump),
this gives you already the "echo" of the correct password
- breakpoint on memory read & write to "AAAA" location and
backtrace the complete main_sector
it's done! Here the code_lines that do protect TOP:
8A841C12 MOV AL,[SI+121C] move in AL first user letter
3A840812 CMP AL,[SI+1208] compare with echo
7402 JZ go_ahead_nice_buyer
EB13 JMP beggar_off_ugly_cracker
Now let's quickly crack it:
------------------------------------------------
CRACKING TOP.EXE (by +ORC, January 1996)
ren top.exe top.ded
symdeb top.ded
- s (cs+0000):0 Lffff 8A 84 1C 12 3A 84
xxxx:yyyy (this is the answer of the debugger)
- e xxxx:yyyy+2 08 (instead of 1C)
- w
- q
ren top.ded top.exe
-------------------------------------------------
And you changed the MOV AL, [SI+121C] instruction in a MOV AL,
[SI+1208] instruction... it is now reading the ECHO instead of
the characters you typed in... no wonder that the ECHO does
compare exactly with itself... and you pass!
"SOMETHING FISHY UNDER COVERS"
Back to the "Passletter" type of password protected programs.
Let's take as an example the protection used in a game of 1990:
"F19", where the protection scheme asks you to identify a
particular plane's silhouette. This kind of protection is used
in order to avoid the use of memory locations where the passwords
are stored: we saw in the first part of our "passwords hands on"
how easy it is to crack those schemes.
To crack this kind of protection, you could try a technique know
as "memory snuffing". The protected program, START.EXE, install
itself first at location xxxx:0000 with a length of 6C62 bytes,
but proceeds to a relocation of its modules (with some SMC, self
modifying code parts) in different locations. What does all this
mean? Well, this could mean quite many things... the most
important one for crackers is that the protection code will
probably snap way ahead of the actual user input phase.
Now you 'll quickly find out that the routine determining
(randomly) which plane is being chosen, leaves the progressive
number of this plane in one memory location: (imc) 43CD:DADA.
This brings us to the random triggering mechanism:
E87FAF CALL random_seed
83C402 ADD SP,02
8946E8 MOV [BP-18],AX and ds:(BP-18) is the location
you are looking for
Now, every time this random triggers, you get a different number
(00-x14) in this location, corresponding to the different plane
the user should choose.
The random seed routine, evidently, comes back with the random
seed in AX... what we now need is to zero it: the user will
always have to choose the same plane: "plane 0", and he will have
given the correct answer. Note how elegant all this is: we do not
need to interfere with the whole mouse pointing routines, nor
with the actual choosing of the planes... the random seed may
choose whatever plane it wishes... the memory location for this
choice will always report the (legitimate) choice of zero.
So, let's quickly crack this program:
---------------------------------------------------
CRACKING "F19" [START.EXE] (by +ORC, January 1996)
ren start.exe start.ded <- let's have a dead file
symdeb start.ded <- let's debug it
- s cs:O lffff 83 C4 02 89 46 E8 <- search ADD SP,02
xxxx:yyyy <- debugger's answer
- e xxxx:yyyy 58 [SPACE] 31 [SPACE] C0 [SPACE]
- w <- write the crack
- q <- back to the OS
ren start.ded start.exe <- re-write the exe
----------------------------------------------------
You just transformed the instruction you searched for
83C402 ADD SP,+02
in the following sequence:
58 POP AX <- respecting ADD SP,+02
31C0 XOR AX,AX <- xoring to zero
(the POP AX instruction increments the stack pointer by 2, in
order to respect the previous ADD SP,+02).
Well, nice. It's getting easier, isnt'it? Now let's take as
example a protection that has no "echo" in memory. (At the
beginning this was a smart idea: "the cracker won't find the
correct password, 'coz it's not there, ah!". We'll now therefore
crack one of the first programs that used this scheme:
[Populous.exe], from Bullfrog.
[POPULOUS.EXE]
A old example of the protection scheme "password that is not
a password" can be found in [Populous.exe], from Bullfrog. It's
a very widespread program, and you'll surely be able to find a
copy of it in order to follow this lesson. The program asks for
the identification of a particular "shield", a combination of
letters of various length: the memory location were the user
password is stored is easily found, but there is (apparently) no
"echo" of the correct password. You should be able, by now, to
find by yourself the memory location were the user password is
stored. Set a breakpoint memory read & write on this area, and
you 'll soon come to the following section of code:
F7AE4EFF IMUL WORD PTR [BP+FF4E] <- IMUL with magic_Nø
40 INC AX
3B460C CMP AX, [BP+0C]
7509 JNZ beggar_off_ugly_copier
8B460C MOV AX, [BP+0C]
A3822A MOV [2A82], AX
E930FE JMP nice_buyer
817E0C7017CMP WORD PTR[BP+0C],1770 <- beggar_off
I don't think that you need much more now... how do you prefer
to crack this protection scheme? Would you choose to insert a MOV
[BP+0C], AX and three NOPS (=6 bytes) after the IMUL instruction?
Wouldn't you rather prefer the more elegant JMP to nice_buyer
instruction at the place of the JNZ beggar_off? This solution has
less nops: remember that newer protection schemes smell
NOPs_patches!). Yeah, let's do it this way:
---------------------------------------------------
CRACKING [Populous.exe] (by +ORC, January 1996)
ren populous.exe populous.ded <- let's have a dead file
symdeb populous.ded <- let's debug it
- s cs:O lffff F7 AE 4E FF <- the imul magic_Nø
xxxx:yyyy <- debugger's answer
- e xxxx:yyyy+4 EB [SPACE] 03 <- JMP anyway
- w <- modify ded
- q <- back to the OS
ren populous.ded populous.exe <- let's re-have the exe
----------------------------------------------------
This time was easy, wasnt'it?
Now you are almost ready with this course... let's crack a
last application, a memory utility that is very widespread, very
good (the programmers at Clockwork software are Codemasters),
very useful for our purposes (you'll use it later to crack a lot
of TSR) and, unfortunately for Clockworkers, very easy to crack
at the level you are now.
But, Hey! Do not forget that you would have never done it without
this tutorial, so do the following: look toward east from your
window, sip a Martini-Wodka (Two blocks of ice first, 1/3 dry
Martini from Martini & Rossi, 1/3 Moskovskaia Wodka, 1/3
Schweppes indian tonic) and say three times: Thank-you +ORC!.
[MAP.EXE]
Let's now go over to one of the best TOOLS for mapping your
memory usage that exist: MAP.EXE (version 2) from the masters at
Clockwork software. The usage of this tool has been recommended
in Lesson 2, and you should learn how to crack it, coz it comes
with an annoying nag-screen ("Nigel" screen). In [Map.exe] this
ubiquitous "Nigel" screen appears at random waiting for a random
amount of time before asking the user to press a key which varies
every time and is also selected at random.
The use of a single letter -mostly encrypted with some XOR
or SHR- as "password" makes the individuation of the relevant
locations using "snap compares" of memory much more difficult.
But the crack technique is here pretty straightforward: just
break in and have a good look around you.
The INT_16 routine for keyboard reading is called just after
the loading of the nag screen. You 'll quickly find the relative
LODSB routine inside a routine that paints on screen the word
"Press" and a box-edge after a given time delay:
B95000 MOV CX,0050
2EFF366601 PUSH CS:[0166]
07 POP ES
AC LODSB
...
You could already eliminate the delay and you could already force
always the same passletter, in order to temperate the effects of
the protection... but we crack deep!: let's do the job and track
back the caller! The previous routine is called from the
following section of the code:
91 XCHG AX,CX
6792 XCHG AX,DX
28939193 SUB [BP+DI+9391],DL
2394AA94 AND DX,[SI+94AA]
2EC7064B880100 MOV WORD PTR CS:[884B],0001
2E803E5C0106 CMP BYTE PTR CS:[015C],06
7416 JZ ret <- Ha! jumping PUSHa & POPa!
505351525756 PUSH the lot
E882F3 CALL 8870
2E3B064B88 CMP AX,CS:[884B]
7307 JAE after RET <- Ha! Not taking the RET!
5E5F5A595B58 POP the lot
C3 RET
... <- some more instructions
E86700 CALL delay_user
BE9195 MOV SI,9591
2E8B3E255C MOV DI,CS:[5C25]
83EF16 SUB DI,+16
2E8A263D01 MOV AH,CS:[013D]
50 PUSH AH
E892C7 CALL routine_LODSB <-- HERE!
B42C MOV AH,2C
CD21 INT 21 <- get seconds in DH
80E60F AND DH,0F
80C641 ADD DH,41
58 POP AX
8AC6 MOV AL,DH
83EF04 SUB DI,+4
AB STOSW
E85A00 CALL INT_16_AH=01
B400 MOV AH,00
CD16 INT 16
24DF AND AL,DF <- code user's letter_answer
3AC6 CMP AL,DH <- pass_compare
75F3 JNZ CALL INT_16_AH=01
E807F3 go_ahead
You just need to look at these instructions to feel it: I
think that unnecessary code segments (in this case protections)
are somehow like little snakes moving under a cover: you cannot
easily say what's exactly going on yet, but you could bet that
there is something fishy going on. Look at the code preceding
your LODSB routine call: you find two JUMPS there: a JZ ret, that
leaves a lot of pusha and popa aside, and a JAE after RET, that
does not take the previous ret. If you did smell something here
you are thoroughly right: The first JZ triggers the NIGEL screen
protection, and the second JAE does THE SAME THING (as usual,
there are always redundances, exactly as there are a lot of
possibilities to disable a single protection). Now you know...
you can disable this protection at different points: the two
easiest blueprints being
1) to change 7416 (JZ ret) in a EB16 (JMP ret anyway)
2) to change 7307 (JAE after ret) in a 7306 (JAE ret).
We have not terminated yet: if you try locating this part
of the code in order to change it, you won't have any luck: it's
a SMC (Self modifying code) part: it is loaded -partly- from
other sections of the code (here without any encryption). You
must therefore first of all set a breakpoint on memory range;
find out the LODSW routine; find out the real area; dump that
memory region; find out a search sequence for the "dead" code...
and finally modify the "dead" program.
Now let's quickly crack it:
------------------------------------------------
CRACKING MEM.EXE (version 2) (by +ORC, January 1996)
ren map.exe map.ded
symdeb map.ded
- s (cs+0000):0 Lffff 74 16 50 53 51 52 57
xxxx:yyyy <- this is the debugger's answer
- e xxxx:yyyy EB
- w
- q
ren map.ded map.exe
-------------------------------------------------
Now you have done it, NIGEL has been cracked!
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are on the Web.
You 'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed.
