「听说有了 AI 什么都挡不住了」— 这其实是两个问题
最近谈安全，AI 总要被提到。作弊制作被自动化、逆向工程变快、现有防御没用了——这些说法混在一起流传。
其中一部分是真的，一部分被夸大了。混在一起就会导致误判：要么出于恐惧把钱花在不需要的地方，要么当成炒作而错过真正发生变化的部分。
所以把问题拆成两个来看。
- 实际发生变化的是什么
- 没有发生变化的是什么
第二个更重要。没变的东西，正是现在依然值得投入的地方。
本文讨论整体变化与应对方向。AI 在 IL2CPP 逆向的哪些环节起到加速作用、检测日志该如何分析，各自是另外的主题。
实际变了的：入门门槛
最准确的说法是：AI 并没有让作弊变得「可能」，它只是降低了原本就可能的事情的门槛。
以前读内存结构、解读反编译代码、编写挂钩代码，都需要相当的熟练度。这份熟练度就是把人数筛下来的那道墙。
现在这些工作的很大一部分可以借助工具完成。随之改变的有三点。
- 尝试的人变多 —— 只需要意愿而不需要能力的区间变宽了
- 变种出得更快 —— 堵掉一个，稍作修改的版本很快就来
- 从上线到第一个作弊出现的时间被压缩 —— 准备期变短了
概括起来，变的不是攻击的难度，而是频率和速度。 这个区分是本文的核心。
没变的：层与层之间的成本差
这里常出现一个错误推论：「AI 既然能帮着分析，那原生层的保护是不是也没意义了？」
并非如此。因为 AI 在每一层的帮助大致是均等的。
读托管代码变快了，分析原生二进制也变快了。两边都变快，两者之间的相对成本差就原样保留。 如果处理原生层原本就比托管层更难，现在依然更难。
打个比方，就像所有人都换上了更快的车。通行时间缩短了，但近处与远处之间的距离差没有变。
所以，「AI 让分层防御失去意义」这个结论并不成立。 恰恰相反，变种出得越便宜，逐个去抓变种的做法就越不划算，而在结构上先把成本抬高的做法价值越高。
没变的：服务端判定
有一个领域 AI 完全够不着：客户端向服务端说谎这件事。
无论工具多精巧，只要服务端自己在计算货币余额，客户端声称「金币 999,999」就毫无意义。这个声称不会被采信，会被直接丢弃。
这不是工具性能的问题，而是判定权位于何处的问题，所以攻击方技术再怎么进步都不会改变。
于是就出现了一个反直觉的结论：在 AI 时代相对价值上升最多的投入，是服务端判定的边界。 它不炫目，不是新技术，是好几年来一直重复的老建议——却是唯一不会动摇的那一点。
那么该调整什么 — 五件事
直接由上面的区分推导而来。既然变的是频率与速度，要调整的也是频率与速度这一侧。
1. 不要押在单一特征上
抓住某个作弊工具的某一个特征，这种做法在变种变便宜之后寿命会越来越短。稍作修改的版本不断出现，就得次次跟进，而这场竞赛不是「赢」，是「追」。
最好同时保留一条从行为或结果出发的判断轴。不管用的是什么工具，只要结果上移动速度异常，这个事实仍然存在。作弊的类型划分整理在Unity 游戏作弊与外挂类型总览。
2. 把层往下放
如前所述，层与层之间的成本差是保留的。如果校验逻辑与它所保护的对象处在同一个地方，攻击者就能把数值和校验代码当作同一件事来处理。把校验放到下面一层，那就变成了另一件事。
IL2CPP 构建实际上能被还原到什么程度，在IL2CPP 真的安全吗里讲过。
3. 扩大服务端判定的边界
从「被操控会影响其他玩家或收入」的数值开始迁移。这不是说要全部搬走，而是说要重新看看这条线该画在哪里。 这并不是因为 AI 才新增的措施，而是原本最稳妥的措施，其相对价值上升了。
4. 抬高关掉检测的成本
比起增加检测项，让检测本身更难被无效化，对变种更有抵抗力。检测项可以被逐个绕过，但关掉检测层本身，每一次都是同等难度的工作。
5. 缩短观测与响应的周期
既然从上线到第一个作弊的时间被压缩，响应周期也要跟上。按季度检查一次的做法追不上。
这里需要的不是更强的阻断，而是更快的察觉。如果看不到什么时候开始、发生了多少，连响应都无从谈起。日志该怎么设计、怎么读，是另外的主题。
防御这一侧同样在用 AI
只谈攻击方只说了一半。同样的工具，防御方也在用。
它尤其适合寻找模式。要从海量正常游玩记录里挑出异常的走向，靠人眼是很难做到的。
不过有两点要说清楚。
- 数据先行。 没有积累可供分析的记录，工具也无事可做。顺序是观测体系在前，分析的精细化在后。
- 必须能说明判断依据。 如果说不出这个账号为什么被判中，就没法处理误报，也没法回应申诉。
听到「基于 AI」这样的说明时，要问的问题只有一个：它以什么为输入，判断什么。 如果这个答案不清晰，很可能只是销售话术。比较接入方式的标准，整理在自研与商用 SDK 的比较。
检查清单
设计
- 检测没有只依赖某个工具的单一特征。
- 校验逻辑与它保护的对象处在不同的层。
- 被操控会造成扩散性损害的数值，最终判定在服务端。
运营
- 正在积累能看出「什么时候开始发生了什么」的记录。
- 响应周期短于季度。
- 检测结果可以由人解释清楚。
判断
- 听到「基于 AI」时，确认过它的输入与判断依据。
- 检查过出现变种时是否必须每次单独应对。
OZero Security 负责的范围与不负责的范围
不负责的范围
- 我们不会把 AI 制作的作弊单独区分出来抓。 我们的检测看的是运行环境与完整性状态，而不是这个工具由什么写成。无论是 AI 生成还是手写，只要二进制被篡改或有调试器附加，都会产生同样的信号。
- 服务端判定的边界与游戏设计不归我们负责。
负责的范围
- 在与 C# 脚本分离的 Native C++ 核心中执行检测与完整性校验，对应上面的第 2、4 项。
- 识别可执行文件的二进制篡改、调试器附加与挂钩，以及模拟器、Root 等非可信运行环境，提高绕过难度。
- 在原生层通过交叉校验检测内存篡改与游戏速度操控的尝试。
- 接入 Pro Add-on 后，收集可疑客户端的遥测数据，支持在后台按运营策略处置——对应上面第 5 项的「更快的察觉」。
还有一点要讲明白：我们也不会因为进入了 AI 时代就拿出什么新魔法。 我们做的事和以前一样。只是在变种廉价涌现的环境里，把层往下放，比逐个应对变种更有相对优势。
结论：变的是速度，没变的是结构
归纳一下：
| AI 带来的变化 | 保持不变 | |
|---|---|---|
| 攻击 | 尝试的人数、变种速度、到第一个作弊的时间 | 每一层所需工作的性质 |
| 防御 | 响应周期必须缩短 | 层间成本差、服务端判定的价值 |
所以应对之道也不在于引入新技术，而在于把原本就有效的事情，用更快的周期跑起来。结论不算有趣，但更接近事实。
在寻找应对新威胁的办法之前，不妨先确认一下：当前结构里，本该由服务端判定的数值是不是还留在客户端。即便到了 AI 时代，这依然是最稳妥的第一步。