ALIBI 论文：二进制内的虚假叙述可误导 LLM 分析

当天发生了什么

2026-09-17 05:27（UTC），Hyeongjun Choi 等作者在 arXiv 提交了 ALIBI（2609.19722）的 v1，归类为 cs.CR 与 cs.LG。论文研究的是被接入恶意软件分诊流程的大语言模型。作者在已编译的二进制末尾追加一个很小、只读、不会执行的数据段，里面是一段看似合理但虚假的「安全产品」叙述；导入表和实际执行行为都不变。它并不直接给模型下指令，而是把可疑证据包装成良性安全工具的正常行为。摘要报告：在 50 个恶意 PE 样本中，Gemini 2.5 Pro 原本判为恶意的 35 个里有 30 个被翻转为良性；GPT-5.5 Pro 与 Claude Opus 4.7 的标签多数未变，但严重程度和置信度明显下降；在 ELF 样本上，Gemini 有 16/40 被翻转。加入验证导向的防御提示后，良性判定约减少一半，但仍有 42.9% 的恶意样本被判为良性。

对开发者威胁模型的含义

这篇论文研究的是恶意软件分诊，不是应用克隆，但对开发者有两点直接启示。其一，越来越多团队用 LLM 帮忙审查第三方 SDK、依赖包，甚至自己的发布产物。论文说明，二进制中的描述性文本属于可被操纵的输入，模型可能把「文件自称是什么」当成证据。其二，有人可能想反过来，在自己的应用里塞入误导性说明来干扰 AI 辅助分析。我们不建议这样做：论文没有评估这种用法；这种手法本身与论文中的恶意样本相似，可能导致应用被安全产品误报；而且面对能读取导入表和行为证据的分析者，它也不构成可靠的保护。作者的结论是需要来源核验，把已验证的事实与样本自带的说法区分开。

可以落实的检查

如果你用 LLM 辅助审查第三方组件或自己的构建：第一，要求每条结论都对应可核验的事实，例如签名、哈希、导入符号、网络行为，而不是二进制里的描述文字；第二，保留非 LLM 的基线流程，例如签名校验、SBOM 比对和已知漏洞扫描，并把 LLM 输出当作线索，而不是裁决；第三，在报告中标注哪些判断来自工具输出、哪些来自模型推理，便于事后追溯。对自己的发布包，也应定期清点其中包含的字符串和资源，确认没有夹带内部说明、调试文本或不应公开的描述。

行动清单

• 要求 LLM 审查结论对应签名、哈希、导入等可核验事实
• 保留签名校验、SBOM 与漏洞扫描等非 LLM 基线
• 定期清点发布包内的字符串与资源，移除内部说明