Windows also has many similar evasion techniques, like checking if there is a top level exception handler. I use scyllahide, but even on gdb you can break at ptrace and patch it or for automated analysis, just flag anything that used ptrace but isn't a debugger and run it in a sandbox without ptracing it. Audit subsystem might be enough.
The Ptrace Anti-RE Trick
21–30 of 36 posts
Re: The Ptrace Anti-RE Trick
#22Earlier quoted context omitted.
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?
You can just use LD_PRELOAD to load your own version of ptrace. Not as stealthy though.
Re: The Ptrace Anti-RE Trick
#23Thankfully 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.
[deleted]
Re: The Ptrace Anti-RE Trick
#24I'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.
You can just patch the call then, right? I.e. turn it into NOPs
Re: The Ptrace Anti-RE Trick
#25Earlier quoted context omitted.
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?
Another way is to load a eBPF program or kernel module for this purpose.
Re: The Ptrace Anti-RE Trick
#26In 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.
I'm curious what the context is where you can't just set a breakpoint on the logging function.
It's possible there's no single logging function (maybe it's a macro). Or you only want some invocations of the logging function to stop.
Re: The Ptrace Anti-RE Trick
#27Re: The Ptrace Anti-RE Trick
#28If I remember it right, only 1 ptrace can be attached. So this seems easy to fix:. Just ptrace yourself, and nobody else will.
As a bonus, write important state to memory supposed to be read-only. If someone hooked your ptrace, the hook has to reimplement ptrace in a lot more detail. Or use breakpoints as a mechanism to call subroutines.
Re: The Ptrace Anti-RE Trick
#29We 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…
A debugger sees exceptions before the application does, and it knows which exceptions it should handle by itself (e.g. breakpoints set by the user) vs passing them to the application.
I don't have a windows machine rn to verify but I'd expect your assumption that it's impossible to debug an INT3 VEH to be incorrect.
Re: The Ptrace Anti-RE Trick
#30Tricks for windows