0

In ptrace I can debug another process to print all the syscall numver that the remote process call.l , with this steps.

  1. Attach to process with PTRACE_ATTACH.
  2. waitpid (with `__WALL flags) to be sure the remote process has been stopped.
  3. In while (cond) print on register that store the syscall number with PTRACE_PEEKUSER

How the remote process can prevent that ?is there any signal that it can to register and print "stop debug me!!"??

PTRACE_ATTACH send SIGSTOP for remote process,but process can't handle that. And PTRACE_PEEKUSER do not send any signal to remote process.

yfr24493AzzrggAcom
  • 159
  • 1
  • 2
  • 13
  • 1
    When you `fork/exec` the target process, your program, in the child, will do: `PTRACE_TRACEME` before the exec call. After that, [AFAIK], the traced process can _not_ detach itself. The tracer _can_ detach the traced process. And, it _can_ attach itself to the traced process after the fact. I'd download the source to the `strace` program to see how to use `ptrace` correctly. After doing `PTRACE_ATTACH`, the tracer has to do `waitpid` to force the stop to take effect. Be sure to read all of `man ptrace` for additional info on this. – Craig Estey May 07 '20 at 20:42
  • @Craig Estey I didn't understand your comment. I wrote that after `PTRACE_ATTACH` I use `waitpid` . I looking for how the remote (tracee) process can catch me according to this algorithm. – yfr24493AzzrggAcom May 07 '20 at 20:51
  • "catch me" as in detect that you're tracing it? The tracee _can_ look at `/proc/self/status` and see that `TracerPid` is non-zero and know that it's being traced. But, tracer can intercept the `read` going to that and "lie" about it (i.e. it can present: `TracerPid: 0`). Normally, most programs don't care and don't bother to look. So, I'd ask _why_ you want to do this? The only reason I can think of is that you're trying to sandbox a hostile app? There are other things you can do [and _may_ need to do], so knowing more about what you're trying to achieve [at a higher level] would help. – Craig Estey May 07 '20 at 21:11
  • @Craig Estey thanks, the main question is if the tracee can register to specific signal that my algorithm make it,so it can catch it and react to this signal – yfr24493AzzrggAcom May 07 '20 at 21:22
  • I assume you mean `SIGSTOP`? No, per `man 7 signal`: _The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored._ The tracee _can_ intercept/block any _other_ signal (e.g. `SIGTERM`) via `signal/sigaction/sigprocmask`, etc. But, once you have control via `ptrace` and the tracee is stopped, you can change/undo anything the tracee does because you can intercept those calls and nop them if desired. And, you can use `peek/poke` to inject any code you want to undo any prior changes. But, if you use `PTRACE_TRACEME`, you will intercept 100% _before_ the fact, so nothing to "undo" – Craig Estey May 07 '20 at 21:34
  • @Craig Estey thanks again good person. Why should my algorithm can cause `SIGTERM` ? I know that the tracee can't react to SIGSTOP/SIGKILL, so is there another signal that causes by my algorithm so the tracee can react for them? – yfr24493AzzrggAcom May 07 '20 at 21:41
  • No, `ptrace` [AFAIK] it only uses `SIGSTOP`. There is _no_ other signal involved. I only mentioned `SIGTERM` as an example of a signal that _your_ program _might_ want to send to cause an effect (e.g. you send `SIGTERM` to tracee, to monitor how it handles it). But, normally, using `ptrace` you have complete control and the tracee can _not_ break out of it. _If_ you let it, it could figure out that you're tracing it, and it could try to `kill(...,9)` you. But, again, you can intercept [and prevent] that. Once again, get `strace` source. It has a lot of info that would be useful. – Craig Estey May 07 '20 at 22:13
  • @Craig Estey if I use `ptrace(req,pid, address,0)` (data=0) in the Tracee perspective is it get only `SIGSTOP` ( and can't handle it?) even `ptrace(PTRACE_SYSCALL,lid,0,0);` in Tracee perspective is that only SIGSTOP? Is that tracee get SIGCONT while PTACE_CONT/PTRACE_SYSCALL if I use data=0? If no how tracee process continue to run without SIGCONT? – yfr24493AzzrggAcom May 11 '20 at 08:15
  • `SIGSTOP` is _special_. It is _never_ actually sent to the userspace process. It merely marks the target process as stopped, and causes a system reshedule. Thus, there is nothing to "catch". AFAICT, it's the same for `SIGCONT`. It just changes the run state for the process, but the userspace signal handler will _never_ be invoked. `SIGSTOP/SIGCONT` are just how the kernel adjusts the run state for the target process to facilitate `ptrace` – Craig Estey May 11 '20 at 17:12

0 Answers0