0x00 前言
看到有壇友發微信、QQ的分析文章，我也來湊湊熱鬧，我分析的是QQ。
本文做法可能不同於其他文章，區別主要在於技術上和目的上。
技術上的不同在於我這裡是對將QQ代碼逆向工程為C++，協議還原只是一部分。
目的上的不同在於我想打造一款挖掘QQ漏洞的自動化工具。
這文章不好寫，原本貼了很多代碼，後來都刪掉了，這一篇不應當是技術分析文章，而應當是交代上下文，技術分析下一篇再來。
目前是基礎功能雛形，只有QQ原生功能，之所以現在就寫文章，是因為曾經有太多東西浪費了，不想再次發生。
5年前公司要做手機管理軟件，還原了iTunes一些功能(對標xy蘋果助手功能)，後來老闆覺得這種軟件不賺錢停了，至今源代碼在硬盤的哪個角落吃灰都記不起了.....
2年前公司要做Android安全防禦軟件，便還原了當時使用率最高的某殼以實現自動脫殼便於服務器自動化分析，半年後公司倒閉，源代碼又吃灰去了...
印象裡DexHunter也是那個時候發佈的,當時考慮到殼早晚會出現抽代碼的保護措施，想來想去最終沒采用，仍然去搞我的模擬器版“火眼”去了，第一個版本出來後一個月，公司倒閉，吃灰....
一起吃灰的還有.....精力最好的年紀如此度過，真叫一個酸爽。
我主業是開發，安全實力很弱雞，這文章可能最終就是一篇垃圾，因為有太多老司機在研究和保護，幹不過他們啊....
獨樂樂不如眾樂樂，目的僅為技術交流討論，還請大家板磚輕拍,謝謝。
0x01 菜刀小試成果
此處為佔位。有了結果我便來更新。
工作實在太忙了，加班加的要炸了!!! 漏洞詳情一個字沒寫呢....
如果報的風險被TSRC認同了，那說明QQFuzz多少還有點用。
如果沒被認同，那也無關緊要，至多新開一貼總結下知識欠缺之處，然後就結束了。
畢竟我不是安全從業人員，沒有太多時間去挖高危。(儘管以我目前對QQ的代碼的理解我認為高危一定是能做到的)
0x02 因緣
“瀏覽器是用戶進入互聯網的第一道門檻,更是網絡攻防對抗的橋頭堡!” --- by 仙果
引用仙果兄的這句話是因為我覺得QQ+微信，在國內可能現在比瀏覽器更當得起攻防的橋頭堡。因為論安裝數的話QQ/微信幾乎覆蓋了全部網民終端，但使用率卻比瀏覽器高很多。
而QQ+微信有獨特的幾個特點是瀏覽器所無法比擬的。
一、點對點攻擊
目標明確，攻擊精準。
二、 主動性強
只要在線，隨時發起攻擊，即時生效。類似xss那種盲打之後只能傻等的痛苦不用體會。
三、多平臺
Windows\Android\macOS\ios. 一點發起攻擊，有可能多點響應。
四、基數大，進程常駐
加上主動性，極小成本大撒網，那影響範圍....
這幾點對於攻擊來講，稱其為具備天時地利人和的利器應該不為過。
但利用這利器卻很困難，甚至聽都沒聽說過，我想原因可能有以下幾點：
1、我的錯覺
一直不是圈裡人，缺少信息來源，也許地下在流通，只是我不知道。
2、挖掘難度高
一個是有太多的安全研究者盯著,同時有專業的團隊防禦著,找到一個有效的漏洞並不容易。
一個是沒工具。cross_fuzz、nmap、metasploit、AFL.... 每個方向都有一大堆，QQ/微信卻沒有一個.....
一個是完全黑盒。沒源碼沒文檔沒標準協議:chromiun/openssl這種是開源的、dom/php/js這種就不說了、word/pdf這種文件協議有很多參考代碼....
3、漏洞標準
看了下我所能搜索到的QQ公開漏洞，業務漏洞居多。
說句不厚道的哈,當我看到那些漏洞的時候第一反應是：都是程序員，誰還不寫個bug啊，程序員何必難為程序員，哈哈。而這裡我們所考慮的是拿下權限的漏洞
4、沒有沉澱
CVE 辣麼多，覆蓋了方方面面，QQ呢？
5、不可抗拒因素
珊瑚蟲，大家都懂的。能分析的人肯定不少，敢用來賺錢的都不敢露面吧。
1和5是技術解決不了的，但234可以用技術解決。
解決的方式就是沒有工具就把工具寫出來，沒有協議就把協議逆出來，雖然這個活不好乾，但這是第一步，總要有人幹才行。
QQFuzzy 就是這個思路。
目標及方式
首先，要明確目標，要不然就像產品提需求，有多少PM自己都不知道自己在想啥瞎提需求?
目標：在用戶環境無汙染的情況下，通過QQFuzz發現攻擊成功的漏洞。
即已將惡意軟件安裝到機器上的不算，網絡劫持不算。類似這種都屬於組合技，是在實施攻擊時的技巧，不屬於漏洞挖掘，這是我的理解，不知道對不對。
按我的理解，QQ漏洞挖掘可分為三部分：
一、瀏覽器部分，即X5Core
這個首先pass，儘管這個可能會更自由。但我沒怎麼分析，不瞭解。
而且這跟瀏覽器攻防有很大一部分是重合的。
二、應用程序部分，即exe\apk\app
二進制漏洞挖掘
三、業務漏洞
太簡單，pass
QQ客戶端分為Windows、Android、MacOs、IOS、Linux、WebQQ 6個平臺,各個平臺又有不同版本。那麼怎樣Fuzzing呢？
常規做法比如afl、Peach、Honggfuzz之類,不管是基於變異的還是基於生成的fuzzer,對於QQ都不太適合,因為折騰半天終於發現個可疑的地方,然後就會發現沒有辦法觸發！！！
即便可以觸發，也效率太低了，Windows的只能Windows用，Android的只能Android用，定位方式完全無法複用,太累了。
於是我就在想，怎樣才可以方便的驗證漏洞是否存在並驗證？是什麼阻礙了觸發和測試？
答案就是：輸入數據和輸出數據被QQ攔腰截斷了。
輸入：完全不能像js一樣寫啥是啥，能不能到達用戶面前都是問題，很多時候到達時已經是另一個樣子。也不能像pdf、word一樣靠文件輸入。
輸出：到了用戶那裡的封包你給改了就會直接丟棄，不丟棄的你不能直接改...
QQ 阻斷的方式就2種，一種是客戶端的對輸入/輸出數據過濾檢查，一種是server的對傳輸數據過濾檢查。
這就決定了無法用通用工具進行Mock，解決辦法也只有2個，一個是Hook，一個是逆向工程。
Hook太累,要處理發送端和接收端,要按功能Hook,各個平臺也不同,測試各種消息體得定位,每次發佈得從頭來一遍,這活又不是搞外掛,能把人搞死。
測試驗證也不方便server 的過濾完全無能為力
放棄
逆向工程
協議總不會三天兩頭兒的改吧？改也不會大換血吧？
測試挖掘那就更簡單了,直接寫代碼就行了,寫代碼能搞定的事都不叫事兒嘛~~
就是還原的過程比較痛苦,準確的說,還原不痛苦,痛苦的是確保你的代碼就是QQ的代碼,要不然啥時候有坑你都不知道。
QQ架構總結、QQFuzzy架構
QQ架構流程圖
圖比較醜陋，湊合看，用Graphviz寫的，便於以後迭代，如果有機會的話。
我把QQ的功能分為三個層次：基礎層、接口層、業務層。
基礎層完全與業務無關，提供基礎功能庫，比如序列化、網絡庫、加解密庫、通訊協議、WebView等。
接口層是連接業務層與基礎層的橋樑,比如消息體、消息路由、與webview的交互規則等。
業務層就是一些基本的功能，比如發送聊天消息。
很棒的設計
從基礎部分代碼來看，按我的理解，在設計之初制訂了一套規則，目的是將業務模塊化，並滿足業務方無論添加什麼新功能都無縫兼容，使業務方專注於業務邏輯開發，基礎也不用被業務方拖著走。
這個規則就是業務消息路由，該路由通過業務名字進行分發。
這個設計天生就具備了強解耦屬性,至多在某些極端場景需要一點輕耦合。
QQFuzzy架構
懶得畫圖了，但總體與QQ的架構方向一致，略有改變。
實現了一套C++版消息機制,參考了IOS的NotificationCenter,並依賴此消息機制模擬實現QQ消息路由、 異步、業務功能獨立、Fuzzy接口實現等。
Fuzzy與QQ自身功能是平行的，目的都是觸發代碼執行，並分類
比如按平臺分類,Android 著重觸發反序列化、反射、so crash、Scheme....Windows 著重觸發崩潰、X5跳轉、XSS...
比如按誘導分,那就著重各種消息、紅包、通知、分享....
總結
總結下我在逆向的過程中的拙劣經驗，供大家參考。
1、不糾結於點，快速推進
這點我浪費了很多時間，而且時間線太長容易遺忘。
還原過程不必參考網絡上的代碼或總結，包括我這篇
主觀原因是我沒找到可參考的，要麼是webQQ的，要麼是抓包特徵碼的，要麼易語言的(看截圖就是特徵碼)...
客觀原因是：紙上得來終覺淺。不親自上手分析很難理解到底怎麼一回事，有問題的話自己還是解決不了。甚至分析的不夠徹底都有可能找不到問題原因。
2、、一開始就做好寫插件或工具輔助分析的準備
腦子好使的童鞋這個就不用啦，我記憶力越來越差了，也越來越懶了，所以寫了一堆的插件來輔助。
我的IDA插件主要功能
註釋、Patch
我的註釋和補丁都是寫在插件中的。當感覺idb有妖的時候,直接刪掉,重新跑一下插件接著分析
結構體定義
結構體定義也是用插件自動生成的,同時生成頭文件,便於同步更新idb和源碼。
偏移計算工具
便於基址變化或版本升級時降低工作量以及其他插件功能使用
流程及架構分析
比如雙向調用鏈
3、類/結構體儘可能搞好
這樣可以便於分析，更好地理解完整流程和保證相似度。
否則，那代碼會慘不忍睹(想象下沒有結構體的1200行的函數是什麼樣子)，說起來全是淚。
4、儘早從架構角度熟悉代碼
架構越早熟悉還原越容易，哪裡風險值高也越清楚。
我的插件裡有個功能就是用來分析架構，分析的結果我存在sqlite數據庫裡，340M。
為了方便閱讀，我還寫過自動生成MarkDown，還寫過自動用graphviz生成流程圖，但都不大好用...
5、組合技一般都挺好用
開發方面掌握Android、IOS開發,逆向方面掌握ARM、smali,會有驚喜哦。
我花費的時間供大家參考：
我總共2次實施完整的還原，協議版本不同，全部為業餘時間。
第一次是2年前，總共花費3個多月。
當時沒經驗，如上面所說代碼慘不忍睹，主要是架構亂，一堆的指針問題，自己都不想看。
第二次是不久前，不到3個月。
時間主要花在架構升級和逆向規範化上，協議本身花的時間很少，最多一個月，現在要測試個什麼很爽。
不負責任YY一則：
假如QQ全網配置清單：
虛擬主機：20w臺
這裡指完全用於QQ自身功能的服務器臺數,即不包括DB、中間件之類。
帶寬：不限
內存：32G.
CPU：E5
全部宕機攻擊成本：7w 肉雞
大家不要認真哈，這裡純屬YY，純屬YY，純屬YY，重要的事情說三遍。
只是從代碼和觀測到的數據來看，我想不出來十分有效的防護辦法，因為這裡是以小博大，和CC、DDOS不是一碼事。
原理我會提交TSRC，可能這壓根就不是問題，貧窮和無知限制了我的想象力。
最終總結
整體難度不高，高相似度還原工作量較大，很容易進坑。
客觀的說，QQ的整個分析過程學習到很多。
現在最欣賞的就是他的基礎架構,這才是實戰出來的好架構,推薦大家都去看看。
同時也看到了該架構的推行阻力或使用不到位,如果有當年負責基礎這一塊的騰訊的兄弟看到這裡,不知我說的對不對？
分析過很多大公司的客戶端,QQ的代碼質量是我覺得最好的之一。
源碼在手，不論是盲測還是定向分析，都很自由
分析難度: Android < IOS < Windows
還原難度：Windows < Android < IOS
這次沒有可直接用的乾貨，對不起大家，如果後面有機會，我拋些代碼出來。
如何使QQFuzzy有意義我還沒想好，我不敢直接放源碼，大家有什麼建議？
不太會寫文章，謝謝觀看
引用文檔
瀏覽器漏洞攻防對抗的藝術 https://bbs.pediy.com/thread-211277.htm
更多幹貨文章，關注看雪學院公眾號 ikanxue~
閱讀更多 看雪學院 的文章
