1.接入手機,通過wireshark抓取微信數據包。
步驟1、配置虛擬AP:
由於微信的pc網頁版本不容易操作,針對本次分析,我們使用Android手機系統下的微信客戶端進行操作。通過手機連接至pc虛擬的無線網絡進行微信的連接,這樣通過wireshark軟件進行抓包。
win7系統下可以很容易將無線網卡設置為虛擬AP,供其他無線設備接入。
配置腳本如下:
#Vitual_Wifi_setup.bat
netsh wlan set hostednetwork mode=allow ssid="HappyBoy" key=******
#在GUI界面下,將正在使用的某個網絡連接共享給該虛擬AP.
netsh wlan start hostednetwork
netsh wlan show hostednetwork
將手機接入後,可以看到: Number of clients
打開wireshark,能看到在接口列表中已經有虛擬AP了(如圖)。手機接入後,打開微信app,點擊開始抓包,就能抓到微信數據包了。
打開微信客戶端,微信開始登錄,可以看到手機分配到的IP為192.168.137.87, AP站點的IP為192.168.137.1
第一包數據是一個域名查詢,微信客戶端向網絡查詢微信服務器,域名為long.weixin.qq.com的IP地址;
第二包數據是ARP地址解析,AP站點向全網廣播,詢問192.168.137.87對應的MAC地址;
第三包數據是ARP應答,手機告訴AP站點自己的MAC地址;
第四包數據是第一包DNS查詢的應答,將該包數據展開,可以看到:
可以看到,查詢到微信域名long.weixin.qq.com的多個服務器IP。接下來TCP的通信過程表明,微信客戶端選擇了IP為120.204.201.154的主機進行數據傳送。
先是建立TCP連接:第5到第7包數據是TCP的三次握手
首先客戶端向服務器發送標誌為SYN的連接請求,數據包標號Seq=0;
收到請求後,服務器向客戶端發送了帶有SYN和ACK的確認應答,發送序號Seq=0,確認序號ACK=1;接下來,客戶端向服務器發送確認應答,Seq=1, ACK=1. 連接建立完成。
第8到第19包數據是客戶端和服務器之前用HTTP協議相互傳送了一些數據。
第18包是HTTP數據包,它的大小為314字節,其中有用數據長度為248字節,數據最後一行為空行,表明數據已經傳送完畢,如下圖所示:
第20和21包數據是關閉連接。傳送完數據後,主機發出帶FIN的TCP報文,要求關閉連接,客戶端發出確認(第21包數據),連接關閉。
超時會重傳:
第39包:未收到第38包數據的確認應答,超時後,開始重傳;
第42包:第38包數據仍未收到應答,又超時,重傳一次;
第43包:終於收到了第38包數據的應答。
用wireshark抓包得到如下數據
首先是DNS解析,展開第二包數據,可以看到
DNS應答返回了域名mapi.mapabc.com的IP:211.151.71.89
mapabc.com是北京圖盟科技有限公司的網站,是一家致力於互聯網地圖、手機地圖和相關位置服務的互聯網軟件技術服務公司,它是高德成員企業。(有個高德地圖的app)
隨後的幾包數據,是客戶端和該服務器之間相互交換信息。
查詢該IP.發現服務器位於北京。
可以看到,微信客戶端的地點信息被收集起來存儲在服務器中,當客戶端發送附近的人請求時,服務器調用地圖信息,通過計算,得到位於附近的用戶數據,將它們傳給該客戶端。
附近的人---用戶頭像下載過程
第134包:HTTP的GET請求,展開該包:
將請求的地址輸入到瀏覽器,會看到一個用戶頭像;
第135包是服務器端的TCP協議將該頭像分段成兩段(第135包和136包),傳送給客戶端;
第136包標為HTTP包,表示頭像傳送出去了。
第137和138包客戶端收到HTTP傳來的頭像後,向服務器發TCP確認,傳送完成。
1.微信通過內置瀏覽器和服務器交互數據。
微信在應用層使用HTTP協議傳輸數據。微信的聊天對話框如下,點擊網址鏈接,會跳轉到瀏覽器模式,打開該消息對應的網頁。現在手機QQ和微博客戶端都內置了瀏覽器。而且用wireshark抓包發現微信的通信都是用HTTP協議收發數據的,內嵌瀏覽器為網絡通信接口。
微信只有在輸入密碼的初次認證過程中的數據是用SSL加密傳輸的。其他數據,比如聊天數據,地理位置信息等,傳輸過程都沒有加密(源端加密未知)
總結:微信各個功能的數據傳輸,幾乎全都是用HTTP協議
①涉及到位置信息,會調用地圖,常用的有:
map.soso.com 搜搜地圖
maps.google.com 谷歌地圖
mapi.mapabc.com 高德地圖
②微信的好多圖片文件的訪問,都是對wx.qlogo.cn和mmsns.qpic.cn的
③微信登陸的時候,有兩個域名:long.weixin.qq.com和short.weixin.qq.com
short.weixin.qq.com是HTTP協議擴展
tcp短連接,運行8080 port,http body為二進制。
提供API:
用戶登錄驗證;
好友關係(獲取,添加);
消息sync (newsync),自有sync機制;
獲取用戶圖像;
用戶註銷;
行為日誌上報。
long.weixin.qq.com
tcp 長連接,端口為8080,類似微軟activesync的二進制協議。
提供API:
接受/發送文本消息;
接受/發送語音;
接受/發送圖片;
接受/發送視頻文件等。
4.關於”微信與運營商大戰”的思考:
TCP短連接是指通訊雙方有數據交互時,建立一個連接,數據發送完成後,則斷開此連接,即每次連接只完成一項業務的發送;TCP長連接,是指連接建立後保持較長時間而不釋放掉。Android默認的推送服務,採用的是Google的GCM技術,其心跳週期約為28分鐘,這才是所謂“慢”的含義——儘可能降低心跳的頻度,從而達到省電、省流量的目的。
微信客戶端與服務器之間的大部分連接都是TCP長連接,慢心跳。本來是為了能夠給用戶提供即使提醒和通知的方便併為用戶節約耗電。但在中國大陸的2.5G網絡中,如果閒置超過大概5分鐘,運營商的IP網關會自動釋放掉(關閉)連接,心跳週期遠遠達不到28分鐘。為此,Android版本的微信選擇以5分鐘為週期發送心跳連接。這種過於頻繁的心跳連接,加上微信龐大的用戶數量,導致了網絡信令的嚴重佔用。這是最近微信和網絡運營商之間矛盾的原因之一。而且,每一次心跳,都相當於把手機從待機狀態喚醒,以5分鐘為一個週期,每天最大約300次喚醒,這會嚴重消耗手機的電量。
因此,從共贏的角度講,運營商方面,應該升級網絡,加速網絡建設,合理收費;而騰訊公司應該優化微信軟件,儘量減少網絡佔用,以期能達到一個平衡。其實微信帶來的問題遠不止信令佔用這一項,更重要的是,微信的通信模式,使傳統的話音業務和短信業務受到巨大沖擊,尤其微信對短信業務的侵蝕非常大,這才是觸及運營商利益的最大頭。其實這也是一個無法避免的發展趨勢,通信業的發展重心,已經開始由話音業務轉向網絡業務,隨著3G和4G網絡的建設,相信微信所引起的矛盾最終會得到解決。
閱讀更多 爬蟲網工 的文章
