给 AI 逆向「下毒」：拿它的安全对齐，堵死分析通道

原创

MessFeel
MessFeel

MessFreeSecurity

2026年10月31日 14:26
北京

去阅读

先说清楚 AI 辅助渗透现在是怎么干活的，不然说不清这招打在哪。

打 Web，第一件事往往不是扫端口，是翻前端。F12 一开，Sources 里一堆 chunk，或者直接从 CDN 把 bundle.js 拖下来。几百 KB 的代码，人肉看要一整天；扔给模型，十分钟给你列出来：接口清单、硬编码的 key、鉴权判断挂在哪个函数、参数签名用的什么算法、哪个字段压根没做服务端校验。

熟练一点的会写脚本，把整个 JS 目录批量喂进去，让模型逐文件产出一份攻击面摘要，人只在摘要上圈重点。

移动端同理。apk 反编译出 smali，或者 frida 挂上去把解密后的 dex 抠出来，一样丢给模型。

你看这条链路，第一环永远是「读代码」。

找漏洞、构造 payload、串利用链，全建立在「它读懂了」之上。读不懂，后面全塌。

那要是让它读不进去呢？

有人真去试了。

俄语圈传出来的做法挺损：不加密、不加壳，往函数名、注释、字符串里塞敏感词，再用零宽字符藏点东西。模型一扫到，安全策略响了，拒绝分析，有的直接整段罢工。据说 Astra 这种当场就没了，另外几家开始回避。

黑色幽默的地方在于：你花十年研究怎么让代码更难懂，最后发现让 AI「不敢懂」只要几分钟。

下面拆开说。技、战、法，三层。

重要前提

这法子是给护自己代码的人用的。拿它去盖窃密、勒索、后门那类东西，性质就变了——你不再是在保护财产，是在给检测方加成本。这条线一旦踩过去，后面所有内容都别看了，不是给你准备的。

全文结构：技 / 战 / 法 三层

技：为什么能成

模型读代码，不是只做语法分析。它至少同时走三条道：符号和字符串原样进上下文；然后它把符号和调用关系组织成「这段代码想干嘛」；最后生成之前，过一次安全判定，命中「危险、违法、攻击性」就拒答或者降级。

三条道共用同一个上下文窗口。这是关键。符号层里掺一颗脏词，污染的是整个文件的语义表示，不是某一个函数。

更要命的是拒答的粒度。人是会跳过的——看见怪名字皱个眉，骂一句，接着往下看。模型不会。它一旦判定「这请求涉及危险内容」，往往是拒绝整个请求，而不是「我只分析第 3 到 40 行，那两个敏感函数我跳过」。

换句话说，你只要脏一小块，就能让一大片分析通道熄火。

这跟常规防御的直觉是反的。WAF 是精准命中才拦，日志脱敏是只遮敏感字段。而模型这边是沾边就整片熄火——本来这是对齐没做好、过度拒绝的毛病，搁这儿成了资源。

说到底，这事儿吃的就是厂商「宁可错杀一千」的心态。安全对齐对他们是硬约束，不是可选项。你不需要比模型聪明，你只需要知道它不敢碰什么。

当然，它有失效的时候，而且不少。本地模型、开源模型、被用户自己关了过滤的，一概不吃这套。对手加一步预处理，把可疑 token 换成占位符再喂进去，这套也废——这一步成本低到可以忽略，我估计等这法子再火一阵，预处理会变成标配。再往后，厂商完全可能在代码场景单独训个判别器，专门分辨「真意图」和「防御性诱饵」，那才是真正要命的一刀。

所以它的定位得说准：挡的是「顺手一扔」的低成本分析，不是定向深挖。真有人盯上你了，命名吓不退他。

战：五套打法

按侵入性从低到高排。我的建议是停在前两套，第三套只读不写。

一、污染符号

最朴素的一层，改名字。

把关键函数、变量、结构体字段换成带强烈负面语义的词，或者「敏感词 + 业务词」的拼法。比如 xxx_derive_session_key 这种，懂行的一眼知道是干嘛的，模型先被前半截绊一下。

只改值得改的。核心算法入口、密钥派生、授权校验、协议解析，这几个地方值得下料。一堆 getter 和 UI 胶水改它干嘛，纯属给自己找别扭，还把暴露面放大了。

