解决bp 请求定位游戏call的困难-----游戏线程发包

啊哈和 · 发表于 2020-5-31 17:45:30

奥术跃迁

利用游戏发包，定位游戏功能函数
 解决bp 请求定位游戏call的困难-----游戏重写发包函数

解决bp 请求定位游戏call的困难-----游戏线程发包

扯淡原理：

又是一个风和日丽的早晨，又对一款游戏产生了念想，又是熟悉的传统手艺——断点发包函数定位功能Call。

奇怪的是无论怎么Ctrl+F9 都返回不到功能call, 点击OD快捷栏 K 按钮查看堆栈调用关系，才惊讶的发现无论做什么动作断下，调用关系都是一样的，也就是说游戏中任何动作都是走的一样的函数一样的代码？

当然不可能的，不同的动作不同的功能，怎么会是同样的代码产生的呢！在断点发包函数的时候，遇到这种现象只能说明厂商对发送请求进行了特殊的处理。就像小说里面的鬼打墙，让我们一直在同样的代码里面打转转。

不过这种手段远没有鬼打墙那么邪乎，它只不过是把发送请求的责任交给了一个子线程——俗称线程发包。

理论如图：

上图就是线程发包最简单明了的情况了，厂商把游戏的功能代码和发包代码放在了不同的线程里面。通过一个一个不变的地址或者结构互相联系。

子线程发包，这个线程里面恐怕是一个死循环，一直在查看全局变量里面是否有游戏主线程写入的请求内容，如果有那就发送出去。

现在的情景就一目了然了，既然是死循环那么循环里面每次运行的代码必然是一样的，所调用的函数也必然是一样的，那么每次的堆栈也是一样的。这就解释了为什么我们会看到一模一样的堆栈调用关系了。

哪怎么才能正常的断点发包，找功能call呢？很简单，以前游戏主线程会直接告诉服务器，游戏角色干了什么事情，现在只不过是把角色干的事情写入到全局变量里面。只需要在写入的地方下断点，我们照样能够找到游戏的功能函数。

要在写入处下断，首先就得找到它的位置，它在哪？也不困难，在全局变量上下一个内存写入断点，自然就会断在写入处。

好的，哪全局变量它又在哪？

解决一个问题总是会引出另一个问题，好在无论什么问题都有解决之道等待着我们去发现、去摸索。

现在我们知道，全局变量存储的是请求内容，而且子线程会调用发包函数把请求内容发送出去，而我们已经知晓了发包函数，无非就是WSASend send sendTo，而请求内容会作为参数传入函数中，只要我们在OD中对这个参数溯其来源，自然可以找到那个不变的地址或者结构。

真是欣慰终于没有套娃了，现在我们终于跳出了这个该死的循环，可以继续快乐了。

上手实战：

光说不练假把式，利用自己搭建的SF游戏幻想神域2 做个实战练习。

这个游戏使用WSASend发包，直接在头部下断点，Ctrl+F9返回上一层。

然后我们在调用WSASend的call指令上下断点，以此在OD堆栈窗口查看它的参数。

其实都没必要我们自己下断点分析了，由于是常用的系统函数，所以OD直接帮我们分析并标注出来了。WSASend 第二个参数pBuffers 是一个结构体地址，这个结构体第一个成员是包长，第二个成员就是包内容的地址。

在往上面回溯之前，我们还有一些准备工作。再次在WSASend 下断点，依次Ctrl+F9 把线程发包里面调用的函数全部标记一下，如图。

很简单，就这样依次 1. 2. 3. 4. 5.... 这样标注下去。

接下来开始回溯包地址的来源，没什么太多好说的逆向的基本功唯一要注意的是 pBuffers来源于一个局部变量，在汇编中常常以[esp+XX]的形式出现，但是esp 栈顶指针是受到很多指令影响而变化的，所以这里要追的是 [esp+0x28] 但是往上面一些这个局部变量可不是 [esp+0x28]了，所以要细心的注意影响栈顶指针esp 的指令，从而推算出我们要追的局部变量是[esp+什么]。

一段无趣的回溯过程之后....