在gdb中绕过ptrace

Question

如果程序使用ptrace来检测它是否在调试器中运行，我发现了以下技巧：

catch syscall ptrace
commands 1
set ($eax) = 0
continue
end

有人可以解释一下它是如何工作的吗？ 我试图在commands 1之后插入ir eax ，但是我不明白我得到的负值：

Catchpoint 1 (call to syscall ptrace), 0x00007ffff778af1e in ptrace (request=PTRACE_TRACEME) at ../sysdeps/unix/sysv/linux/ptrace.c:45
45  ../sysdeps/unix/sysv/linux/ptrace.c: No such file or directory.
eax            0xffffffda   -38

Catchpoint 1 (returned from syscall ptrace), 0x00007ffff778af1e in ptrace (request=PTRACE_TRACEME) at ../sysdeps/unix/sysv/linux/ptrace.c:45
45  in ../sysdeps/unix/sysv/linux/ptrace.c
eax            0xffffffff   -1

Answer 1

ptrace系统调用允许一个进程跟踪另一个进程。 我的猜测是，您的应用程序（正在尝试检测调试器）产生一个子进程（或线程），然后像调试器一样使用ptrace将其附加到该子进程。

问题在于，只有一个进程可以跟踪另一个进程，如果第二个进程尝试使用ptrace进行附加，则第二个ptrace将失败，返回-1并将errno为EPERM 。 如果您在调试器下运行，则调试器将首先进入并附带ptrace ，因此，当应用程序本身尝试使用ptrace进行附加时，此调用将失败。

因此，在您的示例中，当捕捉点在从syscall ptrace 返回时触发时，您可以看到eax设置为-1，表明syscall失败（寄存器eax在x86-64上保留了返回值）。

现在，如果您要调试的应用程序中的代码不是很好，并且它仅检查ptrace返回成功，则将eax的值强制为0（其中0表示ptrace成功） 可能就足以愚弄了应用程序以为它不在调试器下运行。

显然，有可能在应用程序中编写更复杂的代码，从而更广泛地使用ptrace ，这样就很难 （尽管并非不可能）解决此检测问题。