More GDB Anti-Debugging

A couple of months ago, the almighty Silvio had found an interesting behavior on GDB. As he said at his post, this could be used to detect GDB. When a process uses fork(2) to spawn a child process, the parent’s file descriptors are inherited to the new child process. In normal cases, the new process should have only FDs 0 (stdin), 1 (stdout) and 2 (stderr). However, GDB opens up some more FDs (3, 4 and 5) and never closes them, so they are inherited. You can use this bug to detect the debugger simply by having a function similar to this in your code:

Similarly to the previous method for anti-debugging, the detection code is inserted in .CTORS section of the ELF in order to make it more stealth. Of course this limits the target operating systems to just the ones that support ELF, but since this issue only affects GDB I think it is fine. At last, here is at runtime:

Another funny thing that I came across during the above test is that FD 5 of GDB is a symbolic link to the executable that is ptrace(2)‘ing. You can use this to retrieve a copy of the original binary. Assume you have this simple application:

Related

2 Responses

“A couple of months ago, the almighty Silvio had found an interesting behavior on GDB. As he said at his post, this could be used to detect GDB. When a process uses fork(2) to spawn a child process, the parent’s file descriptors are inherited to the new child process.”

mm.. as I posted in silvio’s blog, this is not true.. this was first published in 2005 (http://www.reversing.org/node/view/5) and used as antidebug technics in several crackmes, including one in the NoConName sec conf.

In any case it’s funny to have same conclusion within a year gap for several people :)