feixin协议分析文档格式.docx
《feixin协议分析文档格式.docx》由会员分享，可在线阅读，更多相关《feixin协议分析文档格式.docx（28页珍藏版）》请在冰点文库上搜索。
抓出它访问DNS的包一看，它就只在开始时解析过一次域名：
，这个域名的IP是221.130.45.201——听说开发飞信的人就是微软开发MSN的人，所以啥都跟MSN一样，你看那飞信的主界面元素，你能找一个位置和功能跟MSN不一样的吗？
连解析域名这点都跟MSN一样，没意思啊，印象中MSN也是一开始就解析一个地址，好象是M?
如果想在局域网内封锁MSN，就把这个域名给指向127.0.0.1，MSN就傻了。
既然只解析过，那么221.130.45.203这个工作服务器（SIP的ProxyServer）地址，就应该是返回来的了。
确实是，但只是第一次登录时返回，并保存在了本地。
后面再登录时，如果版本不更新，是不会再返回这些系统配置信息的。
所以，除第一次外，再抓包是看不到这些配置信息的。
本地配置文件并没放在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这两个函数改掉，将这两个函数体改成以下内容：
.maxstack1
IL_0000:
ldarg.0
IL_0001:
ret
即，立即将参数返回。
然后再用ilasm工具重新汇编生成FetionFX.EXE文件，覆盖掉以前那个，然后，再运行飞信，所有配置文件就不会再加密了。
二、构造一个请求，给，让它返回。
请求的内容很简单，抓一下包就会知道，取系统配置的请求过程是：
xxx.xxx.xxx.xxx:
xxxx>
>
221.130.45.201:
80
POST/nav/getsystemconfig.aspxHTTP/1.1
User-Agent:
IIC2.0/PC2.1.0.0
Host:
Content-Length:
233
Connection:
Keep-Alive
--------------------------------------
xxxx<
<
HTTP/1.1100Continue
config>
usermobile-no="
139xxxxxxxx"
/>
clienttype="
PC"
version="
2.1.0.0"
platform="
W5.1"
serversversion="
12"
service-noversion="
1"
parametersversion="
4"
hintsversion="
http-applicationsversion="
5"
/config>
将以上内容中的从serversversion开始的version全置为"
0"
，服务器就会返回配置信息。
注意，配置信息全是UTF-8编码的。
用nc就可构造一个http请求发过去，服务器立马就返回了。
推荐用方法一，因为这样可以看和修改所有配置信息，而方法二仅有系统配置信息。
与我们关注的服务器地址相关的信息在飞信用户目录下的configuration.dat中，一看就明白是啥：
....
sipc-proxy>
221.130.45.203:
8080<
/sipc-proxy>
这就是我们关心的TCP直接连接时的服务器地址
http-tunnel>
HTTP:
//221.130.45.203/ht/sd.aspx<
/http-tunnel>
HTTP直接连接时的入口地址
get-pic-code>
//221.130.45.201/nav/GetPicCode.aspx<
/get-pic-code>
注册时，取验证代码图片的URL
get-system-status>
//221.130.45.201/nav/GetSystemStatus.aspx<
/get-system-status>
取系统状态啦
这个配置信息放到飞信用户目录下是有原因的，就象SIP协议支持的，登录的服务器是可以分用户群的，不同的用户可以登录不同的ProxyServer，每个飞信用户（手机）可以分别登录到本省的ProxyServer，就如同现在的手机和电话网络一样。
其实这些配置内容没什么啊，为什么要加密呢？
而且随便构造一个http请求，就可以获得这些内容的。
最变态的是通过飞信的交谈内容不加密不变换，却把无关紧要配置文件加密了。
另外，用户的密码就保存在ApplicationData\Fetion目录下的Configuration.dat中，当然这个密码进行了变换，遗憾的是，在程序中是还原出了用户密码的，因此，用户密码别人是可以轻易获得的。
幸好丢了可以手机找回。
但这仍然是个非常不安全的因素。
飞信分析之三：
断线的真相
37
飞信老是断线，这点互联网上很多用户都有提及。
我待的地方就老断，一说是跟网络有关系，一说是飞信本身有问题。
近一两天跟踪看了看，发现断得可真是恐怖，一天断20-30次的都有。
可有一次在家通过ADSL上呢，好象又还好。
难道是时间的关系？
但白天碰到的多次断线我感觉是服务器的问题，理由是通过Sniffer，我明确地看到了服务器端发过来的TCPRST的包，也就是说服务器对这个TCP连接做了CLOSE的操作。
让我们看看sniffer记录了什么，来看一次断线的记录（这是OmniPeek的PacketVisualizerData）:
.....
945112:
46:
48.661>
IPL=
40TCP.A....S=
4522
L=
0
10994=AW=64367
TCPInvalidChecksum
945212:
51.181<
IPL=119TCP.AP...
4522=AL=
79S=
10994
W=65402
945312:
51.182>
IPL=115TCP.AP...S=
75
11073=AW=64288
945412:
51.343<
40TCP.A....
4597=AL=
0S=
11073
W=65327
945512:
53:
38.501>
98TCP.AP...S=
4597
58
945612:
38.532<
40TCP...R..
W=
0
从记录中我们看到，12:
38,客户机发了9455号包到服务器，而服务器回了一个RST包（9456号包），从TCP的序列号看，通信过程都是正常的，否则RST包的Sequence就不会是11073了。
9455的包的内容是：
RSIP-C/2.0
F:
565248767
I:
1
Q:
4R
这是一个向SIPProxyServer注册的SIP请求。
我猜测是客户端有几分钟没收到服务器的任何消息（通常服务器在不停地给客户端发presence消息），客户端就向服务器发起一个注册请求，这时服务器应该将所有用户列表向飞信的客户端返回，然而，服务器却回了一个字：
滚！
;
）然后，飞信就痛苦地开始了重新登录过程，然后你的好友就看到你又缓缓地从他屏幕的右下角慢慢地爬了上来，冤啊。
一个半天可以记录到10多次这样的断线，每次均是以如此方式结束：
客户端发一个请求到服务器，服务器回以RST。
是网络问题吗？
我想应该不是，TCP的交互过程是正常的，MSN也是同时用TCP连着的，它也不断。
我认为是飞信服务器的用户状态机处理有问题，莫名其妙地把活动的用户给干掉了。
飞信自己应该知道这种情况的啊，Fetion本身的日志文件中是这么记录的：
Summary>
通信层异常<
/Summary>
Detail>
System.Net.Sockets.SocketException:
远程主机强迫关闭了一个现有的连接。
可怜的飞信。
飞信分析之四：
Fetion协议所支持的SIP方法及SIP消息头域
38
以下分析仍基于Fetion2006beta2.1.0.0。
飞信所使用的协议版本标记是"
SIP-C/2.0"
，协议栈中标记的版权信息是"
Copyright（c）2004-2006ChinaMobileLimited.Allrightsreserved."
，（再次说明飞信开发了很久了嘛;
））。
抓协议包初看的印象是，它基于IETF（InternetEngineeringTaskForce）所制定的标准SIP协议作了一丁点调整。
关于标准的SIP协议，请参见IETF或RFC3261以及其它一些对它进行扩展的RFC，内容实在是太多了，不过如果有点基础的话，估计看个半小时的RFC就明白了个大概。
另外，飞信照着微软做的，所以看微软的实时通信协议的说明也一样：
Look。
一个SIP的请求消息的格式是：
请求行+消息头+空行+消息体，请求行的格式是:
SIP方法+空格+接受方uri+空格+SIP协议版本，如:
INVITEsip:
bob@SIP/2.0
接下来是消息头部，消息头的格式跟http头格式一样，也是FieldName:
FieldValue的形式，如：
Via:
SIP/2.0/UDP;
branch=z9hG4bK776asdhds
Max-Forwards:
70
To:
Bob<
sip:
bob@>
From:
Alice<
alice@>
tag=1928301774
Call-ID:
a84b4c76e66710@
CSeq:
314159INVITE
Contact:
<
Content-Type:
application/sdp
Content-Length:
142
IETFSIP中对这些HeaderField均有专门的定义，见RFC3261以及IETF的SIP草案文档。
Fetion的SIP-C/2.0协议中用到的HeaderField有:
Authorization
缩写为"
A"
CallID
"
I"
Contact
M"
ContentEncoding
E"
ContentLength
L"
ContentType
C"
CSeq
Q"
Date
D"
EndPoints
EP"
Event
N"
Expires
X"
From
F"
MessageID
XI"
ReferredBy
RB"
ReferTo
RT"
Require
RQ"
RosterManager
RM"
Source
SO"
Supported
K"
To
T"
Unsupported
UK"
WWWAuthenticate
W"
以上这些头域很多在RFC并没有定义，只在IETF的协议草案中有定义，如Event。
SIP消息头后，由一个空行分隔，接下来就是SIP的消息体。
消息体通过是用SDP协议描述的，见RFC2327，当然也有直接文本或XML表示的信息，消息体的格式按RFC中的定义，应由头部的Content-Type来决定，但飞信好象不是，具体是怎么定义，还没深入去研究，留待下次吧。
飞信所支持的SIP方法（SIPMethod）有以下几种：
1.Ack方法。
在Fetion的SIP-C/2.0中，缩写为"
，以下是一个Ack消息，会话（Session）发起方用以向SIPProxy确认会话的开始：
ASIP-C/2.0
16
1A
T:
sip:
987654321@;
p=1234
123456789
其中：
123456789是发起方的SIP地址，这个显然没按SIP标准来表达，只是用了一个飞信号码。
987654321@，这个是按标准表达的对方地址。
2.BENotify方法（Fetion缩写为"
BN"
），这不是个标准的SIP方法，既没在RFC中定义，也没出现在IETF的协议草案中，这是微软在其LCS中定义的：
BENOTIFY（"
besteffort"
notify）enhancesserverperformancebyeliminatingtheresponserequirement.Otherwise,aBENOTIFYrequesthasthesamebehaviorasNOTIFY.ApplicationsthatrequireNOTIFYsupportneedtoimplementsimilarprocessingforBENOTIFY."
（见MSDN）。
就是个不需要回复的NOTIFY，微软扩展出这个方法是为了支持大量用户。
以下是飞信的一个BENotify消息，表示用户987654321的在线状态的变化:
BN123456789SIP-C/2.0
13BN
N:
presence
X:
xxxx
9
L:
xxx
events>
eventtype="
PresenceChanged"
presenceuri="
p=xxxx"
basicvalue="
100"
device-id="
PCCL025722"
device-type="
device-caps="
simple-im,im-session,temp-group"
/presence>
/event>
/events>
3.Bye方法（Fetion缩写为"
B"
），以下是一个BYE的请求消息，用以结束会话：
BSIP-C/2.0
11
2B
4.Cancel方法（C），用以取消正在进行中的INVITE请求。
5.Info方法（IN），用以在SIP协议中支持应用相关的控制信息，飞信传文件时，用到了这个方法。
这是RFC中的一个扩展。
以下是一个INFO方法的消息：
INSIP-C/2.0
22
3IN
266
actiontype="
share-content"
method="
request"
transmittype="
relay"
session-id="
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
filename="
xxxxxx.xx"
size="
xxx"
url="
//221.130.45.206/hds/RamRelayDownloadShareContent.aspx?
FileUri=xxxxxxxxxxxxx"
/action>
6.Invite方法（I），这是用建立会话过程的SIP方法。
以下是飞信的INVITE方法的一个协议消息，表示用户123456789要求和987654321建立会话，准备进行文本消息的通信：
ISIP-C/2.0
1I
K:
text/html-fragment
multiparty
137
v=0
o=-00INxxx.xxx.xxx.xxx:
xxxx
s=session
c=INIP4xxx.xxx.xxx.xxx:
t=00
m=message1769sipsip:
123456789@;
p=xxxx
7.Message方法（M），这也是一个标准的SIP扩展，用以支持即时消息。
以下是飞信的一个Message消息，用户123456789向用户987654321发消息说“Hello!
你好”:
MSIP-C/2.0
2M
p=1972
C:
SaveHistory
121
FontFace='
Arial'
Color='
-16777216'
Size='
9'
hello!
/Font>
SimSun'
12'
你好<
8.Negotiate方法（NEG），这是一个IETF定义的SIP的方法，好象没见纳入RFC?
用以在会话建立（INVITE）前的协商会话相关的参数，但没见飞信用啊....以后再说。
9.Notify方法（N），这是IETF定义的一个SIP扩展方法，并被RFC接纳，见RFC3265。
消息见前面的BENotify。
这个消息是需要进行回复的。
10.Options方法（O），标准的SIP方法，用来查询对端或服务器的能力。
比如了解对方支持什么编码类型。
在飞信传文件时使用了以下消息：
OSIP-C/2.0
2O
Shar
升级会员 