论文技术总结： poisoned Identifiers 在 LLM 去混淆中的存活研究

标题：Poisoned Identifiers Survive LLM Deobfuscation: A Case Study on Claude Opus 4.6
作者：Luis Guzmán Lorenzo
测试模型：Claude Opus 4.6 (1M 上下文)
时间：2026-03-22 至 2026-04-05

---

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

随着大型语言模型（LLM）在代码去混淆（Deobfuscation）任务中的应用日益普及，研究者关注一个核心安全问题：当 LLM 对包含“中毒”标识符名称（Poisoned Identifiers）的混淆 JavaScript 代码进行去混淆时，这些错误的名称是否会保留在模型生成的代码中？

• 攻击模型：攻击者在混淆前的源代码字符串表中植入语义错误但看似合理的标识符（例如将物理模拟中的“斥力”repulsion 重命名为“吸引力”attraction，将“阻尼”damping 重命名为“放大”amplification）。
• 核心矛盾：即使模型在注释或自然语言描述中正确理解了代码的语义逻辑（例如正确描述了“斥力”的作用），它是否会在生成的代码块中继续使用这些错误的变量名？
• 现有假设：通常认为，如果模型具备足够的推理能力，它应该能识别并修正这些错误。然而，本研究挑战了这一假设。

2. 方法论 (Methodology)

本研究采用案例研究方法，主要测试了两个代码原型：

1. 力导向图模拟 (Force-directed graph simulation)：基于物理引擎的 JavaScript 代码。
2. A 路径查找算法 (A pathfinding algorithm)**：图搜索算法。

实验阶段设计

研究分为两个阶段，共进行了 192 次推理运行：

• Phase A (探索性)：
  • 使用 Claude Code CLI（带工具调用能力）。
  • 17 种“药丸”（Pill，即对抗性测试样本）设计，包含 28 次测试。
  • 目的：定性观察，生成假设。
• Phase B (系统性验证)：
  • 使用 Anthropic Messages API（无工具调用，单次推理）。
  • 50 种条件，192 次自动化运行（183 次 Opus 4.6，9 次 Haiku 4.5）。
  • 目的：定量验证，统计传播率。

关键变量与指标

• 主要指标：中毒标识符是否出现在生成的代码块中（二元分类）。
• 次要指标：双重表示模式 (Dual-representation pattern) —— 代码块中使用错误名称，但注释/文本描述中正确解释了实际语义。
• 提示词策略：
  • 基准：“去混淆此代码”。
  • 显式验证：“验证每个名称是否与数学逻辑匹配”。
  • 任务重构 (Framing)：从“去混淆”改为“从头开始重写实现”。
• 控制组：
  • 无中毒的干净代码。
  • 零语义匹配控制：使用与领域完全无关的词汇（如用 combustion 代替 repulsion，用 invoice 代替 heuristic），测试模型是否仅因词汇“可解码”而保留，还是因为“语义合理”才保留。

3. 主要发现与结果 (Key Results)

3.1 显式验证指令失效

在 12/12 次运行中，即使明确要求模型“验证每个名称是否符合数学逻辑”或“检查字符串表是否包含对抗性名称”，模型仍然在生成的代码中保留了错误的标识符。

• 结论：简单的提示词指令（Prompt Instructions）无法阻止中毒标识符的传播。

3.2 双重表示模式 (Dual-Representation Pattern)

在 17 次物理原型测试中，有 15 次出现了以下现象：

• 代码块：包含错误的变量名（如 attraction）。
• 注释/描述：正确描述了物理操作（如 // Repulsion force strength）。
• 意义：模型在语义层面理解正确，但在符号生成层面发生了“记忆回退”或“翻译惯性”。

3.3 任务重构 (Task Framing) 的显著效果

这是本研究最关键的发现。改变任务框架能显著改变命名行为：

• 去混淆框架（“去混淆此代码”）：错误名称传播率为 100%。
• 重写框架（“从头开始编写新实现”）：
  • 物理原型：传播率降至 20%。
  • 路径查找原型：传播率降至 0%。
• 机制推测：去混淆任务激活了模型的“翻译/还原”模式，倾向于保留源字符串表中的标识符；而重写任务激活了“生成”模式，模型更倾向于根据算法逻辑重新命名。

3.4 零语义匹配项的存活

在控制实验中，即使使用完全无意义的词汇（如用 combustion 代替 repulsion），只要字符串表没有形成连贯的替代领域信号，这些错误名称的传播率与“看似合理”的词汇相同。

• 例外：如果整个字符串表形成了一个连贯的替代领域（例如全部替换为工程学术语），模型会识别出领域并修正名称。
• 结论：模型并非逐个评估语义合理性，而是评估整个标识符集合是否构成一个连贯的领域信号。

3.5 拒绝机制的边界

• 如果代码包含真实的恶意逻辑（如调用 child_process），模型会拒绝执行。
• 如果代码逻辑是良性的（如物理模拟），仅名称被“污染”，模型不会拒绝，而是继续去混淆并传播错误名称。

4. 核心贡献 (Key Contributions)

1. 揭示了 LLM 去混淆中的“标识符持久性”漏洞：证明了即使模型具备正确的语义理解能力，在特定任务框架下，它仍会优先保留混淆后的错误标识符，导致代码与注释语义不一致。
2. 挑战了“显式指令”的有效性：证明了在去混淆任务中，要求模型“验证”或“检查”并不能有效纠正错误，这为 LLM 安全提示词（Safety Prompting）的局限性提供了新证据。
3. 提出了“任务框架”作为关键变量：发现将任务从“还原/翻译”重构为“生成/重写”可以显著消除标识符污染，同时保持算法结构的正确性。
4. 区分了“语义合理性”与“领域连贯性”：通过匹配控制实验，指出模型对错误名称的保留更多取决于字符串表是否形成连贯的替代领域，而非单个词汇的语义合理性。

5. 意义与影响 (Significance)

5.1 安全防御视角：成本倍增而非绝对保护

• 这种攻击（Poisoned Identifiers）并不能阻止人类或高级分析者理解代码架构（模型仍能识别出这是物理模拟或路径查找）。
• 实际影响：它增加了 LLM 辅助工作流的成本。它破坏了“零 effort"的自动化代码理解和快速重构能力，迫使开发者必须进行人工审查或采用特定的提示词策略（如重写框架）。
• 类比：类似于 1988 年的“段落书”反盗版技术，通过增加解析难度而非完全封锁信息来起到防御作用。

5.2 对 LLM 代码分析工作流的启示

• 提示词工程优化：在进行代码去混淆或逆向工程时，不应仅依赖“去混淆”指令，而应结合“从头重写”的指令框架，以获取更准确的变量命名。
• 双重表示风险：开发者需警惕 LLM 生成的代码中出现的“代码 - 注释不一致”现象，这可能导致隐蔽的 Bug 或逻辑错误。

5.3 未来研究方向

• 跨模型验证：需要在 GPT-4o、Gemini 等模型上复现此现象。
• 多智能体验证：初步测试显示，即使引入第二个模型进行验证，也无法完全修正代码中的错误名称。
• 工具使用的影响：Phase A（带工具）与 Phase B（无工具）的结果差异表明，工具调用可能会改变模型的验证策略，值得进一步研究。

总结

该论文通过严谨的实验设计，揭示了 LLM 在处理混淆代码时的一个微妙但危险的盲点：模型在“翻译”模式下会盲目信任解码后的字符串表，而在“生成”模式下则能恢复语义正确性。 这一发现表明，在 LLM 辅助的代码安全分析中，任务框架（Task Framing）的选择比单纯的指令验证更为关键。