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 an526164@anon.penet.fi