Defeating the Debugger by Giovanni Tropeano

Let me start by saying this - 
 
Quote:
you cannot and will not ever write a program that is not crackable

. But that's not to say you can't make it extremely difficult! 

That being said, let's begin. In this document, we are going to learn some anti-debugging tricks that you can incorporate in your own applications. 

In my first article for Osix I discussed Self Modifying Code, and attempting to throw off disassemblers. Now we'll talk about defeating (or at least discouraging) the debuggers. 

Brief history of debuggers
Once upon a time there was Debug.com, and it was the first Windows debugger. It was part of the regular MS-DOS package, and today it's pretty much useless except for those studying assembly. The first debuggers that were even slightly applicable for cracking appeared with the 80286 processor. No real damage could be accomplished with them, however. Then the situation changed with the 80386. Major complication is software (Windows?) demanded better debuggers. It was at this time that debuggers became a real threat to programmers, as they became much more powerful. Softice emerged on the scene in the end of the 80's and gave protected programs and their developer a lot of trouble. Since then, Softice is hands-down the hackers debugger of choice, although more and more lately Olly is gaining popularity among the younger crackers. 

In view of the current possibilities for analyzing applications, struggling against hackers is a useless occupation. However, another serious threat comes from yesterday's beginners, who have read a lot of different "how-to-crack-programs" FAQs. (Thank goodness they are accessible to everyone.) These beginners now are looking for something on which to test their powerful capabilities. We'll try to throw off these beginners looking for a new challenge. 



How debuggers work
Struggling against a debugger without knowing how it works would be useless. It's important you understand exactly how the debugger works. 

All debuggers can be categorized in one of two categories: 


ones that use the processor's debugging capabilities 


and ones that emulate the processor independently, monitoring the execution of the program being tested 



So far to date, there are no high-quality emulating debuggers that cannot be detected or bypassed by the code. And it's not likely we'll see on anytime soon either. 

And is it even worth developing such an emulator when we can already step through code, control execution of an instruction at a given address, monitor references to a given memory location (or to input-output ports), signal task switching, and so on? I don't think so. Anyways, moving on... 

Okay, I am going to get a little deep here so try to follow me. 

Debuggers will check to see if the trap bit ofthe flags register is set. If so, an INT 1 debug exception is generated automatically after each instruction and control is passed to the debugger. From here, your code could detect tracing (debugging) by analysing the flags register. So in order for debuggers to stay invisible, it needs to recognize the instructions for reading the flags register, emulate their execution, and return zero for the value of the trap flag. Much easier said than done, huh? 

There are four debug registers: 

1. DR0 
2. DR1 
3. DR2 
4. DR3 

And they store the linear addresses of four checkpoints. Of course there is a register that contains a condition for each of these points, and that register is DR7. When any of the conditions are TRUE, the processor throws an INT 1 exception and control is passed to the debugger. There are four conditions: 

1. An instruction is executed 
2. The contents of a memory location are modified 
3. A memory location is read or updated, but not executed 
4. an input-output port is referenced 

Now let's talk about software breakpoints. A software breakpoint is the only thing that cannot be hidden without writing a full-scale processor emulator. If you place this one byte of code -- 0xCC at the beginning of an instruction, it will cause an INT 0x3 exception when an attempt is made to execute it. To discover whether at least one point has been set, it is enough for the program being debugged to count its checksum. To do this, it may use MOV, MOVS, LODS, POP, CMP, CMPS, or any other instructions; no debugger is capable of tracing and emulating any of them (as far as I know!). 



Tracing, and how to overcome
Since the possibility of a completely invisible debugger is only a possibility, most can be detected. 

Most debuggers use the 0xCC one byte(r). 

Let's take a look at a simple protection scheme: 

Listing 1. A Simple Protection Mechanism in C++ 

int main(int argc, char* argv[]) 
{ 
// The ciphered string "Hello, Free World!" 
char s0[]="/x0C/x21/x28/x28/x2B/x68/x64/x02/x36/ 
/x21/x21/x64/x13/x2B/x36/x28/x20/x65/x49/x4E"; 
__asm 
{ 
BeginCode: ; The beginning of the code 
                                  ; being debugged 

        pusha ; All general-purpose 
                                  ; registers are saved. 
        lea ebx, s0 ; ebx=&s0[0] 
GetNextChar: ; do 
         xor eax, eax ; eax = 0; 
         lea esi, BeginCode ; esi = &BeginCode 
         le ecx, EndCode ; The length of code 
         sub ecx, esi ; being debugged is computed. 
         HarvestCRC: ; do 
         lodsb ; The next byte is loaded into al. 
         Add eax, eax ; The checksum is computed. 
         loop HarvestCRC ; until(--cx>0) 
         xor [ebx], ah ; The next character is decrypted. 
         Inc ebx ; A pointer to the next character 
         cmp [ebx], 0 ; Until the end of the string 
         jnz GetNextChar ; Continue decryption 
         popa ; All registers are restored. 
EndCode: ; The end of the code being debugged 
         nop ; A breakpoint is safe here. 
} 
printf(I s0); ; The string is diplayed. 
return 0; 
} 



