[saagarjha]

Some of the detection methods methods were mentioned in a comment (here’s one more: timers), but I should also mention that some binaries try to resist ptrace attempts with ptrace(PTRACE_TRACEME, …) as well if you’re too slow to get in before that.

[kccqzy]

This might be off topic but I never really understood the utility of PTRACE_TRACEME. The documentation suggests that the parent must be a cooperating process (the wording "probably shouldn't" in the documentation is very suspicious). But if the parent knows it will ptrace the child, it could very well set up a pipe and have the child be blocked on it, then PTRACE_ATTACH, then unblock the child with the pipe.

As such, I never truly understood the semantics behind PTRACE_TRACEME, and I'm not sure what bad things will happen if you use that when the parent isn't expecting to ptrace the child.

[saagarjha]

As I understand it, PTRACE_TRACEME causes the process to be put into "traced" mode, where signals (and exec* calls, which will cause a SIGTRAP to be sent) cause the process to stop. This is useful in the context of a debugger because the debugger process will fork, the child will call ptrace(PTRACE_TRACEME, …) to put itself into "traced" mode, then exec the process you want to debug and be conveniently placed into ptrace stop at the first instruction to be executed in the new binary.

The problem with PTRACE_TRACEME is that if you do it to yourself and recieve a signal, you're put into ptrace stop there's and there's no way out of it unless the parent knows how to get you out of it (using ptrace, of course). Sending signals will not work, even SIGKILL; somewhat humorously, on iOS, if you attempt to do the equivalent (using the similar PT_TRACE_ME) and oops yourself, the entire system will slowly grind to a halt as it tries to (at least, I think…) SIGKILL your process for a variety of reasons and fails, at some point locking up waiting for process termination.