1

When I want to inspect tracee syscall I use PTRACE_ATTACH , then PTRACE_SYSCALL in loop , and finally PTRACE_DETACH .

The problem is that if the tracee registered to SIGTRAP or SIGCONT it can change his behaviour while I use PTRACE_SYSCALL or PTRACE_DETACH and I don't want to do it.

When I attach to tracee with PTRACE_ATTACH tracee got SIGSTOP but it can't register/reaction to this signal, so that it fine.

What is the solution that the tracee could not catch SIGTRAP when I use PTRACE_SYSCALL or SIGCONT when I used PTRACE_CONT

Keystone
  • 165
  • 1
  • 9
  • See my recent comments: https://stackoverflow.com/questions/61667231/how-to-prevent-another-process-to-debug-syscall-with-ptrace?noredirect=1#comment109082322_61667231 – Craig Estey May 09 '20 at 22:54
  • @CraigEstey That actually sounds like the exact opposite of this. In that question, the asker was playing the role of malware author, and wanted to know how to keep security researchers from using `ptrace` to analyze their malware. In this question, the asker is playing the role of security researcher, and wants to know how to use `ptrace` to analyze (presumably with breakpoints) malware. – Joseph Sible-Reinstate Monica May 09 '20 at 22:59
  • @JosephSible-ReinstateMonica The techniques for preventing tracee from doing anything that tracer doesn't want are the same. If you start from `PTRACE_TRACEME`, tracer can modify/supress any tracee syscall that it wants _before_ it happens. If from `PTRACE_ATTACH`, tracer may have to inject code to _undo_ something tracee has already done (e.g. `signal(SIGTRAP,SIG_IGN)`). – Craig Estey May 09 '20 at 23:08
  • @Catig , how does the tracer can `undo` `signal(SIGTRAP,...)` for example if the tracee registered to this signal before the tracer attach to tracee? – Keystone May 10 '20 at 05:04
  • @Keystone The point of suppressing the signal is that you can keep their signal handler from running without having to unset it. – Joseph Sible-Reinstate Monica May 10 '20 at 06:21

1 Answers1

1

The tracer always gets first dibs at signal handling, and it can choose to suppress the signal so that the tracee's handler doesn't run. The only thing you have to worry about is if the tracee blocks the signal with something like sigprocmask or a blocking call to pselect and uses something like sigpending or signalfd to look for it, which you could fix by modifying or emulating the relevant syscalls.

To suppress a signal, just pass 0 for sig when resuming after signal-delivery-stop. From man 2 ptrace:

Signal injection and suppression

After signal-delivery-stop is observed by the tracer, the tracer should restart the tracee with the call

ptrace(PTRACE_restart, pid, 0, sig)

where PTRACE_restart is one of the restarting ptrace requests. If sig is 0, then a signal is not delivered. Otherwise, the signal sig is delivered. This operation is called signal injection in this manual page, to distinguish it from signal-delivery-stop.

Joseph Sible-Reinstate Monica
  • 45,431
  • 5
  • 48
  • 98