Let's examine this code closely (read the comments). After starting the program, the words Hello, Free World! should appear on the screen. But when the program is run under the debugger, even with at least one breakpoint set within the limits of BeginCode and EndCode, senseless garbage like "Jgnnm."Dpgg"Umpnf#0" will show up on the screen! Kick ass, huh?!? Now we are getting somewhere. You can even strengthen this protection by putting the procedure that calculates the checksum in a different thread. 

Speacking of threads, they demand a special approach on things. It's kinda hard for us humans to realize that a program can run in several places simutaneously. And commonly used debuggers have a weak point: They debug each thread separately, never simultaneously. The following example shows how this can be used for protection. 

Listing 2. The Weakness of Debugging Threads Separately 

// This function will be executing in a separate thread. 
// Its purpose is to alter imperceptibly the case of the characters 
// in the string that contains the user name. 
void My(void *arg) 
{ 
      int p=1; 
      // This is a pointer to the byte being encrypted. 
      // Note that encryption is not carried out 
      // from the first byte, since this allows the breakpoint 
      // set at the beginning of the buffer to be bypassed. 
      // If the line feed is not encountered, execute. 
      while ( ((char *) arg) [p] !='/n') 
      { 
            // If the next character is not initialized, wait. 
            while( ((char *) arg) [p]<0x20 ); 

            // The fifth bit is inverted. 
            // This toggles the case of the Latin characters. 
            ((char *) arg) [p] ^=0x20; 

            // A pointer to the next byte being processed 
            p++; 
      } 
} 

int main(int argc, char* argv[]) 
{ 
      char name[100]; 
      // A buffer containing the user name 

      char buff[100]; 
      // A buffer containing the password 

      // The buffer of the user name is stuffed with zeroes. 
      // (Some compilers do this, but not all.) 
      memset (&name[0], 0, 100); 

      // The My routine is executed in a separate thread. 
      _beginthread(&My, NULL, (void *) &name[0]); 

      // The user name is requested. 
      printf("Enter name:"); fgets(&name[0], 66, stdin); 

      // The password is requested. 
      // Note: While the user enters the password, the second 
      // thread has enough time to alter the case of all 
      // characters of the user name. This is not evident 
      // and does not follow from the analysis of the program, 
      // especially if it is studied under a debugger that poorly 
      // shows the mutual influence of the program's components. 
      printf("Enter password:"); fgets(&buff[0], 66, stdin); 

      // The user name and the password are compared 
      // with the reference values. 
      if (! (strcmp(&buff[0], "password/n") 
      // Note: Since the name entered by the user has been 
      // transformed to strcmp(&name[0], "Osix/n"), 
      // not strcmp(&name[0], "OSIX/n"), it is compared. 
      // (This is not apparent at first glance.) 

      || strcmp(&name[0], "OSIX/n"))) 
      // The correct name and password 
      printf("USER OK/n"); 
             else 
      // Error: Wrong user name or password 
      printf("Wrong user or password!/n"); 

      return 0; 
} 



Take a look at the listing. What's interesting is that initially the program expects to receive OSIX:password. BUT the true answer is, Osix:password. Let's examine this a bit. After the user enters the username, the second thread processes the buffer that contains the username and toggles the case (except the first char). So you see, when one thread is traced, all the other thread are functioning independently.And these other threads may intervene randomly in the functioning of the thread being debugged (for example, to modify its code). Ah....now this is beginning to have some possibilities! 

Now there's something to consider. We know the threads can be controlled, but if the protection developer places more than four breakpoints, the debug registers become unreliable, and we're forced to use the 0xCC byte, which we already know from reading above can be easily detected. 

This situation is made even worse by the debuggers, including the famous Softice, when dealing with programs with structural exception handling (SEH). The instruction that causes the exception being processed either "defeats" the debugger, releasing itself from the debugger's control, or passes control to the library exception filter, which only passes control to the application's handler after it calls several service functions that may "drown" the cracker. 

But, when compared to early SoftIce versions, this is progress. Before, SoftIce strictly held certain interrupts. For example, it would not allow the program to process independently division by zero. 

Let's have a look at some more code, huh? If the following example is run under any SoftIce version through 4.05, the debugger, having reached the int c=c/ (a-b) line, suddenly will abort execution, losing the control over this application. You could correct this situation though, by presetting the breakpoint on the first instruction of the block __except. Then, the question is how to find the location of this block without looking in the source code, which the hacker would not have. 

