使用Fiddler抓HTTP/HTTPS包，Android7.0以後https抓包失敗問題

原部落格位址：https://www.52pojie.cn/thread-967606-1-1.html

抓包的重要性 網絡抓包，是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 轉載請注明出處

20190524002010766.png (170.93 KB, 下載下傳次數: 0)

描述