5 ms·
The Ptrace Anti-RE Trick
- josephcsible 3y agoThankfully 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.
- lapcat 3y ago> 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.
- adtac 3y agoThe 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 https://man.archlinux.org/man/seccomp_unotify.2.en
- harryfyx 3y agoI 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?
- scandinavian 3y agoYou can just use LD_PRELOAD to load your own version of ptrace. Not as stealthy though.
- pizzapim 3y agoAnother way is to load a eBPF program or kernel module for this purpose.
- MuffinFlavored 3y ago> 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)
- deleted 3y ago[deleted]
- o11c 3y agoThere are also differences in the handling of `SIGTRAP`. For a serious use, this can implement `breakpoint()` function.
- aetherspawn 3y agoWe 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 ...
- harryfyx 3y agoDo you mean using this trick in malware?
- bubblematrix 3y agoNo he is referring to happyware.
- layer8 3y agoShouldn’t that be benware?
- aetherspawn 3y agoActually our competitor was reverse engineering our LOB app and we used this to protect trade secrets.
- 15155 3y agoHow is the VEH target not immediately visible during static analysis?
- maffydub 3y agoI'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.
- complex_exp 3y agoYou can just patch the call then, right? I.e. turn it into NOPs
- ysfr 3y agoYes. Or if it's using dynamic libraries and not compiled static, you can use LD_PRELOAD and overwrite ptrace() to do nothing. You don't have to patch anything then, which might be easier. int ptrace(int request, int pid, void *addr, void *data) { return 0; } And compile it: gcc -shared myptrace.c -o myptrace.so Afterwards you can eiher LD_PRELOAD=./mytrace.so ./thebinary # shell ltrace -S -l ./mytrace.so ./thebinary # strace in shell or for gdb set environment LD_PRELOAD=./mytrace.so
- maffydub 3y agoThanks, both! This was used in a static build that decrypted and checksummed its binary before execution, which ruled out naive implementations of the attacks above. I agree there are ways round these too, but I believe it was just intended to discourage amateurs rather than protect against serious hacking.
- userbinator 3y agoThis "self-debugging" technique is common in the Windows world too: http://profile.maff1t.com/AntiDebugging/ 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.
- jepler 3y agoIn 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.
- Cloudef 3y agoSome android malware also checks TracerPid in /proc/*/status https://github.com/Cloudef/android2gnulinux/blob/master/src/libc-antiantidebug.c https://github.com/Cloudef/android2gnulinux/blob/master/src/...
- _8j50 3y agoWindows 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. https://github.com/x64dbg/ScyllaHide https://github.com/x64dbg/ScyllaHide
- hyperman1 3y agoIf 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.
- jasondoty 3y agoTricks for windows https://anti-debug.checkpoint.com https://anti-debug.checkpoint.com
- jezfromfuture 3y ago[dead]