【游戏逆向】检测加速辅助案例分析

加速类辅助会对游戏平衡造成极大的破坏，这类辅助会通过HOOK api的方式来达到修改游戏对时间判断的目的，一般情况下，在R3层，这类辅助会在 QueryPerformanceCounter TimeGetTime GettickCount这三个API上HOOK，修改他们的返回值，本文章讲解一下某游戏平台对此类加速辅助的检测方法。 首先用pchunter看下游戏是否在以上三个API挂钩。

在该游戏中我们发现只对QueryPerformanceCounter进行了HOOK，我们用OD来看下他的代码（该游戏有简单的反调试，从上图可以看到DbgUiremoteBreakin 被挂钩。
函数头部被跳转到了游戏的检测DLL，跟随看看
Push esi是对esi压栈进行保存，与后面的pop esi对应
进入第一个call
头五个字节是对被HOOK的API头部进行还原，这个call其实就是对QueryPerformanceCounter的正常调用，
然后返回值给esi 再call 300E3BE 这个call应该是对数据的一系列检测，由于代码被VM导致无法正常阅读，这个问题不大，我们只需对原API头部进行还原就可以过掉这个检测，整个过程类似于传说中的CALL检测通过HOOK，检测调用数据判断是否合法。
当然单单还原API头部并不能完全过掉检测，为防止我们还原头部或者加速辅助HOOK该API,游戏对API头部做了字节校验，字节的改动会被检测到。
那么我们可以在API的头部下硬件访问断点，
下面有很多跳转，现在是没有改动头部的字节所以检测是按照正常流程走的，如果改动字节的话应该会跳到其他分支，我们F8往下走
可以看到周围有很多相似的代码，我们正常走下来的是3002B1B0与上个图一样，如果改动了字节则会跳转到周围的那些地方，
那个call ebx调用的是VirtualProtect 参数edi就是他检测的那个地址，往下走F7进入到call 30010FA的内部
[0x3000113D]保存的是VirtualProtect的地址，call esi 两次调用这个API，
Ebx是第一个参数的值，给eax，通过下面一个小循环依次把API前五个字节放到第一个参数的那个地址中，然后调用两次VirtualProtect 然后return
继续单步走
下面movzx eax, word ptr [esi] 后eax值始终是0x34，上面push edi 上面那句是xor ebx，ebx 对ebx清零，后面有 inc ebx 和cmp ebx，eax 很明显我可以得到
如果ebx小于等于 eax 就跳转到 300134E进行判断[edi+0x10]是否等于0 检测开始的情况下他是等于1的 所以进入call 30012B9到达我们刚开始下硬件断点的位置，完成一次检测 ebx就+1，edi+14 检测的API的数量一共是0x34个，[edi+10]对应每个API检测的开关，这时我们只需把每个[edi+10]的值写为0就可以过掉这个游戏对API HOOK的检测了。简单点也可以把这个je直接改成jmp，不过这么做会被游戏另外一个内存检测检测到，这个下篇文章再讲。