关于我最开始的一篇文章，我想补齐这一个细节就是我描述了一种不碰jsc

 更高级的Native so 作弊方式 有些人甚至并不相信 那我就告诉你，我是如何做到的

从一个 0.001 说起：Cocos 游戏里的 XA 内存到底是什么

挺有意思的。

我在 GG 里面看 libcocos2djs.so 的 Xa 区域，搜到了一个 0.001。这个数看起来很普通，改成 0.005 之后，游戏里的动作却明显快了起来，体感差不多就是五倍加速。

很多人看到这里，第一反应可能是：这是不是改了某个角色的速度？或者是改了某个技能的参数？但从实际表现来看，它更像是改到了引擎层的时间参数。

先说截图里这个数的类型。这里选的是 Double，不是普通的整数。Double 可以理解成双精度小数，内存里占 8 个字节，常用来保存时间、间隔、速度、倍率、坐标这一类带小数的数据。GG 里显示的范围从负的 1.8e+308 到正的 1.8e+308，也正是 Double 的大致表示范围。

所以，截图里的 0.001 并不是一段文本，也不是屏幕上看到的字符串，而是按照 Double 格式放在内存里的一个数。

当然，搜到 0.001，也不能说明游戏里只有这一个 0.001。动画、物理、计时、配置参数里都可能有相同的值。真正有用的，得是那个正在被引擎读取、而且确实参与了当前计算的地址。其他相同的数值，改了可能一点反应都没有。

那为什么改成 0.005 之后会加速？一种很容易理解的情况是，这个值参与了时间步长的计算。

比如游戏每次更新时，内部会增加 0.001 的时间。现在它被改成了 0.005，程序并不知道这个值已经被动过，仍然按照原来的代码往下算。这样同样过了一秒，游戏内部累计的时间就可能比原来多很多，动画、移动、攻击间隔、技能冷却等功能自然都会出现异常。

这里不一定是“整个游戏真的跑了五倍帧率”，也可能是游戏内部认为时间走得更快了。玩家最后看到的都是加速效果，但底层原因可能是时间步长、更新间隔、速度系数，或者其他类似参数发生了变化。

这类修改和直接改角色属性不太一样。它不是把某个角色的速度从 100 改成 500，而是动了引擎给游戏提供的时间。游戏逻辑本身可能一行都没改，但它拿到的时间已经不正常了，所以后面的动作都会跟着变。

这也就是我觉得这种方式比较值得讨论的原因：它不是针对某个角色、某个技能、某一段 JavaScript 逻辑，而是从更底层的引擎入手。简单说，就是“改引擎，让游戏跟着引擎走”。

现在大部分人分析这种 JS 游戏，通常都会先想办法解密 jsc。这个思路没错，jsc 里面比较容易看到游戏脚本、函数和变量，找到了以后也更容易理解游戏逻辑。问题是，游戏一更新，脚本内容可能变化，函数位置可能变化，之前找到的地址和特征也可能失效。

而如果改的是引擎层的公共逻辑，情况就不完全一样了。只要游戏这一版本仍然使用相同的时间管理方式，修改引擎里的公共参数，就可能同时影响大量功能。它不需要一个个去找角色，也不需要分别改每个技能。

这不代表所有 JS 游戏都能这么改，也不能看到 Xa 就说那里一定有加速。Xa 只是 GG 对一类可执行内存区域的标记。截图里还能看到 libcocos2djs.so 的路径，说明这部分地址和 Cocos 的 Native 模块有关，但仅凭这个标签，还不能直接判断它到底是代码、常量，还是运行时数据。

它可能是 Native 指令里用到的浮点参数，也可能是引擎运行时保存的公共变量。只有把地址对应的内存映射、实际机器码和调用过程结合起来看，才能知道它究竟是什么。单凭“改了以后有效”，最多只能说明这个位置参与了某个功能，不能马上给它下结论。

另外一个现象是，把某个 10000 改成 1 以后，人物出现了几个亿的伤害，甚至无敌、秒杀。

这个 10000 也不能直接叫作“伤害值”。它可能是倍率，也可能是除数、上限、缩放系数，或者是某个公共计算流程里的参数。比如一个计算过程里原本要除以 10000，改成 1 以后，结果就会被放大很多；如果它是某个边界值，改小以后，也可能让判定逻辑直接失效。

之所以会出现所有角色都受影响，很可能是因为它处在一个公共的伤害处理路径上。所有角色的伤害最后都要经过同一个地方，于是只改一个值，就能看到全局效果。这和修改某个角色自己的属性，思路完全不同。

