Walied (waleedassar) <waliedassar gmail com> |
Tuesday, January 31 2012 05:33.39 CST |
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, 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.
http://ollytlscatch.googlecode.com/files/demo.exe
You can also find its source code here.
https://docs.google.com/document/d/1kd-Fw110lbK9h-i6Jc2fs57LUjdU2sYji97XCLTTawE/edit
An XP-compatible demo can be found here.
http://ollytlscatch.googlecode.com/files/demo_xp.exe
You can find its source code here.
https://docs.google.com/document/d/1G-6VSCrqM9KI_t82kPTGdo05cmaqyoVZG23o304Pk_o/edit
|
This is a portion of an already known imperfection with olly v1 (and thus also with immunity)... Olly used software interrupt 03 for all of its internal breakpoints, so actually a lot of other similar tricks could be used (like scanning your code for int3's in general) in olly v2 there's a new (and very logical) option - to default to hardware breakpoints instead of software ones, which became rather obsolete... |
|
Cautious reverse engineers won't be affected by 0xCC scanning, as they carefully set and delete software breakpoints. But they may be affected, if they don't know the fact that OllyDbg pauses on new threads with software breakpoints. |
Cautious reverses will user HW breakpoints, or combination of software + memory BPs... i believe these are better precautions.
however, notice I wasn't talking about users` breakpoints but all the BPs olly uses itself.
I've actually reminded that there are more BPs olly places other than on thread creation, all of which might be detected with your method.
I've also mentioned that Olly v2 does what most of us do manually for years - use HW BPs.
anyway I've seen the technique you've found used in the wild, where the protector would load DLLs and create threads only to check if they were BPed.
So i guess i can verify someone else had found it, but not sure if it was ever documented anywhere. |
|
It would be great if you make a plugin or patches for the bugs you found for Ollydbg 1.10. |
|
Soon, i will release a plugin to address these issues. |
|