Reverse Code Engineering RCE CD +sandman 2000/ReverseCodeEngineeringRceCdsandman2000.iso/RCE/+Sandman/Htocrk32.txt

Text File | 2000-05-25 | 23KB | 844 lines

                     HOW TO CRACK, by +ORC, A TUTORIAL

---------------------------------------------------------------------------

                Lesson 3.2: hands on, paper protections (2)

---------------------------------------------------------------------------

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

                   --------------------------------------

You have seen in the previous lesson that the use of a password

protection, independently of the coding and hiding methods used

to store them in memory, implies the use of a comparing procedure

with the password that the user types in. You therefore have many

options to begin your cracking work:

-    find the location of the user password

-    find the "echo" in memory of the real password

-    find the routine that compares both

-    find the passwords hideout and encryption type

-    find the go_ahead_nice_buyer exit or jump

-    find the beggar_off_ugly_copier exit or jump

just to name the more obvious ones. In order to make things more

difficult for us crackers, the protectionists have devised many

counter-strategies, the more obvious ones being:

-    keeping the various part of the store/compare/hide routines

well apart in code (no match for zen-cracking);

-    filling these routines with "bogus" compares, bogus jumps

and bogus variables, in order to make things more difficult for

the crack (no match for decent crackers);

-    disseminating the code with anti-debugger tricks, like INT_3

instructions or jumps in and out protected mode (no match for our

beloved [Soft-Ice]);

-    trying to eliminate the need for passwords altogether

letting the user input "one letter" or "one number" or "one

image" as answer to some variable question. In this lesson I'll

teach you how to crack these "passletters" protection techniques.

Let's first resume the "uses" of a password protection:

PASSWORDS AS PERMISSION TO ACCESS

These passwords serve to acknowledge that a legitimate user is

using the program. This is the type of password that you'll find,

for example, protecting your user account on Compuserve, on

Networks or even in ATM machines used by banks or corporations.

These require a little hardwiring to crack: ATM passnumber

protection schemes rely on an answer from the central computer

(they do NOT verify only the three magnetic areas in the magnetic

strip on the card). The lines between ATM's & their hosts are

usually 'weak' in the sense that the information transmitted on

them is generally not encrypted in any way. (Some banks use

encrypted information, but this is fairly easy to crack too).

So for ATMs you should do the following 1) cross over the

dedicated line between the ATM and the host; 2) insert your

computer between the ATM and the host; 3) Listen to the "normal"

messages and DO NOT INTERFERE YET; 4) Try out some operations

with a legal card, make some mistakes, take note of the various

codes; 5) When you are ready insert a fraudulent card into the

ATM. Now the following happens:

-    the ATM sends a signal to the host, saying "Hey! Can I give

this guy money, or is he broke, or is this funny card invalid?";

-    the microcomputer intercepts the signal from the host,

discards it, sends on the "there's no one using the ATM" signal;

-    the host gets the "no one using" signal and sends back its

"good, keep watching out if somebody comes by, and for God's sake

don't spit out any money on the street!" signal to the ATM;

-    the microcomputer intercepts this signal (again), throws it

away (again), and sends the "Wow! That guy is like TOO rich! Give

him as much money as he wants. In fact, he's so loaded, give him

ALL the cash we have!  He is a really valued customer." signal.

-    the ATM obediently dispenses cash till the cows come home.

     All this should be possible, but as a matter of fact it has

not much to do with cracking, unless there is a special software

protection on the line... so if you want to work on ATMs contact

our fellow phreakers/hackers and learn their trade... and

please remember to hack only cash dispenser that DO NOT HAVE a

control camera :=)

PASSWORDS AS REGISTRATION

This type of password is often used in shareware programs. When

you register the shareware program, you are sent a password that

you use to upgrade your shareware program to a complete and more

powerful version. This method, used frequently for commercial

applications, has recently been used quite a lot by many windows

applications that come "crippled" on the magazines cover CD-roms,

requiring you to telephone a hot line (and paying) in order to

get the "unique key" to unlock the "special protection". It's all

bullshit: we'll learn in the "how to crack windows" lessons how

easy it is to disable the various routines that verify your

entry.

PASSWORDS AS COPY PROTECTIONS

