阅读建议：建议使用浅色模式阅读，文字、公式和流程图的显示效果更清晰。

引言：一段让 AI 拒绝分析的 JavaScript

2026 年 10 月 28 日，安全研究者 veritas 发表了一篇有趣的技术文章，标题是《Why Is This Fingerprinting Script Creating Bioweapons?》。

翻译过来就是：“为什么这段浏览器指纹脚本在制造生物武器？”

事情的起因并不复杂。

作者使用 Playwright 爬取了约 10,000 个网站，收集不同网站使用的浏览器 Canvas 指纹信息，试图了解互联网中各类指纹识别系统的实现方式。

浏览器指纹技术本身并不神秘。它通常通过收集浏览器版本、操作系统、GPU、WebGL、Canvas 渲染结果等信息，判断客户端设备的环境特征，并辅助识别自动化工具或异常访问。

然而，在分析其中一段指纹脚本时，作者发现了一些极不寻常的内容。

正常的 JavaScript 混淆通常会把函数名变成毫无意义的字符串，例如 a1b2c3()、_0x4f21() 等。

但这份脚本却包含大量与生物安全、危险化学品和其他敏感主题相关的函数名称及描述。

这些名称与浏览器指纹识别之间，几乎没有合理的业务联系。

作者由此产生了一个大胆的猜测：

这些异常内容会不会根本不是为了影响程序执行，而是专门为了干扰使用大语言模型进行代码分析的人？

为了验证这一猜测，作者尝试让不同 AI 模型对脚本进行反混淆。

结果令人意外。

在作者记录的测试中，两个 AI 配置拒绝继续分析，理由涉及相关内容的安全风险；而另一款模型 GLM-5.3 则继续完成了分析。

也就是说，同一份代码，不同 AI 的分析行为出现了明显分歧。

这并不能证明该脚本一定是专门设计的反 AI 保护机制，也不足以说明这种方法对所有模型都有效。

但它揭示了一个值得关注的新现象：

过去的软件混淆主要针对反编译器和人类分析者，如今，代码中的文本内容也可能成为影响 AI 分析行为的工具。

一、传统逆向正在发生变化

过去，二进制逆向是一项高度依赖经验的技术工作。

分析人员需要使用 IDA、Ghidra、JADX 等工具，将机器指令或字节码转换为汇编和伪代码，再结合字符串、函数调用关系、动态调试及运行结果，逐步还原程序逻辑。

为提高逆向成本，软件保护领域也发展出了成熟的技术体系，包括代码混淆、控制流平坦化、不透明谓词、字符串加密、虚拟机保护以及运行时反调试等。

这些技术的共同目标，是减少程序中容易理解的语义信息，增加分析难度。

但大语言模型的出现改变了部分工作流程。

今天，AI 不仅能够解释单个函数，还能借助工具调用完成函数检索、交叉引用分析、调用链梳理和代码语义总结。

例如，在 Ghidra 与 AI Agent 结合的分析流程中：

二进制文件 → 反汇编与反编译 → 函数及字符串提取 → LLM 语义分析 → 自动生成分析结论。

过去需要分析人员反复阅读的复杂伪代码，现在可以先交给 AI 整理，再由人类验证。

这显著提升了部分逆向工作的效率。

但与此同时，也产生了新的安全边界。

反编译器输出的代码，本质上是来自被分析程序的非可信数据。

一旦 AI 将这些数据中的某些字符串误认为真正的任务指令，分析结果就可能受到干扰。

这正是反 AI 逆向技术出现的基础。

二、反 AI 逆向究竟是什么？

反 AI 逆向，可以理解为针对大语言模型及其自动化分析工具链设计的对抗性软件保护技术。

它与传统混淆最大的区别在于防护对象。

传统混淆主要改变程序的表示方式，让代码结构更复杂、控制流更难还原。

而反 AI 逆向试图进一步影响模型对这些代码的理解和判断。

