Guide to Anti-Debugging - Overview , Techniques and Approaches
I have been nagged a lot regarding guest posts, and almost 90% of them are related to some news, social media bullshit and half baked security crescendo. Until recently, I was contacted by amiable folks at Infosec Institute with a good article on Anti Debugging. This is an article by Dejan Lukan, a security researcher at Infosec Institute, in which he discusses the Anti Debugging techniques in an objective and direct manner. I loved the implementation part, reminded me of my rev days (you can learn about how to reverse Winrar or just have a look at a real noobs guide to reverse some more stuff) , and more importantly Dejan explains how to stop (read : slow down) people from reversing your code. Hope you will enjoy it.Before we begin, we must mention that it’s impossible to completely prevent reversing. What is possible is that we can place as many obstacles on the way as we want to make the process slow enough that reverse engineers will give up. Actually there are hardware implementations where you can buy a black box that attaches to your computer which can do the encryption/decryption for you, but this is far from being used in everyday life.
Techniques to Harden Reverse Engineering
The most basic approaches to harden the reverse engineering of programs are the following [1]:
- Eliminating Symbolic Information
- Obfuscating the Program
- Embedding Antidebugger Code
This can easily be done in C/C++ programs where we only have to append a few compiler flags to the command line that actually compiles the program into the executable. It’s much harder with programming languages like Java and .NET, where those symbols are used internally to reference variables, functions, etc. This is also the reason why Java and .NET programs can easily be converted into a pretty good source code of the original program. We can still strip the symbols from such programs by renaming all the symbols from their meaningful names into meaningless representations, which effectively does the job.
Besides stripping the executable symbols, we can also obfuscate the program. When obfuscating a program, we’re basically changing the code of the program without actually changing the logic behind it, so the program does the same as before but its code is far less readable. Here we have two techniques that can achieve that:
- Encoding: With encoding, we must add the decoding instructions that decode the whole program before it’s being run. This can be done by appending the decoding instruction at the end of the program and changing the entry point to point to the decoding instructions. When the program is run, the decoding instructions are executed first, which decodes the whole program into its original form. After that, we must jump to the start of the program and actually run the original instructions as if the encoding didn’t even happen.
- Packing: When packing the executable, we’re basically reducing the size of the executable as well as encrypting it. When such a program is run, it must first be decoded in memory and then run.
- By obfuscating the program with nonstandard encoders/packers, we can greatly complicate the task of reverse engineering the executable, but at the end, a persistent reverse engineer will nevertheless be able to bypass that and get the non-obfuscated version of the executable, which can easily be reversed.
Last but not least, we can use an antidebugger code, where we can include a code into the executable that can detect if the program is currently being debugged. If that happens, the program terminates itself prematurely without actually executing the functions that would normally be executed if it wasn’t running under a debugger.
Antidebugging
Before discussing how anti-debugging tricks do their magic, we must first talk about how the debugger is able to debug the program. We know that we can stop and resume the program with the use of either software or hardware breakpoints.
When using software breakpoints, we’re replacing the instruction on which we’ve set the breakpoint with the INT 3 instruction (at least on the x86 architecture), which is a special software interrupt. In this case, we’re passing the value 3 to the instruction INT, which means that we’re generating the software interrupt 3. This causes the function pointed to by the 3rd vector in the interrupt address table (IAT) to be executed. I guess we’re all familiar with the INT 80 interrupt that makes a system call on Linux systems.
The INT 3 instruction temporarily replaces the current instruction in a running program. This is also a way for the debugger to know that a software breakpoint has occurred and the program execution should be stopped. After that, the debugger replaces the INT 3 instruction with the original instruction so the program can continue without the loss of instructions, which can otherwise cause abnormal program behavior.
When we use a hardware breakpoint, it’s the processor’s job to know when the breakpoint has been hit and the program has to be stopped. This is why the program is not modified when a hardware breakpoint is set.
When the breakpoint is hit, the program is stopped and we can safely execute instructions in our favorite debugger. At that point, we can run instructions step-by-step by entering into functions, or by executing them the same time. If we’re interested in what the function does, we need to enter into the function; otherwise we can safely ignore the function and step over it. When stepping through the code, each instruction is executed on its own and then the program is again stopped, so we’re able to analyze what the instruction has just done.
When stepping through the code with a debugger, the Trap Flag (TF) in the EFLAGS register is used. When the TF is enabled, an interrupt will be generated after every executed instruction, so we get the feeling of stepping though the program instruction by instruction.
IsDebuggerPresent
The IsDebuggerPresent is a Windows API function, which we can see on the picture below:
The function doesn’t take any arguments and returns a Boolean value notifying us whether the program is running under a debugger or not. This function can be used to trivially detect whether a debugger is being used to run the program. The function uses the Process Environment Block (PEB) to get information about whether the user-mode debugger is used.
Let’s create a simple program that prints the number 0 or 1 if the debugger is present or not. We can do that by first creating an empty console project under Visual Studio C++ and then changing the code of the main cpp file into the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | // isdebuggerpresent.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include #include int _tmain(int argc, _TCHAR* argv[]) { int num; if(IsDebuggerPresent()) { num = 0; } else { num = 1; } printf("Number: %d\n", num); /* wait */ getchar(); return 0; } |
The program prints “Number: 0″ if the debugger is present and “Number: 1″ if the debugger is not. If we run the application under Visual Studio, the program will display the number 0 because it’s being run under a debugger. This can be seen on the picture below:
Let’s also run the program under OllyDbg to be sure that the number 0 is displayed. This can be quickly confirmed by loading the executable program and running it. On the picture below, we can see that the number 0 was printed when the program was run under OllyDbg debugger:
But if we run the same program under normal cmd.exe, it will display the number 1. This can be seen on the picture below:
We can see that the IsDebuggerPresent API function call works as expected, but that the function call is easy to detect and bypass. This is because we can quickly find this function call in the executable and delete it or bypass it. To do this, we can simply open the executable in Ida debugger and check out the Imports table to verify if that function exists somewhere in there. We’re right, the function IsDebuggerPresent is listed among all the imported functions as we can see on the picture below:
This is a clear indication that the executable is using the function to do something different when the debugger is attached to the executable. We can also locate the exact instructions that are used to call that function. The whole Ida graph of the main function that does exactly the same as the main function from the C++ source code above is presented on the picture below:
We can see that, at first, we’re initializing the stack for the function and calling the IsDebuggerPresent function. After that, we’re testing the returned value in eax against itself to determine whether a true or false value was returned. If the eax holds a value different than 0 (1 in our case), then the zero flag will be set and the first box that sets the [ebp+num] to 0 is called. This is exactly what happens now, because we’re running the program under a debugger, but otherwise the block that sets the [ebp+num] to 1 is called. After that, we’re just moving the value of [ebp+num] into the register eax and printing it with the printf function.
If we now set the breakpoint on the call to the IsDebuggerPresent function and rerun the program, the execution will be stopped right where we want it. After the breakpoint has been hit, we can step into the function to see what the function actually does. On the picture below, we can see the function in question:
We can see that the function is pretty simple: we’re loading the address of the currently active thread (TIB) in the register eax and then accessing the structure member that’s located at the 0×30 offset; the PEB data structures lies at that offset. After that, we’re loading the address of PEB in eax and then accessing its data member at 0×2 offset, which holds the data member named BeingDebugged. Thus, we’ve successfully taken a look at what the IsDebuggerPresent function actually does and how it does it. We can see that it’s very simple and not really hard to bypass.
We can determine that IsDebuggerPresent is being used when we try to reverse engineer an executable and the program terminates prematurely, a different execution path is taken, or something else unexpected happens. In such cases, we must first check the Imports table if the IsDebuggerPresent function is being called anywhere in the executable. If that is the case, we can simply delete the instructions that call the IsDebuggerPresent function call, so it won’t bother us when reversing the executable.
On the other hand, if we’re developing a program and we would like to use the IsDebuggerPresent function call, we can copy the above instructions directly into our code, so that we’re not actually calling the IsDebuggerPresent function directly, but using its function body instructions to figure out whether the debugger is being used to run the executable. This is just another trick so that reverse engineers won’t immediately notice the use of IsDebuggerPresent function call and will make the debugging slightly more complicated.
Conclusion
For a deeper understanding of reverse engineering, check out the reverse engineeringtraining course offered by the InfoSec Institute. In this article we’ve seen a few techniques to harden the reverse engineering process. The technique easiest to bypass is symbol elimination where we have to delete all the symbols presented in the executable. This effectively makes the names of the functions unavailable when debugging, which leaves it up to the debugger to properly name the functions. Another technique is program obfuscation, which can be a pretty simple operation like xoring the whole executable then running it, but it can also be pretty complicated. Things get further complicated if we’re using obfuscation with the anti-reversing techniques, which detects if the program is being reversed and terminates the program prematurely if so, greatly hardening the reverse engineering of the executable.
References:
[1]: Reversing: Secrets of Reverse Engineering, Eldad Eilam.
~
samedi 4 mai 2013
0
commentaires
Articles
