Ghidra 调试器如何 attach 到已在运行的目标进程

当目标程序是某个更大系统的一部分、必须保持 in situ（原地）运行时，用调试器直接 launch 它就不合适了。这时需要先在系统里把目标跑起来，再从 Ghidra 的 Debugger 工具 attach 到那个已经存在的进程。本文基于 Ghidra 官方调试器课程 A1-GettingStarted 中的 Attaching 章节，演示在 Linux 上配合 GDB 完成一次完整的 attach 操作，并给出文档中记录的成功判断方法和 Operation not permitted 的排查方式。

适用场景与前提

Ghidra 课程中的做法是：把目标 termmines 运行在 Ghidra 之外的一个终端里，然后从 Ghidra attach 过去。文档同时说明了两个前提：

• 这一技巧之所以可行，是因为 termmines 会停下来等待用户输入（停在 read 中），attach 后有稳定的停顿点可以验证。对不会等待、直接跑完退出的程序，这种 attach 方式无法在课程中复现。
• 早期的 Recorder-based 调试体系没有目标 I/O，attach 几乎是唯一手段；现在使用 Trace RMI 体系时，Debugger 的 Terminal 窗口已经解决了目标 I/O 问题，attach 主要用于上面说的 in situ 场景。

需要准备的环境：

• Linux 目标系统（termmines 是面向 Linux 设计的，可移植到其他 Unix 系统；课程未测试 Windows）。
• 已安装的 GDB。
• 已构建的 termmines 目标程序。如果只有源码，需要系统里有 ncurses 及其开发头文件和库，然后：

cd GhidraClass/ExerciseFiles/Debugger
make

Makefile 会同时构建 termmines 和排查工具 anyptracer（见文末）。构建出的 termmines 经过 strip -Kmain -K_main 处理，符号和调试信息被移除，只保留 main。

• Ghidra 中已打开 Debugger 工具：新建项目导入 termmines，把它拖到工具箱（Tool Chest）里的 Debugger 图标上即可。

在 Ghidra 之外先运行目标进程

attach 的对象是系统中一个已经存在的进程，所以第一步在 Ghidra 之外完成：

./termmines

按目标实际需要的参数运行，在 Ghidra 之外的终端里把它跑起来。目标会显示 9x9 的方格界面并等待输入，保持这个终端里的进程不要退出。

配置无目标的 GDB 会话

attach 的关键区别在于：Ghidra 不 launch 目标，只建立一个没有目标可执行的 GDB 会话，因此要把 Image 字段清空。

1. 在 Ghidra 的 Debugger 工具中，点击工具栏上 Debug 按钮旁的下拉箭头，选择 Configure and Launch termmines using... → gdb。
2. 在弹出的对话框中，把 Image 字段清空，这样配置出的 GDB 会话就没有要启动的目标。
3. Ghidra 还需要知道 gdb 的位置和目标架构。对于 64 位 x86 目标、使用系统自带的 GDB，保持默认值即可。
4. 点击 Launch。

对话框中其他选项的含义参考课程前文（launch 场景）：Run Command 用于指定 GDB 的启动命令，attach 场景的核心动作是清空 Image 字段，其余保持默认。

在 Model 窗口中找到进程并 attach

会话建立后，Ghidra 的 Model 窗口（位于左侧）会列出当前系统中可 attach 的进程：

1. 展开 Model 窗口中的 Available 节点。
2. 在过滤输入框（filter box）里输入 termmines。
3. 右键点击匹配到的节点，选择 Attach；或者记下节点的 PID（例如 1234），转到 Terminal 窗口输入：

attach 1234

两种方式等价，PID 请替换为你在 Model 窗口中看到的实际值。

文档同时给出了一个提示：后续练习如果想恢复默认的 Image 字段值，可以用 Reset 按钮；但记得把 Run Command 改回 "start"。

验证 attach 是否成功

课程给出的验证方法是：在 Terminal 窗口输入

bt

打印出的调用栈中如果处于 read 函数，说明 attach 已完成、目标停在等待输入的调用栈里。

验证完成后，按课程的流程在 Terminal 中退出 GDB（quit），再进入下一模块 A Tour of the UI。

排查：attach 时遇到 Operation not permitted

Linux 上 attach 最常见的失败现象是 Operation not permitted。文档指出，这通常是系统启用了 Yama 的 ptrace_scope=1。有三种处理办法，按侵入性从低到高：

方案一：使用随课程提供的 anyptracer（推荐）

这个工具允许自己的进程被任意其他进程 trace，然后再执行一条 shell 命令。用 exec 作为命令，就能让目标进程运行在这个宽松权限的进程里，效果等同于 ptrace_scope=0，但不降低系统其他部分的安全性：

./anyptracer 'exec ./termmines'

anyptracer 与 termmines 一起由 ExerciseFiles/Debugger 的 make 构建（源码见 anyptracer.c）。之后从 Ghidra attach 到它运行的 termmines 即可。

方案二：以 root 调整 Yama 设置

如果有 root 权限，可以按 Yama 的线上文档修正该设置。文档特别提醒：不要在全局范围内设置 ptrace_scope=0，除非这台机器是专门留作调试用途的独立系统——全局放开会显著降低安全性，任何被入侵的同用户进程都可以 attach 到并窃取其他进程的数据（例如凭据）。

attach 后 Model 窗口的两个检查点

• 如果 Model 窗口是空的：检查 Dynamic Listing 里是否有 "noname" 选项卡，有就点一下。
• 如果 attach 成功后 Model 窗口看起来不完整：确认它的 Filter 输入框已被清空（之前过滤用过的内容还留在里面）。

限制说明

• 课程演示的 attach 路径基于 Linux 上的 gdb launcher；Windows（dbgeng）和 macOS（lldb）的启动流程与 Linux 相同，只是最后一步选择对应的调试引擎，attach 细节课程未展开。
• 目标必须在某处稳定停下（课程依赖 termmines 等待输入这一特性）；文档没有说明目标完全不等待输入时的通用做法。
• anyptracer 只放宽它自己派生出的那个进程的可 trace 性，是逐进程的方案，不改变系统全局安全配置。