使用wireshark抓包軟件分析微信協議--zucc

• 因爲csdn自動壓縮了上傳的圖片，導致高清圖非常的小，稍後將發佈可以下載的文檔說明 下載地址，可以看到超清的圖片，請自行下載

• （現在經過朋友反應實在太小，重新截了一次圖，這次是正常比例，但是改變了高清分辨率，如若需要高清，還是請下載）
• https://download.csdn.net/download/sos768/11230576

---

• 1.通過使用wireshark分析網絡協議。
  2.瞭解微信認證、聊天協議。

---

• 有朋友配置AP的時候遇到了一些麻煩，如果相處於同一個wifi時候，又不想用手機的熱點，用宿舍的網線的話，可以使用這個： http://wifi.ggsafe.com/
• 如若軟件出錯，請自行搜索: http://wifi.ggsafe.com/faq.shtml
• 或者可以私聊博主，借用無線wifi 網卡usb進行配置

二、實驗內容原理實驗結果與分析

1.選擇微信使用模式（微信App或者網頁微信），合理配置網絡環境。
【實驗步驟】

• 使用mac進行wireshark抓包，並選擇使用客戶端微信,同時將機器置於手機熱點wifi之下
  
• 可以看到當前實驗機器獲得的ip爲 172.20.10.2
  所以當前連接的AP站點ip爲172.20.10.1

【實驗結果與分析】

配置當前的ip以及微信所在的實驗環境，如上圖所示

2.分析微信登錄認證方式。

【實驗步驟】

• 因爲不必要的ipv6的信息傳輸干擾，所以先屏蔽了一些ipv6的信息
• 以下是我之前使用的笨方法，一個一個去屏蔽
  
• 經過朋友提醒，還可以這麼做，直接ip篩選，效果是一樣的：

• 從上圖可以看出，我的電腦獲得的ip是172.20.10.2，並且網關是172.20.10.1

• 此時，我的電腦正在發出dns，域名查詢的包，之所以是8.8.8.8，是因爲我對電腦做了一些配置，如下圖所示，我的電腦會默認向一下兩個dns服務器發出請求，(10.61.10.10是學校的dns服務器之一emm)。
  

• 當我們拆開去解讀消息的時候會發現他的query是去查詢這個域名 szshort.weixin.qq.com。並且在之後dns返回了查詢到的IP
  
  

• 當我打開完客戶端，掃了二維碼之後但還沒在手機按下確認鍵的時候，我的wireshark抓到了這些包，看樣子是在獲取二維碼和一些相關的信息。
  

• 點擊確認之後，從抓取的包裏面也可以看出，雙方在不停的發包並進行ssl加密傳輸，和一些相關的認證信息。
  
  

• 建立連接，並且獲取一些好友隊列的信息
  發送post請求進行data驗證並且獲取消息。
  

【實驗結果與分析】

成功與服務器進行了連接，並且認證成功

3.分析微信好友聊天過程。

【實驗步驟】
作爲測試，發送了四條消息:

• 做完實驗後，又去查了以下相關資料，原來抓包軟件可以進行設置成ip顯示成域名，下圖是對之後實驗的ip更直觀的一種顯示
  

握手協議，也是一次認證

• 一共抓到了以下這些包，經過分析，可以確定此次信息傳輸是與之前dns查詢中查到一個服務器121.51.140.144進行了交互

• 進行以下篩選，172.20.10.2是我電腦的ip地址
  

• 可以看到信息數據乾淨了許多，繼續進行分析
  

• 前三個包是在進行tcp三步握手認證，由我的電腦向服務器發送syn請求，服務器收到後發送syn和ack進行確定，最後從客戶端向服務器發送ack完成認證。
  

• 之後從第20個包開始，便一直在進行交互，不斷的進行連接，傳送完消息之後客戶端的Fin斷開連接請求，和之後恢復連接的ack，
  （在發送fin之後，一定時間內，如果客戶端和服務端還有數據交互，兩者可以恢復連接而不需要再進行三步握手認證）
  
  
  

• 期間有一次重置，斷開連接並且重新進行了三步握手認證進行連接
  

• 測試中途發現了一些不是微信服務器的ip頻繁出現，如下圖中的121.51.8.102，在我使用小號進行測試的時候出現了多次，而且其flags是psh和ack居多(數據傳輸)，然後去ip138.com進行了ip查詢，結果與預料相差不大。

• 查詢網站時 ip138.com （僅供參考）
  
  

4.分析微信羣聊過程。

【實驗步驟】

• 選擇了羣聊進行分析，一共發送了以下這些信息：
  

• 使用121.51.24.106進行ssl加密傳輸，在中間傳輸的時候出現了數據重傳的情況，說明當不可達時，數據包會自動選擇進行重傳，直到傳輸成功。
  

• 這一步裏面syn同步請求包也在不斷的重新發送，直到之後的syn+ack包的確認連接使得連接開始建立，非常經典的tcp三步握手認證。

• 與和之前的單獨私聊的過程幾乎一致，只是請求的服務器發生了改變，從121.51.24.144 轉換成了121.51.24.101
  

• 這是客戶端向服務端提交數據和服務端向客戶端發送的迴應包
  可以看到傳送的信息是進行加密之後的，只有提交的data數組 是可以明文可見的，還有服務端的迴應中的code等信息是可見的
  

• 這些http請求和迴應組成了信息交互的大部分過程
  

5. 總結微信聊天協議

• 可以發現微信的聊天信息都進行了ssl加密進行傳輸，並且在選擇服務器的時候會選擇最近的服務器。更容易發現的是，微信的聊天基於http協議，通過get，post與服務器進行交互，穿插在包裏的http響應和請求包足以證明這一點，而當我把傳送數據替換成圖片時，交互的服務器並沒有發生大的改變，依舊是在121.51.24.144和121.51.24.101進行切換交互。

• 對於微信好友頭像的獲取，從wx.qlogo.cn和cwx.qlogo.cn裏進行get獲取
  
  

• 在做完了全部客戶端的測試之後，我又去進行了web端的測試，發現傳輸消息使用的服務器域名爲szshort.weixin.qq.com，文字數據和圖片的傳輸，get和post請求，而在調用地圖的時候，會轉換成另一個服務器去調取數據進行同步。以下是一部分web測試數據。
  

• 對web端來說，原來還有一些密文隨機數的認證方式，且隨時間會發生改變

三、本課程心得及建議

• 在動手實驗的時候，遇到了很多的困難，但在自己的動手實踐，和在不斷的嘗試中獲取的知識來看，這是值得的。
• 在失敗中，我收穫了許多，鞏固了一些基礎知識，在複雜的包堆裏面找到了正確的包，也學會了如何去過濾一些不需要的包，希望這門課之後會更加的廣闊，也希望更多的同學可以收穫寶貴的知識。

---

參考blogs

• https://www.2cto.com/kf/201611/566019.html 這位博主的blog對https中的SSL/TLS講解真的讓我豁然開朗
• https://wenku.baidu.com/view/ae65006a192e45361066f58e.html 這個幫助也挺大的，是這篇報告讓我找到了bug，沒有去找vx獲取頭像的獨立服務器
• https://blog.csdn.net/dxt1107/article/details/77467751 這篇建議指閱讀前半部分，他讓我發現了公衆號是不加密的
• https://blog.csdn.net/hezhipin610039/article/details/50099685 這篇是講http抓包的，對爬蟲挺有幫助的
• https://download.csdn.net/download/zhangmiaoping23/8722179 這是第2個參考的blog裏的pdf版本，但是太貴了- -，而且不值得