This type of password is often used for games and entertainment

software. The password query does not usually appear any more at

the start of the program, or as the program is loading. Instead,

the password query appears after one or more levels are completed

(this innovation was pioneered by "EOB I" and the "Ultima"

series) or when the user reloads a saved game or session.

DONGLE PASSWORDS

     A few extremely expensive programs use a dongle (also called

an hardware key). A dongle is a small hardware device containing

a password or checksum which plugs into either a parallel or a

serial port. Some specially designed dongles even include

complete program routines. Dongles can be cracked, but the amount

of work involved is considerable and the trial and error

procedure currently used to crack them via software is extremely

tedious. It took me more than a week to crack MULTITERM,

Luxembourger dongle protected program. The quickest method to

crack dongle protected programs, involves the use of pretty

complicated hardware devices that cannot be dealt with here. I

myself have only seldom seen them, and do not like at all to

crack dongles via software, coz it requires a huge amount of zen

thinking and of luck and of time. If you want more information

on the hardware way to crack dongles, try to contact the older

ones on the appropriate web sites, they may even answer you if

you are nice, humble and really technically interested.

     The obvious principle, that applies to the software password

types mentioned above is the following: The better the password

is hidden, and the better it is encrypted, the more secure the

program will be. The password may be

-    encrypted and/or

-    in a hooked vector and/or

-    in an external file and/or

-    in a SMC (Self modifying code) part

     Let's finally inspect the common "ready_made" protection

schemes (used by many programmers that do not program

themselves):

*    password read in

*    letters added to a key to be entered

*    complement of the letters formed xoring with 255

*    saved key (1 char)

*    saved password (256 chars)

*    saved checksum (1 char), as protection, against simple

     manipulations

*    generating file PASSWORD.DAT with password, to be inserted

     inside a different file than the one containing the calling

     routine

Now the lazy programmer that wants to "protect" his program

searches first the file where the password is stored, then loads

the key, the password and the checksum. He uses a decrypt

procedure to decrypt the password and a check_checksum procedure

to check whether the password was modified. All this is obviously

crackabe in few seconds.

[PASSWORD ACCESS INSIDE THE SETUP]

     Some computers have a password protected access INSIDE the

Setup (at the beginning), the protection scheme does not allow

a boot with a floppy and does not allow a setup modify. In these

cases the only possible crack is an old hack method:

*    open the PC

*    find on the motherboard a small jumper (bridge) with the

     words "Pw"

*    take it away

*    PC on

*    run the setup with F1 or Del (depending from the BIOS) (the

     protection will not work any more)

*    deactivate inside the setup the option password

*    PC off

*    put the small jumper (bridge) back again

*    close the PC

*    PC on, cracked (if you want to be nasty you could now use

     the setup to set YOUR password)

     If you want to know more about access refuse and access

denying, encryption and locking of the FAT tables, get from the

web, and study, the (very well written) code of a virus called

"Monkey", that does exactly this kind of devastation. Virus

studying is, in general, very useful for cracking purposes, coz

the virus'code is at times

-    very well written (pure, tight assembly)

-    using concealing techniques not much different from the

     protection schemes (often far superior)

-    using the most recent and best SMC (self modifying code)

     tricks

     But, and this is very important, do not believe that the

protection schemes are very complicated! Most of the time the

protection used are incredibly ordinary: as a final example of

our paper protection schemes, let's take a program released not

long ago (1994), but with a ridiculous protection scheme: TOP

(Tiger on the prowl) a simulation from HPS.

Here the cracking is straightforward:

-    MAP(memory_usage) and find main_sector

-    type "AAAA" as password

-    (s)earch main_sector:0 lffff "AAAA"

-    dump L80 "AAAA" location -40 (gives you a "wide" dump),

     this gives you already the "echo" of the correct password

-    breakpoint on memory read & write to "AAAA" location and

     backtrace the complete main_sector

it's done! Here the code_lines that do protect TOP:

     8A841C12  MOV  AL,[SI+121C]   move in AL first user letter

     3A840812  CMP  AL,[SI+1208]   compare with echo

     7402      JZ   go_ahead_nice_buyer

     EB13      JMP  beggar_off_ugly_cracker

Now let's quickly crack it:

------------------------------------------------

