这就是我们经常看见这种发言的原因吗？
这次主角是这个
初见就如同本人当初做最后高中数学那最后一道大题，不能说不会，那简直是一点想法都不敢有。
但是呢，这种是目前最主流的封包，要想搞一些莫名奇妙
都是111， 除了前两个字节，其他只能说毫不相干，按照明文 + 密钥 = 密文这个公式，我们很容易知道，他密钥是变化的，而且每一个包里面用多个密钥，
因为111，没有三个连续相同的字节与之相对应。
稍等！这里还有个疑惑，既然每次密钥都是变化的，那么它是怎么传输的，我们先假设它分两次传送，第一次传送密钥，第二次传送内容，这样的话每次发送一条消息，都有两条封包，显然第一次的密钥非常显眼，而且严重影响服务器效率。所以它密钥和内容在同一个封包中。这样既能动态变化密钥，还能干扰你的分析。
下面进入正题：
对于这种复杂的封包，首先分析结构，我们的基本原则是相同中找不同，不同中找相同。
按照这条原则，我们可以轻松的搞成这样
这里再放个内容相同密文不同的封包方便阅读
前两字节为一部分，很明显，82为封包头，9C为封包长度（对比右边的封包），EA EF我们暂时理解为分隔符，分为上下两部分，13 29为上部分的子分隔符，里面还有EF像是分隔符。
分析到这，我们需要知道我们的目的，找到内容和密钥，因为只有找到这两，我们又有密文，才能验证解密是否是对的。
假设上部分直接每个和下部分异或，我们可以得到，倒数第14位总是1A，我们也可以从上面封包得到相同的结果，至于意义，本人猜测是终止符。
但是并没有其他有用的信息。
破解之路陷入了僵局。
洗洗睡吧，咋不是学破解的料。
咋也不是这么容易半途而废的？
只能用最笨的方法了。控制变量法
和原封包改变一个字节，然后不停发送，最后得出一个结论，最后13位是无效的，也就说，怎么改变，对整条封包来说没有影响，相反除了这13个字节，其他改变都能使服务器改变你的套接字（重新连接），所以封包中存在验证码，不然改变内容的相应字节，内容应该也发生变化， 而不是失败。
通过上面这一种方法，下部分基本解密结束；
这里还有一个问题，你怎么知道加密方式是异或？
解密中首选的就是异或，其次是位运算，因为效率好效果好（看上去比较复杂），加减乘除在底层运算比较复杂，同一数用同一个密钥结果相同，不同数用同一个密钥也很容易看出来（成等差，等比）。位运算和乘除差不多，密钥为01，02之类的。
我们开始解密下部分（纯纯的计算量）：
13 29 之间的内容，大概率是消息内容，我们如果有经验的话，可以直接锁定DB EF，EA EF是密钥， 因为最后后字节相同，DB xor EA 刚好等于31， 13 29 分别xor 22 18刚好也是31。
解密到这似乎已经结束了？
我们要做到完全理解这条封包
这里再放个内容相同密文不同的封包方便阅读
其中六个字节（黑色），似乎没有规律，通过计算EF xor E9 = 6, EA xor EE = 4, DE xor EA = 34, 两个封包相同的字节位计算结果相同。
至于E4 4F, 我们需要与13 29 异或为 F7 66，这两个字节每个封包（内容不同）计算都是这两个结果（F7 66）。
到这里完了吗？
还有没，我们再看看这个
我们可以发现内容长度不同，结构有一些变化，长度3和7，2和6， 1和5的结构是一样的，也就是说有四种结构，刚好和密钥位数相对应。
总结上面规律和这种结构，我们其实可以知道了，封包中2-6位为密钥，也就是上面提到的EA EF 13 29 不是分隔符，它是由于明文为0异或之后产生的，所以才与密钥相同。
它的解密方式是2-6位为密钥，后面每四个为一个可读框，进行异或。
封包结构有四种（总体相同）：
0位封包头，1位封包长度 + 2-5位密钥+ 6-7位内容缓冲区长度（6位内容缓冲区长度，7位为0）+ 8-11位为校验位（8-9位为F7 66，10-11位为校验码，规则长度乘2) + 12位至（12+内容缓冲区长度）位为内容缓冲区 + 若干0 + 倒数14位为1A + 13位填充位。
其实解密过一次这种封包，以后可以直接用 明文 异或 密文 再对比 密文，找出密文中密钥。
解密：
VeryCapture_20220923185141.jpg
这次主角是这个
VeryCapture_20220924071717.jpg
初见就如同本人当初做最后高中数学那最后一道大题，不能说不会，那简直是一点想法都不敢有。
但是呢，这种是目前最主流的封包，要想搞一些莫名奇妙
VeryCapture_20220924070411.jpg
都是111， 除了前两个字节，其他只能说毫不相干，按照明文 + 密钥 = 密文这个公式，我们很容易知道，他密钥是变化的，而且每一个包里面用多个密钥，
因为111，没有三个连续相同的字节与之相对应。
稍等！这里还有个疑惑，既然每次密钥都是变化的，那么它是怎么传输的，我们先假设它分两次传送，第一次传送密钥，第二次传送内容，这样的话每次发送一条消息，都有两条封包，显然第一次的密钥非常显眼，而且严重影响服务器效率。所以它密钥和内容在同一个封包中。这样既能动态变化密钥，还能干扰你的分析。
下面进入正题：
对于这种复杂的封包，首先分析结构，我们的基本原则是相同中找不同，不同中找相同。
按照这条原则，我们可以轻松的搞成这样
VeryCapture_20220924074716.jpg
这里再放个内容相同密文不同的封包方便阅读
VeryCapture_20220924080605.jpg
前两字节为一部分，很明显，82为封包头，9C为封包长度（对比右边的封包），EA EF我们暂时理解为分隔符，分为上下两部分，13 29为上部分的子分隔符，里面还有EF像是分隔符。
分析到这，我们需要知道我们的目的，找到内容和密钥，因为只有找到这两，我们又有密文，才能验证解密是否是对的。
假设上部分直接每个和下部分异或，我们可以得到，倒数第14位总是1A，我们也可以从上面封包得到相同的结果，至于意义，本人猜测是终止符。
但是并没有其他有用的信息。
破解之路陷入了僵局。
洗洗睡吧，咋不是学破解的料。
咋也不是这么容易半途而废的？
只能用最笨的方法了。控制变量法
和原封包改变一个字节，然后不停发送，最后得出一个结论，最后13位是无效的，也就说，怎么改变，对整条封包来说没有影响，相反除了这13个字节，其他改变都能使服务器改变你的套接字（重新连接），所以封包中存在验证码，不然改变内容的相应字节，内容应该也发生变化， 而不是失败。
通过上面这一种方法，下部分基本解密结束；
这里还有一个问题，你怎么知道加密方式是异或？
解密中首选的就是异或，其次是位运算，因为效率好效果好（看上去比较复杂），加减乘除在底层运算比较复杂，同一数用同一个密钥结果相同，不同数用同一个密钥也很容易看出来（成等差，等比）。位运算和乘除差不多，密钥为01，02之类的。
我们开始解密下部分（纯纯的计算量）：
13 29 之间的内容，大概率是消息内容，我们如果有经验的话，可以直接锁定DB EF，EA EF是密钥， 因为最后后字节相同，DB xor EA 刚好等于31， 13 29 分别xor 22 18刚好也是31。
解密到这似乎已经结束了？
我们要做到完全理解这条封包
VeryCapture_20220924090307.jpg
，这里再放个内容相同密文不同的封包方便阅读
VeryCapture_20220924080605.jpg
，其中六个字节（黑色），似乎没有规律，通过计算EF xor E9 = 6, EA xor EE = 4, DE xor EA = 34, 两个封包相同的字节位计算结果相同。
至于E4 4F, 我们需要与13 29 异或为 F7 66，这两个字节每个封包（内容不同）计算都是这两个结果（F7 66）。
到这里完了吗？
还有没，我们再看看这个
VeryCapture_20220924091642.jpg
VeryCapture_20220924091938.jpg
，我们可以发现内容长度不同，结构有一些变化，长度3和7，2和6， 1和5的结构是一样的，也就是说有四种结构，刚好和密钥位数相对应。
总结上面规律和这种结构，我们其实可以知道了，封包中2-6位为密钥，也就是上面提到的EA EF 13 29 不是分隔符，它是由于明文为0异或之后产生的，所以才与密钥相同。
它的解密方式是2-6位为密钥，后面每四个为一个可读框，进行异或。
封包结构有四种（总体相同）：
0位封包头，1位封包长度 + 2-5位密钥+ 6-7位内容缓冲区长度（6位内容缓冲区长度，7位为0）+ 8-11位为校验位（8-9位为F7 66，10-11位为校验码，规则长度乘2) + 12位至（12+内容缓冲区长度）位为内容缓冲区 + 若干0 + 倒数14位为1A + 13位填充位。
其实解密过一次这种封包，以后可以直接用 明文 异或 密文 再对比 密文，找出密文中密钥。
解密：
VeryCapture_20220924095313.jpg
VeryCapture_20220924095327.jpg