【转帖】QQ协议分析之TCPF包结构

2009年05月16号 21:35  |  分类:案例分析

 

Toad转帖一篇TCPF包结构的文章,大家先看看,Toad也需要研究一下!

包结构类型:

TCPF包我们把它分为5类:

登录请求包(LIP,LogIn Packet),它是由客户端向服务器发出登录请求的数据包。

登录应答包(LRP,Login Reply Packet),它是由服务器响应客户端登录请求的数据包。

注销请求包(LOP,LogOut Packet),它是由客户端向服务器发出注销登录请求的数据包,

服务器对这个包不作应答。

客户端其它包(CSP,Client Sent Packet),它是由客户端向服务器发送的其它包。

服务器其它包(SSP,Server Sent Packet),它是由服务器向客户端发送的其它包。

包头:

所有TCPF包的前7个字节是包头,包头可以识别TCPF包的内容。包头的格式为:

第0字节:TCPF包标识:0×02。

第1-2字节:发送者标识。如果是0×01 0×00,表明是由服务器发送。客户端的标识与所使用的使用的QQ版本有关,目前最新版本QQ2003(0808)的标识为0×0A 0×1D。具体的协议的格式与这个字段所标识的客户端版本有关。目前我们以这个最新的0A1D版本来讨论。

第3-4字节:命令编号。具体的命令编号含义在《QQ协议概述》(Protocol Overview.rtf)中有描述。如果这个字段是0×00 0×01,那么这是一个注销请求包。如果这个字段是0×00 0×22,而发送者标识是0×01 0×00,那么这是一个登录应答包。如果这个字段是0×00 0×22,而发送者标识是其它(例如0×0A 0×1D),那么这是一个登录请求包。其它的命令代码表明是其它包,我们通过发送者标识来区分它是CSP还是SSP。

第5-6字节:命令序列号。客户端和服务器都有各自的当前发送序列号。每初始发出一个指令的时候,使用当前的序列号,然后把当前序列号加一,如果超过0xFFFF,就绕回。如果是响应对方发出的命令,则使用这个命令的序列号。例如,客户端当前的序列号为0×1110,它向服务发送一个0×0016命令,它使用0×1110这个序列号,服务器收到以后,返回一个序列号为0×1110的0×0016命令响应。下一次,客户端又发送一个0×0026命令,这一次它使用加一了的序列号0×1111,服务器也响应0×1111序列号的一个0×0026命令响应。如果这是服务器要向客户端发送0×0017命令,它使用它自己的当前序列号,比如说0×2220,客户端收到以后,也响应一个序列号为0×2220的0×0017命令应答。我们可以通过序列号来判断发出的指令是否已经得到了应答,如果没有,可以重发。服务器对收到的命令的序列号顺序没有要求。服务器也不会一定按照发出的顺序给予应答。

 

包尾:

所有的TCPF包都以0×03作为包尾。在包头和包尾中间的包数据则不同类型的包有所不同。

LIP包:

登录请求包的包数据格式为:

第7-10字节(4 bytes):发出登录请求的QQ号码。这是一个Big Endian(高位在前)的unsigned long型数值。例如:0×01 0×82 0×5D 0×90就是0×01825D90,转换为十进制是25320848,表明发出请求的QQ号是25320848。

第11-26字节(16 bytes):随机密钥。这个密钥由于加密后面的数据。QQ使用TEA算法来加密数据。它使用的是128bit(16 bytes)的密钥。在0A1D版本中,这个密钥已经固定为16个01。

第27-106字节(80 bytes):加密后的登录包数据。

LRP包:

从第7字节开始到包尾前:加密的登录应答包数据。解密的密钥随客户端版本的不同,有不同的可能。在旧有版本中,使用登录包的随机密钥,在后期的版本,使用用户QQ密码的MD5 Digest。在0A1D中,使用QQ密码的MD5 Digest的MD5 Digest(这体现了腾讯有多么的愚昧和无耻,为了改变而改变)。LRP包内数据很重要的是16个字节的Session Key,它用来作为以后通讯的加密密钥。

LOP包:

它的序列号总是0xFFFF。不过,在新的版本中,好象已经没有了这个要求。

第7-10字节(4 bytes):发送注销登录请求的QQ号码。

第11字节到包尾前:加密的注销登录包数据。使用Session Key作为密钥。

CSP包:

第7-10字节(4 bytes):发送请求的QQ号码。

第11字节到包尾前:加密的包数据。使用Session Key作为密钥。

SSP包:

从第7字节开始到包尾前:加密的服务器发送包数据,使用Session Key作为密钥。

QQ通信原理逐步解析日记

2009年05月13号 22:19  |  分类:案例分析

 

为什么标题中要加入“逐步”二词呢?因为Toad从来没对QQ的通信原理做过详细的Sniifer研究。

这是一份QQ通信原理的研究日记,Toad不敢保证这份日记的正确性,一旦发现错误,Toad会及时更正,同时,也希望读者朋友及时指出来!

通过SE,Toad知道了QQ使用的应用层协议是TCPF(文字聊天协议族)全称为:“Text Chatting Protocol Family”,呵呵,第一次听说这个协议,不知道是国际标准,还是腾讯自己设计的。不知道其协议的格式是怎样的,一会儿Sniffer看一下。研究所使用的软件环境如下:

WIN 2003+QQ 2009+科来网络分析系统

很意外,科来已经为我们准备好了QQ的过滤规则,不用自己去写了,Very Good!

OK,让我们开始吧,下图是登录QQ,10秒内的数据抓取结果:

 

QQ通信原理Sniifer图

                                                                      图1

 

一共有236个数据包 。刚一登录,QQ客户端就向服务端发送了8个数据包。大家注意看,这8个数据包的目的IP都不一样,但目的端口是一样的:8000,源端口则为4000-4008。我们再来看看这8个数据包协议首部情况!QQ使用的UDP协议这个外星人都知道,直接看应用层首部:

QQ之TCPF协议首部Sniffer图

                                                                   图2

这8个数据包中,TCPF协议首部中都有“数据包头”,“数据包尾”两个协议域,且,值都是固定的,前者为:2,后者为:3。这应该是TCPF协议类似“边界符”的设计。版本标识,不知道是指TCPF协议版本,还是指QQ版本!命令:145,不知道意义是什么,根据Toad的经验,不同命令会触发服务器不同的处理行为,下来再仔细研究下。顺序号,通过分析,感觉跟TCP中SYN、ACK标志的意义相同,应该是防止数据错位的一种设计!QQ号码,这个就不用多想了,23111055正是Toad的QQ号码。加密数据协议域,这8个数据包都一样:64字节。

文章来源于>>TCP/IP协议分析博客     转载请注明:Toad的博客