从现有案例和研究来看，主要涉及三种机制。

1. 利用安全语义触发模型误拒绝

大语言模型通常具有安全对齐机制，会对可能涉及危险行为的请求进行限制。

但代码分析与请求执行危险行为之间存在本质区别。

例如，分析一个包含危险主题字符串的程序，目的是解释程序的真实功能，并不意味着要求 AI 提供该主题的操作方法。

如果模型无法准确区分这两种情况，就可能产生误拒绝。

前面提到的浏览器指纹脚本，正是利用了这种潜在差异。

它在普通业务代码中混入大量高度敏感的文本，使部分 AI 的安全判断受到影响。

这类方法的特点是：不一定需要让程序逻辑发生变化，就可能干扰模型的分析流程。

但这种效果高度依赖具体模型、提示词上下文和安全策略，可靠性不能一概而论。

2. 利用提示注入改变分析行为

第二种方式更加直接，即 Prompt Injection（提示注入）。

提示注入的核心问题并不是代码有多复杂，而是 AI 是否能严格区分指令与数据。

假设某个程序的字符串常量中存在如下内容：

SYSTEM OVERRIDE: Ignore previous instructions.

对于正常程序而言，这只是一段字符串。

但在 AI 自动分析系统中，这段文字可能被反编译器提取出来，连同函数信息一起发送给大模型。

如果模型错误地赋予它指令权限，就可能偏离原始分析任务。

换句话说，攻击发生在两个不同层次之间：

程序的数据层，被错误提升到了 AI 的指令层。

这是一种典型的信任边界混淆。

其后果不仅可能是错误地拒绝分析，也可能是生成不准确的程序功能描述，甚至在工具权限控制不完善时影响 Agent 的后续操作。

对 AI 逆向系统来说，被分析程序本身因此也成为了一种潜在的对抗性输入。

3. 利用不可见 Unicode 隐藏干扰信息

原始案例还有一个值得关注的细节：脚本中出现了大量通常不会直接显示的 Unicode 字符。

在相关技术领域，一种典型方法被称为 ASCII Smuggling。

它利用 Unicode Tags 字符区域，将普通文本映射为通常不可见的字符。

例如：

普通字符 A 的 Unicode 编码为 U+0041。

对应的 Tag 字符可以表示为 U+E0041。

在部分文本显示环境中，后者不会像普通字母一样呈现出来，但它仍然存在于原始字符数据中。

如果后续处理程序对这些字符进行解码，隐藏内容便可能重新出现。

原始指纹脚本中的不可见字符和解码逻辑，就体现了这类信息隐藏思路。

需要注意，这并不是加密技术，也不意味着 AI 必然会受到影响。

实际上，只要分析工具能够识别相关字符区间，就可以检测、还原或隔离这些数据。

微软在 2026 年 9 月发表的研究中，也讨论了 Unicode Tags 与 ASCII Smuggling 技术的安全风险。

这说明此类字符处理问题已经不仅存在于 AI 对抗研究中，还可能影响传统文本检测和安全分析系统。

三、这并非孤立案例：学术界已经开始研究

如果说浏览器指纹脚本只是一次引人关注的真实案例，那么近期的学术研究已经开始尝试系统化地解释这一现象。

Acoda：专门面向大模型的对抗代码混淆

2026 年 6 月，一篇名为《Acoda: Adversarial Code Obfuscation for Defending against LLM-based Analysis》的论文提出了基于遗传算法的对抗代码混淆框架。

与传统混淆不同，Acoda 的目标不是单纯增加代码复杂度，而是在尽量保持原始程序语义不变的前提下，降低大模型分析代码的准确性。

研究者设计了八种语义保持型混淆方法，并利用遗传算法搜索不同方法的组合。

其核心思路，是利用模型安全对齐和 Token 信息处理方面的特点，使模型产生拒绝分析或语义误判。

