WebQQ 協議更新後引入 SSL 層,導致舊版登入邏輯失效。本文基於抓包分析,詳細記錄最新登入協議的四個關鍵步驟、Cookie 流轉機制,並提供可參考的請求參數說明。(註:WebQQ 已停止服務,內容僅供協議分析學習參考)
完整登入分為四階段:
GET https://ssl.ptlogin2.qq.com:443/check?
uin=QQ號碼
&appid=1003903
&js_ver=10041
&js_type=0
&login_sig=動態簽名
&u1=http%3A%2F%2Fweb2.qq.com%2Floginproxy.html
&r=隨機數
Cookie: 無
回傳: ptvfsession 或 verifysession(需保存供下一步)
GET https://ssl.ptlogin2.qq.com:443/login?
u=QQ號碼
&p=加密後密碼(需實現 PT 登入加密演算法)
&verifycode=驗證碼
&webqq_type=40
&remember_uin=1
&login2qq=1
&aid=1003903
&u1=http%3A%2F%2Fweb2.qq.com%2Floginproxy.html%3Flogin2qq%3D1%26webqq_type%3D40
&h=1
&ptredirect=0
&ptlang=2052
&daid=164
&from_ui=1
&pttype=1
&dumy=
&fp=loginerroralert
&action=3-12-12775
&mibao_css=m_webqq
&t=1
&g=1
&js_type=0
&js_ver=10041
&login_sig=動態簽名
Cookie: 提交第 1 步獲得的 ptvfsession/verifysession
回傳 Cookie: pt2gguin、uin、skey、ETK、superuin、superkey、supertoken、ptisp、RK、ptuserinfo、ptcz、ptwebqq、airkey
首次登入成功後,回應包含回調地址:
ptuiCB('0','0','https://ptlogin4.web2.qq.com/check_sig?
pttype=1&uin=QQ號碼&service=login&nodirect=0
&ptsig=加密串
&s_url=http%3A%2F%2Fweb2.qq.com%2Floginproxy.html%3Flogin2qq%3D1%26webqq_type%3D40
&f_url=&ptlang=2052&ptredirect=100
&aid=1003903&daid=164
&j_later=0&low_login_hour=0®master=0','0','登錄成功!','I');
請求此 URL(會 302 跳轉),必須攜帶上一步所有 Cookie,最終獲得關鍵 Cookie:p_skey、pt4_token、p_uin。
POST https://d.web2.qq.com/channel/login2
Cookie: 必須包含
ptvfsession、verifysession、skey、ptcz、ptwebqq、
RK、superkey、supertoken、p_skey、pt4_token、
uin、p_uin、ptui_loginuin
Body (application/x-www-form-urlencoded):
r={"ptwebqq":"...","clientid":53999199,"psessionid":"","status":"online"}
| 難點 | 說明 | 建議方案 |
|---|---|---|
| 密碼加密 | 採用雜湊+RSA 混合演算法,需移植官方 JS 加密邏輯 | 參考開源專案(如 python-qq、go-qq)的加密實作 |
| 動態簽名 login_sig | 每次請求不同,需從首頁 JS 逆向 | 模擬瀏覽器完整流程自動獲取 |
| Cookie 管理 | 跨域、多步驟、需完整透傳 | 使用 CookieJar(Guzzle/GuzzleHttp\Cookie\CookieJar)自動處理 |
| 驗證碼識別 | 圖形驗證碼需 OCR 或人工介入 | 接入打碼平台或改用掃碼登入(協議不同) |
Cookie、Referer、User-Agent 標頭p_skey 缺失或過期,重新走回調步驟appid、daid)可能隨版本變更,以抓包為準掌握上述流程,即可理解基於 Cookie 的多階段 SSO 登入協議設計模式,對分析類似系統(如微信 Web、企業內部 SSO)有直接參考價值。