抖音爬虫，当你写爬虫抓不到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