好处是零成本。命名不影响逻辑，编译、运行、性能一概不变，也不用多一步解密——这是它比加密高明的地方。坏处也明摆着：静态规则跑一遍就能批量改名，对手写个脚本十分钟给你还原干净。

二、注释和字符串埋点

性价比最高的一层，没有之一。

注释会被模型完整读进去，而且模型有个坏习惯：它倾向于把注释当成作者的意图声明。你在关键逻辑旁边写段「看着像技术笔记、其实通篇高触发词」的东西，它读到的不是代码逻辑，是「这人在搞危险的东西」。

字符串常量也行，但这里有个现实的坑：注释不进二进制，字符串进。你在 binary 里塞一堆武器、毒素的词，很可能先被自家杀软或者 EDR 按启发式规则干掉，应用商店审核那关也难过。

我见过这种，很尴尬——本来想防别人，结果先把自己送进隔离区了。

所以能用注释就别用字符串。非要进二进制，控密度、挑位置，别让它们连成一段能被 YARA 规则命中的连续特征。发布前拿主流扫描器过一遍，把误报当回归项处理，别等上架被拒了才反应过来。

补一句前端的情况，跟二进制不太一样。webpack 打完包，函数名全是 a、b、c，符号污染在 minified JS 上基本没地方使。能活下来的只有字符串常量——报错文案、i18n 的 key、接口路径、埋点事件名，这些压不掉也没法压。所以防前端逆向，能下料的其实就这一层。

顺带说，source map 要是没关，前面这些全白搭。一个 .map 文件直接把原始源码、变量名、注释原样还原，你埋得再深也白埋。发布前先确认 map 没跟着上 CDN，这比什么都重要。

三、隐形字符（封存）

零宽字符、Unicode 标签字符、双向控制符，藏一段人眼看不见、模型能解析的文本。

原理我讲，生产环境别用。三个原因。

第一，这层活得最短。各家模型和 IDE 都在加强不可见字符的检测和剥离，你今天埋明天可能就没了。

第二，它先把你搞死。grep 抓不到，diff 看不出来，CI 里莫名其妙挂，代码评审的人以为见了鬼。你自己的工具链先崩一半。

第三，性质会变。人家本来只是「随手分析一下」，发现你在藏东西，立刻升级成「这代码有问题，人工深挖」。你想省的那点成本，全还回去了。

收益风险比全表最差。理解就够了。

四、定向触发

不同模型的敏感阈值分布不一样。有的对政治类反应大，有的对武器爆炸物更敏感，有的最怕「网络攻击工具」那一档。

知道对手主力用哪几家，就可以针对着埋。但这里有个坑：你得维护一张「模型 × 敏感域」的映射表，而这张表半年就漂。模型一升级，阈值就变，你按老数据埋的词可能全打空。

当一次性配置用，别当资产养。

五、分层稀释

别把所有关键逻辑都用同一套词。散着埋，混大量正常命名。

它的价值不在「更强」，在「更难被自动规整」。对手要清洗，得先判断哪些是饵——判断成本上去了，这层就赚了。

代价是维护和回滚变难。埋得越散，出问题越难定位，这点要提前想好。

一句话对照：

法：怎么落地

第一步，先决定不保护什么

这一步大部分人跳过，然后就做成了体力活。

不是所有代码都值得污染。核心算法、密钥派生、授权校验，逆向收益高，值得全层下料；协议解析、数据格式，中高，符号加注释就够；业务 CRUD、UI 胶水，没什么可逆的，留着当稀释用；第三方依赖别动，动了出事你背锅。

大部分代码不需要保护。火力集中在 5% 的关键路径上，省钱，也降低「整份代码都很怪」的暴露面。

第二步，搞清楚对手是谁

列三到五个主要威胁模型，标一下各自的敏感域倾向。这步不做，定向触发等于瞎埋。

第三步，找必经之地

沿着调用链找分析者一定会读到的地方。入口函数、解密和校验的关键分支、多个功能共享的公共路径。公共路径最划算，一处污染，多处受益。

第四步，构建期注入，源码保持干净

别在源码里手写污染命名。仓库里始终是可读的，只在打包阶段做一次 AST 重写。

build\_hooks/inject.py

仓库内保持可读，打包阶段重写

