【问题标题】:Cannot make a breakpoint in my mini debugger for linux无法在我的 linux 迷你调试器中设置断点
【发布时间】:2017-10-21 19:56:43
【问题描述】:

我致力于制作一个迷你调试器作为个人项目。该调试器适用于 GNU/Linux 环境下的 x86 处理器。

在我在调试程序的特定地址设置断点的方法中,我第一次使用我的调试器。如果我再试一次,它会失败。

我想确定我这样做是否正确。

假设我有一个 helloworld 程序要调试如下:

#include <iostream>
int main()
{
    std::cerr << "hello,World\n";
return 0;
}

并用 objdump -d 如下所示

0000000000400907 <main>:
400907: 55                      push   %rbp
  400908:   48 89 e5                mov    %rsp,%rbp
  40090b:   be 04 0a 40 00          mov    $0x400a04,%esi
  400910:   bf 60 10 60 00          mov    $0x601060,%edi
  400915:   e8 06 ff ff ff          callq  400820 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
  40091a:   b8 00 00 00 00          mov    $0x0,%eax
  40091f:   5d                      pop    %rbp
  400920:   c3                      retq 

当然,我用 -g 选项编译了我的 helloworld。

在第一次试验中,我在 0x4009150x40091a 处设置了一个断点。所以我所期待的是,当我 continue(像 GDB 这样的命令)我的调试器时,它将停止在 0x400915 并且当我再次 continue它会打印“helloworld”,但没有发生。它只是返回,因为没有任何断点。

作为另一个试验,当我的调试器启动我的 helloworld 程序时。我看到 helloworld 程序的 pid 并在 /proc/[helloworld pid]/maps 打开它的 ma​​ps 文件,看起来像

00400000-00401000 r-xp 00000000 08:07 1578540                            /home/yahia/mytinydebugger/tdbg/build/debugging-examples/helloworld
00600000-00602000 rw-p 00000000 08:07 1578540                            /home/yahia/mytinydebugger/tdbg/build/debugging-examples/helloworld
7f9483434000-7f9483457000 r-xp 00000000 08:06 529041                     /lib/x86_64-linux-gnu/ld-2.19.so
7f9483656000-7f9483658000 rw-p 00022000 08:06 529041                     /lib/x86_64-linux-gnu/ld-2.19.so
7f9483658000-7f9483659000 rw-p 00000000 00:00 0 
7fff5a314000-7fff5a335000 rw-p 00000000 00:00 0                          [stack]
7fff5a335000-7fff5a337000 r--p 00000000 00:00 0                          [vvar]
7fff5a337000-7fff5a339000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

然后关注堆栈的第一个地址,即

7fff5a314000-7fff5a335000 rw-p 00000000 00:00 0                          [stack

并添加 0x7fff5a314000 + 0x400915 = 0x7FFF5A714915 和相同的 0x40091a 。它第一次按我的预期工作,但是当我再次尝试时它不起作用。我什至通过自动从 /proc/[helloworld pid]/maps 获取它来自动在代码中执行这个十六进制数学。似乎它第一次就可以正常工作,但无论我再试一次它都没有。

我不知道为什么它并不总是有效。

我二审设置断点的做法对吗?

我知道我应该将 intel 的 INT3 指令放在我想要断点的地址处。 这是我用来设置断点的代码。

void breakpoint::enable() {
    // Fetch the program instruction at the desired address of a specific process.
    auto data = ptrace(PTRACE_PEEKDATA, m_pid, m_addr, nullptr);
    // Save the lower byte which will be replaced with INT3 instruction.
    m_saved_data = static_cast<uint8_t>(data & 0xff);
    uint64_t int3 = 0xcc;
    // Set the lower byte to INT3 instruction
    uint64_t data_with_int3 = ((data & ~0xff) | int3);
    // Push the modified instruction with the breakpoint to the same address it was fetched.
    ptrace(PTRACE_POKEDATA, m_pid, m_addr, data_with_int3);
    // Enable that (this) object of the class has a breakpoint at [m_addr] of [m_pid] process.
    m_enabled = true;
}

调试器的完整代码是here。它不大。它很简单,因为它还处于早期阶段,所以提交很少。

我的操作系统是 ubuntu 14.04,调试器和 helloworld 示例都是用 g++ 7.2.0 编译的

【问题讨论】:

  • 在 Linux 上没关系,但一个明显的错误是您应该使用 {PEEK,POKE}_TEXT 而不是 _DATA
  • @EmployedRussian 它在 Linux 中没有任何区别。
  • 是的,我就是这么说的。但它仍然是一个错误。
  • 我的意思是改变 {PEEK,POKE}_TEXT/DATA 在 linux 的上下文中没有什么不同。阅读 ptrace 手册页。
  • 您正在编写的代码在非 Linux 系统上错误,而 当前恰好在 Linux 上没有错误。这不是一个非常聪明的方法,这就是我要说的。通常,您应该努力编写正确代码,尤其是这样做不会花费您任何成本。

标签: c linux debugging gdb ptrace


【解决方案1】:

首先,您应该使用personalityADDR_NO_RANDOMIZE 来获得可预测的地址,就像GDB 默认做的那样。这将帮助您弄清楚发生了什么。不过,您还没有启用 PIE,因此 ASLR 并不是您在主程序中设置断点的原因。

然后你需要检查ptrace函数的结果是否有错误。您需要在调用前将errno 设置为零,然后检查它是否已更改。这将告诉您(在合理范围内)您是否传递了一个完全伪造的地址。

另请注意,ptracePTRACE_PEEKDATAPTRACE_POKEDATA 总是修补完整字词。为了修补单个字节,您需要使用移位和屏蔽操作将断点指令放入字内的正确字节中。

【讨论】:

  • 我尝试了个性化,我在调试器启动时使用了它,这是正确的用法还是我需要在 ptrace(peekdata,..) 之前使用?但这无济于事。我检查了 ptrace 的错误,它在使用试用 2 时返回我 EIO。试用 1 仍然因个性或没有个性而失败。
  • 您需要在创建新进程的execve系统调用之前设置个性值。
【解决方案2】:

我通过恢复被 INT3 指令损坏的指令以及其他更改(如我的存储库中的 my merge request 所示)来解决了这个问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-10-16
    • 2015-10-28
    • 2017-07-11
    • 2018-08-06
    • 1970-01-01
    • 2023-03-06
    • 2018-08-27
    相关资源
    最近更新 更多