I have recently come up with a new anti-debug trick, which can be useful only if the "Break on new thread" option is set. The trick has been tried on OllyDbg v1.10 and Immunity Debugger v1.83 in WOW64 running on Windows 7. Actually, i am not sure if someone else has already found it.

In any affected debugger, if CREATE_THREAD_DEBUG_EVENT is received and the "Break on new thread" option is set, the debugger places an int3 software breakpoint on the lpStartAddress. There is a narrow time window between setting the int3 software breakpoint and recovering the original byte and this is what we are going to exploit.

N.B. The next few lines are only for demonstration. More complicated methods may evolve out of them.

Having two threads in an application, the first thread does almost nothing and the second one checks the first byte of the first thread's entrypoint, we can simply detect the debugger. See the image below.

The demo can be found here. You can also find its source code here.

An XP-compatible demo can be found here. You can find its source code here.

The original topic is here.

Edited January 20, 201213 yr by waliedassar

Yes, there's a race condition where one thread can even remove the breakpoint and cause the thread to run without debugger control.

It's just a variation of the attach problem.

Bypassing this trick is as easy as unchecking the "Break on new thread" option. But you should find another way to check new threads.

Always the debugger detected message shows.

test it.

antidbg.exe

Regards.

sean.