引子
前面写过一篇有关ssl-pinning的文章，里面具体介绍了应用阻止中间人攻击的ssl-pinning方案与反制该方案的方案。但是这篇文章在面对FaceBook体系的应用时就不在适用了。通过对Instagram的最新v92.0.0.12.12版本分析后，我得出了以下结论：
FaceBook体系的应用采用的反抓包方案的具体理论依然是ssl-pinning，不同的是FaceBook体系应用使用的通信体系不在是我们平常最常见的那套(如iOS平台的NSURLConnection、NSURLSession、AFNetworking)，因此基于这套体系构建的SSL Kill Switch就不在适用了。
分析思路
首先打开SSL Kill Switch后，使用抓包工具无效，考虑很可能是应用代码中对服务器下发的证书做校验。
其次从导出的头文件中搜索应用中与网络通信相关的头文件，尝试用networking/didReceiveChallenge/policy/evaluateServerTrust等经常与网络通信、证书效验相关的关键字搜索可疑代码并用动态调试验证，最终没有定位到想要的证书检验代码。
NSURLSession中证书校验回调
AFNetworking中证书校验通常会重写Policy类
这一步是具体了解Instagram应用代码的过程，通过上面的探索，应该能够发现Instagram中的通信代码既没有使用NSURLConnection、NSURLSession，也没有使用AFNetworking网络库。自然可以做这样两种假设：要么它在上层使用了一种我们经验范围之外的网络库，要么它在下层用c/c++代码实现了一套http通信框架。那么第二种可能性无疑是最高的，毕竟它是FaceBook哎。顺着这个思路，如果足够机敏的话，一个叫proxygen的字符很快就能进入我们的眼帘，它是FaceBook开源的一套用c/c++实现的http/https网络库。没错吧，FaceBook无论什么都会有自己的一套轮子，还好这套轮子是开源的。
是的，一旦定位到这个库，这个抓包的问题可以说已经解决了70%了，剩下的工作就是从这个网络库的源码中定位证书校验的代码。
通过proxygen库走到Fizz库，最终可以发现fizz/protocol/DefaultCertificateVerifier.cpp的verify函数正是我们要找的证书校验接口。这个函数里使用了openssl库提供的X509_verify_cert接口来校验证书的合法性。因此破解方法很简单：定位这个接口的地址，hook将使该接口永远返回1即可。
临门一脚
在实施上面的破解方案时，悲剧的发现Fizz这个库竟然使用的是最新版本的TLSV1.3版本协议，而charles工具竟然没有支持，导致其一直报下图中的错误。
因环境导致无法使用Charles抓包，此为Burp出现该问题
最后在这篇文章中找到合适的解决办法：使用java 11命令行运行Burp来抓包，最终，Instagram的外衣成功地被脱掉了，enjoy it!
抓包效果
尾注
这篇文章的标题强调了FaceBook体系应用的抓包，也就是说这篇文章所说的思路适合于FaceBook旗下所有使用了ProxyGen网络库的应用，而不仅仅是适用于Instagram。
另外，本人将手头上一些不是太重要的算法放在了这个平台上，欢迎大家光临。
网友评论