Jump to content
Tuts 4 You

Recommended Posts

Posted (edited)

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.

1.jpg

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 by waliedassar
  • Like 2
Posted

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.

Posted

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

  • 12 years later...
Sean the hard worker
Posted

Always the debugger detected message shows.

test it.

antidbg.exe

Regards.

sean.

  • Like 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...