PIN、IMG_AddInstrumentFunction 和 ELF 加载器

Question

基本上，我试图弄清楚 PIN 如何使用 IMG_AddInstrumentFunction 跟踪“图像”加载。文档说“使用它来注册回调以捕获图像的加载”。 （在 source/tools/ManualExamples 中有一个imageload pintool 使用它）。

From what I understand 一个被执行（execve'd）的 ELF 二进制文件被内核映射到内存中。如果可执行文件有一个 PT_INTERP 段（指向类似 ld-linux.so.2 的东西），它将将该文件的段映射到内存中并将控制权传递给它。

我想弄清楚的是：什么行为导致 PIN 识别“图像加载”？

最初我认为这将是一组指示图像加载的 open-fstat-mmap2-close 系统调用。 PIN 还显示加载中的初始可执行映像，但由于它无法拦截从 execve 到内核空间的 mmap 调用，所以我认为 PIN 也会监视 execve。

但是，当我尝试在 Linux 上使用带有 UPX 压缩二进制文件的 PIN 时（最终被剥离并静态链接），我根本找不到任何图像加载（甚至不是主可执行图像）。

为什么会这样？

Answer 1

什么行为导致 PIN 识别“图像加载”

ld-linux.so 和调试器（如 GDB）之间有一个“标准”接口：每次加载或卸载 ELF 图像时，ld-linux 设置一个全局变量 _r_debug.r_state == RT_CONSISTENT 并调用一个函数 _dl_debug_state() （在自身内部）。该函数通常只是一个RET。

[这个描述是从它的实际工作原理简化的，但实际发生的细节在这里无关紧要。]

调试器应在_dl_debug_state 上设置断点，然后检查_r_debug.r_state 和_r_debug.r_map 以查看发生了什么。

我认为 PIN 使用相同的技术来监视“正常”图像加载和卸载。

当我尝试将 PIN 与 UPX 压缩二进制文件一起使用时......我根本找不到任何图像加载

这正是我所期望的：PIN 查看了 UPX 的二进制文件，发现它是完全静态的，并且没有设置任何断点（毕竟，当控制到达时，ld-linux.so 没有加载到内存中UPX 的二进制文件，因此它无法在 _dl_debug_state 上设置断点，即使它想要）。

在 UPX 二进制文件上运行 GDB，并设置 stop-on-solib-events 1 也 不会停止。 IOW，UPX “愚弄”了 GDB 和 PIN，让他们认为共享库在这个二进制文件中是不可能的。