HOW TO CRACK, by +ORC, A TUTORIAL

Lesson 2: tools and tricks of the trade

[INDY.EXE]

LOST IN THE DARK CODEWOODS When you break into a program you end up in portions of code that are unfamiliar to you. It is also not uncommon for the breakpoints to occur outside of the confines of the program you want to crack. Getting your bearings is, in these cases, very important. One of the handiest utilities is the memory dump tool -it tells you where all the device drivers and TSR are loaded, in which memory locations the program you are cracking dwells, how much memory is left and what the next program load point is. The tools you use should report on the following: the contents of interrupt vectors the state of the BIOS data area, beginning at address 40:0 internal structures within DOS, such as the MCB chain, the SFT (System File Table) chain, the chain of installed device drivers, the PSPs and memory allocations associated with installed TSRs memory allocation statistic from XMS and EMS drivers When seeking to understand a section of foreign code, you must be especially careful to seek the real intent of the code.

Consider using a profiler prior to undertaking an analysis of an unfamiliar program. This will help you by ensuring that you dont waste time studying sections of the program that arent even involved in the protection scheme you are chasing down. Using a utility that charts a programs 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 Borlands 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 wont do. Ill 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 dont have a strong hunch. Most of the time youll end up missing important details. So first of all sit down and ponder... thats

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 programs 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 programs execution. If your debugger sports a backtrace buffer, logging window, or similar feature, by all means learn how to use it. The debugger its your best weapon, you must know all the possibilities it offers and all the capabilities it possesses. Having a debuggers 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 programs 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 dont overdo it! To reverse-engineer even a small program can involve many hours of analysis and documentation work. If youll 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: youll 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 programs 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 functions interrelationship with the programs 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! Its 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 programs binary modules. If the program happens to load its message strings from separate files, your search has just been simplified. Your debuggers 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 messages 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 characters position. If this wont 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 debuggers disassembly output of the instructions immediately following an interrupt call doesnt 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 cant 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 youll 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 isnt 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 lets find the address of the INT_21 interrupt vector. Since the interrupt vector table starts at address 0000:0000 (easy to remember, isnt 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)... its 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 = 2E03 (offset)

19AC3-16CC0

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 set maxhits 140 set maxhitspm 15 find stepdos

<- anywhere in string <- (100-1000) <- not just 1 file all over

<- 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. Its a visual utility: it enables you to see graphically the 1-meg of PC memory in 8 kbyte chunks. Its 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 its a great help when youll 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. Its 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, youll 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.OBrien, 1046 bytes long, its nice. [SPRAY.COM] Thats a good crack utility indeed! This 1989 program by Daniel M.OBrien gives you a post-mortem picture of your memory. You redirect it to <myfile> and study it at ease. Its 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 its 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 its 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 Hork could easily be

the best one, and comes with source code(!). Ill teach you how to crack without any of them (you do not need them if you zencrack), 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. Its a fairly good sourcering tool. Version 4.08 has been cracked (its 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: Ill teach you how to crack without sourcering (you dont 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 Borlands 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! Thats the whole point in cracking: a mission to IMPROVE the best accomplishments of humanitys 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, youll 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) zencracking. I ll give you right now an example of this, so that you know what Im talking about, but -unless you are already capable- youll have to finish this tutorial part for normal cracking before attempting this techniques. Lets 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 Its 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 its 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. Youll get some

locations. (In the case of INDY 500 you get 6 such locations). feel the locations (thats the tricky part). OK, you already made it! Here is the protection strategy: 8BBF28A5 AC B4FF 2A25 MOV DI,[BX+A528]<-- DI points to coded data area <-- load first digit of answer in AL <-- load mask in AH

:compare_loop LODSB

MOV AH,FF

SUB AH,[DI] <-- sub coded data from mask and get

real answer 47 3AC4 INC DI <-- ready to get next coded data <-- user answer = real answer ?

CMP AL,AH

751A JNZ beggar_off_coz_false_answer 0AC0 75F2 59 ... And if the protection scheme had been more far away? And if you cannot feel the right one? And if my grandma had wheels? Youll learn it, believe me. Now lets quickly crack this crap. OR AL,AL <-- more numbers?

JNZ compare_loop POP CX <-- all OK, go on, nice guy

CRACKING INDY.EXE (by +ORC, January 1996) ren indy.exe indy.ded symdeb indy.ded

 s (cs+0000):0 Lffff B4 FF 2A 25 47 3A C4 75 1A xxxx:yyyy <-- this is the answer of the debugger

s (cs+1000):0 Lffff B4 FF 2A 25 47 3A C4 75 1A (nothing, but you must be sure there isnt a mirror) e xxxx:yyyy+8 00 w q ren indy.ded indy.exe <-- JNZ 1A ahead changes to JNZ 0

Cracked: you just changed the JNZ beggar_off instruction in a JNZ go_ahead_anyway. Nice, isntit? WHY WE CRACK Strange as it may seem, the reasons for cracking are very important for the success of our task. We (at least we old crackers) crack AGAINST society, and OPPOSING laws and conventions. We usually DO NOT crack for money or for other commercial reasons (just sometimes, and we are expensive: I have plenty of money already and my services are VERY expensive if you need an aimed deprotection). But in general we dont care much for money and -as you can see- I am giving away the basis of what I know for free with this tutorial. The programs we crack should be made free for everybody, even if we spent some of our time deprotecting them. We could not care less of the commercial value of a given program, not to mention the holy work of the ethical programmers... we program ourselves, but only because we LIKE it... if somebody does something only in order to gain money, he does not deserve anything. Its the mind challenge that

counts, NEVER the profit! (Even if you can make good use of the cracked programs and even if -as I said- there is at times a personal profit). This is an indispensable attitude! Only a non-mercantile mind can leap forward to the satori knowledge that you desperately need if you want to crack quickly and elegantly huge iperbloated monstruosities that somebody else wrote and protected, or if you want to gain access to some hidden information, data that you would like to snoop but that somebody declared off limits, coz a stupid government, or useless industry sector, or money oriented programmer or dirty lobby of interest decided it. If you do accept the society where we are compelled to live, its awfully egoistic way of life and its dirty profit values, you may eventually learn how to disable some simple protections, but youll never be able to crack in the right way. You must learn to despise money, governments, televisions, trends, opinion-makers, public opinion, newspapers and all this preposterous, asinine shit if you want to grasp the noble art, coz in order to be emphatic with the code you must be free from all trivial and petty conventions, strange as it may sound. So you better take a good look around you... youll find plenty of reasons to hate society and act against it, plenty of sparks to crackle programs in the right way... Hope all this did not sound too cretin. Well, thats 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 Ill actually know them already, but if they are really new youll 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, Ill 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