在对一款游戏的数据分析中，明文封包的重要地位是无可取代的，准确的发送封包可以让我们在实现功能时避免很多风险与麻烦。比如，我们可以节省大量的功能函数的参数分析与特征定位，也可以跳过大量中间函数的判断，直接实现功能，甚至可以实现很多普通玩家无法做到的特殊功能。

然而，这一切都是建立在“准备”这两个字上面的，如果胡乱的使用封包，或者某些结构数据没有分析完全，很有可能会让事情变糟，掉线，崩溃，甚至封号等等。

准确的分析封包，不只限于对单个封包的结构进行分析，因为很多功能并不单一封包可以实现的，如果不能将所有相关的封包一一发送，也许无法实现某些功能，甚至可能会在“漏发”之后出现一些未知的错误。下面我们对一款本地架设的游戏封包进行分析。

我们先调到明文封包的位置，分析一个最简单的打开NPC。

图中是最外层明文包头部地址，之前的线程发包分析过程我们就不做讲解了。

我们在这个头部下断，并打开NPC，游戏会断下

返回后重新下断，对结构体进行分析

这款游戏有一个特点，就是我们需要通过游戏自带的函数申请内存，才可以对明文CALL进行调用，否则游戏就会崩溃，虽然功能也会实现。

申请结构体之后会在下面的函数中进行组包

根据组包函数的参数可以分析出我们只需要传入一个NPCID即可

那么我们通过代码注入器来对这个封包进行发送

发送之后游戏没有反应，NPC并没有打开。多次尝试之后依然如此。这说明我们找的封包并不是打开NPC的。相信很多人已经想到问题所在了，再打开NPC之前，有一个前置封包对我们进行了干扰，而这个封包就是选中NPC。而游戏中没有反应的原因是因为选中NPC的本地效果在外层，所以并没有显示出来。

那么我们通过左键先选中NPC，然后再次点击左键打开，这时游戏会断到一个新的返回地址。

这个函数和选中NPC唯一不同的地址就是组包函数的地址，那么我们修改之后再次调用

打开NPC成功了

以上的问题常常会对萌新造成一些麻烦，但是注意一些还是可以避免的。

单个的功能实现比较简单，但是如果我们将这些封包以一定的逻辑组合起来，编成一个脚本的话，会发现可能会出现一些未知的错误。

比如，我们发送以下连续封包 打开NPC----交任务----接任务

这时就会发现，接受任务无法成功

这时如果手动打开NPC也无法打开NPC，以及接受任务。

这说明我们在这个过程中忽略一些东西，而出现这种问题的主要原因是我们通过函数头部下断去分析封包很麻烦，各种跟包和心跳会影响我们的判断。

想要避免这种问题的出现，我们就需要对明文封包进行HOOK，通过调试输出对发包流程进行观察。

由于外层函数HOOK起来比较麻烦，而且还需要调用游戏自带的申请内存。所以我们在内层寻找一个比较合适的地方进行HOOK，并分析了加密函数，自我实现send发包。

接着上面继续分析，由于提交任务是成功的，但是接受任务失败了，所以我们主要对提交任务的封包进行观察

在提交任务后，我们得到了这些封包，第一个包很明显是交任务包，第二个包则是打开NPC，

单独调用打开NPC，会跟着输出一个包

单独发送一次交任务包，会跟出另外两个包

那么也就是说我们在提交任务之后，需要再次发送一个打开NPC包，这样才能够继续接受任务。

下面做一个连续测试，打开NPC----交任务----打开NPC----接任务

接受任务成功，说明我们的分析是没有问题的。

以上就是我们对封包实现功能的分析过程，在这个过程中，HOOK封包使我们的分析简单多了很多，虽然通过OD去逐条分析每一个访问也可以达到效果，但是很明显会麻烦很多。

本文中的实例都是比较简单的，还有很多游戏的封包比这个要麻烦很多，不过分析的方法是没有区别的。如果有什么意见和疑问，大家共同探讨。（可以联系我大家一起探讨）

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)