x86游戏逆向之实战游戏线程发包与普通发包的逆向-Toy模板网

这篇具有很好参考价值的文章主要介绍了x86游戏逆向之实战游戏线程发包与普通发包的逆向。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

网游找Call的过程中难免会遇到不方便通过数据来找的或者仅仅查找数据根本找不到的东西，但是网游中一般的工程肯定要发给服务器，比如你打怪，如果都是在本地处理的话就特别容易产生变态功能，而且不方便与其他玩家通信，所以找到了游戏发包的地方，再找功能就易如反掌了。

在游戏逆向过程中，通常会遇到下面几种情况的发包。

1.在主线程直接发包

游戏某功能-->组包-->加密-->发送

2.在线程中发包

Thread1:游戏某功能-->组包-->加密-->写缓冲区

Thread1:死循环->读缓冲区是否有内容->发送

主线程发包的话伪代码大致如下：

bool GameFunc(...)

{

if(xxx)

{

......

send(x,x,x,x);

}

线程发包大致伪代码如下：

char g_szBuf[4096]={0};

bool GameFunc(...)

{

if(xxx)

{

......

//打开互斥

WriteProcessMemory(...,g_szBuf......);

}

DWORD WINAPI ThreadProc(LPVOID lpParameter)

{

char szTmpBuf[4096]={0};

while(1)

{

//打开互斥

if(strlen(g_szBuf)!=0)

{

memcpy(szTmpBuf,g_szBuf);

ZeroMemony(g_szBuf);

}

//关闭互斥

send(....,szTmpBuf....);

ZeroMemony(szTmpBuf);

Sleep(10);

}

当然。。以上代码肯定有错误，大概就是表达个意思，就是一个是直接组好包就发一个是在线程里面发

1.主线程发包

在游戏里面如何分辨是不是主线程发包？

首先肯定是跳转到3大发包函数，send , sendto ,WSASend 分别下段。如果下断点马上就断下，那么基本就是线程发包了。除此之外，是主线程发包的可能性比较大了。

这种情况下，bp ws2_32.send下好断点后，只要Crtr+f9多跳几层，每层都打好断点就很容易判断出功能函数了

2.线程发包

那么线程发包是什么情况呢？

就是在发包函数上下断点马上就断下，而且断的非常的频繁，基本就可以确定是线程发包了。

找线程发包的主要步骤如下：

找到真正的发包函数，找到包内容的位置。再跟包内容的写入位置，基本就可以找到正确的明文包了。

接下来具体分析线程发包，跳出线程发包有两种方法，如果游戏发包不频繁，建议使用第一种方法，如果游戏发包异常多，建议使用第二种方法

下面的演示以天龙八部私服和官服分别演示，因为天龙八部私服发包不频繁所以用来演示第一种方法，具体操作就是进游戏有下send断点，然后对数据包下硬件访问断点，我们去游戏选怪，硬件断点断下后，删除我们下的断点，然后Ctrl+f9一层一层返回，每次返回的CALL都下个断点，然后让游戏跑起来，跑起来后我们再选怪，对断下的地方进行分析

进游戏后使用bp ws2_32.send下段，然后选怪，可以看到，立马就断下来了

断下来后，我们右键data参数，跳转到内存窗口https://bpsend.net/thread-99.htm

在内存窗口对这个内存首地址下断点，然后去游戏里面选怪

选怪后游戏立马又断下来，这时候我们跳到上一层，下断，再跳再下断，多下几个。然后让游戏跑起来，再选怪

然后断下来了，这就是选怪Call了。EAX就是怪物的ID，其他参数都可以获取到。这个Call就找到了

接下来是第二种方法：

为什么会产生这种方法呢？因为有的游戏发包太频繁了，你下好硬件断点后根本来不及操作就被游戏断点断下来了，所以不得已使用这种方法。

前面都是一样，下send断，然后对send的data参数下硬件断，这里会发现它一直断，不管你有没有做动作都一直断

这就有点烦，不好继续找，不要着急，我们来看看上面说的线程发包的流程

Thread1:游戏某功能-->组包-->加密-->写缓冲区

Thread1:死循环->读缓冲区是否有内容->发送

比方说你是游戏的程序员，你要实现组包，或者加密的时候如果是以下代码：