The Ptrace Anti-RE Trick
hkopp.github.io
The Ptrace Anti-RE Trick
1–10 of 36 posts
Re: The Ptrace Anti-RE Trick
#2Thankfully 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.
Re: The Ptrace Anti-RE Trick
#3Thankfully 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.
Re: The Ptrace Anti-RE Trick
#4Thankfully 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.
The malware will then rely on actual ptrace behaviour as a check. You could instead use seccomp_unotif and let the target ptrace itself as much as it wants: https://man.archlinux.org/man/seccomp_unotify.2.en
Re: The Ptrace Anti-RE Trick
#5There are also differences in the handling of `SIGTRAP`. For a serious use, this can implement `breakpoint()` function.
Re: The Ptrace Anti-RE Trick
#6We 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 that no other program has registered another exception handler before doing anything interesting.
If you need to hook functions in third party software, this trick can be used to hook the function without modifying any of the functions code. All you need to do is modify some pointer used by the function to zero, and it will raise an exception as soon as something like p-> is executed on that pointer, then your exception handler can execute whatever code you need (i.e. write over stack, write to memory, exfiltrate handles) and on exit all you need to do is restore the correct register containing the pointer and wind back the execution counter by the size of the de-reference instruction.
Please don't use this knowledge to hurt people ...
Re: The Ptrace Anti-RE Trick
#7I've seen this used preemptively - have the process ptrace itself on startup (and then do nothing with it) to make it impossible (or at least far-from-trivial) for other interested parties to ptrace it.
Re: The Ptrace Anti-RE Trick
#8We 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?
Re: The Ptrace Anti-RE Trick
#9Thankfully 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.
The malware will then rely on actual ptrace behaviour as a check. You could instead use seccomp_unotif and let the target ptrace itself as much as it wants: https://man.archlinux.org/man/seccomp_unotify.2.en
I don't know reverse engineering. But, I guess the ultimate solution would be running a custom OS to fake ptrace results in the kernel level?
Re: The Ptrace Anti-RE Trick
#10Thankfully 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.
> have your debugger catch the ptrace syscall
Cat + mouse: Have your program catch any signals/stops (which debuggers do on Linux when they attach I believe)