2

我正在编写一个监视系统调用的程序(除其他外)。但是我在让 ptrace 识别我传递给它的进程 ID 时遇到了一些麻烦。执行程序后,我收到以下错误消息:

:No such process

但是,我已经在调用之前验证了进程 ID,方法是将其打印到控制台并使用ps -all.

以下是一些可能相关的代码(如有必要,我可以发布更多):

领导子进程:

/* Call to be traced */

if (ptrace (PTRACE_TRACEME, 0, 0, 0) < 0){
   perror ("Process couldn't be traced");
   exit (-1);
}

/* Execute process image */

if (execv (ProcessArgs[0], &ProcessArgs[1]) < 0){
    perror ("Couldn't execute process");
    exit (-1);
}

在父进程的线程中:

DbgdProcess * _Process = ( DbgdProcess * ) _ProcessPass;

int SystemCall = 0,
        Status = 0;

/* I have tried sleep(1) here to wait for PTRACE_ME to no avail */

while (!_Process->CloseSignal){
    if ( wait  (&Status) < 0) // error handler
    if ( WIFEXITED  (Status)) // error handler
    if (!WIFSTOPPED (Status)) continue;

    SystemCall = ptrace (PTRACE_PEEKUSER, _Process->ID, 4 * ORIG_RAX, 0);

    if (SystemCall < 0) // error handler

    printf ("Process made system call %d\n", SystemCall);

    if (ptrace (PTRACE_CONT, _Process->ID, 0, 0) < 0) // error handler
}

有人可以向我解释这种行为吗?

一些额外的说明:

  • 被调试的进程是父进程的直接子进程
  • 我很确定这是一个 64 位编译,因为 sys/reg.h 只定义了 RAX
  • 所有错误处理程序都包含一个 perror() 消息

更新:

我从手册页中读到了这个:

大多数 ptrace 命令(除 PTRACE_ATTACH、PTRACE_SEIZE、PTRACE_TRACEME、PTRACE_INTERRUPT 和 PTRACE_KILL 之外的所有命令)都要求被跟踪者处于 ptrace-stop 中,否则它们会因 ESRCH 而失败。

我相信 ESRCH 给出的信息是“没有这样的过程”。那么,当我进行 ptrace 调用时,进程可能没有被 ptrace 停止?

更新:

我正在测试这个例子中的代码。在执行以下操作后,我确实让它工作了: - 将标头从更新为 - 将 (eax_orig * 4) 更改为 (rax_orig * 8)

但是这些更改也在我的程序中,但仍然无法正常工作。

更新:

我的代码工作正常。我不完全确定为什么,但是在我在使用 ptrace(2) 进行轮询调用的同一线程中调用 PTRACE_ATTACH 后它开始工作。我想这意味着 ptrace 必须在父进程的同一线程中使用,但我不完全确定。我现在的问题是,有人知道这是不是真的吗?或者,如果不是,为什么 ptrace 会这样?

更新:

我找到了这个链接,这似乎表明我的问题并非闻所未闻。

4

2 回答 2

1

在检查进程是否停止之前,为什么要执行 PTRACE_SYSCALL?

理想情况下,在父线程中,您应该使用等待来等待子线程停止。

一旦孩子停止使用 WIFSTOPPED,则只使用任何其他 ptrace 调用。

PTRACE_SYSCALL 似乎正在返回 ESRCH。你能确认一下吗

于 2013-05-27T22:16:19.183 回答
1

sleep(1) 有时是不够的;尝试睡眠(5)。

于 2013-05-27T12:58:19.643 回答