Низко-служебный способ получить доступ к пространству памяти прослеженного процесса?

Они - то же самое . URI является обобщением URL. Первоначально, URIs были запланированы, чтобы быть разделенными на URL (адреса) и УРНЫ (имена), но тогда было мало различия между URL и URI, и http URIs использовались в качестве пространств имен даже при том, что они на самом деле не определяли местоположение никаких ресурсов.

7
задан vovick 5 June 2009 в 22:05
поделиться

6 ответов

Если это Linux (как предполагают теги), вы можете поделиться всем адресным пространством дочернего элемента с родительским, используя clone () с Флаг CLONE_VM . Поскольку два процесса используют одно и то же пространство виртуальной машины, все изменения будут немедленно видны между ними, практически без накладных расходов.

Это означает, что вы не можете затем exec () в дочернем элементе; поскольку он заменит пространство виртуальных машин обоих процессов.

4
ответ дан 7 December 2019 в 10:06
поделиться

Контролируете ли вы дочерний процесс и его исходный код? Если это так, вы можете рассмотреть возможность использования общей памяти .

1
ответ дан 7 December 2019 в 10:06
поделиться

Если вы контролируете дочерний процесс, может быть, вы могли бы добавить интерфейс отладки, позволяющий записывать данные в рассматриваемую память?

0
ответ дан 7 December 2019 в 10:06
поделиться

Рассмотрите возможность внедрения некоторой функции отладки в процесс ptrace и ее вызова через ptrace_setregs. Что-то вроде того, как gdb может запускать любую функцию процесса ptraced.

Также вы можете попробовать внедрить код в процесс через LD_PRELOAD. Можно даже попробовать заставить работать без ptrace, используя сигналы.

upd1: Внедрение Gdb или «вызов подчиненной функции» довольно сложен. См. Функцию call_function_by_hand в файле gdb-6.6.50.20070809 ›gdb› infcall.c здесь: 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);
  }
1
ответ дан 7 December 2019 в 10:06
поделиться

Для чтения лучше всего разобрать файл /proc//maps на предмет виртуальных адресов интересующих областей памяти.

Затем вы можете прочитать их, открыв /proc//mem и выполнив read() вызов с большим буфером на интересующих областях.

Для записи я еще не нашел простого способа записывать целые блоки, я полагаю, что это связано с блокировкой и стабильностью дочернего процесса, вызовы через ptrace() могут гарантировать это, но прямой доступ к памяти другого процесса не может. Обычно я пишу обертку вокруг ptrace(PTRACE_POKEDATA, ...) для зеркального отражения WriteProcessMemory() Windows.

0
ответ дан 7 December 2019 в 10:06
поделиться

clone или mmap - это то, что вы ищете. mmap временный файл между двумя процессами и использование этого пространства памяти для передачи данных туда и обратно.

0
ответ дан 7 December 2019 в 10:06
поделиться
Другие вопросы по тегам:

Похожие вопросы: