飞信协议分析

分析之一：飞信协议类型2007年03月08日22:28作者：nathan以下分析均基于飞信的这一版本：Fetion2006beta版本2.1.0.0。被迫开始用飞信(Fetion)，痛苦啊，这玩意儿开发了几年（飞信博客上一家伙说参加飞信项目两年了），而且用的是.NET（工作量要比C++小了去了），居然这么烂，也算是个奇迹了。。。。自己找点乐子，分析飞信的通信协议好了。。。这不是什么破解，俺也不是什么什么客，纯属无聊。抓包看了一下，飞信是用了混合协议的：1、基于HTTP(XMLWebServices吧？)进行获取系统配置、更新程序、注册用户2、基于HTTPS进行登录时密码验证3、应用层协议是SIP协议，但不是标准的，估计是自创的？所有交互过程如发消息、短信通过SIP协议进行。关于SIP，有巨多的RFC描述，飞信的SIP协议栈实现的是TCP、HTTP承载1.TCP承载方式：连接服务器(目前是221.130.45.203)的8080端口，这时在客户端的“网络设置”中显示的是“TCP直接连接”，SIP信令直接就放在TCP的包中。2.HTTP承载方式：连接服务器(目前是221.130.45.203)的80端口，采用POST方式，将信令包在POST请示中，这时在客户端的“网络设置”中显示的是“HTTP直接连接”因为是TCP和HTTP承载，所以其包格式是非常清楚的，那么注意力就可以直接放到SIP协议或SIP信令上，详细的内容稍后再写。总的来说，飞信协议是比较简单的，不对，准确地说法是比较规范和清晰，但协议本身是复杂的，另外：1.飞信的协议是明文，这一点如同其兄弟MSN，是不如QQ和RTX的，因此，通过飞信的交谈过程是可轻易截获的，通过很简单的工具，就可以截到同一网段上所有人的交谈，估计会有人写FetionChatSniffer的，就跟MSN一样，假如有一天Fetion有那么流行......要不我写一个？:)2.协议效率比较低，我加了近200人，一次登录过程要传递的数据量居然超过了230K，我靠。3.状态有问题，presence处理得不太好好象，我在线别人却看到我离线，真是奇怪，而且一会儿发一个presence一会儿发一个，讨厌啊。BTW:RFC在这里看:，太方便了，就是关于SIP的多得看不过来。Fetion分析之二：服务器地址从何而来——变态的配置文件2007年03月08日22:30作者：nathan以下分析均基于飞信的这一版本：Fetion2006beta版本2.1.0.0。作协议分析时，一抓包，就发现飞信工作时连的是221.130.45.203这个服务器。那这个IP地址从哪来的呢？会变吗？飞信的客户端程序中并没有配置服务器地址这一说。固定一个IP？不会吧，一面向全国的系统，不可能用一个IP地址。用一个固定域名解析出来的多IP地址中的一个吗？抓出它访问DNS的包一看，它就只在开始时解析过一次域名：nav.fetion.com.cn，这个域名的IP是221.130.45.201——听说开发飞信的人就是微软开发MSN的人，所以啥都跟MSN一样，你看那飞信的主界面元素，你能找一个位置和功能跟MSN不一样的吗？连解析域名这点都跟MSN一样，没意思啊，印象中MSN也是一开始就解析一个地址，好象是Messenger.msn.com?如果想在局域网内封锁MSN，就把这个域名给指向127.0.0.1，MSN就傻了。既然只解析过nav.fetion.com.cn，那么221.130.45.203这个工作服务器（SIP的ProxyServer）地址，就应该是nav.fetion.com.cn返回来的了。确实是，但只是第一次登录时返回，并保存在了本地。后面再登录时，如果版本不更新，是不会再返回这些系统配置信息的。所以，除第一次外，再抓包是看不到这些配置信息的。本地配置文件并没放在Fetion的程序目录中，而是放到了%USERPROFILE%\Application\Fetion目录下。这个目录下有configuration.dat和飞信的用户目录，每个飞信用户目录下还有configuration.dat、contacts.dat、userinfo.dat这三个配置文件，看名字就知道是与用户相关的系统配置文件、好友列表文件、用户的个人信息文件。这些文件全是XML格式的，所以可以用Notepad打开，不过，你打开后就会发现，这些文件的内容全被加密了，变态啊，这些文件有什么好加密的呢。我们如何获得这里头的信息呢？方法有两个：一、我们让Fetion不要加密这些文件的内容，方法是：修改FetionFx.EXE文件。用ildasm，将FeionFX.EXE反汇编出来，将其中的Imps.Client.Pc.PersistentManager.EncodeMode1和Imps.Client.Pc.PersistentManager.DecodeMode1这两个函数改掉，将这两个函数体改成以下内容：.maxstack1IL_0000:ldarg.0IL_0001:ret即，立即将参数返回。然后再用ilasm工具重新汇编生成FetionFX.EXE文件，覆盖掉以前那个，然后，再运行飞信，所有配置文件就不会再加密了。二、构造一个请求，给nav.fetion.com.cn，让它返回。请求的内容很简单，抓一下包就会知道，取系统配置的请求过程是：xxx.xxx.xxx.xxx:xxxx221.130.45.201:80POST/nav/getsystemconfig.aspxHTTP/1.1User-Agent:IIC2.0/PC2.1.0.0Host:nav.fetion.com.cnContent-Length:233Connection:Keep-Alive--------------------------------------xxx.xxx.xxx.xxx:xxxx221.130.45.201:80HTTP/1.1100Continue--------------------------------------xxx.xxx.xxx.xxx:xxxx221.130.45.201:80configusermobile-no=139xxxxxxxx/clienttype=PCversion=2.1.0.0platform=W5.1/serversversion=12/service-noversion=1/parametersversion=4/hintsversion=4/http-applicationsversion=5//config将以上内容中的从serversversion开始的version全置为0，服务器就会返回配置信息。注意，配置信息全是UTF-8编码的。用nc就可构造一个http请求发过去，服务器立马就返回了。推荐用方法一，因为这样可以看和修改所有配置信息，而方法二仅有系统配置信息。与我们关注的服务器地址相关的信息在飞信用户目录下的configuration.dat中，一看就明白是啥：....sipc-proxy221.130.45.203:8080/sipc-proxy这就是我们关心的TCP直接连接时的服务器地址http-tunnel直接连接时的入口地址get-pic-code注册时，取验证代码图片的URLget-system-status取系统状态啦....这个配置信息放到飞信用户目录下是有原因的，就象SIP协议支持的，登录的服务器是可以分用户群的，不同的用户可以登录不同的ProxyServer，每个飞信用户（手机）可以分别登录到本省的ProxyServer，就如同现在的手机和电话网络一样。其实这些配置内容没什么啊，为什么要加密呢？而且随便构造一个http请求，就可以获得这些内容的。最变态的是通过飞信的交谈内容不加密不变换，却把无关紧要配置文件加密了。另外，用户的密码就保存在ApplicationData\Fetion目录下的Configuration.dat中，当然这个密码进行了变换，遗憾的是，在程序中是还原出了用户密码的，因此，用户密码别人是可以轻易获得的。幸好丢了可以手机找回。但这仍然是个非常不安全的因素。飞信分析之三：断线的真相2007年03月08日22:31作者：nathan飞信老是断线，这点互联网上很多用户都有提及。我待的地方就老断，一说是跟网络有关系，一说是飞信本身有问题。近一两天跟踪看了看，发现断得可真是恐怖，一天断20-30次的都有。可有一次在家通过ADSL上呢，好象又还好。难道是时间的关系？但白天碰到的多次断线我感觉是服务器的问题，理由是通过Sniffer，我明确地看到了服务器端发过来的TCPRST的包，也就是说服务器对这个TCP连接做了CLOSE的操作。让我们看看sniffer记录了什么，来看一次断线的记录(这是OmniPeek的PacketVisualizerData):.....945112:46:48.661IPL=40TCP.A....S=4522L=010994=AW=64367TCPInvalidChecksum945212:46:51.181IPL=119TCP.AP...4522=AL=79S=10994W=65402945312:46:51.182IPL=115TCP.AP...S=4522L=7511073=AW=64288TCPInvalidChecksum945412:46:51.343IPL=40TCP.A....4597=AL=0S=11073W=65327945512:53:38.501IPL=98TCP.AP...S=4597L=5811073=AW=64288TCPInvalidChecksum945612:53:38.532IPL=40TCP...R..L=0S=11073W=0从记录中我们看到，12:53:38,客户机发了9455号包到服务器，而服务器回了一个RST包(9456号包），从TCP的序列号看，通信过程都是正常的，否则RST包的Sequence就不会是11073了。9455的包的内容是：Rfetion.com.cnSIP-C/2.0F:565248767I:1Q:4R这是一个向SIPProxyServer注册的SIP请求。我猜测是客户端有几分钟没收到服务器的任何消息（通常服务器在不停地给客户端发presence消息），客户端就向服务器发起一个注册请求，这时服务器应该将所有用户列表向飞信的客户端返回，然而，服务器却回了一个字：滚！;)然后，飞信就痛苦地开始了重新登录过程，然后你的好友就看到你又缓缓地从他屏幕的右下角慢慢地爬了上来，冤啊。一个半天可以记录到10多次这样的断线，每次均是以如此方式结束：客户端发一个请求到服务器，服务器回以RST。是网络问题吗？我想应该不是，TCP的交互过程是正常的，MSN也是同时用TCP连着的，它也不断。我认为是飞信服务器的用户状态机处理有问题，莫名其妙地把活动的用户给干掉了。:)飞信自己应该知道这种情况的啊，Fetion本身的日志文件中是这么记录的：....Summary通信层异常/SummaryDetailSystem.Net.Sockets.Socke