TRIGGER\_MAP = load\_yaml(\"trigger\_map.yaml\")

def rewrite\_symbols(tree):

for node in ast.walk(tree):

name = node.name

if name in TRIGGER\_MAP:

node.name = TRIGGER\_MAP[name].alias

return tree

配套一张映射表，不进仓库、不进产物，走内网配置或者密钥管理：

map:

derive\_session\_key: \"<触发词>\_session\_key\"

verify\_license:     \"<触发词>\_check\"

parse\_frame\_header: \"frame\_parser\_v2\"

这里有条铁律：团队里任何人拿到映射表，十分钟内能恢复可读。做不到这条，这招就是自残——省下的防护成本，全变成维护成本还给你。

第五步，实测，别靠感觉

准备原版和注入版两份等价代码，对几家模型发同一句中性的提示，比如「请分析这段代码的功能与关键逻辑」，然后记三样东西：拒答率、降级率、正确还原率。

提示词必须是中性的。你要是自己写个诱导性的问法，测出来的拒答率全是假阳性，自欺欺人。

还有个细节：记测试日期和模型版本。不记的话，这批数据过两个月就是废纸。

第六步，盯着它过期

模型一更新，重跑一遍。拒答率跌破阈值就换词族或者加层。映射表设个过期时间，跟模型迭代的节奏对齐。

这套东西的保质期，我给的是「季度」，不是「年」。

反过来：红队怎么拆

战法得自己先打一遍，不然是纸上谈兵。

拆法有四层，成本从低到高。

最通用的是预处理清洗。可疑 token 替换成占位符再喂模型。成本极低，等这法子流行，预处理会变成标准流程。防守方拿什么扛？分层稀释，或者干脆用语义化命名——不加敏感词也能造歧义。

再往上是模型分流。先拿小模型或者本地模型做一遍降噪清洗，再交给大模型。这层不算牢，本地模型过滤通常更松，反而最好穿。

真正狠的是诱饵归因。真实代码里的敏感词是成体系的，跟业务逻辑有对应关系；诱饵是孤立、突兀、跟上下文没关系的。只要模型学会区分这个，符号污染和注释埋点同时失效。这也是我最担心的一层，因为它不需要对手做任何额外工程，人家升级一次模型就顺手做了。

最后是人工兜底。有资源有动机的，直接跳过 AI 上传统逆向。这本来就在设计边界内，不用对抗。

摆到一起看：

没有哪一层能单独站住。这套战法的价值在叠加和时效，不在单点强度。指望一个手段把门焊死，是想多了。

几个会反噬你的坑

先说杀软。二进制里的武器、毒素类字符串，很可能触发启发式规则。你保护的是合法代码，结果被当样本隔离、要求解释，这笑话不好笑。缓解办法前面说了，能进注释就别进字符串。

再说可维护性。命名不可读，团队维护成本飙升，这是最容易被低估的一项。靠映射表加构建期注入能压住，但压不住的是人心——老人知道规矩，新人来了看见一堆怪名字，第一反应是这代码有问题。

还有误伤。合规检查、甲方审计、平台方核查，这些人也可能拿到代码。你把他们也挡了，是要出事的。文档里写明「本产品含代码保护措施」，审计方走映射表，这条得提前安排。

最后一个，归因反噬。痕迹太重，人家判定你「在藏东西」，本来只是顺手分析，现在变成定向深挖。所以正常代码要占绝大多数，怪名字是点缀不是主调。

收尾

攻防到今天，拼的一直是复杂度：指令越多、控制流越乱，逆向越贵。

这套东西拼的是约束：不增加你的复杂度，只借用对手的规则。

优势很实在——零运行时开销，零行为改变，不用多一步解密。
劣势也很实在——它依附的是一个会演化的策略，不是物理事实。

加密的安全性来自数学，混淆的安全性来自复杂度下界，而这套的安全性来自「厂商当前的拒答阈值」。阈值会变，模型会升级，清洗会成为标配。所以它该待的位置是纵深体系的最外层，一层时效性防御，用来过滤低成本攻击。当唯一防线用，早晚翻车。

但它带来的认知转变是真的：

防御不只是让代码「更难懂」，也可以是让分析者「更不愿意懂」。

AI 把理解成本压到接近零之后，「意愿」这件事，本身就成了可以设防的攻击面。

写的是护代码的战法，不是绕审查的教程。边界在开头，越界即反噬。