Listing 3. An Example That Employs Structural Exception Handling 

int main(int argc, char* argv[]) 
{ 

// A protected block 
__try{ 
         int a=1; 
         int b=1; 
         int c=c/ (a-b); 
         // This is an attempt to divide by zero. 
         // Several statements are used because most compilers 
         // return an error after encountering a statement like 
         // int a=a/0; 
         // When SoftIce executes the following instruction, it loses 
         // control over the program being debugged. It "falls off" to 
         // code that never gains control but may be misleading. 
         // If the a and b variables are assigned values 
         // returned by some functions, not immediate values, 
         // their equality will not be obvious when 
         // the program is disassembled. As a result, the hacker 
         // may waste time analyzing useless code, hee hee ha! 
} 

__except(EXCEPTION_EXECUTE_HANDLER) 
{ 
         // This code will gain control when the exception "division by 
         // zero" arises, but SoftIce will not recognize this 
         // situation. Instead, it will ask that a breakpoint be 
         // set manually on the first instruction of the block __except. 
         // To determine an address of the block __except, the hacker 
         // will have to figure out exactly how SEH support is 
         // implemented in a particular compiler. 
} 
} 



In order for crackers to deal with such a protection as this, they will have to study in depth how structural exceptions are processed, both at the operating system level and at the level of a particular compiler. Too much work for the casual cracker, wouldn't ya say? 

Since SEH is implemented differently in each compiler, it is not surprising that SoftIce refuses to support it. Good for us programmers! Bad for crackers. 

Therefore, the previous example is highly resistant to breaking and, at the same time, is easy to implement. It works equally well under all operating systems of the Windows family, starting from Windows 95. 



Getting Around Breakpoints
Breakpoints that are set on system functions are powerful weapons in the hands of crackers. Suppose that protection tries to open a key file. Under Windows, the only documented way of doing this is to call the CreateFile function (actually, CreateFileA or CreateFileW for the ASCII or UNICODE name of the file, respectively). All other functions inherited from early Windows versions, such as OpenFile, serve as wrappers to CreateFile. 

Knowing this, the hacker may set a breakpoint on the starting address of the beginning of this function (which is known to the hacker), and instantly locate the protection code by calling this function. 

However, not all hackers know that the file can be opened in other ways: by calling the ZwCreateFile (or NtCreateFile) function exported by NTDLL.DLL, or by addressing the kernel directly via a call to the INT 0x2Eh interrupt. This is true not only for CreateFile, but for all functions of the kernel. Interestingly, no privileges are needed for this. Such a call can even originate from an application code. 

This little trick won't stop the devoted cracker for long. Damn. But it is worth placing this little time bomb in there (the call of INT 0x2E in the __try block ). 

Now, what can be done with functions of the USER and GDI modules (for example, GetWindowsText) that are used to read the user-entered key information (as a rule, a serial number or a password)? Since we know that all these functions begin with the PUSH EBP/MOV EBP, ESP instructions, this can be executed independently by the application code: Control can be passed not to the beginning of the function, but to three bytes lower (Since PUSH EBP modifies the stack, control must be transferred using JMP instead of CALL.) The breakpoint set at the beginning of the function will not produce any effect. Such a trick may temporarily lead even a skilled hacker astray. 

Breakpoints can be divided into two categories: breakpoints built into the program by the developer and dynamic breakpoints set by the debugger itself. The first category is clear: To stop the program and pass control to the debugger at a certain place, it is necessary to write __asm{int 0x3}. 

It is more complex to set a breakpoint in an arbitrary place of the program. The debugger should save the current value of the memory location at the specified address, then write the code 0xCC there. Before exiting the debug interrupt, the debugger should return everything to its former place, and should modify IP saved in the stack so that it points to the beginning of the restored instruction. (Otherwise, it points to its middle.) 

What are the drawbacks of the breakpoint mechanism of the 8086 processor? The most unpleasant is that the debugger must modify code directly when it sets the breakpoints. 

SoftIce implicitly places the breakpoint at the beginning of each next instruction when it traces the program using Step Over (the <F10> key). This distorts the chesksum used by protection. 

The simplest solution to this problem is instruction-by-instruction tracing. Of course, this is a joke; it is necessary to set a hardware breakpoint. In a similar situation, our ancestors (the hackers of the 1980s) usually decrypted the program manually and replaced the decrypting procedure with the NOP instructions. As a result, debugging the program did not present a problem (if there were no other traps in protection). Before IDA appeared, the decrypting procedure had to be written in C (Pascal, BASIC) as an independent program. Now this task is easier, since decrypting has become possible in the disassembler itself. 

Decrypting is reduced to the reproduction of the decrypting procedure in the IDA-C language. In this case, the checksum from BeginCode to EndCode must be calculated, taking into account the sum of the bytes and using the lower byte of the checksum to load the following character. The obtained value is used to process the s0 string using the exclusive OR operation. All this can be done using the following script (assuming that the appropriate labels are already in the disassembled code): 

