背景
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。
聊天記錄解密
使用上面的session_key即可解出聊天記錄，具體不做說明了。
例項程式
根據上面登入過程編寫了一個例項程式，截幾個屏吧：


鄭重宣告：本程式編寫純屬個人對技術的愛好，絕不含惡意程式碼，請勿將本程式用於非法目的。
剛發現360會誤報，如需測試請先關閉殺軟。