大航海时代online 发包分析

之前好几位朋友留言都提到通过追send找动作CALL但失败了问我怎么追，以前我其实也没研究过航海的数据包部分，今天简单研究了一下。

网游发包CALL有好几种设计思路。设计思路简单，实现也就简单，追踪也简单；设计思路复杂，实现就复杂，追踪也麻烦。

最简单直男的思路就是：动作CALL→构造数据包→加密数据包→发包。这种思路的游戏几乎已经没有了，代码复用性不高，效率也低。

改进的思路是：构造消息队列或者使用多线程，不管哪种，都需要有一个共享的变量容器用于存取数据包。

断点 bp ws2_32.send

断点时机很重要。最好的断点时机是随便输入账号密码，来到选择服务器界面，这个时候没有心跳包和游戏互动内容干扰。X64DBG开启断点，游戏点确认，会中断3次。包的大小分别是8、260、变动。包的数据不需要看最开头的40字节，那是用于数据包协议的，跟游戏无关。

登录了3次，每次固定3个发包，3个收包。前2个发包长度是固定的，后一个长度随账号密码的长度而变。

第一个发包只发送8，接受了一大堆字符，三次均如此。那么猜测第一个发包是请求本机解密数据包的通信密钥之类的证书，服务器发回了证书。

第二个发包也发送了证书，猜测是服务器用于解密数据包的。第二个收包直接就是加密的数据了，猜测是服务器回答“已成功加解密”之类的回复。

第三个发包长度随账号密码的长度而变。登录了3次，第2次我输入帐号1密码1，第三次我输入帐号111111111111密码111111111111，长度分别是24和48。可以猜测第三次发包是发送账号密码。收包是服务器回复账号密码是否正确。这里不正确，所以发了回复就不继续了，如果正确，应该是双方继续通信人物信息之类的。

所以应该从第3次发包中断的时候往回追溯。

v12020

第3次发包中断时的堆栈信息：

回到游戏主界面，从最外层函数（最下面的）依次在CALL下层函数语句下断点测试，找出下断点后不中断的某层函数。找出后【00BF5E33 | call 0xBF3C30】，点开始游戏，游戏会问服务器要版本数据，此时理论上会中断，实际上也中断了。说明该语句所在的函数sub_BF5A80是发包函数的最外层逻辑函数。

但是在函数BF5A80的开头BF5A80地址处下中断，立刻又被中断了，说明是在函数内部判断是否需要发包。函数判断跳转较多，跟踪麻烦，不管他，直接在地址BF5E33下断点即可。

接下来需要过滤心跳包。进入游戏，找个不受干扰的环境避免杂包，比如码头就很棒。

Wireshark捕获数据包，发现心跳包长度是0。

这说明游戏是使用TCP协议本身来实现心跳包的，或者说保持TCP连接的。

0长度的心跳包是用来保持TCP连接的，游戏自己还有一个长度24字节的心跳包，每30秒发送一次。如果游戏内没操作，第10分钟的那次心跳包发完后游戏就显示闲置提示。

2023年8月14日14:28:43修改

还是在码头，在地址BF5E33下中断，立刻会被断下。说明函数【00BF5E33 | call 0xBF3C30】是发包总函数。不连接服务器时不调用，发包包括心跳包和数据包。最好找只发数据包的地方。

找到函数BF5E33中调用下层发包函数的语句【00BF3F3D   |  call 0xBF14C0】，在此下中断。程序没有被中断下来，然后点击进城按钮，程序立刻被中断。说明此处是只发送数据包的语句。这里下断点最舒服。

但跟踪后发现找不到动作CALL的信息。说明虽然航海没有把收发包设计为多线程，也不是用消息队列触发发包动作，那有可能是有一个deque容器之类的数据结构，动作CALL往里放包，发包CALL往出拿包。需要找出这个共享容器，找出后在容器下写入断点，就可以追到动作CALL。（用这种方法追动作CALL属实是高射炮打蚊子大材小用，本篇文章追踪回溯的路线最适合用来跟踪加密解密函数）

之后的内容就不适合公开了😁

参考：https://www.cnblogs.com/Sna1lGo/category/1988759.html