本人非常欣赏暴雪及他们的游戏，之所以写这个文章，是想让大家了解一些网络封包分析方面的常见方法以及学习暴雪游戏在网络处理方面的经验，偶认为作为一个网络编程者，熟练掌握封包分析的工具和方法应该是其基本功之一。本文所列的所有封包分析内容，全部是采用普通黑箱方式即可得来的，并未涉及对魔兽世界可执行程序的逆向工程。同时，除此文涉及的内容外，本人拒绝向任何人透露更详细的关于魔兽世界封包方面的更多内容，有兴趣者请自己进行相关的试验，本人在此文中也将尽量避免公开敏感的封包内容及相关加解密算法。谨以此文献给忠爱的暴雪！
一、登录模块流程及封包分析
我们先看登录流程。从封包流程来看，魔兽私服的登录流程是这样的：
1.由Client向登录/账号服务器(Login Server)发送用户名及密码等信息。此数据包的最后部分是用户名(明文表示，未加密)，在用户名的前一个字节表示的是用户名的长度。登录/账号服务器向Client返回登录成功及后续连接到游戏服务器服务器所必备的信息等。这中间的两个来往数据包，我还没有看出具体有什么作用。在这个交互过程中，由登录/账号服务器向Client发送所有的游戏服务器列表，服务器列表数据包的内容包括：ip, port, 服务器上所拥有的角色个数等信息，因服务器列表内容过多，被客户端分为两次接收完毕。
2.Client收到Login Server的服务器列表后，根据最近访问的服务器标识(这个信息应该是包含在那个服务器列表数据包中)，连接到最近游戏的那个游戏服务器(Game Server)。连接成功后，Game Server首先向Client发送一个8字节的数据包，据以往的常识判断，这个数据包的内容很可能是以后客户端与服务器通信的加密密钥。
3.Client向Game Server再次发送自己的账号信息。Game Server与Client经过两个数据包的交互后，向Client发送角色数据包，此包中包括了玩家在该Game Server所创建的所有角色信息，当然这个信息只是部分的，并不是该角色的所有信息。
4.在此后的通信过程中，Client每隔30秒向Game Server发送一个保持连接的包，该包长度为10字节，包的最后四字节是一个递增数字，前面6字节暂时未看出规律。
5.只要Client没有点击某个角色进入最终的Game Server，则Client要始终与Login Server保持连接。当Client点击角色进入Game Server时，Client才与Login Server断开连接。在以后的游戏过程中，Client始终与且仅与该Game Server进行数据通信。
通过对登录流程中的数据包初步分析，可以得出以下几个结论：
1.Client向Login Server发的第一个数据包，用户名部分是采用明文的，且该数据包的内容，每次登录都一样，并没有因时间的不同而发生改变。由此可以推算：针对于此数据包中的密码加密算法是固定不变的，换句话说，密码的加密算法是比较容易通过逆向工程被找到的。偶认为，针对于此处，服务器也应该先向客户端发送一个加密密钥，以后的通信可以用该密钥作为安全验证的依据。但暴雪没有这样作，最大的可能是为了提高服务器的效率，在登录服务器上，如果每个客户端一旦连接成功，登录服务器都得向客户端广播一个数据包的话，可能这个量还是比较大的，这可能延长了玩家的登录等待时间，所以他们没有在这块作。
2.Client在登录Login Server的地址，每次Login Server的登录地址都可能是不一样的。偶没有在客户端目录里找到这些地址，只在客户端目录里找到了四个大区的四个域名，我猜想，魔兽世界是用的DNS解析的简单方法来实现Login Server的简单动态均衡的。不知道这个猜想是否正确。
3.“根据玩家最近在玩的哪个游戏，由客户端和服务器自动为玩家选择进入这个游戏服务器”，这一项设定充分体现了暴雪一贯的风格：为玩家着想，最大限度地提高游戏的舒适度。再次对暴雪的态度予以肯定！
4.一旦玩家进入了游戏世界，客户端与服务器的通信端口会一直保持不变。即：魔兽世界的游戏世界服务器群设计结构采用的是带网关的服务器集群。
5.偶觉得在整个的登录流程中，让我产生最大疑问的就是Login Server与Client的连接保持逻辑。当Client与Game Server连接了之后，Client并未与Login Server断开，是一直保持连接的。后来，经进一步的抓包分析，Client之所以要与Login Server保持这样的连接，是为了当Client重新选择服务器时，不至于重新连接Login Server。当Client点击了"选择服务器"按纽后，Login Server会每隔5秒向Client发一个当前所有的服务器列表数据包。要知道，这个服务器列表数据包的内容可是非常大的，如果有玩家就打开了这个窗口不关闭，Login Server向这种情况的所有玩家每5秒钟就发一个服务器列表数据包，这个广播量可是很大的哦(2k左右，这可是一个用户是2k哦)。偶认为这里的逻辑设计是相当不合理的。Login Server如果为了给客户端提供一个最新的全局服务器列表，可以保持连接，但也没必要每隔5秒就向客户端发一个服务器列表，最多只在客户端在某个服务器上创建了不同的角色后再更新这个列表也是可以的，但只用更新这个列表中的变化内容即可，不用发全部的完整包，这样，在通信量上就小了很多。据说，魔兽刚开始的时候，产生DOWN机的原因就是登录模块没有处理好，偶不知道现在的这个情况是不是已经经过改良的了。但偶还是认为每隔5秒就向客户端发送一个2K的包，这一点是不可以被接受的。
以上只是针对于魔兽世界登录流程的简单分析，没有多少技术含量，拿出来跟大家相互讨论讨论，看看有没有可以借鉴的地方，后面还会有其它部分的封包分析。欢迎继续关注偶的Blog:http://blog.csdn.net/sodme。
偶在文章前面部分说过，作为一个网络编程人员，熟练使用截包软件和掌握基本的封包分析方法是其基本能力之一，发此文的目的一个原因也是希望向正在作网络编程的兄弟介绍一下相关工具的使用和常见的分析方法。下面补充一下关于封包分析的基本方法和相关工具：
1.你需要一个截包工具，偶推荐：commview，小巧但功能强大，支持自定义的封包分析插件以DLL形式装载，也就是说只要你愿意，你可以写个DLL对某类特殊形式的包进行显示、记录、解密等特别处理。
2.如何查看真正的封包数据。在commview里，会详细列出自网卡级别以上的各层封包数据，包括Ethernet层，IP层和TCP层。而我们作封包分析时，只需要关注TCP层。但TCP层里也有很多内容，对于我们的分析需求来说，我们需要关注的是其Data字段（在协议目录里可以看到"data length标识，点击即可查看data段"）的内容。
3.TCP的几个状态对于我们分析所起的作用。在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG.其中，对于我们日常的分析有用的就是前面的五个字段。它们的含义是：SYN表示建立连接，FIN表示关闭连接，ACK表示响应，PSH表示有DATA数据传输，RST表示连接重置。其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，如果只是单个的一个SYN，它表示的只是建立连接。TCP的几次握手就是通过这样的ACK表现出来的。但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。PSH为1的情况，一般只出现在DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。
封包分析的手段，说简单也挺简单的，那就是：比较！要不断地从不同的思维角度对封包进行对比分析，要充分发挥你的想象力不断地截取自己需要的包进行比较。不仅要作横向（同类）的比较，还要作纵向（不同类）的比较。即时对于同一个包，也要不断地反复研究。
初涉封包分析的新手，一般会不知道封包分析究竟该从何入手。基于经验，本文将告诉你一般会从哪些类型的包入手进行分析以及应该怎样对封包进行初步的分析。需要指出的是：封包分析是一件非常有趣但同时也非常考验耐心的事，通常，半天的封包分析下来，会让你眼前全是诸如“B0 EF 58 02 10 72....”之类的网络数据，而且附带有头疼、头晕症状，所以，没有充分的心理准备，还请不要轻易尝试。呵呵。
从事封包分析的基本前提是：应该了解和熟悉TCP协议，并知道数据包“粘合”是怎么一回事。当然，我们平常截获到的包，从数量上来看，只有一小部分是属于“粘合”的情况。但如果不了解它，将可能会对你的分析思路产生误导和困惑。关于“粘包”的更详细解释，请参考我的另外一篇文章“拼包函数及网络封包的异常处理(含代码) (http://blog.csdn.net/sodme/archive/2005/07/10/419233.aspx)”。
上一篇有关魔兽世界封包分析的文章（http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx）中，我根据客户端与服务器端连接及断开事件的处理流程以及登录过程中的一些数据包分析了魔兽的架构和登录逻辑。这篇文章中，我将结合聊天数据包的分析，来阐述魔兽世界封包的大体结构。
首先解释一下我们的目标：封包的大体结构。封包的大体结构包含哪些内容呢？一般情况下，封包的大体结构至少包括两方面的信息：
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:由于每次封包分析的内容都很多，所以，一有了点结论后，要及时记录和总结，并与之前取得的总结进行对比，及时更新相关的记录文档。