QQ2012 Beta3->QQ2013 Beta1聊天协议剖析

【转】：  QQ2012 Beta3->QQ2013 Beta1聊天协议剖析

⦁ 背景

QQ，一个通信工具，号称拥有N亿，现在注册QQ已经是10位数了，如果QQ注册的号码是不断递增的话，那么QQ应该已经被注册了至少10亿次。在中国，只要你是经常上网的网民，手中必须得有一个QQ号，当然你也可以没有，但你的朋友、同学、亲戚、同事全都有，大家都通过QQ进行沟通，你不用，要沟通多不方便啊。
作为一个通信工具，必定涉及到网络通信协议。由于腾讯基于QQ这个产品承载了很多业务，要将协议全部分析完全就需要相当大的工作量了，而且没有这个必要。今天就拿QQ中最基本的聊天协议进行分析一下。
⦁ 协议
QQ协议首选的传输层协议是UDP，如果UDP不可用，那么会再尝试使用TCP进行传输。UDP使用的端口是8000（0x1F40），TCP使用的端口是443（0x1BB）。
QQ协议中每个通信包都有一个协议头部，如图：
 
使用结构体可以这样表示:
typedef struct _QQ_DATA_HEAD
{
uchar ucFlag;
ushort usVer;
ushort usCmd;
ushort usSeq;
uint  uiSender;
} QQ_DATA_HEAD, *PQQ_DATA_HEAD;

在进行协议还原的时候，我们最关心的就是协议头部的命令字，需要根据不同的命令字，来进行相应的处理，获得密钥解密聊天内容。

⦁ 登录过程
这里我们通过分析QQ密钥交换过程来分析QQ的登录过程，这个过程很重要，最后得到的SessionKey将作为后面聊天记录解密的密钥。 这里只列出关键的项，这些命令在QQ2012 Beta3以前的版本中也存在，但命令编号和解密数据存放的位置都有很大变化 ：
命令字      含义
⦁ Login verify（0x2608）
C->S向服务器发送登陆请求，需要使用密码进
行运算解密的报文中包含对第2步的解密密钥。
⦁ Login verify reply（0x2608）
S->C服务器返回的报文，使用第1步获得的密
钥进行解密，可以获得解密第3步的密钥。
⦁ Login session（0x2808）
S->C服务器返回的报文，使用第2步获得的密
钥进行解密，可以获得SessionKey，这个
SessionKey就是后面用来解密聊天记录所使用
的密钥。

⦁ Login verify（0x2608）
相当重要！获取SessionKey首先得解密该报文。但是要解密该报文，必须先知道登录QQ用户的密码，而用户密码只有用户自己知道（也许TX也知道），第三方一般情况下是不知道的。数据传输过程中使用的加密算法是TEA算法。
说到QQ密码获得，大概有这么几种方式：1、通过键盘记录记录用户输入（需要编写驱动）；2、使用dll注入，hook关键函数，截获用户输入的密码；3、获得本地保存的密码hash，进行暴力破解（需要用户记住密码的情况）。这里不多说了。
  LoginVerify报文经过两次加密的：
LoginVerifyUdpPacket = Key2 + Tea(Key2, Tea(Key1, PlainUdpPacket))
Key1 = MD5(MD5(Password)+QQ)
可以看出Key2是包含在包里的，我们可以先使用Key2解密获得报文1，再使用Key1解密获得明码的报文，明码的报文中我们获得了login_verify_key。这里的Key1是QQ用户密码的QQ号码经过两次MD5获得的。
⦁ Login verify reply（0x2608）
这个报文是发送报文1后服务器返回的报文，使用login_verify_key解密该报文，可以得到login_verify_reply_key。
⦁ Login session（0x2808）
这个报文是服务器发回来的，2和3中间还有一些报文，都不是获得SessionKey所必需的，不做说明了。使用login_verify_key可以解密这个报文，获得session_key。

回想一下：要获得session_key，密码才是关键，有了密码才能解密LoginVerify报文，然后解密后续的报文。其步骤为：
Password->verify_key->verify_replay_key->session_key。