/ 作者簡介 /
本篇文章轉自MegatronKing的博客，分享了Android中https抓包相關的解決方案，希望對大家有所幫助！
/ 前言 /
HTTP協議發展至今已經有二十多年的歷史，整個發展的趨勢主要是兩個方向：效率和安全。效率方面，從HTTP1.0的一次請求一個連接，到HTTP1.1的連接復用，到SPDY/HTTP2的多路復用，到QUIC/HTTP3的基于UDP傳輸，在效率方面越來越高效。安全方面，從HTTP的明文，到HTTP2強制使用TLSv1.2，到QUIC/HTTP3強制使用TLSv1.3，越來越注重數據傳輸的安全性。總而言之，HTTP協議的發展對用戶是友好的，但是對開發者而言卻不那么友善。
抓包是每個程序員的必修技能之一，尤其是在接口調試和程序逆向方面具有廣闊的用途。但是，隨著越來越多的通信協議使用加密的HTTPS，而且系統層面也開始強制規定使用HTTPS，抓包似乎是顯得越來越難了。
本篇博客，主要詳解Android平臺下，HTTPS抓包的常見問題以及解決辦法。工欲善其事必先利其器，博客中以HttpCanary作為抓包工具進行講解。更多HttpCanary的資料，請見：
GitHub地址：
https://github.com/MegatronKing/HttpCanary
/ 抓包原理 /
幾乎所有網絡數據的抓包都是采用中間人的方式（MITM），包括大家常用的Fiddler、Charles等知名抓包工具，HttpCanary同樣是使用中間人的方式進行抓包。
從上面這個原理圖，可以看出抓包的核心問題主要是兩個：
- MITM Server如何偽裝成真正的Server
- MITM Client如何偽裝成真正的Client
第一個問題，MITM Server要成為真正的Server，必須能夠給指定域名簽發公鑰證書，且公鑰證書能夠通過系統的安全校驗。比如Client發送了一條https://www.baidu.com/的網絡請求，MITM Server要偽裝成百度的Server，必須持有www.baidu.com域名的公鑰證書并發給Client，同時還要有與公鑰相匹配的私鑰。
MITM Server的處理方式是從第一個SSL/TLS握手包Client Hello中提取出域名www.baidu.com，利用應用內置的CA證書創建www.baidu.com域名的公鑰證書和私鑰。創建的公鑰證書在SSL/TLS握手的過程中發給Client，Client收到公鑰證書后會由系統會對此證書進行校驗，判斷是否是百度公司持有的證書，但很明顯這個證書是抓包工具偽造的。為了能夠讓系統校驗公鑰證書時認為證書是真實有效的，我們需要將抓包應用內置的CA證書手動安裝到系統中，作為真正的證書發行商（CA），即洗白。這就是為什么，HTTPS抓包一定要先安裝CA證書。
第二個問題，MITM Client偽裝成Client。由于服務器并不會校驗Client（絕大部分情況），所以這個問題一般不會存在。比如Server一般不會關心Client到底是Chrome瀏覽器還是IE瀏覽器，是Android App還是IOS App。當然，Server也是可以校驗Client的，這個后面分析。
/ 安裝CA證書 /
抓包應用內置的CA證書要洗白，必須安裝到系統中。而Android系統將CA證書又分為兩種：用戶CA證書和系統CA證書。顧明思議，用戶CA證書是由用戶自行安裝的，系統CA證書是由系統內置的，很明顯后者更加真實有效。
系統CA證書存放在/etc/security/cacerts/目錄下，名稱是CA證書subjectDN的Md5值前四位移位取或，后綴名是.0，比如00673b5b.0?？紤]到安全原因，系統CA證書需要有Root權限才能進行添加和刪除。
對于非Root的Android設備，用戶只能安裝用戶CA證書。
無論是系統CA證書還是用戶CA證書，都可以在設置->系統安全->加密與憑據->信任的憑據中查看：
/ Android7.0的用戶CA限制 /
Android從7.0開始系統不再信任用戶CA證書（應用targetSdkVersion >= 24時生效，如果targetSdkVersion < 24即使系統是7.0+依然會信任）。也就是說即使安裝了用戶CA證書，在Android 7.0+的機器上，targetSdkVersion >= 24的應用的HTTPS包就抓不到了。
比如上面的例子，抓包工具用內置的CA證書，創建了www.baidu.com域名的公鑰證書發給Client，系統校驗此證書時發現是用戶CA證書簽發的，sorry。。。那么，我們如果繞過這種限制呢？已知有以下四種方式（低于7.0的系統請忽略）。
配置networkSecurityConfig
如果我們想抓自己的App，只需要在AndroidManifest中配置networkSecurityConfig即可：
<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
<application android:networkSecurityConfig="@xml/network_security_config"
... >
...
</application>
</manifest>
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config cleartextTrafficPermitted="true">
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
</trust-anchors>
</base-config>
</network-security-config>
這樣即表示，App信任用戶CA證書，讓系統對用戶CA證書的校驗給予通過。更多相關信息，詳見
Network security configuration：
https://developer.android.com/training/articles/security-config
調低targetSdkVersion < 24
如果想抓一個App的包，可以找個歷史版本，只需要其targetSdkVersion < 24即可。然而，隨著googlePlay開始限制targetSdkVersion，現在要求其必須>=26，2019年8月1日后必須>=28，國內應用市場也開始逐步響應這種限制。絕大多數App的targetSdkVersion都將大于24了，也就意味著抓HTTPS的包越來越難操作了。
平行空間抓包
如果我們希望抓targetSdkVersion >= 24的應用的包，那又該怎么辦呢？我們可以使用平行空間或者VirtualApp來曲線救國。平行空間和VirtualApp這種多開應用可以作為宿主系統來運行其它應用，如果平行空間和VirtualApp的targetSdkVersion < 24，那么問題也就解決了。
在此，我推薦使用平行空間，相比部分開源的VirtualApp，平行空間運行得更加穩定。但必須注意平行空間的版本4.0.8625以下才是targetSdkVersion < 24，別安裝錯了。當然，HttpCanary的設置中是可以直接安裝平行空間的。
安裝到系統CA證書目錄
對于Root的機器，這是最完美最佳的解決方案。如果把CA證書安裝到系統CA證書目錄中，那這個假CA證書就是真正洗白了，不是真的也是真的了。由于系統CA證書格式都是特殊的.0格式，我們必須將抓包工具內置的CA證書以這種格式導出，HttpCanary直接提供了這種導出選項。
操作路徑：設置 -> SSL證書設置 -> 導出HttpCanary根證書 -> System Trusted(.0)。
PS. 很不幸的HttpCanary v2.8.0前導出的證書名稱可能不正確，建議升級到v2.8.0以上版本操作。
導出.0格式的證書后，可以使用MT管理器將.0文件復制到/etc/security/cacerts/目錄下，或者通過adb remount然后push也可（這里稍微提一下，別在sdcard里找這個目錄）。
/ Firefox證書安裝 /
火狐瀏覽器Firefox自行搞了一套CA證書管理，無論是系統CA證書還是用戶CA證書，Firefox通通都不認可。這種情況，我們需要將CA證書通過特殊方式導入到Firefox中，否則Firefox瀏覽網頁就無法工作了。
HttpCanary v2.8.0版本提供了Firefox證書導入選項。在設置 -> SSL證書設置 -> 添加HttpCanary根證書至Firefox 中：
點擊右上角復制按鈕將url復制到粘貼板，然后保持此頁面不動，打開Firefox粘貼輸入復制的url。
出現下載證書彈框后，一定要手動勾上：信任用來標志網站和信任用來標志電子郵件用戶。然后確定即可。
/ 公鑰證書固定 /
證書固定（Certificate Pinning）是指Client端內置Server端真正的公鑰證書。在HTTPS請求時，Server端發給客戶端的公鑰證書必須與Client端內置的公鑰證書一致，請求才會成功。
在這種情況下，由于MITM Server創建的公鑰證書和Client端內置的公鑰證書不一致，MITM Server就無法偽裝成真正的Server了。這時，抓包就表現為App網絡錯誤。已知的知名應用，比如餓了么，就采用了證書固定。
另外，有些服務器采用的自簽證書（證書不是由真正CA發行商簽發的），這種情況App請求時必須使用證書固定。
證書固定的一般做法是，將公鑰證書（.crt或者.cer等格式）內置到App中，然后創建TrustManager時將公鑰證書加進去。很多應用還會將內置的公鑰證書偽裝起來或者加密，防止逆向提取，比如餓了么就偽裝成了png，當然對公鑰證書偽裝或者加密沒什么太大必要，純粹自欺欺人罷了。
證書固定對抓包是個非常麻煩的阻礙，不過我們總是有辦法繞過的，就是麻煩了點。
JustTrustMe破解證書固定
Xposed和Magisk都有相應的模塊，用來破解證書固定，實現正常抓包。破解的原理大致是，Hook創建SSLContext等涉及TrustManager相關的方法，將固定的證書移除。
基于VirtualApp的Hook機制破解證書固定
Xposed和Magisk需要刷機等特殊處理，但是如果不想刷機折騰，我們還可以在VirtualApp中加入Hook代碼，然后利用VirtualApp打開目標應用進行抓包。當然，有開發者已經實現了相關的功能。詳見：
案例1：
https://github.com/PAGalaxyLab/VirtualHook
案例2：
https://github.com/rk700/CertUnpinning
不過，這里CertUnpinning插件的代碼有點問題，要改改。
導入真正的公鑰證書和私鑰
如果Client固定了公鑰證書，那么MITM Server必須持有真正的公鑰證書和匹配的私鑰。如果開發者具有真正服務端的公鑰證書和私鑰，（比如百度的公鑰證書和私鑰百度的后端開發肯定有），如果真有的話，可以將其導入HttpCanary中，也可以完成正常抓包。
在設置 -> SSL證書設置 -> 管理SSL導入證書 中，切換到服務端，然后導入公鑰證書+私鑰，支持.p12和.bks格式文件。
/ 雙向認證 /
SSL/TLS協議提供了雙向認證的功能，即除了Client需要校驗Server的真實性，Server也需要校驗Client的真實性。這種情況，一般比較少，但是還是有部分應用是開啟了雙向認證的。比如匿名社交應用Soul部分接口就使用了雙向認證。使用了雙向認證的HTTPS請求，同樣無法直接抓包。
關于雙向認證的原理
首先，雙向認證需要Server支持，Client必須內置一套公鑰證書 + 私鑰。在SSL/TLS握手過程中，Server端會向Client端請求證書，Client端必須將內置的公鑰證書發給Server，Server驗證公鑰證書的真實性。
注意，這里的內置的公鑰證書有區別于前面第5點的公鑰證書固定，雙向認證內置的公鑰證書+私鑰是額外的一套，不同于證書固定內置的公鑰證書。
如果一個Client既使用證書固定，又使用雙向認證，那么Client端應該內置一套公鑰證書 + 一套公鑰證書和私鑰。第一套與Server端的公鑰證書相同，用于Client端系統校驗與Server發來的證書是否相同，即證書固定；第二套SSL/TLS握手時公鑰證書發給Server端，Server端進行簽名校驗，即雙向認證。
用于雙向認證的公鑰證書和私鑰代表了Client端身份，所以其是隱秘的，一般都是用.p12或者.bks文件+密鑰進行存放。由于是內置在Client中，存儲的密鑰一般也是寫死在Client代碼中，有些App為了防反編譯會將密鑰寫到so庫中，比如S匿名社交App，但是只要存在于Client端中都是有辦法提取出來的。
雙向認證抓包
這里以S匿名社交App為例，講解下如何抓取使用了雙向認證的App的HTTPS包。如果服務器使用了Nginx且開啟了雙向認證，抓包時會出現400 Bad Request的錯誤，如下：
有些服務器可能不會返回404，直接請求失敗。接下來看，如何使用HttpCanary配置雙向認證抓包。
首先，解壓APK，提取出.p12或者.bks文件，二進制的文件一般存放都在raw或者assets目錄。
將client.p12文件導入手機，然后在HttpCanary的設置 -> SSL證書設置 -> 管理SSL導入證書中，切換到客戶端（因為需要配給MITM Client），然后導入.p12文件。
由于雙向認證的公鑰證書和私鑰是受密鑰保護的，所以需要輸入密碼：
一般通過逆向可以從APK中提取出密鑰，具體操作這里略過。輸入密鑰后，需要輸入映射域名，這里使用通配符*映射所有相關域名：
導入完成后如下：
可以點進證書詳情查看細節，這個client.p12文件包含公鑰證書和私鑰，是用于雙向認證的。
配置完成后，重新進行抓包，看看效果。
可以看到，之前400 Bad Request的兩個要求雙向認證的請求成功了！
/ SSL重協商 /
有些服務器可能會開啟SSL重協商，即SSL/TLS握手成功后發送請求時服務器會要求重新握手。這種情況一般比較少，但是也不排除，已知的應用比如 10000社區 就使用了SSL重協商。
由于Android系統對SSL重協商是有限支持，所以部分系統版本抓包會失敗，表現為網絡異常。在Android 8.1以下，SslSocket是完全支持SSL重協商的，但是SSLEngine卻是不支持SSL重協商的，而HttpCanary解析SSL/TLS使用的是SSLEngine。在Android 8.1及以上，SSLEngine和SslSocket統一了實現，故是支持SSL重協商的。
所以，如果確認服務器使用了SSL重協商，請使用8.1及以上版本系統進行抓包。
/ 非Http協議抓包 /
如果確認了以上幾點，HttpCanary仍然抓包失敗，那么極有可能使用的并非是HTTP協議。比如像微信聊天，視頻直播等，使用的就不是HTTP協議，這種情況需要使用其它的抓包工具，比如Packet Capture這種直接解析TCP/UDP協議的，但是往往非HTTP協議的數據包即使抓到了也無法解析出來，因為大概率都是二進制而非文本格式的。
/ 總結 /
抓包是個技術活兒，需要對網絡協議有大致的了解，對抓包感興趣的同學可以多查閱TCP、UDP、SSL/TLS、HTTP等相關資料。
HttpCanary是專業的HTTP協議抓包工具，專注HTTP協議三十年（吹過頭了），不過目前還不支持QUIC/HTTP3這種新協議，等QUIC/HTTP3正式應用起來再說吧。