所以，无敌、秒杀和超高伤害不一定来自 jsc 里的某个技能函数。脚本层只是上层逻辑，真正执行时，很多调用还是会进入 libcocos2djs.so。只要客户端把关键计算放在 Native 层完成，运行时就可能暴露出可以被修改的代码或数据。

老练一点的分析者，往往不会只盯着 jsc 里能不能找到函数。他们会先观察哪个运行时位置改了以后确实有效，再考虑怎么把这个效果固定下来。游戏更新以后，脚本里的固定位置可能变了，但引擎层某些公共逻辑未必马上改变，这也是为什么有人会更关注 Native 运行时。

在实际外挂里，人工找到效果之后，还可能把修改封装成一个开关，用悬浮界面控制打开和关闭。这样原本一次临时测试，就变成了可以重复使用的功能。这里不展开具体工具操作，但从防守角度来说，确实不能只检查“有没有人解密 jsc”，还要考虑运行时内存、引擎时间、异常控制流，以及战斗结果本身。

这类方式之所以看起来更高级，主要不是因为它有什么神秘技巧，而是它修改的位置更靠下，影响范围也可能更大。改脚本，通常是改某一个功能；改引擎，则可能让依赖这个引擎时间或计算结果的功能一起异常。

不过，“更通用”也不是绝对的。不同 Cocos 版本、不同架构、不同编译方式，地址和实现都会变化。这个版本能改，不代表下个版本还能直接照搬。服务端如果会重新计算伤害、速度和冷却，单纯修改客户端引擎，最后也未必能真正改变服务器认可的结果。

从防护角度看，最根本的问题其实不是 jsc 有没有加密，而是客户端是不是拥有了太多决定权。如果伤害、速度、奖励和战斗结果都由客户端算完以后直接告诉服务器，那么攻击者从脚本层改也好，从 Native 层改也好，都可能把异常结果提交上去。

比较稳妥的做法，是让服务器自己维护时间线和关键状态。客户端可以负责显示加速后的动画，但攻击间隔、伤害数值、冷却时间和奖励结果，不能只听客户端的一面之词。客户端运行时的异常修改，也可以作为一个风险信号，但不应该单独依赖某一个 Xa 地址来判断。

回到这次的两个现象：0.001 改成 0.005 后加速，说明它很可能参与了某种统一的时间或速度计算；10000 改成 1 后出现无敌和秒杀，说明它可能处在公共的伤害、倍率或边界处理路径上。

这两个现象共同说明了一件事：很多人以为只要把 jsc 加密起来，别人看不懂脚本，游戏就安全了。其实脚本最后还是要交给引擎执行，关键数据也还是要进入运行时。只要客户端负责了关键结果，运行时就存在被观察和修改的可能。

说到底，改的不是一个角色，也不只是一个技能。改 0.001 的时候，动的是游戏理解时间的方式；改 10000 的时候，动的可能是整个战斗系统共用的计算参数。

普通做法是去找游戏逻辑，老练一点的做法是去看游戏逻辑依赖的引擎。前者是在改游戏，后者是在改游戏运行的尺子。尺子一旦不准，后面所有依赖它的结果都会跟着偏。

所以最终计算libcocos2djs.so 0x182DAA8是加速地址 伤害同理

作弊者会通过lgl等开源作弊菜单进行修改来达到开关作弊效果

我们发现此办法修改后几乎可以逃逸所有反作弊模块 时间加速检测 属于一种更高级的通用办法

更有甚libcocos2djs.so libcocoslua.so相关的游戏他在已有检测的情况下甚至会把这种修改后表达出来的伤害列入合规状态，逃避检测

如果你本地写的检测也走这一个链条呢？那么你检测伤害最高不要超过100万，那么是不是变成了1万倍的上限？如果你的其他参数也在这个链条当中呢？比如648的支付不会变成1万倍？那么改大之后会不会变得合法呢？变成了0.1支付？这不是焦虑，这是我们要讨论的地点

我们也不希望你拿着这些东西去做不好的事,我们发现看雪上的小伙伴们更喜欢攻击侧方面的，我们不想去长期的去表达这种行为 在后续文章当中我们会更基于如何防护？防护链条构成去体系化反制作弊的手段 在通用场景下，我们如何全链路打击作弊场景

而金丝雀团队针对此类篡改作弊行为 已有相关对应方案 当此类so地址 被恶意篡改时 将会立刻触发破坏 终止游戏运行

并且覆盖通用引擎 游戏热更新将会自动走降级 但不会影响到检测 该数据链条是否被修改 仍可被检测

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！