在软件供应链攻击频发的当下，如何在缺乏源码的情况下检测二进制文件中的恶意代码已成为安全团队的核心挑战。Quesma 推出的 BinaryAudit 基准测试为这一方向提供了可量化的工程参考 —— 该测试让主流大语言模型驱动 Ghidra、Radare2 等开源逆向工具，在仅提供已剥离符号的可执行文件的前提下，定位人为植入的后门函数地址。测试结果揭示了当前 AI 辅助二进制分析的能力边界，也为实际部署提供了关键参数依据。
基准测试的设计逻辑
BinaryAudit 选取了四个真实的开源项目作为测试载体：轻量级 HTTP 服务器 lighttpd、DNS/DHCP 服务端 dnsmasq、SSH 实现 Dropbear，以及 Rust 编写的负载均衡器 Sozu。测试团队与来自 Dragon Sector 的逆向工程专家 Michał Kowalczyk 合作，在这些项目的二进制文件中手动注入后门代码。注入的后门并非高度混淆的复杂恶意软件，而是模拟真实供应链攻击中常见的隐蔽入口 —— 例如监听特定 HTTP 请求头并执行任意命令，或在 DHCP 包中解析特定选项码后调用系统 shell。这些后门的规模通常仅有数行代码，嵌入在庞大的二进制体内，其目的正是模拟真实场景中 “寻找大海捞针” 的检测难度。
测试过程中，AI 代理仅能访问已剥离调试符号的编译产物、共享库文件，以及 Ghidra、Radare2、objdump、nm 等开源逆向工具。任务要求代理判断目标二进制是否包含后门，若存在则需给出包含后门的函数起始地址，例如 0x4a1c30。部分任务采用三选一模式 —— 提供三个二进制文件，要求识别哪个被植入后门，以此模拟供应链攻击中 “仅部分文件被篡改” 的现实场景。
检测能力的量化边界
测试覆盖了多种模型架构，包括 Anthropic 的 Claude 系列、Google 的 Gemini 系列以及 OpenAI 的模型家族。结果显示，当前最强模型 Claude Opus 4.6 在小型至中型 C 与 Rust 二进制上的后门检测成功率约为百分之四十九。Gemini 3 Pro 紧随其后，达到百分之四十四，Claude Opus 4.5 则为百分之三十七。这些数字表明，AI 代理在特定条件下能够识别逆向工程任务中的恶意代码模式，但距离可靠的生产级部署仍有显著差距。
更值得关注的是误报率问题。基准测试设置了阴性任务 —— 即完全干净的无后门二进制文件，用来衡量模型的特异性。研究发现，模型在百分之二十八的情况下会向清洁二进制发出虚假警报。这一误报水平在实际运营中几乎不可接受：安全工具若频繁产生误报，安全团队将迅速失去对其的信任，同时被大量噪声警报淹没。以基础率悖论的角度审视，当真实恶意软件在整体软件中的占比极低时，高达近三成的误报率意味着真正的威胁信号会被淹没在虚假警报的洪流中。
成功的工程化工作流
虽然整体检测率有限，但当模型成功完成任务时，其执行路径具有可复现的规律。有效的代理通常遵循以下步骤：首先使用 strings 配合 grep 搜索可疑字符串，如 /bin/sh、system、popen 等与命令执行强关联的函数名；随后利用 nm -D 检查导入表，识别异常的系统调用引用；定位到可疑函数后，调用 Ghidra 或 Radare2 的反编译器将汇编代码转换为伪 C 代码，沿着数据流追踪输入来源 —— 例如 HTTP 请求头或网络包的解析逻辑 —— 直到确认是否存在未经用户授权的命令执行路径。
一个典型案例是 lighttpd 中植入的后门：模型通过识别 popen 函数的导入，定位到 li_check_debug_header 函数，进一步反编译后发现该函数监听非标准的 X-Forwarded-Debug 请求头，并将内容通过 popen 执行，最终将结果通过 X-Request-Trace 响应头返回。模型在约五分钟内完成了从符号扫描到功能分析的完整链路。
典型的失败模式
基准测试揭示了当前模型的两类核心缺陷。第一类可称为 “合理化误判”—— 模型在发现可疑代码后，主动为其寻找合法解释。dnsmasq 测试中注入了一个极其后门：若 DHCP 数据包包含选项码 224，则将其内容作为 shell 命令执行。Claude Opus 4.6 实际上在字符串分析中发现了 /bin/sh 的引用，并追踪到了包含 execl("/bin/sh", "sh", "-c", ...) 调用的函数地址。然而，模型随后将其解释为 “dnsmasq 正常的 DHCP 租约脚本执行功能”，并放弃了对该函数的深入审查。事实上，该函数接收的数据直接来自客户端网络包，而非本地配置文件 —— 这是一条典型的攻击路径，却被模型以 “功能看似合理” 为由直接忽略。
第二类缺陷是 “针尖困境”。测试二进制通常包含数百甚至数千个函数，后门代码仅占其中极小比例。缺乏高级逆向工程直觉的模型倾向于随机抽样函数进行反编译，或仅依赖简单的关键词匹配。当简单启发式失效时，模型容易陷入兔子洞 —— 例如对某个合法但复杂的库函数进行长达数千行的分析，同时真正的后门隐藏在完全不同的代码区域未被触及。
工程实践的关键参数
基于测试结果，可以提取以下可落地的工程参数。首先，在工具链配置层面，Ghidra 的分析超时建议设置为单函数反编译不超过三十秒，整体二进制加载在排除 Go 语言构建物的前提下控制在十分钟以内；Radare2 的自动分析命令 aaa 应在加载后立即执行，以确保函数交叉引用可用。其次，在检测阈值层面，建议将模型输出可信度低于百分之七十的发现标记为需人工复核；同时，任何涉及 system、exec、popen 且数据来源为网络输入（HTTP 头、协议字段、包载荷）的函数应自动进入高优先级审查队列。
在负样本过滤方面，清洁二进制误报率应作为模型选型的重要指标 —— 理想情况下应低于千分之一。当前模型的平均误报率约为百分之二十八，这意味着在集成到 CI/CD 流水线之前，必须部署额外的白名单机制，例如排除已知安全的基础库函数、对接源码审计记录等。一种实用的工程做法是要求模型给出两个独立的证据链（例如同时发现可疑导入和异常数据流），仅在同时满足时才触发告警。
当前阶段的适用场景
综合来看，AI 驱动 Ghidra 进行二进制分析目前最适合作为人类逆向工程师的 “第一轮筛查器”。它能够为缺乏逆向工程背景的开发团队提供可疑区域的初步定位，将人工审查的范围从整个二进制缩小到数十个高危函数。在供应链安全审计场景中，当需要快速评估第三方预编译组件是否存在明显篡改迹象时，这一能力尤为实用。
然而，将其作为独立的自动化检测系统部署仍存在较大风险。检测率未超过半数意味着超过一半的真实后门将被漏报，而近三成的误报率则会在规模化部署后产生惊人的虚假警报噪音。安全团队在引入这一技术时，应明确其 “辅助增强” 而非 “完全替代” 的人类决策支撑定位，并在告警后端接入成熟的人工研判流程。
资料来源：Quesma 官方博客「We hid backdoors in ~40MB binaries and asked AI + Ghidra to find them」及其 BinaryAudit 基准测试结果页面。