| 
 | 
 
2007.5.24 更新至连载二,在以后的连载中,我们都会提供相关部分的数据包文件,供大家查看。   
  
近段时间对MSN协议进行了一番学习,现在我将的一些学习内容以连载的方式贴出来,内容主要分为MSN的登录,聊天过程,传输文件等! 
 
今天,我们就来看MSN的登录过程。 
 
----------------------------------我是分隔线--------------------------------------------- 
 
 
连载一:MSN登录 
 
1   前言 
 
MSN Messenger是Microsoft开发的聊天工具,目前在世界使用率第一的IM软件。使用MSN Messenger可以与他人进行文字聊天,语音对话,视频会议等即时交流,还可以通过此软件来查看联系人是否联机等。平常我们在使用MSN Messenger时,包括登录,聊天等等过程看似是这样的轻松简单,然而殊不知在这样简单的操作下面,包含了非常复杂的过程。 
 
然而这些复杂的过程都是通过MSN协议完成的。1999年,Microsoft向IETF提交了一份"MSN Messenger Service 1.0 Protocol"草案,这是最初版本的MSN Messenger协议。MSN协议已经发展到了第13个版本。 
今天,我们怀着对协议的学习的态度,通过使用科来网络分析系统,捕获MSN通讯的数据包,来对MSN Messenger的一些通讯过程进行分析学习。 
我的网络环境非常简单:个人PC通过ADSL拨号上网。同时,我们使用Windows Live Messenger 8.1进行分析。 
 
2   协议简述 
 
MSN Messenger通常使用TCP 端口1863进行通信。在MSN Messenger工作中,客户端与三种服务器通过协议进行通信和数据交换,客户端和各服务器之间主要通过两种形式的进行通信,一种是命令,另一种是消息。  
 
命令(Command):使用纯ASCII码多数数据是以标准的命令格式发送的。标准的命令格式主要由三部分组成,以命令标识符开始,然后是参数,以换行为结束。参数之间以空格区分。  
 
消息(Message):符合MIME 1.0标准,由消息头与消息体组成。通常使用UTF-8编码,消息头中也需要URL编码格式,消息体则直接用二进制数据。它是一种独特的命令方式。它以MSG开头,每个消息的第一行的末尾以一个数字来表示消以下部分息的字节数(包括mime头和主体部分)。第二行为mime的头,一般形式为mime-version: 1.0,以换行结束。下一行所代表的是要发送消息的类型,定义的格式为content-type: */*; charset=utf-8,其中*/*代表消息类型,charset=utf-8是完全可选的,与是否使用该参数与定义的消息类型有关。随后mime头以两个换行结束,用于区分消息主体。  
 
Transaction id:在客户端向服务器端发送的每个命令和消息中都包含一个transaction id。其位于命令标识符和MSG后面,服务器收到客户端的相应命令和消息后,回应客户端时把对应的Transaction id返回给客户端,客户端根据Transaction id来判断服务器回应的是哪个请求。每次客户端向服务器发送一次命令或消息后,Transaction id自动加1。 
 
3   分析过程 
我们启用科来网络分析系统,设置MSN协议的数据包过滤器,开始捕获。同时,使用Windows Live Messenger 8.1客户端进行登录,然后进行文字聊天,传输文件以等操作后,并停止捕获。下面我们通过捕获的数据包文件,分别对MSN的各个过程进行详细的分析。 
 
3.1    MSN登录 
 
我们先来看MSN的登录过程。MSN协议建立在TCP之上,除了文件传输和语音聊天是直接的"点对点"通信之外,其它所有的情形全部通过服务器进行。 
首先我们特别了解三种类型的服务器,如下: 
 
派遣服务器(Dispatch Server, DS):客户端最初连接的服务器。负责给客户端分配合适的通知服务器。域名是messenger.hotmail.com,标准服务端口是1863。完成派遣任务后,切断TCP连接。  
 
通知服务器(Notification Server, NS):客户端需要一直保持连接的服务器。很多任务要在这个会话内完成,包括登录、改变状态、获取用户列表、修改用户信息、发起聊天、接受呼叫、邮件通知、退出等等。服务端口由派遣服务器指定,通常也是1863。  
         
接线服务器(Switchboard Server, SS):客户端之间聊天使用的中转服务器。每开一个聊天窗口,客户端和服务器就建立一个TCP会话。当客户端之间需要进行文件传输或语音聊天时,发送系统消息,建立"点对点"会话通道(可能转为使用UDP)。服务端口通常也是1863。"点对点" 通信使用的端口由客户端自动协商决定,如文件传输通常使用6891端口。 
 
现在我们开始结合数据包文件进行查看。如图1。 
  
(图1  与派遣服务器建立TCP连接) 
 
图1中,客户端在登录时,首先与派遣服务器建立TCP连接。当连接成功后,客户端会向派遣服务器发送一个VER命令,命令中将包含协议版本的参数。服务器收到请求后,同样返回VER命令。如图2所示。 
  
(图2  VER命令协商版本) 
 
随后,客户端将通过CVR命令与派遣服务器协商本地的一些信息,比如操作平台等信息,服务器也对其进行响应,随后客户端向派遣服务器请求认证。如图3。 
  
(图3  CVR命令及派遣服务器认证) 
 
图3中显示了客户端与派遣服务器之间的一些版本协商信息。 
当客户端向派遣服务器请求认证后,派遣服务器会将会把客户端重定向到通知服务器,然后与客户端断开连接。客户端到派遣服务器的过程就结束了。如图4。 
  
 
图4中,编号为9和10的数据包为客户端主动向派遣服务器断开连接。编号11的数据包为重定向到通知服务器的数据包。最后编号为12和13的数据包表示派遣服务器断开与客户端的连接。派遣服务器这边的工作结束了。 
由于客户端被重定向到了通知服务器,所以现在客户端将与通知服务器建立连接,并进行更多的登陆操作。如图5所示。 
  
(图5  与通知服务器建立连接) 
 
图5中,数据包编号为14、16和17这个三个数据包描述了客户端与通知服务器建立连接的过程。数据包编号为18、19、20和21这四个数据包说明了客户端和服务器也经历协商版本信息的过程。我们可以看到,客户端与通知服务器建立连接的过程和派遣服务器的前几步是一样的,只是它们在认证过程是不同的。 
下面我们看看客户端与通知服务器之间的认证过程。如下图6。 
  
(图6 Notification认证过程) 
 
图6中选中的数据包为客户端与通知服务器认证的过程。 
客户端向服务器请求认证,根据参数向通知服务器发送USR命令,其中传入两个参数,第一个为Notification服务器返回的MD5,第二个参数为客户登录的电子邮件地址。服务器收到请求后返回USR。客户端再根据收到的答复后再次发送一个USR,参数为MD5。其中MD5值为上次服务器返回的MD5 hash的小写16进制。服务器收到后返回USR,进行认证,最后登录成功。  
 
以上就是我们根据捕获到的数据包文件,通过对数据包的分析,所了解的MSN的登录过程。 
 
注:不同版本的MSN协议,可能存在一些细小差异。 
 
 
----------------------------------我是分隔线--------------------------------------------- 
 
相关数据包文件:  
本节完,下回请早!   
 
[ 本帖最后由 KelvinFu 于 2007-5-24 16:00 编辑 ] |   
 
评分
- 
1
查看全部评分 
 
- 
 
 
 
 
 |