可乐+代码 的人生

重要前提： 使用飞信号登陆。
是的，只要有使用飞信号登陆就可以绕过2008验证码。其实，在飞信登陆的过程中，第一步获取自适应的配置，和第二步SSI登录，这两步可做可不做。
SSI登录那一步有两个目的：
1、获取飞信的URI，我最近发现，其实URI后面的p值没有太多的含义，随便写都可以，主要是飞信号。
2、获取SSIC。SSIC主要是WEB部分，如获取头像，设置头像等需要验证身份必须要SSIC。如果不进行这些操作，SSIC可以不需要；
上面两点，如果都不需要，SSI就可以不做。而在2008的客户端中，验证码的出现是在SSI的过程中，如果不做，就可以绕过验证码。
从上面的分析可以看出，如果你有飞信号，就可以不SSI登录，也就绕过了验证码。至于用户的Uri可以自行构造：
sip:{飞信号}@fetion.com.cn;p=1234，后面p的值可以随便写。
另外在SIPC验证的过程中，第二步用户验证的那个包，有个A字段，里面有SSIC，直接去掉就可以了
R fetion.com.cn SIP-C/2.0
F: 123456789
I: 1
Q: 2 R
A: Digest algorithm=”SHA1-sess”,response=”49A3741AC50CDFABD704240E19B2A7C1″,cnonce=”479940A21881CD5C307D47F21586F38C”,salt=”2764D001″
L: 298

<args><device type=”PC” version=”0″ client-version=”3.5.1170″ /><caps value=”simple-im;im-session;temp-group;personal-group;im-relay” /><events value=”contact;permission;system-message;personal-group;compact” /><user-info attributes=”all” /><presence><basic value=”400″ desc=”" /></presence></args>

