抖音爬蟲，當你寫爬蟲抓不到APP請求包的時候該怎麼辦？

這篇文章的主要內容是解決在遇到APP沒有使用Android自帶的HTTP客戶端進行請求，而且對HTTP客戶端的代碼進行了混淆，致使通用工具JustTrustMe失效的問題。而中級篇中除了JustTrustMe之外的全部方法也都會對這種狀況一籌莫展，緣由是中級篇中的一、三、4方法本質上針對的是Android 7.0+系統增長的SSL Pinning方案，而沒法對各個HTTP客戶端本身實現的檢測方案生效。（據說有個叫車速拍的APP就是這種類型呢）
那麼應該怎麼作才能抓到這類APP的包呢？很簡單，依然是使用JustTrustMe之類的Hook工具就行了，只不過咱們須要針對混淆後的名字對原來Hook的部分進行特殊處理。

---

這裏我專門寫了一個樣例APP來進行演示（別抓我，我什麼都不知道），這個APP作的事情就是在你點擊了按鈕以後，對百度首頁發起一次請求，可是這個請求在沒有破解SSL Pinning的正常狀況下是不可能成功的，由於我設置的是一個隨便輸入的證書哈希，因此在請求的時候會由於正常的證書哈希與我隨便輸入的哈希不一樣致使出現請求失敗的狀況。

樣例APP代碼
這個APP我已經編譯好放到GitHub上了，有兩個版本，一個是對代碼進行過混淆的，一個是沒混淆的，文末會有下載地址，讀者能夠下載下來本身玩玩。

兩個編譯好的APK
開始演示以前說一下測試機的配置吧，這裏用的測試機是Android 8.1.0的，已經Root+Xposed，同時已經安裝並激活了JustTrustMe。

測試機系統信息

Xposed模塊管理界面-JustTrustMe已開啓

---

咱們先來看一下沒混淆過代碼的版本，裝上以後打開它，而後點擊「點擊發送請求」按鈕。

樣例APP界面
不出意外的話會出現請求成功的字樣，若是出現請求失敗的話多是你網絡問題，證書問題會提示「證書驗證失敗」。
接下來咱們看看混淆過代碼的版本，操做同上。

證書驗證失敗
此次就是證書驗證失敗了，JustTrustMe並無正常生效。

---

咱們將這兩個APK都放到Jadx中反編譯一下看看。
在Jadx中反編譯兩個樣例APK
能夠看到混淆過的版本里，okhttp3下的全部類名已經變成了abcd這種名字。
而後咱們來看一下JustTrustMe的代碼。

JustTrustMe代碼中Hook okhttp3的證書驗證部分
能夠看到它的代碼中是對okhttp3.CertificatePinner類下的check方法進行Hook的，這個CertificatePinner類和check方法在沒混淆過的APK中能夠很清楚地看到。

反編譯檢測代碼1
反編譯檢測代碼2
那麼如今JustTrustMe面對混淆後的版本就失效的緣由已經很清晰了，由於它找不到這個okhttp3.CertificatePinner.check，因此根本就不可能Hook到檢測方法，天然不會有任何效果。
因此...應該怎麼辦呢？這裏依然是給出多種方法供讀者選擇：
一、修改JustTrustMe代碼中Hook的類名和方法名而後從新編譯
很簡單，找到對應的檢測方法，把JustTrustMe代碼中Hook的className和methodName改爲混淆後的名字便可，好比在這個混淆後的樣例APP裏，okhttp3.CertificatePinner.check變成了okhttp3.f.a。

反編譯檢測代碼-混淆後
咱們修改JustTrustMe中的Hook部分，一樣改成f和a。

JustTrustMe對okhttp3的證書檢測Hook


修改JustTrustMe對okhttp3的證書檢測Hook
改完以後編譯一下，安裝到手機上替換原來的就行了。
二、使用Frida進行Hook
這個方法比方法1要更方便、更直接一些，由於須要的時候直接修改腳本立刻就能用，不須要從新編譯、重啓手機或APP，這裏直接拿瘦蛟舞大佬寫的解除SSL Pinning腳本修改一下，一樣是修改Hook okhttp3.CertificatePinner.check的部分，改爲混淆後的名字便可。

修改瘦蛟舞的ObjectionUnpinningPlus腳本
三、魔改JustTrustMe，增長一個能夠在運行時根據狀況調整每種HTTP客戶端的SSL Pinning檢測部分的類名和方法名的功能
這個我暫時沒空弄，感興趣的同窗能夠本身實現一下。
四、魔改JustTrustMe，對Hook部分增長動態適配功能，作到即便開發者對代碼進行了混淆也能自動找到真實的檢測類和方法
同上，實現方式能夠參考微信巫師框架部分的自動適配代碼，實現之後理論上來說是最方便的辦法之一，由於是徹底自動的操做，不須要人工介入。
五、修改反編譯APP獲得的代碼再打包回去
我以爲應該沒人會用這麼蠢的辦法吧...用Hook的方式作起來要方便太多了。
選擇任意一種方法操做後，再打開混淆版本的APP就能夠正常請求了。

---

這時候可能會有同窗要問了，怎麼樣知道APP用的是哪一個HTTP客戶端？又怎麼樣快速定位混淆後的檢測方法位置呢？
很簡單，咱們先關掉破解工具，連上代理而後抓個包看看混淆版本APP的請求。

抓包查看請求

User-Agent部分
和平時遇到SSL Pinning的狀況同樣，這裏只會抓到一個CONNECT請求，注意右邊的headers，從User-Agent中能夠看出這個APP使用的是okhttp3，那麼咱們在混淆後的代碼中定位檢測部分代碼的位置時，就只須要對照着okhttp3的原始代碼來找就行了（其餘HTTP客戶端同理）。固然了，也不排除有些APP會把User-Agent改掉，若是從User-Agent上看不出來的話，那就看一下反編譯出來的源代碼部分結構，看看有沒有像okhttp3之類的這種特別明顯的HTTP客戶端的名字，有的話就把它幹掉就行了。


——————————————————————————————————————————

TiToData：專業的短視頻、直播數據接口服務平臺。

更多信息請聯繫： TiToData

覆蓋主流平臺：抖音，快手，小紅書，TikTok，YouTube