DebugHarness: Emulating Human Dynamic Debugging for Autonomous Program Repair

1. 研究背景与问题 (Problem)

• 核心挑战：在复杂的软件系统中，自动修复严重的安全漏洞（特别是 C/C++ 中的底层内存安全漏洞，如 Use-After-Free、内存破坏等）仍然是一个巨大的挑战。
• 现有方法的局限性：
  • 静态分析的不足：现有的基于大语言模型（LLM）的自动程序修复（APR）工具（如 PatchAgent, VulnResolver 等）通常将漏洞修复视为纯粹的静态代码生成任务。它们仅依赖静态工件（如问题报告、堆栈跟踪、源代码），缺乏对程序动态执行上下文的理解。
  • 复杂漏洞的盲区：对于涉及内存布局、时间顺序（如悬空指针）或复杂状态违规的深层漏洞，静态分析往往无法定位根本原因（Root Cause）。例如，崩溃点可能只是症状，而真正的错误发生在更早的执行路径中，且不在堆栈跟踪里。
  • 人机差距：人类安全专家在调试此类问题时，会利用交互式调试器（如 GDB）、内存检查工具（如 pwndbg）和时间旅行调试（如 rr）来动态观察内存状态和反向追踪错误，而现有的 LLM Agent 缺乏这种动态交互能力。

2. 方法论：DebugHarness (Methodology)

为了解决上述问题，作者提出了 DebugHarness，一个自主的、由 LLM 驱动的调试代理框架。其核心理念是模拟人类系统工程师的交互式动态调试实践。

核心架构与流程

DebugHarness 是一个端到端的框架，包含三个主要阶段，形成一个闭环：

1. 签名驱动的初始化 (Signature-Driven Initialization)：

   • 输入：可复现的崩溃触发器（PoC）和 sanitizer 报告（如 ASan 报告）。
   • 机制：系统解析崩溃报告以识别漏洞类型（如堆缓冲区溢出、Use-After-Free）。
   • 动态注入：根据漏洞类型，将特定的**调试指南（Troubleshooting Guidelines）**注入到 LLM 的系统提示词中。这些指南包含专家知识，指导 LLM 关注特定的内存状态和调试策略（例如，UAF 需检查堆元数据，堆溢出需检查边界）。

2. 交互式状态内省 (Interactive State Introspection)：

   • 动态执行：LLM 不再仅阅读代码，而是指挥调试工具在运行时环境中执行。
   • 工具集成：
     • GDB：用于执行控制和断点设置。
     • pwndbg：用于深度的堆和内存内省。
     • Mozilla rr：用于确定性记录与回放（Record-and-Replay），支持反向执行（Reverse Execution）。这对于追踪时间相关的内存错误（如悬空指针的起源）至关重要，允许 Agent 在崩溃前“倒带”查看状态。
   • 上下文管理：为了解决调试输出过长的问题，系统利用 LLM 生成 Python 脚本来处理原始调试输出（如提取特定模式、汇总内存状态），将非结构化数据转化为语义摘要，从而节省 Token 并保留关键信息。
   • 假设 - 验证循环：Agent 根据动态观察提出根因假设，并通过调试命令验证假设，直到定位根本原因。

3. 补丁合成与验证 (Patching and Validation)：

   • 补丁生成：基于确定的根因，LLM 生成补丁（Unified Diff）。
   • 自动修正：在应用补丁前，使用确定性算法自动修复 LLM 可能生成的格式错误（如行号偏移），避免因格式问题导致的验证失败。
   • 闭环反馈：在隔离环境中重新编译并运行 PoC 和测试套件。如果验证失败（编译错误、Sanitizer 再次报错或测试失败），系统会将错误日志蒸馏后反馈给 LLM，触发新一轮的假设修正和补丁生成。

3. 关键贡献 (Key Contributions)

1. 交互式 LLM 调试框架：首次将动态、交互式的执行调试直接集成到 LLM 的推理循环中，从静态代码分析转向动态状态内省，填补了静态推理与底层系统复杂性之间的鸿沟。
2. 系统实现：设计并实现了一个端到端框架，通过签名驱动的调查和交互式状态内省引导 LLM。利用 rr 等工具实现了可逆的调试过程，有效隔离了根因并减少了非确定性行为。
3. 全面的实证评估：在包含 200 个真实世界 C/C++ 安全漏洞的基准测试 SEC-bench 上进行了严格评估。结果表明，动态调试显著提升了 LLM 的诊断能力。

4. 实验结果 (Results)

• 数据集：SEC-bench（29 个开源项目，200 个漏洞，涵盖 16 种 CWE 类型）。
• 修复成功率：
  • DebugHarness 在 SEC-bench 上的整体修复率约为 90%（具体为 89.5% - 94.5%，取决于使用的 LLM 骨干模型，如 GLM-5, DeepSeek-V3.2, Gemini-3 Flash）。
  • 对比基线：相比最先进的基线，性能提升显著。
    • 优于 VulnResolver (67.5%) 约 22 个百分点。
    • 优于 PatchAgent (57.5%) 约 32 个百分点。
    • 远超通用 Agent（如 SWE-agent, OpenHands，成功率约 20-37%）。
• 消融实验 (Ablation Study)：
  • 移除动态调试 (w/o debugger)：仅依赖静态信息时，修复率降至 77.0%（下降 12.5%），证明动态上下文对复杂漏洞至关重要。
  • 仅使用 GDB (GDB-only)：移除 rr 和 pwndbg 的高级功能后，修复率降至 82.0%（下降 7.5%），表明时间旅行调试和深度堆内省对解决时间相关漏洞（如 UAF）尤为关键。
• 成本效率：平均每个漏洞的修复成本约为 $0.09，与基线工具相当，但修复率更高，性价比更优。

5. 意义与影响 (Significance)

• 范式转变：DebugHarness 标志着自动程序修复从“静态猜测”向“动态证据驱动调试”的根本性转变。它证明了在解决底层系统漏洞时，动态执行上下文是不可或缺的。
• 解决复杂漏洞：成功解决了大量现有静态 LLM 代理无法处理的复杂内存安全漏洞（特别是涉及悬空指针、堆破坏和跨文件状态污染的问题）。
• 通用性潜力：虽然目前主要针对 C/C++ 内存安全漏洞，但其“签名驱动 + 交互式调试”的架构具有扩展性，未来可应用于并发错误（数据竞争）、逻辑错误及性能瓶颈的自动诊断与修复。
• 填补安全鸿沟：有效缩小了自动化漏洞发现（如 Fuzzing）与自动化漏洞修复之间的差距，降低了安全维护成本。

总结

DebugHarness 通过模拟人类专家利用调试器动态追踪内存状态和反向执行的能力，成功克服了纯静态 LLM 在修复复杂系统漏洞时的局限性。其实证结果表明，将动态调试工具深度集成到 LLM Agent 的工作流中，是提升自动化程序修复（APR）在安全关键领域有效性的关键路径。