11–20 of 36 posts
We used to place an INT3 vectored exception handler on function entry points and do everything interesting inside the exception handler. This made the execution stack basically invisible to every debugger since it doesn't debug exception handlers. You can enable/disable interrupts and tracing and whatever you need to do inside the exception handler to guarantee that nobody can see what you are doing and/or verify tha…
http://profile.maff1t.com/AntiDebugging/
Interestingly enough, VirtualBox does this too, and they call it "hardening", but IMHO it's quite an unexpected and hostile behaviour which is more characteristic of malware.
In an old $DAY_JOB I used a variant of this as a way to make certain internal errors execute a breakpoint when debugged, and generate an error log if not debugged. iirc this did not happen until after an error had already occurred, so it was not very useful as anti-RE.
We used to place an INT3 vectored exception handler on function entry points and do everything interesting inside the exception handler. This made the execution stack basically invisible to every debugger since it doesn't debug exception handlers. You can enable/disable interrupts and tracing and whatever you need to do inside the exception handler to guarantee that nobody can see what you are doing and/or verify tha…
Do you mean using this trick in malware?
Thankfully this is easy to circumvent: have your debugger catch the ptrace syscall and lie about the result. Also, if antivirus programs haven't already added a signature for any programs that do that, they should.
> Thankfully this is easy to circumvent: have your debugger catch the ptrace syscall and lie about the result. Yeah, Apple iTunes did that IIRC, and it was super easy to bypass.
Earlier quoted context omitted.
> Thankfully this is easy to circumvent: have your debugger catch the ptrace syscall and lie about the result. Yeah, Apple iTunes did that IIRC, and it was super easy to bypass.
On Apple platforms ptrace supports an additional flag "PT_DENY_ATTACH", which is what iTunes uses. It causes the target process to exit.
We used to place an INT3 vectored exception handler on function entry points and do everything interesting inside the exception handler. This made the execution stack basically invisible to every debugger since it doesn't debug exception handlers. You can enable/disable interrupts and tracing and whatever you need to do inside the exception handler to guarantee that nobody can see what you are doing and/or verify tha…
How is the VEH target not immediately visible during static analysis?
It's actually not so easy to find the VEH because if you are injecting the VEH into a third party process from another process, then not only does the VEH not exist during static analysis of the binary at rest, but its program address changes on each execution. Moreover, the VEH can be encrypted at rest before it is injected into the second process.
We used to place an INT3 vectored exception handler on function entry points and do everything interesting inside the exception handler. This made the execution stack basically invisible to every debugger since it doesn't debug exception handlers. You can enable/disable interrupts and tracing and whatever you need to do inside the exception handler to guarantee that nobody can see what you are doing and/or verify tha…
Do you mean using this trick in malware?