waliedassar Posted January 20, 2012 Posted January 20, 2012 (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. 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, 2012 by waliedassar 2
Peter Ferrie Posted January 23, 2012 Posted January 23, 2012 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.
waliedassar Posted January 24, 2012 Author Posted January 24, 2012 Bypassing this trick is as easy as unchecking the "Break on new thread" option. But you should find another way to check new threads.
Sean the hard worker Posted April 8 Posted April 8 Always the debugger detected message shows. test it. antidbg.exe Regards. sean. 1
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now