通过发送封包，我们可以让一些反复的枯燥的行为变的简单，高效。

比如XXZ的萃取装备，我们可以一瞬间萃取大量的装备，而省去读条的过程。

我们来萃取一下看看效果

手动萃取是有读条的，那么如果很多装备的话，大量的读条过程会浪费很多的时间

如果说我们用封包来实现的话，效率就会大大提高，我们先来看看封装好的效果

只要一瞬间，所有的装备全都变成了材料，而且是没有经过读条的过程的。

下面我们来讲解一些实现的过程和原理。

一、封包协议与函数调用关系

我们知道，代码的执行是逐层函数的调用关系

封包协议，是这一系列调用的最后一环，中间的每一层函数调用，都进行了非常复杂的逻辑判断。

如果直接发送封包包协议，就会绕过客户端所有的判断逻辑，从而实现BUG功能。

而安全防护的办法，就是尽量的将这些关键的逻辑判断放在服务器上运行。

从本质上说，所有的变态功能，bug漏洞都是可以通过封包协议来挖掘和防护的。

无论是篡改代码逻辑还是修改内存数据，从本质上讲都是影响的封包协议。

这是我们找到的明文包，由于没有用到线程发包，所以找的过程就不赘述了。

二、分析分解包

我们来分析一下分解装备的这个封包，下断后在读条结束时游戏断下了，这说明这个读条是本地的，而读条结束时才会发包

分别将几个参数的数值记录下来

这里的包头是2A0，包长是0C，包内容里面有一个000A应该是装备的位置，而0001可能是分解的数量或者代表着背包

还剩一个ECX，我们简单的分析一些来源，如果用XDBG返回去分析会遇到VM代码

所以我们用CE去扫描一下，发现可以直接得到一个基地址，那我们直接用即可

接下我们只需要将CALL封装成代码，结合背包遍历等数据，就能够实现瞬间批量分解的功能了。

三、其他例子

再举两个例子看一下

比如说我们直接频繁的发送技能封包或者是攻击封包，就能判断游戏是否存在无CD的BUG。

如果你发送封包还不能实现无CD的话，那就说明这个CD是由服务器来判断的。

如果你在一面墙前面去发送，走到墙后的封包，就能判断是否有穿墙的bug。

如果福气没有判断这个障碍物，而是本地来判断，那么我们直接发个封包就穿墙走过了，

顶多再结合一下修改本地坐标等方法来实现完整效果。

游戏中修改障碍物判断的逻辑，还是修改寻路目的地坐标点的这个位置，无非最终影响的都是封包协议。

那最后呢再给大家出一个题目：如果一个游戏中怪物死亡的时候，我们会发送怪物死亡的封包。

那么，请说明这个游戏有没有秒杀功能呢？