CRACKING TOP.EXE (by +ORC, January 1996)

ren top.exe top.ded

symdeb top.ded

-    s (cs+0000):0 Lffff 8A 84 1C 12 3A 84

xxxx:yyyy           (this is the answer of the debugger)

-    e xxxx:yyyy+2  08 (instead of 1C)

-    w

-    q

ren top.ded top.exe

-------------------------------------------------

And you changed the MOV  AL, [SI+121C] instruction in a MOV AL,

[SI+1208] instruction... it is now reading the ECHO instead of

the characters you typed in... no wonder that the ECHO does

compare exactly with itself... and you pass!

"SOMETHING FISHY UNDER COVERS"

Back to the "Passletter" type of password protected programs.

Let's take as an example the protection used in a game of 1990:

"F19", where the protection scheme asks you to identify a

particular plane's silhouette. This kind of protection is used

in order to avoid the use of memory locations where the passwords

are stored: we saw in the first part of our "passwords hands on"

how easy it is to crack those schemes.

To crack this kind of protection, you could try a technique know

as "memory snuffing". The protected program, START.EXE, install

itself first at location xxxx:0000 with a length of 6C62 bytes,

but proceeds to a relocation of its modules (with some SMC, self

modifying code parts) in different locations. What does all this

mean? Well, this could mean quite many things... the most

important one for crackers is that the protection code will

probably snap way ahead of the actual user input phase.

Now you 'll quickly find out that the routine determining

(randomly) which plane is being chosen, leaves the progressive

number of this plane in one memory location: (imc) 43CD:DADA.

This brings us to the random triggering mechanism:

E87FAF    CALL random_seed

83C402    ADD  SP,02

8946E8    MOV  [BP-18],AX     and ds:(BP-18) is the location

                              you are looking for

Now, every time this random triggers, you get a different number

(00-x14) in this location, corresponding to the different plane

the user should choose.

The random seed routine, evidently, comes back with the random

seed in AX... what we now need is to zero it: the user will

always have to choose the same plane: "plane 0", and he will have

given the correct answer. Note how elegant all this is: we do not

need to interfere with the whole mouse pointing routines, nor

with the actual choosing of the planes... the random seed may

choose whatever plane it wishes... the memory location for this

choice will always report the (legitimate) choice of zero.

So, let's quickly crack this program:

---------------------------------------------------

CRACKING "F19" [START.EXE] (by +ORC, January 1996)

ren start.exe start.ded       <- let's have a dead file

symdeb start.ded              <- let's debug it

- s cs:O lffff 83 C4 02 89 46 E8 <- search ADD SP,02

xxxx:yyyy                     <- debugger's answer

- e xxxx:yyyy 58 [SPACE] 31 [SPACE] C0 [SPACE]

- w                           <- write the crack

- q                           <- back to the OS

ren start.ded start.exe       <- re-write the exe

----------------------------------------------------

You just transformed the instruction you searched for

     83C402    ADD  SP,+02

in the following sequence:

     58        POP  AX        <- respecting ADD SP,+02

     31C0      XOR  AX,AX     <- xoring to zero

(the POP AX instruction increments the stack pointer by 2, in

order to respect the previous ADD SP,+02).

Well, nice. It's getting easier, isnt'it? Now let's take as

example a protection that has no "echo" in memory. (At the

beginning this was a smart idea: "the cracker won't find the

correct password, 'coz it's not there, ah!". We'll now therefore

crack one of the first programs that used this scheme:

[Populous.exe], from Bullfrog.

[POPULOUS.EXE]

     A old example of the protection scheme "password that is not

a password" can be found in [Populous.exe], from Bullfrog. It's

a very widespread program, and you'll surely be able to find a

copy of it in order to follow this lesson. The program asks for

the identification of a particular "shield", a combination of

letters of various length: the memory location were the user

password is stored is easily found, but there is (apparently) no

"echo" of the correct password. You should be able, by now, to

find by yourself the memory location were the user password is

stored. Set a breakpoint memory read & write on this area, and

you 'll soon come to the following section of code:

F7AE4EFF  IMUL WORD PTR [BP+FF4E]       <- IMUL with magic_N°

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.

                                E-mail +ORC

                        +ORC [e-mail]