1

The documentation on ptrace is a little bit fuzzy to me. It says:

A tracee first needs to be attached to the tracer. Attachment and subsequent commands are per thread: in a multithreaded process, every thread can be individually attached to a (potentially different) tracer, or left not attached and thus not debugged. Therefore, "tracee" always means "(one) thread", never "a (possibly multithreaded) process".

Also:

In the following requests, pid specifies the thread ID of the tracee to be acted on. For requests other than PTRACE_ATTACH, PTRACE_SEIZE, PTRACE_INTERRUPT and PTRACE_KILL, the tracee must be stopped.

So, if we have a multithreaded process and we attach to a single thread with PTRACE_SEIZE and stop it with PTRACE_INTERRUPT, will we able to read/write the entire process's global data with PTRACE_PEEKTEXT, PTRACE_PEEKDATA, PTRACE_POKETEXT or PTRACE_POKEDATA?

Secondary question: If the answer to the main question is yes, why is it needed for a thread to be stopped? I was thinking that the stop is needed for achieving some sort of locking mechanism, but if a single thread is stopped, then the other ones can write into the memory that ptrace is trying to read/write freely.

MciprianM
  • 513
  • 1
  • 7
  • 18

1 Answers1

0

Yes, you can read the global memory, but the result may be inconsistent if there are running threads modifying the memory concurrently. Moreover, the thread context (registers and flags) can only be obtained for traced, stopped threads.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084