本文作者：sodme 本文出处： 声明：本文可以不经作者同意任意转载、复制、传播，但任何对本文的引用均须注明本文作者、出处及本行声明信息。谢谢！
封包分析的手段，说简单也挺简单的，那就是：比较！要不断地从不同的思维角度对封包进行对比分析，要充分发挥你的想象力不断地截取自己需要的包进行比较。不仅要作横向（同类）的比较，还要作纵向（不同类）的比较。即时对于同一个包，也要不断地反复研究。
初涉封包分析的新手，一般会不知道封包分析究竟该从何入手。基于经验，本文将告诉你一般会从哪些类型的包入手进行分析以及应该怎样对封包进行初步的分析。需要指出的是：封包分析是一件非常有趣但同时也非常考验耐心的事，通常，半天的封包分析下来，会让你眼前全是诸如“B0 EF 58 02 10 72....”之类的网络数据，而且附带有头疼、头晕症状，所以，没有充分的心理准备，还请不要轻易尝试。呵呵。
从事封包分析的基本前提是：应该了解和熟悉TCP协议，并知道数据包“粘合”是怎么一回事。当然，我们平常截获到的包，从数量上来看，只有一小部分是属于“粘合”的情况。但如果不了解它，将可能会对你的分析思路产生误导和困惑。关于“粘包”的更详细解释，请参考我的另外一篇文章“拼包函数及网络封包的异常处理(含代码) ()”。
上一篇有关魔兽世界封包分析的文章（）中，我根据客户端与服务器端连接及断开事件的处理流程以及登录过程中的一些数据包分析了魔兽的架构和登录逻辑。这篇文章中，我将结合聊天数据包的分析，来阐述魔兽世界封包的大体结构。
首先解释一下我们的目标：封包的大体结构。封包的大体结构包含哪些内容呢？一般情况下，封包的大体结构至少包括两方面的信息： 1、一个封包是如何表示它的长度的？封包长度是由哪个字段表示的？（或者说：如何表示封包的开始和结束的） 2、各种不同的封包类型是通过哪个字段表示的？
是不是所有游戏的封包都必然会有表示“长度”信息的“字段”呢？答案是否定的。有的游戏确实没有采用这种方式，它们的作法设定特殊的包开始和包结束标志。但是，从应用的角度来看，偶推荐使用“长度”这样的方法，因为不管在网络底层的处理效率以及上层应用的处理便捷性来说，使用“长度”字段标识一个完整的逻辑包都是比较好的办法。在确定了封包的大体结构后，我们才方便分析具体类型包（比如聊天、行走等）的详细结构。
作数据包分析，在单纯采用黑箱分析的阶段，我们选取的数据包，须要是具有这种性质的，即：在数据包发送前客户端未进行加密等处理时，这个数据包中的部分内容，我们是已经知道的。这样的包，就可以作为封包分析的突破口。这样看来，我们拿“聊天封包”作为第一个分析对象也就不难理解了，因为我们说的话，打上去的字，我们自己是知道的，但是我们说的话经过客户端的处理后，发到网络上的可能就是已经加了密的或者加了校验码的。站在黑箱分析的角度，我们能作的，就是不断截取各种“聊天包”进行对比、判断和总结。
OK，打开你的commview。让我们从“聊天封包”开始。
分析“聊天包”的前提，是我们能够正常判断哪种类型的数据包是属于聊天的，不要误把行走或其它的数据包当作了聊天数据包。为了减小分析难度，建议新手到游戏中人少或周围没有玩家的地方进行封包分析。这样一来没人打扰，二来你的网络通信量会相对小得多，比较容易进行一些封包判定。
第一步，我们需要确定客户端与服务器通信所用的端口，然后在commview的rules->ports中设定服务器端口，截获与该端口通信的所有数据包。服务器端口的确定方法：不要使用其它网络通信工具，打开commview，进游戏，截包，观察其通信端口。进行封包分析时，特别是初期的封包分析时，你的网络通信应该尽可能是单一的，即：除了游戏，其它的通信软件尽可能不要开。但当你确定了服务器的IP和端口后，就可以照常使用其它网络软件了。
第二步，如前面述，在游戏中找个人少或没人的地方，开始“自言自语”，呵呵。说话的内容，建议以字母和数字为宜，不要说中文。因为中文是双字节的，而字母和数字是单字节的，对于单字节的信息内容，截包软件会以单字节的文本信息显示，但对于双字节的汉字而言，截包软件在对其进行显示时由于换行等原因会造成部分中文显示有乱码，不容易直接看出中文内容。如果执意要说中文，偶也不拦你，给你推荐一个工具：String Demander(下载地址：)，这个软件，可以查询中文所对应的编码。
第三步，设定好commview的rules并使之生效，开始截包。
观察通过以上的过程所截的包，可以发现，魔兽世界的聊天封包的说话内容是明文的！这一点，用不着大惊小怪，呵呵。聊天封包本身并不会对游戏的关键逻辑造成损害，所以，即使让其明文显示也不足为奇。但是，我们还是不太相信自己的眼睛，于是再截若干个包，发现包中的说话内容确实是明文的！但是，包的其它字段却是我们一时看不懂的“密文”。
看来，下面的事情就是对这些包里的“密文”进行研究了。一般情况下，这种“密文”的加密方法，通过封包分析是分析不出来的，但，我们仍然可以通过封包分析来推论一些与“密文”生成算法有关的问题。我们可以作以下的对比分析： 1、连续三次输入“a”，并分别观察及保存封包数据； 2、连续三次输入“aa”，并分别观察及保存封包数据； 3、连续三次输入“aaa”，并分别观察及保存封包数据。
输入的封包用例，我们选择了字母"a"，它的ASCII码是61。输入的规律是：每种情况连续输入三次，然后逐次增加a字母的个数。于是，我们发现这样一个有趣的现象： 1、包中有关说话的内容是明文的； 2、即使针对于同样的说话内容，比如“a”，客户端所发出去的包也是不一样的； 3、当一次说话的字母个数增加1时，封包的总体长度也随之增加1； 4、除每个封包的前面6个字节以及说话的字节外，其余的封包内容每次都一样； 5、每个聊天封包的结尾字节都是0。
于是，我们可以试着得出如下结论： 1、包是没有压缩的，它所使用的加密算法应该是按字节进行的，并没有改变封包的长度使之看上去使用统一的长度； 2、包是以0结尾的（尽管我们不知道它是以什么表示开头的，呵呵）； 3、封包加密算法中所使用的密钥是可变的，即针对于相同的数据包内容由于加密的密钥不同，所以产生的密文也不同。由于客户端的数据传到服务器端后，服务器端还要对数据进行解密。所以，客户端的加密算法与服务器端的解密算法应该共用了前6字节中的某些内容，以此作为解密算法的密钥。如果这6字节中没有包含有关封包加、解密所需要的同步数据，那客户端和服务器之间应该会通过其它的方式同步这样的数据。不过，偶倾向于前者，即：这6字节中应该含有加、解密所需要的密钥信息。
回头看我们上面观察到的有趣现象，针对于第2点，反过来想，这应该也是最起码的功能了。就是说，即使客户端作出的是同样的动作，在客户端发出的包中，包的内容也是不一样的。这样，外挂就不能靠单纯的重复发相同的包而达到其目的了。
分析来分析去，我们还是没能确定魔兽封包的大体结构。其实，到现在，我觉得我此文的目的已经达到了，即向大家展示封包分析的思维角度和思维方式。至于具体结果，偶觉得倒真的不重要的了。可以肯定地告诉大家的是，魔兽的封包结构偶大致已经掌握了。偶仅在此公布我的分析结果： 1、魔兽的封包长度字段是每个封包的前两字节，它的表示方式是：前两字节的数值＋2。之所以加这个2，是因为封包长度字段本身占用了两个字节的长度。 2、魔兽的封包类型偶推断是第三和第四字节，其中普通聊天的类型标识是“95 00”。
请不要来信向我询问任何有关魔兽封包破解的内容，偶能说的都已经在文章里说了，偶之所以写这个系列的文章不是想破解魔兽，而是想以这样优秀的一款游戏作为案例来向大家展示它在封包设计方面值得我们学习和讨论的地方，同时向更多的朋友普及有关封包分析的常识、工具以及思维方式，仅此而已。
ps:由于每次封包分析的内容都很多，所以，一有了点结论后，要及时记录和总结，并与之前取得的总结进行对比，及时更新相关的记录文档。