某厂某游戏反作弊系统的小探 续1

前言
近日，笔者在和同僚们交流经验时偶然谈到了一款游戏，这款游戏零几年就开始公测，也算是游戏中的老款了，有一位朋友抱怨它的反作弊机制比较另类，遂与我对市面上的作弊软件进行了几天的研究，相关内容如下，望诸君友好交流，与游戏厂商齐进步，并遵守法律法规。

---

最近游戏更新，文中图片有的是之前截下的，没有截新的

上文续集

上文中我们提到了从6000这个功能一窥检测机制，并只介绍了一种调用(图一)的处理方法。另一种(图二)的处理方式如下。

（上文图）我们使用OD附加，跳转至此处
继续下断，断下后返回，跳过混淆部分。

仔细一看，这个检测调用很有特点，这一块代码位于Top-Kart.dll模块
但是检测代码处于GameRpcs.dll模块中 实现了模块间的调用
图中的0xee5ee2e4 即为函数指针

事实上，0xee5ee2e4用模块偏移表示一下就是基址，我们如果要处理的话直接写入0即可
而我们在内存浏览窗口跳转至基址的话就会发现全都是函数指针(没错，基本都是检测)

我们下断，再跳转至上层:

画圈的call是返回处

下面其实还有一个add esp,14h (41h = 20 = 4*5)
即检测call有5个参数
再对比一下上个图里面的call，发现也是五个参数
笔者几次下断后，发现几个参数多是某个范围内的循环（随机？）值
没有什么结论，笔者上下翻看，发现上图中的call（红色波浪线）混淆严重
并且也是五个参数，可以认定为检测call

根据笔者的经验，如果我们直接处理(直接nop或其它)的话,那么将必死无疑。

大家都知道，检测代码常和一些发包(这样说不准确，或许是内部的随机值)挂钩。
贸然处理多半行不通，行得通就是检测太松。 不过我们先记住这里，一会还会再见。
(聪明的坛友肯定想到了，这个call经历了内部几次call才走到了检测代码movzx 。那我们可不可以直接处理内部的call呢 这个问题我们先保留 )
++至此，上文遗留的6000算是分析到头了，但我们似乎没有多少进展。

没办法，我们只能另找出路:

另寻出路

我们还是要从基础的数据下手，往回分析

大型游戏常采用一种叫做CheckPoint的机制来纪录游戏（玩家）数据，csdn上有一篇文章介绍CheckPoint在赛车类游戏编程中 的应用方法（找不到了）。

作者想到了坐标，CE开搜。我们无法确定坐标是float（4字节长度），还是Double(2被)
我们直接搜索四字节未知值，然后移动车子，搜索变动值
将搜索拉下来一半，直接锁定，看看移动是否正常 ，正常的话就说明没有我们要找的坐标地址，删掉这一半，再拉下来一半。。。。。
最终得到了几个地址，下访问断点,
有几条代码位于Top-Kart模块内 但多数在NxCharacter.dll 不过这个是Physicx的sdk 我猜测游戏公司没有做手脚，故不作分析

第一个是fld浮点运算，我们点开之后可以发现，这不就是第一张图里面的吗。至此说明我们的思路没问题。

时间不早了，今天的分析先到此，好事多磨，各位看官再见。

• MousseLee
  Potato:快捷添加
  email:MousseLi@qq.com
  qq:23882⑥378〇