LOST IN THE DARK CODEWOODS When you break into a program you end up in portions of codethat are unfamiliar to you. It is also not uncommon for thebreakpoints to occur outside of the confines of the program you want to crack. Getting your bearings is, in these cases, veryimportant. One of the handiest utilities is the memory dump tool -ittells you where all the device drivers and TSR are loaded, inwhich memory locations the program you are cracking dwells, howmuch memory is left and what the next program load point is. Thetools 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, youmust be especially careful to seek the real intent of the code.Consider using a profiler prior to undertaking an analysis of anunfamiliar program. This will help you by ensuring that you don'twaste time studying sections of the program that aren't eveninvolved in the protection scheme you are chasing down. Using a utility that charts a program's calling hierarchycan give you an important perspective on how your babe conductsits internal operations.YOUR DEBUGGER: YOUR FAVOURITE TOOL First and foremost, your debugger must be designed for usewith resident modules (or must be itself a resident module). Trying to crack with simplistic [debug.com] is a sure way to getabsolutely nowhere. We recommend Softice.exe from Nu-Megatechnologies (Version 2.6 [S-Ice.exe] has been cracked by MARQUISDE SOIREE and its vastly available on the Web). You could alsouse [Periscope] or [Codeview] or Borland's Turbodebugger... allthese programs have been boldly cracked and/or distributed andare now on the Web for free... learn how to use YAHOO and findthem. In emergency cases you could fix some quick crack using[debug] or [symdeb], but, as said above, most of the time theseolder debuggers won't do. I'll nevertheless ALWAYS give the final crack procedure for [debug.com], in order to permit even lusersto 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 schemeused, going in too deep too soon can be a problem when you don'thave a strong hunch. Most of the time you'll end up missingimportant details. So first of all sit down and ponder... that'sthe zen-way, the only one that really works. Single-stepping is expensive, not only because of the timeit requires but also because of the amount of detail with whichyou must contend. Your immediate goal is to home in on theprotection scheme through a series of successively refined traps,your broader aim is to get an overview idea of the program'saction... the wise use of breakpoints will condense these minutiae into an understandable form. The first step is to try to identify the section of theprogram 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 theprogram's execution. If your debugger sports a backtrace buffer,logging window, or similar feature, by all means learn how to useit. The debugger it's your best weapon, you must know all thepossibilities it offers and all the capabilities it possesses.Having a debugger's display output echoed to a printer is anotherpossibility. Using breakpoints is beneficial for two basic reasons: speedand reduction of detail. Manual single-stepping is invaluablewhen you are close to the protection scheme, but too much of itwill bore you to death. When selecting breakpoint locations and the types of breakpoint to use, it is important to step back once more, drinka cool Martini-Wodka (use only Moskovskaja: non-russian Wodkasare appalling) and ask yourself: "What is this going to tell me?"and "What else will I need to know once the break occurs?". MOSTIMPORTANT OF ALL: "Is my current cracking approach the simplestand most direct?", coz you do not want to waste precious cracking time. When devising a set of breakpoints it is wise to considerhow "a trail of bread crumbs" can be left. Not allowing for anexecution chronicle from the start can mean having to restart acracking session. Setting breakpoints on certain software interrupt calls isan excellent way to get an overview of a program's operations.The INT_21 DOS services interrupt is probably the most universaluseful of these, with BIOS interrupts such as the INT_13 (BIOSDisk services) and INT_16 (BIOS keyboard services) useful forspecific cracking. When working with a debugger, evaluative breakpoints areusually your best shot. To avoid having to deal with a plethoraof calls, you would want to have a debugger capable of being toldto "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 smallprogram can involve many hours of analysis and documentationwork. If you'll not be able to use the zen-cracking techniquesdescribed in this tutorial (sadly not everybody can) paceyourself and make sure your chair is comfortable: you'll besitting for quite a spell. Much of the work involved in reverse-engineering consist of chasing down tentacles. In order to understand the operations ofone function, you must understand what happens within each of thefunctions it calls- its child functions. To understand thesechild functions you must study their children; and so on down thecalling 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 otherfunctions you must reckon with. When it comes to analyzing afunction's interrelationship with the program's data structure,no such list is provided. You must have instinct, feeling andluck. Data analysis requires more of a broad-based inquisition.For each memory variable you are interested in, you must surveyall functions to determine which ones read and write thatvariable. The use of memory conditional breakpoints and of adisassembler that builds a cross-reference table can make thistask a lot easier. (Use Sourcer! It's a fairly good tool andversion 4.08 of [sr.exe] has been long ago cracked anddistributed on the Web).ALL SYSTEM CALLS IN ONE LOCATION Remember that if the program you are cracking was writtenin assembler in the first place (very unlikely knowing thelaziness of to_days programmers), system calls are probably madedirectly from the functions which need them. But when a programis developed in a high-level language, it is more likely thatcommon library functions will be used for many operationsinvolving system calls. When a program makes all of its INT_21calls from the same location, you know that this is certainly thecase. Now, what happens sometimes is that the programmers writethe whole application in a overbloated language like C++, but areafterwards compelled to "speed up" critical sections of the codewriting them in assembler. And loo! A section where yourepeatedly find assembler crafted patches is precisely theprotection scheme! So you could have a program with all INT_21calls from the same location but for one or two calls which arecoming out of the section where the morons have "hidden" their protection strategy. By just "looking" at the dead code of aprogram, you should be capable to tell wich parts have been"added on" in a later phase. They presents themselves asunevenness and irregularities, especially if you use an utilitythat represents graphicallly the code of a program. Protectionsare often added on at the end of the development. Should you determine that the system calls relevant to yourcracking 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 somepoint in between these calls. Break in with your debugger at theend of the first system call, just where it is returning to thepoint of call. From there, trace through the remainder of thecommon 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 theprogram you want to crack, it can be enlightening to use a hexdump utility to examine the message strings contained within theprogram's binary modules. If the program happens to load itsmessage strings from separate files, your search has just beensimplified. Your debugger's memory-dumping feature is one tool that canbe useful for this type of exploration. You could also constructa filtering program, which would read a binary file and outputall sequences of bytes that are comprised of displayable characters and are over a certain minimum length (the bestcracker tools are often the ones you write yourself). When a protection scheme is marked by the issuance of aspecific message on the screen, you could go into the program andlocate the code that emits this message, and then determine whattriggers it. A good way to start the location process is to seeif 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 theconsole. When the message's display is not a result of one of thesesystem calls, direct video writing is probably being used. If youknow the screen location used, and if that part of video memoryis not used for anything else at the time (a big if), a memorywrite breakpoint could be set on the video buffer addresscorresponding to the first character's position. If this won'twork, use the step-over/step-around tracing technique whilewatching for the message to appear. Now you found it: from a disassembled listing, you locatethe address of the message string and then survey the reminderof the file for any instructions that reference this address.[Sourcer] can generate labels for specific memory locations anda cross-reference table showing where these labelled locationsare referenced. Otherwise, load the disassembled listing fileinto your editor and use its search capabilities. Manuallysearching for such things in a listing will make you old beforeyour time.CODE AND DATA When stepping through code at the assembler level, watch outfor interrupt calls that are followed by data. Sometimes you willfind an interrupt call, typically within the range INT_34 toINT_3F, where several bytes immediately following the interruptinstruction will be data rather than code. Be especially suspicious of this type of code-and-datamixture when your debugger's disassembly output of theinstructions immediately following an interrupt call doesn't makesense. Sometimes you can determine the offset of the next trueinstruction by inspecting the following code and data. In othercases, you will have to trace through the interrupt call to seehow it accesses the data following the interrupt call instructionand 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 aswhat interrupt handlers are established by the target program,can provide useful clues. For example, if a protectionestablishes an INT_09 intercept just before the snapping of akeyboard verification routine, your range of suspects has justbeen narrowed significantly. To study the interrupt vector activities of an application,a vector dump map utility is useless. It can't be run whilerunning the application you want to crack. One solution is to runthe program under a debugger and watch for system calls to INT_21functions 25h (set interrupt vector) and 35h (get interruptvector), but in the event that the program reads and writesinterrupt vectors directly, this method will not give you acomplete picture. Normally you'll use a spy, trace or "step"utility. APPLYING A MEMORY WRITE BREAKPOINT TO A SPECIFIC VECTOR ORTO THE ENTIRE TABLE is another way to deal with this. Note that some sort of direct vector writing must beoccurring if a vector change is detected between system calls. If a vector change is detected during a system call but itisn't function 25h of INT_21, suspect that an IRQ handler may beeffecting the change.LITTLE TRICKS OF THE TRADE: * determining interrupt vector addresses **************** How do you determine the interrupt vector addresses? Asexample 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 pervector, the basic process is to multiply the interrupt numberfour times and use the result at the offset (on segment zero). 21h + 21h = 42h 42h + 42h = 84hThe int_21 vector is located at address 0000:0084You could also use a calculator, for instance, the address ofINT_63 is 63h*4=18ch -> 0000:018C * address conversion *************************************** After a painstaking cracking session, you have finallydetermined that a byte of memory at address 6049:891C is thetrigger. But when you isolate the offending instruction, you findthat the address it is generating when the protection occur isdifferent, being 6109:7D1C instead! How can this be? An 80x86 type CPU, when running in real or VM86 mode, useswhat is known as segment:offset type addressing. One side effectof this addressing method is that one physical address can beequivalent to many different segment:offset addresses. To find the PHYSICAL ADDRESS for a given segment:offset dothe following:- convert the segment portion of the address to a 1-based numberby multiplying it by 16 (x10)... it's easy: add 0 at the rightend of the number!... 6049 -> 60490 6109 -> 61090now 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, say19AC3, and you want to obtain a segment:offset address you mustfirst 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:2E03TOOLS OF THE TRADEBefore starting this section, for those of you that do not knowanything, here is the ARCHIE way you get all the program that doEXIST on the planet: e-mail following1) (address) archie@archie.univ-rennes1.fr I use this french archie, but you can get a worldwide list usingthe 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 fileWait two hours, get your post and ftp the file you wanted (andYES!, 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 isa (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 apowerful tool in order to locate quickly bit mapped graphics andother '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 ameliorateversion of Memscan itself. Looking at the VISUAL STRUCTURE of aprogram it's a great help when you'll crack higher levels.[TRACKMEM.COM] A very good tool by James W.Birdsall, tracks memory usageof programs (EMS, XMS, conventional).[SCANCODE.COM] "THE" scancode lister, by the code_masters from clockworksoftware. The must utility for crackers that do not learn allscancodes by heart.[MAP.EXE] Actually "MAP2", THE memory mapper from the code_masters atclockwork software. It's a very good tool and an interesting onetoo, coz you get it with the "Nigel" nag screens. They are notdifficult to remove (a "passletter" protection scheme, you'lllearn 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 dumpingis one of the first exercise they learn you at C-school.Hexdump.com is 558 bytes long, Tdump.exe 120.704, pick the oneyou 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 byDaniel M.O'Brien gives you a "post-mortem" picture of yourmemory. You redirect it to <myfile> and study it at ease. It'sdifficult to say how many hours of cracking it did spare me (youshould study the program, only 252 bytes long, and will have tomodify it a bit, coz it's pretty primitive, in the originalversion, for instance, the redirection to the printer works onlyif 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 inTDUMP.EXE too. This 1991 program by S.Krupa it's sometimes veryuseful.[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 bethe best one, and comes with source code(!). I'll teach you howto crack without any of them (you do not need them if you zen-crack), but they can nevertheless be very useful in somesituations. Stepdos.exe, by Mike Parker, is a excellent program:a pleasure to crack in order to use it for slightly differentpurposes :=) [SOURCERING UTILITIES] SR.EXE can be used for sourcering unknown programs. It's afairly good sourcering tool. Version 4.08 has been cracked (it'sa "ORIGINAL NUMBERCODE" protected program) and distributed on theWeb, so you should easily find it. This said, you should NEVERuse such a brute force approach, unless you are really desperate:I'll teach you how to crack without sourcering (you don't needto sourcer if you zen-crack). [HEXEDITORS]Every idiot has written at least one hexeditor, and you can findvery 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 1990program by Gary C. Crider (Parity Solutions, 1903 Pavia Ct.Arlington, TX 76006... sometimes even americans can write goodprograms). If you do use it (as you should) disapt the nag screenas small exercise in cracking.[DEBUGGER] Your best friend in cracking, your weapon, your hidecloak...I suggest [Softice.exe] from Nu-Mega technologies (Version 2.6has been cracked by MARQUIS DE SOIREE and its vastly availableon the Web). You could also use [Periscope] or [Codeview] orBorland's Turbodebugger... all these programs have been boldlycracked and/or distributed and are now on the Web for free...learn how to use ARCHIE and YAHOO in order to find them. Yourdebugger is the only tool you 'll REALLY need, believe me. So choose your weapon wisely and learn how to use backtrace rangesand (FOREMOST!) breakpoint on user written qualificationsroutines. You 'll be able to crack almost EVERYTHING using thesefeatures in the right way. You should get all the programs mentioned above (all theprograms that EXIST for that matter) for free on the Web. Usethem, but also modify them recklessly! REMEMBER THAT YOU ARE (GOING TO BE) A CRACKER! The first programs you should crack andmodify are therefore your very tools! So steal the code of thebest tools you find! Snatch the best routines and change them forthe better! That's the whole point in cracking: a mission toIMPROVE the best accomplishments of humanity's genius :=) HOW TO CRACK, ZEN-CRACKING You 'll learn, beginning with next lesson, how to cracksystematically the different protection schemes: paper & password protections, time protections, access protections. At the end ofthe "methodolocical" part, you'll be able to deprotect programs,but you still wont be a cracker. In order to crack higher youmust 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 alreadycapable- you'll have to finish this tutorial part for "normal"cracking before attempting this techniques. Let's zen-cracktogether a password protection scheme (aka "paper protection",coz you need the original manual of the program in order toanswer). This protection is based on the typing, at the nagscreen, of the correct sequence of numbers. Our example is a gamefor the reasons explained in lesson 1, but you 'll find the SAMEprotection scheme in the access protection procedure of some oldTapestry networks... so do not frown upon games protections.INDIANAPOLIS 500, Papyrus software & Electronic Arts, 1989It's a rather widespread program, you should therefore find itpretty easily. The nag screen asks for data based on thehistorical performances of race cars... that means that theanswers 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 ofthe time fairly effective, but there is a better way: the "zenway", the only one that can really enable you to crack highprotection schemes.- Run the program and break in at the nag screen- Answer consist of 2-3 digits? Search for "AC" (i.e. theinstruction LODSB, load digit of answer in AL) in the area 500bytes BEFORE and 500 bytes AFTER your position. You'll get somelocations. (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 youcannot "feel" the right one? And if my grandma had wheels? You'lllearn it, believe me.Now let's quickly crack this crap. ------------------------------------------------CRACKING INDY.EXE (by +ORC, January 1996)ren indy.exe indy.dedsymdeb indy.ded- s (cs+0000):0 Lffff B4 FF 2A 25 47 3A C4 75 1Axxxx: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- qren indy.ded indy.exe -------------------------------------------------Cracked: you just changed the JNZ beggar_off instruction in a JNZgo_ahead_anyway. Nice, isnt'it?WHY WE CRACK Strange as it may seem, the reasons for cracking are veryimportant for the success of our task. We (at least we oldcrackers) crack AGAINST society, and OPPOSING laws andconventions. We usually DO NOT crack for money or for other "commercial" reasons (just sometimes, and we are expensive: Ihave plenty of money already and my services are VERY expensiveif you need an aimed deprotection). But in general we don't caremuch for money and -as you can see- I am giving away the basisof what I know for free with this tutorial. The programs we crackshould be made free for everybody, even if we spent some of ourtime deprotecting them. We could not care less of the commercialvalue of a given program, not to mention the holy work of theethical programmers... we program ourselves, but only because weLIKE it... if somebody does something only in order to gainmoney, he does not deserve anything. It's the mind challenge that counts, NEVER the profit! (Even if you can make good use of thecracked programs and even if -as I said- there is at times apersonal profit). This is an indispensable attitude! Only a non-mercantilemind can leap forward to the "satori" knowledge that youdesperately need if you want to crack quickly and elegantly hugeiperbloated monstruosities that somebody else wrote andprotected, or if you want to gain access to some hiddeninformation, data that you would like to snoop but that somebodydeclared "off limits", coz a stupid government, or uselessindustry 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 you'll never be able to crack in the "right" way. You mustlearn 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 fromall trivial and petty conventions, strange as it may sound. Soyou better take a good look around you... you'll find plenty ofreasons to hate society and act against it, plenty of sparks tocrackle programs in the right way... Hope all this did not soundtoo cretin. Well, that's it for this lesson, reader. Not all lessons of mytutorial are on the Web. You 'll obtain the missing lessons IF AND ONLY IF you mailme back (via anon.penet.fi) with some tricks of the trade I maynot know that YOU discovered. Mostly I'll actually know themalready, 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. Yoursuggestions and critics on the whole crap I wrote are alsowelcomed.