Low-overhead way to access the memory space of a traced process?

Question

I\'m looking for an efficient way to access(for both read and write operations) the memory space of my ptraced child process. The size of blocks being accessed may vary from

Answer 1

clone or mmap are what you are looking for. mmap a temp file between the two processes and use that memory space for passing data back and forth.

Answer 2

Consider injecting of some debug function into ptraced process and calling it via ptrace_setregs. Something like the way how gdb can run any function of ptraced process.

Also you can try to inject some code into process via LD_PRELOAD. You can even try to make in work without ptrace, using signals.

upd1: Gdb injection or "inferior function call" is rather complicated. See function call_function_by_hand in file gdb-6.6.50.20070809›gdb›infcall.c here: http://sources.debian.net/src/gdb/7.6.2-1/gdb/infcall.c?hl=462#L462

/* All this stuff with a dummy frame may seem unnecessarily complicated
   (why not just save registers in GDB?).  The purpose of pushing a dummy
   frame which looks just like a real frame is so that if you call a
   function and then hit a breakpoint (get a signal, etc), "backtrace"
   will look right.  Whether the backtrace needs to actually show the
   stack at the time the inferior function was called is debatable, but
   it certainly needs to not display garbage.  So if you are contemplating
   making dummy frames be different from normal frames, consider that.  */

/* Perform a function call in the inferior.
   ARGS is a vector of values of arguments (NARGS of them).
   FUNCTION is a value, the function to be called.
   Returns a value representing what the function returned.
   May fail to return, if a breakpoint or signal is hit
   during the execution of the function.

   ARGS is modified to contain coerced values.  */

struct value *
call_function_by_hand (struct value *function, int nargs, struct value **args)
{
...
  frame = get_current_frame ();
  gdbarch = get_frame_arch (frame);

  if (!gdbarch_push_dummy_call_p (gdbarch))
    error (_("This target does not support function calls."));

  /* A cleanup for the inferior status.
     This is only needed while we're preparing the inferior function call.  */
  inf_status = save_infcall_control_state ();
  inf_status_cleanup
    = make_cleanup_restore_infcall_control_state (inf_status);

  /* Save the caller's registers and other state associated with the
     inferior itself so that they can be restored once the
     callee returns.  To allow nested calls the registers are (further
     down) pushed onto a dummy frame stack.  Include a cleanup (which
     is tossed once the regcache has been pushed).  */
  caller_state = save_infcall_suspend_state ();
  make_cleanup_restore_infcall_suspend_state (caller_state);
...
    sp = push_dummy_code (gdbarch, sp, funaddr, args, nargs,
                  target_values_type, &real_pc, &bp_addr,
                  get_current_regcache ());
... pass args ...
  /* Create the dummy stack frame.  Pass in the call dummy address as,
     presumably, the ABI code knows where, in the call dummy, the
     return address should be pointed.  */
  sp = gdbarch_push_dummy_call (gdbarch, function, get_current_regcache (),
                bp_addr, nargs, args,
                sp, struct_return, struct_addr);
...
  /* Everything's ready, push all the info needed to restore the
     caller (and identify the dummy-frame) onto the dummy-frame
     stack.  */
  dummy_frame_push (caller_state, &dummy_id);
... 
    /* Run the inferior until it stops.  */

    e = run_inferior_call (tp, real_pc);
  }

Answer 3

If you're in control of the child process, maybe you could add a debug interface that allows you to write to the memory in question?

Answer 4

If this is Linux (which the tags suggest it is), you can share the entirety of the child's address space with the parent by using clone() with the CLONE_VM flag. As the two processes share the same VM space, all modifications will be immediately visible between the two, with essentially zero overhead.

This does mean you can't then exec() in the child; as it will replace the VM space of both processes.

Answer 5

Are you in control of the child process and its sourcecode? If so, you could consider using Shared memory.

Answer 6

For reading, your best bet is to parse the /proc/<pid>/maps file for the virtual addresses of the memory regions of interest.

You can then read these by opening /proc/<pid>/mem and perform read() call with a large buffer on areas of interest.

For writing, I've yet to find an easy way to write entire blocks, I believe this has to do with locking and stability for the child process, calls through ptrace() can guarantee this, but direct access to another process' memory cannot. I typically write a wrapper around ptrace(PTRACE_POKEDATA, ...) to mirror Windows' WriteProcessMemory().