4 ms·

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

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.

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.
- sjtgraham 3y ago
  On Apple platforms ptrace supports an additional flag "PT_DENY_ATTACH", which is what iTunes uses. It causes the target process to exit.
  - lapcat 3y ago
    Yeah, that's it. Also DVD Player, for example. Pretty trivial to work around.
adtac 3y ago
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 https://man.archlinux.org/man/seccomp_unotify.2.en
- harryfyx 3y ago
  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?
  - scandinavian 3y ago
    You can just use LD_PRELOAD to load your own version of ptrace. Not as stealthy though.
  - pizzapim 3y ago
    Another 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]