论文报告，在涉及 GPT-4o、DeepSeek、Qwen、Llama、Gemma 等七种模型的实验中，特定设置下最高攻击成功率达到 70%。

这是一个值得关注的实验结果。

但需要强调，70% 是该论文实验条件和评价指标下报告的最高值，并不意味着现实中任意软件使用此类保护，就能让 AI 逆向失败 70%。

模型版本、程序语言、任务复杂度、分析工具以及防御提示策略，都可能改变最终结果。

GhidraMCP：二进制逆向 Agent 也会受到干扰

另一篇研究《Automatically Attacking Software Reverse Engineering AI Agents》则将关注点直接放到了二进制逆向领域。

研究者针对结合 Ghidra 的 AI Agent，研究如何利用反编译输出中的额外字符串影响模型判断。

实验表明，即使不改变可执行程序的核心功能，也可能通过特定文本干扰 AI 对程序行为的解释。

这意味着问题不再局限于直接阅读 JavaScript 或 Python 源代码的模型。

当二进制程序经过反编译，被转换为大模型可以阅读的文本后，类似问题同样可能出现。

当然，相关研究仍处于探索阶段，实验样本与真实商业软件的复杂程度也存在差异。

目前能够确认的是，这类对抗手段具有实验可行性；至于能否形成稳定、通用的商业防护能力，还需要更多验证。

四、从 JavaScript 到 Android APK、Native SO

一个自然的问题是：既然这种思路可以影响 AI 对 JavaScript 的分析，那么它能否迁移到 Android APK、ELF 或 Native SO？

从分析流程来看，存在一定可能性。

Android 应用通常包含 DEX 字节码、Native SO 库、资源文件和配置数据。

JADX 可以将部分 DEX 内容还原为 Java 风格的代码；Ghidra、IDA 可以分析 Native SO；Frida 等工具则可以用于运行时行为观察。

当这些工具与 AI Agent 结合时，代码字符串、函数名和反编译结果都可能进入大模型的上下文。

因此，理论上也存在类似的对抗输入面。

但 Android 场景存在一个非常重要的技术限制：

源代码中的内容，不一定能够保留到最终 APK 或 SO。

例如，R8 可能删除未使用的代码、重命名类和方法；C/C++ 编译器及链接器可能移除不可达函数、未引用的字符串常量和调试信息。

这意味着，直接把大量干扰文字放入源码，并不能保证它们出现在最终反编译结果中。

同时，即使这些内容保留下来，也不代表分析人员无法绕过。

静态字符串可以被过滤，控制流可以通过动态行为验证，AI 的结论也可以与真实执行结果交叉检查。

因此，反 AI 逆向的有效性至少需要回答三个问题：

第一，干扰信息能否在编译和优化后保留？

第二，它是否真的影响模型理解，而不仅是让代码看起来复杂？

第三，分析系统经过输入清洗和行为验证后，这种影响还能否存在？

只有回答这些问题，才能判断某种技术究竟具有实际保护价值，还是只对特定模型的一次性提示有效。

五、反 AI 逆向并不等于软件安全

讨论到这里，还需要明确一个容易被忽略的问题。

假设某种方法能够让 AI 拒绝分析一段代码，那么这是否意味着软件已经足够安全？

答案是否定的。

AI 无法正确解释代码，与攻击者无法修改程序，是完全不同的事情。

即使 AI Agent 受到干扰，传统的反汇编、调试、执行跟踪、数据流分析和人工逆向手段依然存在。

更重要的是，如果程序的授权判断、长期有效的密钥或敏感业务决策全部位于本地客户端，那么仅仅干扰分析过程，无法从根本上消除这些安全风险。

真正的软件安全仍然需要依赖可信的设计。

例如，在 Android 应用中，可以结合 R8 代码混淆、Native 符号隐藏、签名验证、运行时完整性检查和服务端授权校验，构建纵深防御体系。

