Stay Ahead With Linux Security Features

security researchmalware analysislinux techniques

Advanced Anti-Debugging Techniques: Detecting Breakpoints in Linux

In the previous part of our Hacker's Corner series, we covered anti-debugging using a trivial self-modifying code. Here, instead of blocking debugging completely, we will detect various debugger-induced activities.. Breakpoints A breakpoint is intentional "pause" in normal execution of a program, generally used to inspect the internals of said process in more detail. This is the *most* used feature of any debugger. On x86 CPUs, there are two types of breakpoints: hardware breakpoints and software breakpoints. While they overlap to a certain degree they are not exactly the same. In most of debugging cases, you will be using software breakpoints, which do not need any special hardware support. These are implemented using same interrupt mechanism which is used by pretty much everything else. On x86, 3rd interrupt is used to implement a breakpoint. When you set a breakpoint, your debugger overwrites target address (where you want to put the breakpoint) with INT 3 (0xCC in hex). When this instruction gets executed, debugger gets the control back from target process, and can inspect its state (registers, memory etc). To resume the execution, debugger will silently remove breakpoint, execute the instruction, and set the breakpoint again before letting the process resume (until it terminates, or breaks). Features like step over, step out are also implemented using "transparent" software breakpoints, which are set and removed automatically by debugger. Generally, you can set any number of software breakpoints; however these cannot be set on non-code address (i.e. these can break the program only when target address content is executed; but not if the address is read from or write to). Hardware breakpoints, on the other hand, are much more powerful and flexible than software breakpoints. These can be set to break not only on execution, but also on memory access (read and write both), I/O port access etc. These debuggers are set by writing into special "debug registers" which are largelyplatform specific (and not all platforms will have support for hardware breakpoints). On x86, registers DR0-3 and DR6-7 are used to set these breakpoints (DR4-5 are reserved as of now). If you have ever used "watchpoints" which let you break when certain memory address is accessed, you have used hardware breakpoints. Here, one can try looking this inside a debugger, and then claim that this is not how software breakpoints work: (gdb) break main Breakpoint 1 at 0x116d (gdb) disassemble main Dump of assembler code for function main: 0x0000000000001169 : push rbp 0x000000000000116a : mov rbp,rsp 0x000000000000116d : lea rsi,[rip+0xe91] # 0x2005 0x0000000000001174 : lea rdi,[rip+0x2f05] # 0x4080 0x000000000000117b : call 0x1040 0x0000000000001180 : mov rdx,rax 0x0000000000001183 : mov rax,QWORD PTR [rip+0x2e46] # 0x3fd0 0x000000000000118a : mov rsi,rax 0x000000000000118d : mov rdi,rdx 0x0000000000001190 : call 0x1050 0x0000000000001195 : mov eax,0x0 0x000000000000119a : pop rbp 0x000000000000119b : ret End of assembler dump. (gdb) Here, we cannot see any interrupt instruction; not because there is none; but because our debugger is lying here. It will show you disassembly as it looked before setting any breakpoints so that it matches with what compiler generated from source. Detecting Software Breakpoint Since we know that software breakpoints are set by overwriting 0xCC at first byte of instruction, we can easily check for such breakpoints in our code: - Find where our target function (or any chunk of code) is located in memory - Read 1 byte from address - If byte is 0xCC, a breakpoint has been set A trivial implementation looks something like this: #include bool isBreakpointPresent(unsigned char *func) { bool result = *func == 0xCC; return result; } void secret() { for (int i = 0; i <10; ++i) { std::cout

Jul 18, 2022 • Brittany Day