Anti-Reversing Techniques (Part 2)
In the first part we discussed some common techniques used by malware authors to protect their applications from reverse engineering. In this second part, we will take a look at more methods and techniques used to detect and prevent reverse engineering.
Debugger Detecting:
Code Execution Timing technique:
When using a debugger to analyze an executable sometimes we use a single step execution to go through some assembly instructions, the time of execution will be much longer than normal execution, let’s take this code for an example:
At the beginning of the code we have a call to “GetTickCount” function that return the number of milliseconds that have elapsed since the system was started. The code until the execution of “ShellExecuteW” function will take 30 to 47 milliseconds as I measured on my machine. After that we call “GetTickCount” function again to get the time and then get the difference between the two calls values, and if it’s longer than 70 milliseconds exit process, otherwise print the message.
There is other Windows APIs that can be used for getting time such as:
- GetLocalTime().
- GetSystemTime().
- QueryPerformanceCounter().
Software Breakpoints:
Software breakpoints are a common anti-debugging technique used by malicious actors to make it more difficult to reverse engineer their malwares. This technique involves inserting a specific code instruction, known as a breakpoint, into the program at a specific location. When the program is executed, the breakpoint will cause the program to stop running, making it difficult for a debugger to analyze the program’s behavior.
One way to implement a breakpoint using assembly language is to use the int 3 instruction. This instruction is a software interrupt that causes the program to stop running and transfer control to the debugger. Here is an example of how to use the int 3 instruction in C++:
Hardware Breakpoints:
Hardware breakpoints are a type of anti-debugging technique that uses specialized hardware features of the CPU to detect and prevent debugging of a program. This technique involves setting a breakpoint on a specific memory address or register, and then instructing the CPU to trigger an interrupt whenever the program accesses or modifies the specified address or register.
Below is an example of how to check if a hardware breakpoint is set:
A non-zero value in any of the debug registers could suggest that the process is being run under a debugger with a hardware breakpoint set.
Self-Debugging:
Is a technique used by malware authors to prevent a debugger from attaching to the process or checking if the process is under a debugger. It involves using a debugger to debug the program itself, in order to detect and prevent other debuggers from attaching to the program.
Below is an example of an instance that creates a second instance of the process and create a named event with the name “debugger_present”. The second instance of the process, will try to attach a debugger to the parent process and if it fails, it will set the event which will indicates to the parent process that another debugger is attached to it:
UnhandledExceptionFilter()
If a program encounters an exception that is not handled by any registered exception handlers, the kernel32!UnhandledExceptionFilter() function will be called. It is possible to register a custom unhandled exception filter using the kernel32!SetUnhandledExceptionFilter(). However, if the program is being debugged, the custom filter will not be called and the exception will be passed to the debugger instead. Therefore, if the control is passed to the unhandled exception filter, it can be inferred that the program is not running under a debugger:
thank you for taking the time to read this until next time.