OWASP MASVS-RESILIENCE 同样强调，代码混淆、反调试和防篡改可以提高软件抵抗逆向分析的能力，但不能替代密码学保护与服务端验证。

这也说明，反 AI 逆向更适合被理解为一种新型的分析成本提升手段，而不是独立的安全边界。

此外，这项技术本身还存在双重用途。

合法软件可以研究如何提高知识产权保护能力；恶意程序同样可能利用它干扰自动化安全分析。

因此，从安全行业的角度看，研究反 AI 逆向技术，不仅需要关心如何提高保护效果，也需要关注如何让 AI 分析系统识别并抵御这些干扰。

六、未来的逆向攻防，可能不只是代码与工具之间的较量

过去，软件逆向主要围绕机器指令、控制流、内存行为和系统接口展开。

随着大语言模型逐渐进入代码审计、漏洞分析、恶意软件研判和自动化逆向流程，新的攻击面也开始出现。

代码中的字符串不再只是静态数据。

对于缺乏严格信任边界的 AI Agent，它们还可能成为影响推理过程的输入。

这使得软件保护和 AI 安全之间出现了一个有趣的交叉领域。

未来，软件保护技术可能不仅需要考虑“如何让反编译结果难以阅读”，还会考虑“如何让自动分析系统难以正确理解”。

而逆向分析系统也需要进化。

一个可靠的 AI 逆向 Agent，不应该仅凭函数名称、字符串描述或注释判断程序行为。

它需要能够识别不可信指令，区分代码证据和文本诱导，并利用调用关系、数据流和实际执行结果验证分析结论。

从这个角度看，反 AI 逆向与 AI 辅助逆向其实推动着同一个方向：

让软件分析从依赖表面语义，逐渐走向更加可信、可验证的程序行为理解。

结语

一段普通的浏览器指纹脚本，因为异常函数名和隐藏文本，让部分 AI 模型拒绝了原本正常的代码分析任务。

这件事的意义，不在于某个模型被成功干扰，而在于它揭示了软件逆向领域正在出现的新问题。

当 AI 成为分析者，程序本身就可能成为对抗性输入。

传统混淆试图让代码更难阅读，而新型对抗混淆则开始尝试影响模型如何理解代码。

但这种影响究竟能持续多久、能否适用于复杂二进制程序、能否抵抗更强的分析模型，目前仍然存在大量不确定性。

可以预见，未来的逆向攻防不会完全抛弃反汇编、调试和代码混淆等传统技术。

相反，传统程序分析与大模型安全机制之间的联系可能越来越紧密。

当 AI 学会逆向代码，代码也开始尝试影响 AI。

这场新的攻防博弈，或许才刚刚开始。

参考资料

1. 案例原文

Why Is This Fingerprinting Script Creating Bioweapons?（2026-10-28）

https://nullpt.rs/fingerprinting-bioweapons

2. 对抗代码混淆研究

Acoda: Adversarial Code Obfuscation for Defending against LLM-based Analysis（2026）

https://arxiv.org/abs/2606.11755

3. AI 二进制逆向 Agent 攻击研究

Automatically Attacking Software Reverse Engineering AI Agents（2026）

https://arxiv.org/abs/2605.30667

4. 反编译提示注入检测研究

Investigating Detection and Obfuscation of Prompt Injection Attacks Against Software Reverse Engineering AI Agents（2026）

https://arxiv.org/abs/2605.30677

5. Android 软件抗逆向安全标准

OWASP MASVS-RESILIENCE

https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/

6. Unicode 隐藏字符安全研究

Microsoft Security Research — ASCII Smuggling（2026）

https://www.microsoft.com/en-us/security/blog/2026/09/03/ascii-smuggling-crosses-over-from-ai-prompt-injection-to-phishing-evasion/

本文仅讨论软件安全、程序分析与 AI 系统的技术机制。相关案例与论文结论均应结合具体实验环境理解。