HOW TO CRACK, by +ORC, A TUTORIAL --------------------------------------------------------------------------- Lesson 8.1: How to crack Windows, an approach --------------------------------------------------------------------------- [WINPGP.EXE] -------------------------------------- -------------------------------------------------------- SPECIAL NOTE: Please excuse the somehow "unshaven" character of the windows lessons... I'm cracking the newest Windows '95 applications right now, therefore at times I had to add "on the fly" some corrections to the older Windows 3.1 and Windows NT findings. "homines, dum docent, discunt". --------------------------------------------------------- -> 1st THING TO REMEMBER The NE format does give every windows executable the equivalent of a debug symbol table: A CRACKER BLISS! -> UNDOCUMENTED DEBUGGING One of the many feature of Windows based on undocumented foundations is the "ability to debug". A word about undocumented functions in the MS-Operating Systems: Microsoft manipulates its rule and domination of the operating systems in use to day (MS-DOS, Windows, Windows '95) with two main wicked aims: 1) getting the concurrence completely bankrupt (that's the scope of all the using of undocumented functions and CHANGING them as soon as the concurrence uses them). The battle against Borland was fought in this way. 2) getting all future "programmers" to use windows as a "black box" that only Microsoft engineers (if ever) can master, so that everybody will have to sip the ill-cooked abominations from Microsoft without ever having a chance to alter or ameliorate them. Strange as it may seem, only the sublime cracker community fights against these intolerable plans. All stupid governments and lobbies -on the contrary- hide behind the fig-leaf of the "market" "freedom" in order to ALLOW such heinous developments (I'm speaking as if they were capable to opposing them even if they wanted, which they do not. Be assured, they couldn't anyway, "Governments" are deliberately MADE to serve Gates and all the remaining suckers, and lobbies are the shield of feudalism. You can forget "democracy", the only rule existing is a malevolent oligarchy based on money, personal connections, defect of culture, lack of knowledge and dictatorship of bad taste through television in order to keep the slaves tamed... enough now...) The windows situation is particularly reminiscent of the older situation in DOS, where for years the key "load but don't execute" function, used by debuggers, such as [DEBUG], [SYMDEB] and [CODEVIEW], was "reserved" by Microsoft. The windows debugging library, WINDEBUG.DLL, a number of undocumented functions and even the interface it provides are undocumented! The WinDebug() function is used by all available windows debuggers, including [CVW] (CodeView for Windows), [TDW] (TurboDebugger for Windows), [Multiscope] and [Quick C for Windows] (the last two are GUI, not text debuggers. The use of WinDebug() doesn't show up in MAPWIN output 'coz debuggers link to it at run-time via the amazing GetProcAddress() function. WinDebug() is a hacked 32-bit version, for the old Windows 3.0, of the poorly documented DOSPTrace() function from OS/2 1.x (study these older Operating Systems! Studying the past you'll understand EVERYTHING! Sometime I think that the only way to hack and crack correctly is to be more a software historian than a programmer... fac sapias et liber eris!). DOSPTrace is, in turn, based on the ptrace() function in Unix. Like DosPTrace(), WinDebug() takes commands such as Go, Single-Step, Write&Read Registers, Write&Read Memory. It returns to its caller either when the command completes or when a breakpoint occurs (or a DLL load). These commands and notifications appear in a large structure whose address is passed in WinDebug(). WinDebug() was renamed CVWIN.DLL (and TDWIN.DLL) for Windows 3.1., all crackers should study it and get the maximum possible documentation about it. As you will see in the following, it is worth to study also TOOLHELP.DLL (what Microsoft would like you to fiddle with) and INT_41h (the real debugging interface). Interrupt handling under Windows Interrupt handling under Windows can be tricky: you need to use Toolhelp (a rather scaring lobotomy for your programs) or to have special code for Standard vs. Enhanced modes, because the information on the stack of an interrupt or exception handler differs between the two windows modes. In addition, some handlers would be installed using INT_21h, while others are set up using DPMI services. Toolhelp has quite a bit of internal code that "cooks" the interrupts and sends them to you in an easily digestible form. Remember that Windows uses GP faults as a "hacker" method of doing ring transitions that are not allowed with legal 80x86 instructions: the virtual memory system of Enhanced mode is implemented via the page fault. Some tools for cracking windows (-> see lesson 9) ----------------- DEBUGGERS CVW and TDW (you have to know the function's segment:offset address beforehand in order to crack a function) WCB [Windows Codeback] by Leslie Pusztai (it's a really cool tool!) WDEB386 Microsoft's WDEB386 (clumsy, and requires a second monitor) Soft-Ice/Windows best (BY FAR!) windows debugger! NuMega is so good I am at times really sorry to crack their products! [WINICE] is the single, absolutely essential debugger and snooping utility for windows crackers. Get it! ----------------- POST MORTEM INSPECTORS CORONER, etc. (a lot of shareware) MS-DrWatson Old and clumsy Borland's Winspector THE BEST! It has the BUILDSYM utility that allows the creation of a debug .SYM file from an .EXE without debug information. ----------------- INSPECTORS MS-Spy Old Borland's WinSight (Best one, select "Other") MicroQuill's Windows DeMystifiers (from Jeff Richter): VOYEUR (hold SHIFT picking Message Selection), COLONEL, MECHANIC and ECOLOGIST ----------------- SNOOPERS [INFSPY.EXE], 231.424 bytes, version 2.05 28/8/1994 by Dean Software Design, may be the more complete one. [SUPERSPY.EXE], 24.576 bytes, 10,6,1994, quite handy for quick informations. [WINVIEW.EXE], 30.832 bytes, Version 3.00 by Scott McCraw, MS(c) 1990-1992, this is the old MS-Spy, distributed by MS [TPWSPY.EXE], 9.472 bytes, quite primitive, but you get the pascal source code with it. -> INSIDE A WINDOWS '95 DEBUGGER You can debug a program at the assembly-language level without any debugging information. The DOS [DEBUG] program does that, allowing breakpoints and single-stepping, all of which implies that the hardware must be cooperating. Back in the time of the 4-MHz Z-80s, you used a debugger that plugged interrupt op codes into the instruction stream to generate breakpoints. Nothing has changed. That's how you debug a program on a 80586 (=Pentium). The x86 architecture includes software interrupts. The 1-byte op code xCC is the INT_03 instruction, reserved for debuggers. You can put the INT_03 op code in place of the program instruction op code where the break is to occur and replace the original op code at the time of the interrupt. In the 80386 and later, you can set a register flag that tells the processor to generate a not-intrusive INT_01 instruction for every machine instruction executed. That device supports single stepping. The Win32SDK (Windows '95 software developer's kit) includes functions that allow one program to launch another program and debug it. The SDK's debug API takes care of how the interrupts and interrupt vectors get managed. The logical consequence of such an approach is that fewer and fewer people will be able to know what's going on inside an application. The bulk of the programmers -in few years time- will not be able any more to reverse engineer an application, unless the few that will still understand assembler-language do offer them the tools to do it. Microsoft -it is evident- would like the programmers to use a "black box" approach to programming, writing nice little "hallo world" application and leaving to the engineers in Microsoft alone the capacity to push forward (and sell) real programs that are not toy application. The Win32 documentation seems vast, almost luxurious, until you begin serious work and you discover its shortcomings, like the fact that extended error codes are not documented, and numerous APIs are documented either incorrectly or so poorly that you must burn precious time testing them. What we definitely need is to find some secret fellows inside Microsoft (like good old Prometeus) that smuggles to the outside the real documentation that the Microsoft engineers have reserved for themselves. If you are reading this and do work for Microsoft, consider the possibility of double-crossing your masters for the sake of humanity and smuggle us the secret information. In windows '95 a debugger program launches a program to be debugged by calling the _CreateProcess function, specifying in an argument that the program is to be debugged. Then the debugger program enters a loop to run the program. At the top of the loop the debugger calls _WaitForDebugEvent. Each time _WaitForDebugEvent returns it sets indicators that tell about the vent that suspended the program being debugged. This is where the debugger traps breakpoints and single-step exceptions. _WaitForDebugEvent fills in an event structure that contains among other things the address that was interrupted end the event that caused the interrupt. The debugger calls _GetThreadContext to get the running context of the debugged program, including the contents of the registers. The debugger can, as the result of cracker interaction, modify these values and the contents of the debugged program's memory. The debugger sets breakpoints by saving the op code at the instruction to be intercepted and putting the INT_03 op code at its place, it's always the same old marmalade. When the breakpoint occurs, the debugger replaces the original op code in the program's instruction memory, and decrements the interrupted program counter in the saved context so that execution resumes at the instruction that was broken. To single-step a program, the debugger sets a bit in the context's flags register that tells the processor to generate an INT_01 for every instruction cycle. When that interrupt occurs, the debugger checks to see if the interrupted address is at a new source-code line number. If not, the debugger continues execution. Otherwise, the debugger displays the new line in the IDE and waits for the cracker to take an action that resumes the program. While the debugged program is suspended, the debugger interacts with the cracker and provides full access to the debugged program's context and memory. This access permits the cracker to examine and modify part of the code. To resume the debugged program, the debugger resets the program's context by calling _SetThreadContext and calls _ContinueDebugEvent. Then, the debugger returns to the top of the loop to call _WaitForDebugEvent again. To extract debug information from a Win32 executable file, you must understand the format of that file (best thing to do, to practice yourself, would be to reverse engineer small programs). The executable file has two sections not found in other executable files: ".stab" and ".stabstr". How nice that they used names that suggest their purpose (nomen est omen). You'll find them inside a table of fixed-length entries that include entries for .text, .bss, .data and .idata. Inside these sections the compilers put different parts of a program. There are several different formats for encoding debug information in an executable file. Borland's Turbo Debugger one format. Microsoft's CodeView another. The gnu-win32 port from Cygnus the stab format, an acronym meaning "symbol table", although the table contains much more than just symbol information. The .stab section in a portable executable file is a table of fixed-length entries that represent debugging information in the stab format. The .stabstr section contains variable-length, null terminated strings into which the .stab table entries point. The documentation for the stab format is available in text format on the Cygnus ftp site (ftp.cygnus.com//pub/gnu-win32). Stabs contain, in a most cryptic format, the names and characteristics of all intrinsic and user-defined types, the memory address of every symbol in external memory and on the stack, the program counter address of every function, the program counter address where every brace-surrounded statement block starts and ends, the memory address of line numbers within source-code files, and anything else that a debugger needs. The format is complex and cryptic because it is intended to support any source-code language. It is the responsibility of a debugger program to translate the stab entries into something meaningful to the debugger in the language being debugged. Windows '95 invokes dozens of INT_21 services from 32-bit code, including KERNEL32.DLL and possess Krn32Mutex, which apparently controls access to certain parts of the kernel. Some of the functions in KERNEL32 can be blocked by the Win16Mutex, even though Microsoft says this isn't the case. SO, I WANNA CRACK, WHAT SHOULD I DO? I'll show you a simple windows crack, so easy it can be done without WINICE: let's take [WINPGP4.1.] (front-end for PGPing in windows, by Geib - I must thank "Q" for the idea to work on this crack). Using WCB you'll find out quickly that the "CONGRATULATIONS your registration number is OK" and the "SORRY, your registration number is not correct" data blocks are at the block starting at 36.38B8 (respectively at 36.38D5 and 36.3937), that relocs to 13.081B. Looking at 13.0000 and following code, you'll find a push 38D5 (68D538) and a push 3937 (683739) at 13.064D and 13.06AE. The road to the crack is now open, you just need to find and "fool" the calling routines. You'll learn the exact procedures for this kind of WINcracks in part 2 and 3 of -> Lesson 8. Let's now have a look at the protection scheme (disassembly from WCB): ... 13.0E88 660FBF46F8 movsx eax, word ptr [bp-08] 13.0E8D 668946F4 mov [bp-0C], eax 13.0E91 668B46F4 mov eax, [bp-0C] 13.0E95 6669C00A000300 imul eax, 0003000A 13.0E9C 668946F0 mov [bp-10], eax 13.0EA0 668B4606 mov eax, [bp+06] 13.0EA4 663B46F0 cmp eax, [bp-10] 13.0EA8 7505 jne 0EAF <- beggar_off 13.0EAA B80100 mov ax, 0001 <- flag 1 = "Right!" 13.0EAD EB04 jmp 0EB3 <- and go on beggar_off: 13.0EAF 33C0 xor ax,ax <- flag 0 = "Nope!" 13.0EB1 EB00 jmp 0EB3 <- and go on I want you to have a good look at this protection scheme. IT'S THE SAME OLD SOUP! You do remember lesson 3 and the protection schemes of the old DOS stupid games of the '80s, don't you? IT'S THE SAME OLD SOUP! In this "up-to-date" "new" windows application, in WINPGP version 4.1 of 1995/1996, exactly the same kind of protection is used to "conceal" the password! A) compare user input with memory echo B) beggar off if not equal with AX=0 C) go on if equal with AX=1... how boring! Besides, look at all the mov eax, and eax, moves preceding the compare! That's a typical pattern for these "number_password" protections! I wrote (years ago) a little crack utility that searches for code blocks with a "66" as first instruction_byte repeating in four or more consecutive instructions and it still allows me to crack more than half of these windows password smuts in less than three seconds flat. The IMUL instruction creates the "magic" number, and if you give a closer look at the mathematical part of the "conceal" routine, it could help you to crack analogous schemes used in order to protect the "Instant access" (c) & (tm) time_crippled software :=) Now you could crack the above code in 101 different ways, the most elegant one would probably substitute je 0EAF (or jZ 0EAF, that's the same) to the jne 0EAF at 13.0EA8. You just write a 74 at the place of the 75, like you did for the cracks in 1978... how boring: it's really the same old soup! (But you'll see some new tricks in the next lessons). 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 526164@anon.penet.fi