基本上，我试图弄清楚 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 上使用 PIN 和 UPX 压缩二进制文件(最终被剥离和静态链接)时，我找不到任何图像加载(甚至没有主可执行图像)。
为什么会这样？
最佳答案
What behaviour causes PIN to recognise an "image load"
ld-linux.so 和调试器(例如 GDB)之间有一个“标准”接口(interface):每次加载或卸载 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 使用相同的技术来监视“正常”图像加载和卸载。
when I tried using PIN with a UPX compressed binary ... I could find no image loads at all
这正是我所期望的:PIN 查看了 UPX 的二进制文件，发现它是完全静态的，并且没有设置任何断点(毕竟，ld-linux.so 当控制到达 UPX 的二进制文件时，它不会加载到内存中，因此它无法在 _dl_debug_state 上设置断点，即使它想要设置)。
在 UPX 的二进制文件上运行 GDB，并设置 stop-on-solib-events 1 也 不会停止。 IOW、UPX“愚弄”了 GDB 和 PIN，使其认为共享库在此二进制文件中是不可能的。
关于linux - PIN、IMG_AddInstrumentFunction 和 ELF 加载程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28590060/