[[346612]]

每次分析app時都免不了抓包這一環(huán)節(jié)。想要抓到包就要看app采取的什么通信協(xié)議了。由于http存在的種種不安全性，當前大部分的app基本都已經是采用https的通信協(xié)議。所以連抓包也變得越來越不友好。不論是使用burpsuite還是fiddler，當前的抓包工具基本原理都是采用的中間人的方式。原理就是這些工具作為中間人，對客戶端偽裝成服務端，對服務端偽裝成客戶端。

HTTPS
http即超文本傳輸協(xié)議，是互聯(lián)網上應用最為廣泛的一種網絡協(xié)議 ，是一個客戶端和服務器端請求和應答的標準（TCP），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網絡傳輸減少。然而他也存在著一些缺點，比如通信使用明文，內容極易被竊聽；不驗證通信方的身份，因此有可能遭遇偽裝；無法證明報文的完整性，所以有可能遭到篡改。因此，http的加強版https應運而生。https中的s是ssl或者tls，就是在原HTTP的基礎上加上一層用于數據加密、解密、身份認證的安全層。

HTTP + 加密 + 認證 + 完整性保護 = HTTPS

https需要CA證書，我們之前說的中間人需要對客戶端偽裝成真正的服務端，要求就是當客戶端向我們發(fā)送網絡請求時，我們必須能夠給指定域名簽發(fā)公鑰證書，且公鑰證書能夠通過系統(tǒng)的安全校驗。對于我們是不是真正的客戶端，通常來說服務器是不太會關心的，他是不會去關心你是谷歌瀏覽器還是百度瀏覽器，當然了也會有例外。接下來要說的雙向驗證就是如此。

單向驗證與雙向驗證
首先了解一下什么是https的單雙向驗證，主要說一下雙向驗證，雙向驗證相比較單向驗證，增加了服務端對客戶端的認證。

雙向認證詳細過程如下：

（1）客戶端發(fā)起HTTPS請求，將SSL協(xié)議版本的信息發(fā)送給服務端。
（2）服務端去CA機構申請來一份CA證書，在前面提過，證書里面有服務端公鑰和簽名。將CA證書發(fā)送給客戶端
（3）客戶端讀取CA證書的明文信息，采用相同的hash散列函數計算得到信息摘要（hash目的：驗證防止內容被修改），然后用操作系統(tǒng)帶的CA的公鑰去解密簽名（因為簽名是用CA的私鑰加密的），對比證書中的信息摘要。如果一致，則證明證書是可信的，然后取出了服務端公鑰
（4）客戶端發(fā)送自己的客戶端證書給服務端，證書里面有客戶端的公鑰：C_公鑰
（5）客戶端發(fā)送支持的對稱加密方案給服務端，供其選擇
（6）服務端選擇完加密方案后，用剛才得到的C_公鑰去加密選好的加密方案
（7）客戶端用自己的C_私鑰去解密選好的加密方案，客戶端生成一個隨機數（密鑰F），用剛才等到的服務端B_公鑰去加密這個隨機數形成密文，發(fā)送給服務端。
（8）服務端和客戶端在后續(xù)通訊過程中就使用這個密鑰F進行通信了。和之前的非對稱加密不同，這里開始就是一種對稱加密的方式

SSL pinning
SSL Pinning是一種防止中間人攻擊的技術，主要機制是在客戶端發(fā)起請求–>收到服務器發(fā)來的證書進行校驗，如果收到的證書不被客戶端信任，就直接斷開連接不繼續(xù)求情?？梢园l(fā)現中間人攻擊的要點的偽造了一個假的服務端證書給了客戶端，客戶端誤以為真。解決思路就是，客戶端也預置一份服務端的證書，比較一下就知道真假了。
SSL-pinning有兩種方式：
證書鎖定（Certificate Pinning） 和公鑰鎖定（ Public Key Pinning）。

證書鎖定
需要在客戶端代碼內置僅接受指定域名的證書，而不接受操作系統(tǒng)或瀏覽器內置的CA根證書對應的任何證書，通過這種授權方式，保障了APP與服務端通信的唯一性和安全性，因此客戶端與服務端（例如API網關）之間的通信是可以保證絕對安全。但是CA簽發(fā)證書都存在有效期問題，缺點是在
證書續(xù)期后需要將證書重新內置到APP中。

公鑰鎖定
提取證書中的公鑰并內置到客戶端中，通過與服務器對比公鑰值來驗證連接的正確性。制作證書密鑰時，公鑰在證書的續(xù)期前后都可以保持不變（即密鑰對不變），所以可以避免證書有效期問題，一般推薦這種做法。

雙向驗證與SSL pinning的區(qū)別
一定要注意雙向驗證與SSL pinning的區(qū)別！
SSL pinning實際上是客戶端鎖定服務器端的證書, 在要與服務器進行交互的時候, 服務器端會將CA證書發(fā)送給客戶端, 客戶端會調用函數對服務器端的證書進行校驗, 與本地的服務器端證書(存放在.\asset目錄或\res\raw下)進行比對。而雙向認證是添加了客戶端向服務器發(fā)送CA證書, 服務器端對客戶端的證書進行校驗的部分。在app上，https雙向認證的方案也可以防止中間人劫持，但這種雙向認證開銷較大，且安全性與SSL pinning一致，目前大多數app都采用SSL Pinning這種方案。

突破雙向認證抓包
由于私鑰是受密碼保護的，所以主要的逆向目標就是找到key--密碼?？戳撕枚啾砀绲奈恼?，終于學會了一些奇淫巧計。由于當前的app都會有加殼混淆等等防護手段。所以可以到一些應用商店（如360手機助手，豌豆莢等等）下載應用的歷史版本。低版本的保護不多分析難度相對較低。容易找到目標。
首先是到./assets目錄下尋找證書。

確實是有密碼保護的。

繼續(xù)往下看可以看到一些相關信息

這個getSocketFactory就是關鍵函數

可以看到EncryptUtils函數。

看到native需要分析so層。進入so后。

解密即可找到。
找到密碼后，輸入密碼即可

使用xposed hook繞過SSL證書驗證
在全球最大的同性交流網站某hub 下載JustTrustMe
然后在xposed上安裝這個框架就可以了。JustTrustMe的原理就是將各種已知的的HTTP請求庫中用于校驗證書的API都進行Hook，使無論是否是可信證書的情況，校驗結果返回都為正常狀態(tài)，從而實現繞過證書檢查的效果。

總結
抓包是進行app逆向分析的第一步，走好每一步才能走向最后的成功。