在 飞信2010分析 – SIPC验证 文章里，简单的提到了飞信使用HTTP传输模式。
HTTP模式是所有传输方式中效率最低，是在其他传输方式都建立失败后才会采用HTTP传输模式，可见飞信在网络环境适应上下了很大的功夫的。
在第一步获取自适应的配置中，曾经提到下面几个参数：
含义 位置 结果举例
SIPC-PROXY /config/server/sipc-proxy 221.130.46.141:8080
SIPC-SSL /config/server/sipc-ssl-proxy 221.130.46.141:443
HTTP-TUNNEL /config/server/http-tunnel HTTP://221.130.46.141/ht/sd.aspx
飞信建立连接主要就是这三个传输方式。
来看下飞信的建立连接的顺序：
第一步： 尝试连接建立 SIPC-PROXY连接 。 即SIPC服务器端口为8080的连接。 这是最稳定的，效率最高的传输方式。
第二步： 如果第一步失败，则尝试建立SIPC-SSL连接。 即SIPC服务器端口为443的连接。 和SIPC-PROXY连接方式完全一致，就是端口变了。虽说是SSL端口，却仍然没有加密；
第三步： 如果第二步失败，则尝试建立HTTP-TUNNEL连接。 即HTTP代理连接。 采用长连接的模式，效率比较低，而且不太稳定。不过只要能访问HTTP，就可以连接上飞信服务器。
第四步： 如果第三步建立失败，则飞信客户端和飞信服务器建立连接失败。
可以看出如果要分析HTTP模式，则需要把SIPC-PROXY和SIPC-SSL的IP和端口堵上。一般都是相同的IP不同的端口，可以使用防火墙来完成。
HTTP分析可以使用HTTPAnalyzer帮助分析。 在我的飞信资源整合那篇文章中有这两个工具的下载。
在分析之前，还是简单的介绍长连接模式。因为HTTP模式下就是使用了长连接的方式。
我们知道HTTP是一个请求-回复类型的协议。在发起一个请求之后，服务器需要返回一个回复。可以理解为是单向的，请求只能是浏览器发送，服务器只能被动的接受请求处理请求，并不能主动的和客户端发送消息。
在Socket通信模型中，客户端和服务器的通信是双向的，客户端可以主动的向服务器发送信息，服务器也可以主动的向客户端发送信息。这在即时通信里面很有必要，假如其他用户主动的发消息给你，服务器可以在第一时间内主动的发消息通知你。
飞信是需要双向通信的模式，但HTTP服务器是不能主动的给客户端发送信息的。于是产生了长连接的技术，也就是Comet，来模拟服务器主动给客户端发送消息。
长连接其实很简单，客户端主动的发起一个HTTP请求给服务器，服务器收到这个请求后，会查看是否有消息可以返回给客户端，如果有把消息放入回复体内，立即返回给客户端。如果没有，就阻塞掉这个请求，不返回，直到服务器有可以返回的消息或者超时才结束这个请求。客户端检查这个请求，如果是超时，就立即发起另外一个请求，如果不是超时，就处理服务器的返回的数据，处理完了继续发起下一个请求。
这样服务器就始终保留了一个客户端的连接，如果收到消息后就可以立即返回给客户端，完全可以模拟Socket双向的通信模式。
只不过这种模式效率低，而且不太稳定，服务器资源占用率大（因为要维持多个连接），不过在一些特别的情景下需要使用。目前WebQQ和WebFetion等即时通信的WEB都是采用了这样的通信模式。
详细的长连接信息请参见IBM工程师写的文章 – Comet：基于 HTTP 长连接的“服务器推”技术 。
分析很简单的，不罗嗦过程，直接写结果吧。
HTTP模式下，假如HTTP://221.130.46.141/ht/sd.aspx为获取自适应配置返回的HTTP-TUNNEL地址：
下面是一个HTTP请求的例子：
POST /ht/sd.aspx?t=s&i=2 HTTP/1.1
Cookie: ssic=CRIOAAA0L0hiEKIY+8MORa3QNc4OJcB3rACWXefS7rmhOaQ5fifHEGsFh8+wPK91WlYD9M4zEqvgSG/hiReF2X30HurJRVRinJLO12MtuQdrY9lN4fpni9AvwA6Qj/FDkKr0wT8AAA==
Accept: */*
Pragma: xz4BBcV9df9de4e-0cd9-49c5-bf32-6adc28fcee63
Host: 221.130.46.141
Content-Length: 134
Content-Type: application/oct-stream
User-Agent: IIC2.0/PC 4.0.0000
Connection: Keep-Alive
Cache-Control: no-cache

R fetion.com.cn SIP-C/4.0
F: 685592830
I: 1
Q: 1 R
CN: 258dbcc7cc8a1633c677ebb0abaa5168
CL: type=”pc”,version=”4.0.3340″

SIPP
————————————
HTTP/1.1 200 OK
Connection: close
Date: Sun, 01 Aug 2010 03:14:12 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: [...]

今天发这篇文章刚好是全国哀悼玉树地震的中遇难的日子，整个互联网都很悲伤。的确，我也是亲身经历过汶川的地震，经历过那种面对死亡的恐惧和重生过后的喜悦。
汶川地震，我们活着，我们是幸运儿。我们每一个在这场大劫中余生的人，都应该有一种获得重生的净化。在自然面前，人的生命是那么的脆弱。活着，比一切都好。这是地震给我最大的感触。
而在地震中不幸遇难的人们，我们应该为他们祈福，愿他们在天堂活得快乐……阿门····
谨以此文纪念在玉树地震以及汶川地震中死去的同胞们！
飞信发送消息用的是SIP协议里面的标准的M请求。飞信给客户端在线的好友和短信在线的好友发送消息的方式是不同的。我们来先看给状态为短信在线或离线的好友发送消息。
注意我这里说的是消息。飞信由于有短信就有点复杂。解释一下：飞信用户可以给飞信好友发送消息（只要是在用户好友列表里面的用户都视为飞信好友，无论是否开通飞信），
1.如果用户在线，消息直接通过聊天服务器中转后直接发送给客户端。
2.如果好友不在线，
a.好友设置为飞信客户端离线时使用手机短信接收飞信消息，给该好友发送的消息就通过飞信的短信服务器直接通过手机短信的方式把消息发送到好友的手机上，
b.用户设置为客户端不在线不用手机接收飞信消息，飞信服务器就保存用户发送的消息，不发送到好友的手机，然后等待好友再次登录客户端后才发送给好友。
现在来说明好友URI为sip:111111111@fetion.com.cn;p=1111，状态为短信在线或者离线或者隐身，发送和接收飞信消息的交互过程。（如何判断好友是客户端在线，还是短信在线，还是离线，请参见我上一篇文章。）

文章更新晚了，请大家见谅，上周的事情比较多，呵呵~
标题里面的成功登录之后指的是SIPC验证成功之后。也就是说登录成功是指在完成第一步获取系统配置信息，SSI登录成功，SIPC验证成功之后才能算登录成功。
在SIPC验证成功之后，服务器会返回很多信息，登录记录，个人信息，好友分组，好友列表，个人配置等，这些信息在2008的协议里面都是逐个发起请求来获取的，现在2010的协议登录成功就直接把这些所有的数据都返回来了，这个改进还不错，减少了很多操作。如果没有返回某一类的信息，表明本地存储的信息版本和服务器一致，就直接读取缓存，如果不做缓存，也就是说本地版本总是0，服务器也会总是返回数据。
这里再详细的的说下其中的好友列表，这是其中的一个好友节点：
<b i=”987654321″ u=”sip:123456789@fetion.com.cn;p=1234″ n=”阿呆” l=”5″ f=”0″ r=”1″ o=”0″ p=”identity=1;phone=1;email=1;birthday=1;presence=1;”/>
为了便于分析，这里转为完整的拼写如下：
<buddy user-id=”987654321″ uri=”sip:123456789@fetion.com.cn;p=1234″ local-name=”阿呆” buddy-lists=”5″ feike-read-version=”0″ relation-status=”1″ online-notify=”0″ permission=”identity=1;phone=1;email=1;birthday=1;presence=1;”/>
简单的说下简写代表的含义:

OK，接上文，继续分析。
飞信登录的第三部就是连接SIPC服务器，验证并获取好友列表等信息。
SIPC是什么含义呢？ SIP是会话初始协议（Session initializtion Protocol），是一个标准的协议，其RFC可以在这里下载。协议的规定如何开始一个会话。通常和这个协议一起使用的还有SDP协议。
但飞信只用了SIP,并且把SIP协议做了一些拓展，所以后面有个C。C可能代表China Mobile。关于SIP协议的格式和移动在SIPC上的拓展和不同，请参照nathan2007的文章。这里就不多说了。
上文说过，飞信SIPC服务器的地址是在第一步获取自适应配置中获得，有三个配置有用。
含义    位置         结果举例
标准SIPC直连接 /config/server/sipc-proxy   221.130.46.141:8080
SSLSIPC连接  /config/server/sipc-ssl-proxy  221.130.46.141:443
HTTP代理连接   /config/server/http-tunnel   HTTP://221.130.46.141/ht/sd.aspx
从上面可以看出飞信支持三种连接方式，
标准SIPC连接方式就是直接连接服务器的8080端口，SIPC信令直接放在TCP包中，
SSLSIPC连接方式连接服务器的443端口，虽说连接的是443端口，却没有使用SSL加密，仍是明文传输，不做任何处理，和标准直连接没有任何区别，只是端口号变了而已。
HTTP代理连接方式是在只能访问80端口的情况下才启用的连接方式，使用POST方式，SIPC信令就放在POST的数据包中，这个我会详细的写文章分析的。
可见飞信对网络环境的适应能力是非常强的。基本能在限制比较多的网络环境中登录成功。还有个细节不知各位注意没，标准直连接和HTTP连接是连接到同一个服务器上，这就需要这个服务器同时运行两个服务：SIPC服务和WEB服务，这对服务器的稳定性和性能要求还是比较高的。

一个月前，移动飞信发布了飞信2010版，也就是V3.6版（飞信2008版为V3.5）,并升级了飞信的通信协议。飞信2010版最显著的功能更新就是非移动用户也可以使用飞信了，只需使用一个邮箱注册即可。但限制还是比较多的，只能已经开通飞信的人发送消息，注意不是短信，当该用户不在线的时候以离线的消息发送。但可以每个月可以免费发送三条短信，如果要发送更多，还得绑定手机号。。
其实很早就想写关于飞信2010版的内容。在飞信2010发布没几天我就开始分析SSI登录和SIPC验证。SSI登录很快就搞定了，但SIPC验证总是失败。查了很久都没有结果，于是就放了有两周吧。两周后的某一天实在是无聊，翻出以前分析飞信2010的代码，拖出Reflector和VC# Express又分析一通，总算搞定了。。网上关于飞信2010的资料还少，我还是简单的写出来，和大家分享我的飞信的研究心得吧，如果我说得不对，别拍我板砖哈~~
废话少说，简单说下飞信2010版协议的变化：
1、SSi登录使用新的V4版本，地址是：https://uid.fetion.com.cn/ssiportal/SSIAppSignInV4.aspx
2、飞信通信协议版本升级为 SIP/C-4.0，主要的操作协议已经是V4了，比如GetContactInfoV4
3、通信协议中很多地方为了减少流量都简写了，比如presence简写为pr，local-name 简写为l

一、飞信的第三方程序和开发库
LibFetion
作者：邓东东
网址：http://www.libfetion.org/
下载： http://web.libfetion.org/demoapp_download.php
说明：
这个不用说了，第三方飞信中做的最好的。开发很早，用c语言编写，现在各个平台都推出了LibFetion的版本。也就是LibFetion,让我们在Linux上面终于用上了飞信。官方说LibFetion是一个飞信的开发包，事实上作者只发布了linux下面的开发库，没有发布Windows下的开发库，这让想开发基于飞信的应用变得比较困难。（这也是促使我写MapleFetion的原因。）因为作者考虑到如果LibFetion大规模的被滥用可能会被移动封杀，而且有个隐私的问题。
Fetion.php (OpenFetion)
作者：youngc527
网址：http://openfetion.sourceforge.net
下载： http://ishare.iask.sina.com.cn/f/7215569.html
说明：
这是个牛人用PHP写的一个PHP的版飞信。最初发布在SourceForge上面。由于飞信官方调整，现在SF上面下载的暂时登陆不了，请下载修改后的PHP飞信。实现了登陆飞信，获取好友列表，发送短信的功能。PHP最大的硬伤是不支持线程，无法用一个线程读取数据另外一个线程处理数据，只能使用飞信的HTTP通信模式。而且PHP脚本执行时间有限制，所以这个PHP脚本只能登陆成功然后发送一条短信就退出了。如果需要用这个ＰＨＰ版的飞信做一个自己的应用，一定要注意PHP脚本超时的问题。

研究飞信是其实是一件很意外的事情。
学校科技立项，我有一个很好的想法，就是做一个信息中心，简单的说就像是10086那种短信营业厅的那种，你可以主动的发信息请求某种信息，也可以订阅某种信息，如果更新之后马上通知订阅者。本来是想把所有的即时聊天工具都整合在一起，比如QQ，飞信，MSN，GTALK等。随便百度了一下，MSN，GTALK都不难，因为官方公布了通信协议，难的就是ＱＱ和飞信。
于是我选择了从ＱＱ入手，百度了很久找到了小虾的MYQQ，（先崇拜下牛人小虾，独立的分析出QQ2009的协议。）照着小虾的分析我就用ＪＡＶＡ去移植，前面一切顺利，结果就卡在0×0030的数据包上了，我研究了几天都没进展，无比郁闷了，就放下了。于是转向了飞信。（关于QQ2009的分析，以后如果有时间的话也会把分析过程分享出来）
原打算找一个高手写好的飞信开发库来用，我知道libFetion。但libFetion是用C语言开发的，而且还不是开源，这让我很不爽。搜了半天都没有一个开源的飞信开发库，郁闷了，算了，还是自己动手，丰衣足食吧。