在软件供应链安全日益严峻的背景下，逆向工程与恶意代码检测面临前所未有的挑战。Quesma 发布的 BinaryAudit 基准测试提供了一个系统化的评估框架：在约 40MB 的真实二进制文件（lighttpd、dnsmasq、Dropbear、Sozu）中人工注入后门，考察当前主流 AI 模型结合 Ghidra、Radare2 等逆向工具的检测能力。实验结果揭示了 AI 在二进制分析领域的潜力与局限性，也为工程化检测流程的优化指明了方向。
实验设置与二进制规模
BinaryAudit 基准测试的核心设计理念是模拟真实的供应链攻击场景。研究团队选取了四个开源项目作为测试对象：轻量级 HTTP 服务器 lighttpd、DNS/DHCP 服务端 dnsmasq、SSH 服务器 Dropbear，以及 Rust 编写的负载均衡器 Sozu。这些项目的编译后二进制文件大小普遍在数十兆字节级别，其中部分测试用例达到约 40MB，属于中等规模的二进制分析任务。
后门注入采用了两种典型模式。第一种是在 HTTP 请求处理流程中插入隐蔽的指令执行路径，例如在 lighttpd 中添加对未文档化 HTTP 头部 X-Forwarded-Debug 的检测逻辑，当该头部存在时直接调用 popen() 执行攻击者提供的 shell 命令，并将输出通过响应头部返回。这种后门的隐蔽性在于其利用了合法的调试功能接口，代码量极少（仅约十行），且位于网络数据处理的关键路径上。第二种模式更为直接，在 dnsmasq 的 DHCP 选项解析逻辑中监听未使用的选项号（224），一旦收到包含该选项的 DHCP 报文，即将其内容作为 shell 命令执行，这本质上是一个网络可达的远程代码执行后门。
参与测试的 AI 智能体仅能访问编译后的可执行文件（无源代码、无调试符号），可调用的逆向工具包括 Ghidha（NSA 开发的开源反编译器）、Radare2 以及标准 binutils 工具链。任务目标是判定目标二进制是否包含后门，并精确定位恶意函数的起始地址。
量化检测率：多模型能力对比
测试结果呈现出显著的能力差异。在正向检测任务（即二进制确实包含后门）中，Claude Opus 4.6 以 49% 的任务通过率位居榜首，这意味着模型能够准确识别近一半的后门并给出正确的函数地址。Google Gemini 3 Pro 紧随其后，达到 44% 的检测率。Anthropic 上一代旗舰模型 Claude Opus 4.5 则为 37%。这些数据表明，当前顶流大模型已经具备一定的二进制逆向推理能力，能够在缺乏源码的情况下追踪数据流并识别恶意代码模式。
然而，更值得关注的是误报率这一关键指标。在负向测试（clean binaries，不含后门的干净二进制）中，各模型的误报率高达 28%。这意味着模型在接近三分之一的情况下会将正常的二进制标记为存在后门，产生大量虚假告警。对于实际的安全运营场景而言，这一误报率是不可接受的 —— 考虑到真实环境中绝大多数软件均为合法程序，即使 1% 的误报率也会导致严重的告警疲劳，而 28% 的误报率几乎使工具完全失去实用价值。
具体案例分析揭示了误报的典型模式。以 Gemini 3 Pro 为例，模型曾将命令行参数解析逻辑误判为后门：它注意到程序在处理 --max-cache-ttl 参数时将字符串存储到全局配置结构的特定偏移地址，随后又从该地址读取数据并追加字符串后调用 popen() 执行。模型据此推断攻击者可以通过传递特殊参数值实现任意命令执行。但实际上，源代码中该参数被正确验证为整数类型，根本不存在代码执行路径。这类误判说明模型在理解数据流语义方面存在根本性缺陷 —— 它能识别出代码调用了危险函数，却无法判断输入是否真正可达。
失败模式与漏报根因
除了误报问题，更令人担忧的是模型在面对真实后门时的高级漏报行为。实验中发现的最具代表性的失败案例是 dnsmasq 中的 DHCP 选项后门。该后门的实现堪称 “明目张胆”：当 DHCP 报文包含选项 224 时，程序直接将选项内容复制到缓冲区并调用 execl("/bin/sh", "sh", "-c", buf, NULL) 执行。Claude Opus 4.6 在分析初期就通过字符串搜索定位到了 /bin/sh 的引用，进一步追踪到了包含 execl 调用的目标函数。
然而，模型随后展现了一种名为 “理性化” 的认知偏差。它在分析报告中写道：execl("/bin/sh", "sh", "-c", ...) 的使用模式是 dnsmasq 正常的 DHCP 租约脚本执行功能，这一判断基于该函数确实被用于执行 DHCP 相关的外部脚本这一已知事实。模型没有进一步验证后门代码接收的数据来源 —— 它来自网络报文中的 DHCP 选项，而非授权的本地脚本文件。由于这一先入为主的假设，模型放弃了对该函数的标记，转而继续审计其他 “更可疑” 的代码区域，最终错过了真正的后门。
这种失败模式揭示了当前 AI 模型在逆向工程中的核心局限：缺乏对程序上下文的深层语义理解。模型能够执行模式匹配（识别危险函数调用）、进行基础的程序路径追踪，但在判断特定代码路径是否真正构成安全威胁时过度依赖经验性推断。当后门伪装成合法功能（如调试接口、DHCP 脚本执行）时，模型倾向于将其归类为正常代码而非恶意行为。
另一个显著的工程挑战是 “大海捞针” 问题的复杂性。40MB 二进制文件通常包含数千个函数，代码总量可达数十万行。后门可能仅占其中的数十行，隐藏在网络协议解析、配置加载等复杂的控制流中。模型缺乏人类逆向工程师的领域直觉 —— 优先审计网络数据入口点、用户输入处理路径、权限提升相关逻辑。相反，模型常采用暴力枚举策略：随机选取函数进行反编译，或使用简单关键词（如 system、exec）进行全局搜索。这种无差别扫描在面对编译器优化导致的代码结构变形时效率极低，模型很快耗尽上下文窗口却始终无法触及真正的恶意代码。
工程化检测流程优化建议
基于上述实验发现，以下工程化策略可显著提升 AI 辅助二进制后门检测的实用性。
聚焦高风险代码区域：在调用 AI 之前，先使用传统静态分析工具对二进制进行预处理。识别网络协议处理函数（通过解析函数调用图，定位处理 socket 数据的代码路径）、危险函数调用点（system、exec、popen、dlopen 等）、新增或修改的字符串（通过对比同一开源项目的不同编译版本），将这些区域作为 AI 分析的优先输入，可将有效分析范围压缩一到两个数量级。
构建多模型投票机制：由于不同模型在不同类型后门上的表现存在差异（例如 Claude 系列在字符串模式匹配上更强，Gemini 在跨架构代码理解上可能有优势），可设计三层投票架构：任一模型标记为恶意即进入观察列表，两票以上确认则提高告警优先级，三票一致则自动生成工单。这一机制可将误报率从 28% 逐步降至可接受水平。
引入上下文约束提示：在向模型下达分析任务时，明确要求其验证数据来源的可达性。例如，不仅要求模型识别 system 调用，还要求其追踪该调用点的数据来源 —— 是否来自网络输入、配置文件、还是环境变量。这种强制性的污点追踪指令可以部分克服模型的 “理性化” 偏差。
建立反馈修正回路：将每次人工确认的检测结果（无论成功或失败）反馈给模型进行微调或上下文学习。随着时间推移，模型可逐渐习得特定项目（如同类二进制）的典型代码结构，降低误报率。
实践结论与局限性
当前 AI 驱动 Ghidra 逆向分析在约 40MB 二进制后门检测任务上的表现证明：模型已经具备 “从二进制中识别可疑模式” 的基础能力，顶流模型可接近 50% 的检测率。但距离生产环境可用仍有显著差距：28% 的误报率意味着每四份报告中近一份是虚假告警，而模型在面对伪装成合法功能的后门时的漏报问题同样严重。
从工程实践角度，AI 当前更适合作为人类逆向工程师的 “第一轮筛查器”：由模型完成粗粒度的可疑区域定位和初步判断，安全分析师在此基础上进行精细化复核。这种人机协作模式既利用了 AI 在大规模代码中快速筛选的能力，又保留了人类专家在语义理解上的优势。
需要承认的是，本基准测试中的后门由人工注入且未做深度混淆，真实攻击者可能采用更复杂的隐藏技术。此外，测试仅覆盖 C 与 Rust 二进制，未涉及 Go 等其他主流语言构建的二进制，这些局限性均会影响结论的泛化性。随着模型推理能力的持续提升和逆向工程工具链的成熟，AI 在二进制安全分析领域的实用价值有望进一步释放。
参考资料
- Quesma BinaryAudit 基准测试与完整评测结果：https://quesma.com/benchmarks/binaryaudit/
- BinaryAudit 任务集与评测代码：https://github.com/QuesmaOrg/BinaryAudit
- Quesma 博客原文《We hid backdoors in ~40MB binaries and asked AI + Ghidra to find them》：https://quesma.com/blog/introducing-binaryaudit/