Listing 239. Reproducing the Decrypting Mechanism in IDA-C 


auto a; auto p; auto crc; auto ch; 
for (p=LocByName("s0"); Byte(p) !=0; p++) 
{ 
      crc = 0; 

      for(a=LocByName("BeginCode"); a<(LocByName("EndCode")); a++) 
      { 
            ch = Byte(a); 
            // Since IDA does not support the byte and word types 
            // (which is a pity), it is necessary to engage in bit 
            // operations. The lower byte, CRC, is cleared, 
            // and then the value of CH is copied to it. 

            crc = crc & 0xFFFFFF00; 
            crc = crc | ch; 
            crc=crc+crc; 
      } 
      // The high-order byte is taken from CRC. 
      crc = crc & 0xFFFF; 
      crc = crc / 0x100; 

      // The next byte of the string is decrypted. 
      PatchByte(p, Byte(p) ^ crc); 
} 





If IDA is not available, HIEW can be used to carry out this operation as follows: 

   NoTrace.exe ?W PE 00001040 a32 <Editor> 28672 ? Hiew 6.04 (c)SEN 
00401003: 83EC18 sub esp, 018 ;"$" 
00401006: 53 push ebx 
00401007: 56 push esi 
00401008: 57 push edi 
00401009: B905000000 000005 
0040100E: BE30604000 [Byte/Forward ] 406030 ;" @'0" 
00401013: 8D7DE8 1>mov bl, al | AX=0061 p][-0018] 
00401016: F3A5 2 add ebx, ebx | BX=44C2 
00401018: A4 3 | CX=0000 
run from here: 4 | DX=0000 
00401019: 6660 5 | SI=0000 [0FFFFFFE8] 
0040101B: 8D9DE8FFFF 6 | DI=0000 
00401021: 33C0 
.0040101B: 8D9DE8FFFFFF 
.00401021: 33C0 xor eax, eax 
.00401023: 8D3519104000 lea esi, [000401019]; < BeginCode 
.00401029: 8D0D40104000 lea ecx, [000401040]; < EndCode 
.0040102F: 2BCE sub ecx, esi 
.00401031: AC lodsb 
00401032: 03C0 add eax, eax 
00401034: E2FB loop 000001031 
00401036: 3023 xor [ebx], ah 
00401038: 43 inc ebx 
00401039: 803B00 cmp b, [ebx], 000 ;" " 
0040103C: 75E3 jne 000001021 
0040103E: 6661 popa 
to here: 
00401040: 90 nop 
00401041: 8D45E8 lea eax, [ebp][-0018] 
00401044: 50 push eax 
00401045: E80C000000 call 000001056 
0040104A: 83C404 add esp, 004 
1Help 2Size 3Direct 4Clear 5ClrReg 6 7Exit 8 9Store 10Load 



At the first stage, the checksum is computed. The file is loaded in HIEW, and the necessary fragment is found. Then, the <Enter> key is pressed twice to toggle in the assembler mode, the <F8>+<F5> key combination is pressed to jump to the entry point, and the main procedure in the start code is found. Next, the <F3> key is pressed to enable editing the file. The editor of the decryptor is called using the <Ctrl>+<F7> key combination. (This combination varies from one version to another.) Finally, the following code is entered: 


mov bl, al 
add ebx, ebx 



Another register can be used instead of EBX, apart from for EAX, since HIEW clears EAX as it reads out the next byte. Now, the cursor is brought to the 0x401019 line and the <F7> key is pressed to run the decrypt up to, but not including, the 0x401040 line. If all is done correctly, the high-order byte BX should contain the value 0x44, precisely the checksum. 

In the second stage, the encrypted line is found (its offset, .406030, is loaded into ESI), and "xor-ed" by 0x44. (The <F3> key is pressed to toggle the editing mode, the <Ctrl>+<F8> key combination is used to specify the key for encrypting, 0x44, then the <F8> key is pressed to conduct the decryptor along the line.) 


  NoTrace.exe ?W PE 00006040 <Editor> 28672 ? Hiew 6.04 (c)SEN 
00006030: 48 65 6C 6C-6F 2C 20 46-72 65 65 20-57 6F 72 6C Hello, Free World 
00006040: 20 65 49 4E-00 00 00 00-7A 1B 40 00-01 00 00 00 eIN z$@ $ 



All that is left is to patch XOR in the 0x401036 line with the NOP instructions; otherwise, when the program is started, XOR will spoil the decrypted code (by encrypting it again), and the program will not work. 

After the protection is removed, the program can be debugged without serious consequences for as long as necessary. 

Well, that's it for now. Another long, but hopefully interesting article on assembly and debugging.