抓包的重要性
網絡抓包，是Android應用逆向分析的重中之重，很多時候我們拿到一個APP，不知道從何入手分析，往往是從抓包開始，先弄清楚他與服務器通信的內容，如果一目瞭然，我們完全可以照搬，自行寫一個程序來模擬，如果有一些加密字段和隨機字段，也不用擔心，我們可以從抓包中瞭解到一些關鍵的URL和session之類的信息，然後再反編譯分析代碼的時候，這些字符串可以幫助我們更快的定位關鍵代碼所在之處。
Fiddler的使用
Fiddler簡直是HTTP抓包分析的神器，比Chrome等瀏覽器自帶的調試工具高不知道哪去了，瀏覽器自帶的調試工具，基本只能查看包內容，而Fiddler除了查看，還可以針對不同類型的內容進行格式化，觀賞效果真的不要太爽。除了“看”數據包，它還可以一鍵重發HTTP請求，修改請求內容並重發HTTP請求，攔截修改數據包，返回預設的欺騙性內容等，還可以編寫腳本進行更高級的自動化處理。
廢話不多說，到Fiddler官網下載安裝：https://www.telerik.com/fiddler
接下來，我們要開啓Fiddler的HTTPS抓包功能，否則只能看到HTTP請求的內容，而HTTPS請求則是密文。
在Fiddler中點擊 [Tools] — [Options] — [HTTPS] 勾選如下設置：
然後在 [Connections] 選項卡中勾選 [Allow remote computers to connect]，我們知道Fiddler默認在8888端口開啓HTTP/HTTPS代理服務，不管是Android、IPhone還是PC等等設備和程序，只要設置了HTTP/HTTPS代理，流量從Fiddler走，就可以抓包分析。此處開啓遠程訪問，使得我們的Android/Iphone手機可以在WLAN設置上設置它爲HTTP/HTTPS代理，從而手機上的應用的HTTP/HTTPS流量將從Fiddler走，Fiddler就能捕獲它們。
然後確保手機和PC在同一個局域網中，然後在手機上設置WLAN代理，此處我的PC內網IP地址是192.168.1.100，你需要根據自己的情況進行設置：
然後我們在手機瀏覽器中打開http://192.168.1.100:8888 下載Fiddler根證書並安裝
這是Fiddler解密HTTPS通信的關鍵，Fiddler對HTTPS包解密的原理是中間人攻擊，對客戶端聲稱自己的服務端，對服務端聲稱自己的客戶端，兩頭欺騙。當然要想欺騙成功，前提是讓客戶端信任自己的根證書，接下來就可以愉快的觀看HTTPS請求明文內容了。
暢快的抓包
Fiddler這個抓包方法，不僅對Android有用，對IPhone也有用。接下來在手機上，無論是打開瀏覽器，打開手機上的應用，應用內嵌的WebView，我們都可以在Fiddler中看到HTTP/HTTPS請求內容，但細心查看就會發現，還是有的HTTP包裝不到。一般能抓到包的幾種情況：
- Android內置瀏覽器
- 應用內置WebView
- 應用使用URLConnection或OkHttp發起HTTP請求
抓不到包，很可能目標APP使用了其它HTTP Client，比如自帶一個libcurl的so，那樣最終調用的是系統的Socket API，WLAN上設置的HTTP/HTTPS代理對它無效，但其實這種情況很少，市面上絕大多數的應用，都是使用URLConnection和OkHttp，尤其是近些年的應用，幾乎都是清一色的OkHttp，所以絕大多數情況下都能抓到包，如果抓不到，很可能是應用自己進行了額外的SSL證書校驗工作，根據情況再特殊分析特殊處理。
注意！Android7.0以後抓包失敗
以前我一直都是在Android5.1的手機上抓包分析應用，屢試不爽，但是近來使用Android7.1和Android8.1的手機，發現按照上面設置以後，儘管向Android導入了Fiddler的根證書，還是沒法抓到HTTPS包的內容。
以 [雲閃付] 爲例，具體表現爲APP中的WebView無法打開內容，和網絡斷開了一般，Fiddler中可以看到大量的CONNECT然後就沒有下文了。
回顧之前我們總結的Fiddler抓不到包的原因 《Windows抓包指南②：Fiddler抓不到的包是怎麼回事？》可以猜想，很可能在Android7.0以及以後的版本，即便是導入了Fiddler根證書，但是APP的URLConnection、OkHttp、WebView，仍然不信任系統中導入的Fiddler根證書。
驗證猜想
自行編寫Android應用，分別使用URLConnection、OkHttp發起HTTPS請求，用WebView打開HTTPS的網頁，看看出了什麼錯誤。
try {
OkHttpClient client = new OkHttpClient();
Request request = new Request.Builder()
.url("https://www.csdn.net")
.build();
Response response = client.newCall(request).execute();
String back_data = response.body().string();
}
catch (Exception e){
Log.e("TestHttp", e.toString());
}
運行後果然拋出了異常：
javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
不出所料，和我們之前在Windows上分析的情況一樣，客戶端並不信任我們導入系統的Fiddler根證書，那爲什麼在Android6.0及以前能正常工作呢？經過查閱資料，這個改動果然是從Android7.0開始的。
查看Android官方文檔說明：https://developer.android.com/training/articles/security-config.html
By default, secure connections (using protocols like TLS and HTTPS) from all apps trust the pre-installed system CAs, and apps targeting Android 6.0 (API level 23) and lower also trust the user-added CA store by default.
果然，在Android 6.0 (API level 23)及以前，APP默認信任系統自帶的CA證書以及用於導入的CA證書，Android 6.0 (API level 23)以後，APP默認只信任系統自帶的CA證書，對於用戶導入的不予理會。
也就是說，關於 [network-security-config]，在Android 6.0 (API level 23)及以前默認是這樣的：
<base-config cleartextTrafficPermitted="true">
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
</trust-anchors>
</base-config>
Android 7.0 (API level 24) 及以後是這樣的：
<base-config cleartextTrafficPermitted="true">
<trust-anchors>
<certificates src="system" />
</trust-anchors>
</base-config>
同時在上面的鏈接中，Google也給出了辦法，怎麼在Android7.0及以後的系統中，讓APP信任我們手工導入的CA證書。
那就是在編譯APK之前，在你的Android項目的res文件夾下創建xml文件 [net_security_config.xml] 內容爲：
<?xml version="1.0" encoding="utf-8"?>
<network-security-config xmlns:android="http://schemas.android.com/apk/res/android">
<base-config cleartextTrafficPermitted="true">
<trust-anchors>
<certificates src="system" overridePins="true" />
<certificates src="user" overridePins="true" />
</trust-anchors>
</base-config>
</network-security-config>
然後在AndroidManifest.xml中的application標籤下添加
android:networkSecurityConfig="@xml/net_security_config.xml"
編譯安裝，然後該APP就信任用戶添加的CA證書，從而Fiddler就可以抓到它的HTTPS包並解密內容。
Are You Kidding Me?
什麼？你讓我重新編譯APP？我就是要分析第三方APP的通信協議，你讓我重新編譯微信？重新編譯QQ？
非也非也，還記得我們之前在《Windows抓包指南(一)：Proxifier+Fiddler對第三方程序強制抓包》中說的嗎？
強上！得不到的就強上！三年血賺，無期不虧。
四個解決方案
強上的辦法有四個：
① 重新打包目標APK，修改AndroidManifest.xml
我們可以使用Apktool等工具對目標APK進行解包，添加 [net_security_config.xml] 並修改 [AndroidManifest.xml] 然後重新打包。但是現在很多應用都做了防打包處理，要麼利用Apktool弱點，製造錯誤讓Apktool拋異常，要麼重新打包後程序校驗自身證書，校驗失敗無法啓動，罷工。
② Root手機，安裝Xposed框架，使用JustTrustMe模塊幹它
這個方案實際上就是之前我們在 《Windows抓包指南②：Fiddler抓不到的包是怎麼回事？》中的思路在Android上的實踐。Xposed的JustTrustMe模塊Hook了Android SDK的HTTP庫，強制跳過SSL證書驗證，不管是真證書還是假證書，一律驗證通過，於是Fiddler作爲中間人攻擊製造的假證書也被通過了。
JustTrustMe項目源代碼：https://github.com/Fuzion24/JustTrustMe
需要注意的是JustTrustMe有個坑，不要下載它Github中編譯的Latest release版本，其實那是一個很古老的版本，對於APP內嵌的WebView沒有做處理，安裝以後，URLConnection、OkHttp通信的HTTPS是可以抓到了，但是APP內嵌的WebView仍然出錯。所以最好git clone它的最新源代碼，然後自行編譯。
也可以下載我編譯的最新版本：https://github.com/encoderlee/JustTrustMe/releases/download/v0.3/JustTrustMe_20190516.apk
當然這個方案也有缺點，畢竟手機被Root後，還安裝了Xposed框架，有的APP可是會檢測的，發現手機被Root，或者自身被Xposed Hook，就罷工了。
③退縮，使用Android5.1 Android6.0的手機來抓包分析
④終極大法，購入Google親兒子手機，比如Nexus Pixel，下載Android AOSP代碼，直接修改Android系統源代碼，強行驗證所有SSL證書爲真，編譯，刷機，愉快工作。
愉快的抓包分析
可以看到，在使用了方案②後，Android7.1.2的手機，成功解密APP的HTTPS通信內容
不要高興的太早
此處，雖然依舊能抓到大部分Android APP的HTTP/HTTPS包，但是別高興的太早，有的APP爲了防抓包，還做了很多操作：
① 二次加密
有的APP，在涉及到關鍵數據通信時，會將正文二次加密後才通過HTTPS發送，我們抓包抓到的是一堆二進制base64
② 自帶HTTP Client
像支付寶那樣的變態，自己帶了一個基於so的HTTP Client庫，對於關鍵數據，都不走URLConnection和OkHttp，而是走自己的HTTP Client庫，甚至一些WebView頁面的渲染，都是先用自帶的HTTP Client請求得到json數據，然後填到HTML模板裏面，再在WebView裏渲染出來。
③ SSL/TLS Pinning，APP自帶服務端證書，除了自帶證書什麼都不信
當然，兵來將擋，水來土掩，針對各種情況再逐一對症分析，弄清楚原理，才能解決更多的難題，在逆向工程的道路上走的越遠。
抓包的基本方法已經介紹完畢，後續文章將會分享一些我在工作中遇到的Windows、Android平臺上無法抓包的難題及解決方案，感謝持續關注。。。
本文由encoderlee發表於CSDN博客：https://blog.csdn.net/CharlesSimonyi/article/details/90493122 轉載請註明出處