Re:The Ptrace Anti-Re Trick
by josephcsible on Sunday August 27, 2023 @07:10PM
(#37287555)
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.
[ Parent
| on HN ]
> 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.
Yeah, that's it. Also DVD Player, for example. Pretty trivial to work around.
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
by scandinavian on Monday August 28, 2023 @03:30AM
(#37290956)
You can just use LD_PRELOAD to load your own version of ptrace. Not as stealthy though.
Another way is to load a eBPF program or kernel module for this purpose.
Re:The Ptrace Anti-Re Trick
by MuffinFlavored on Sunday August 27, 2023 @10:12PM
(#37288863)
> 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)