iOS逆向工程（10）破解任意 APP HTTPS 加密

前提说明

• 我们经常会遇到很多APP的 HTTPS 接口请求，Charles 安装证书后也无法进行抓包看到内容。
• 为什么要抓包呢，如果我们能够抓取APP任何的请求，那么就可以干很多事情，比如分析接口返回数据，分析下发内容，分析性能，分析图片，分析接口，等等很多用途。
• 所以本篇文章主要是讲是针对这种抓不到HTTPS 加密请求的解决方案和问题探究。

涉及

• 脱壳（Frida 脱壳，脱壳后才能进行修改APP代码）
• 重签名 （非越狱机安装ipa的一种方法）
• 动态注入（修改代码后，注入正常APP）
• MonkeyDev （一种懒人越狱开发环境工具）
• NSURLProtocol （用于拦截请求）
• Charles中间人攻击与HTTPS原理 （了解）

重签名原理，动态注入，脱壳，本篇文章不做详细深入。

目录

• 背景说明
• 猜测连接为 CONNECT 原因导致
• Charles 抓取HTTPS原理
• 逆向思考 - 如何预防Charles 抓 HTTPS 包
  • 客户端判断用户是否代理访问
  • 使用 HTTPS 双向认证
  • 客户端本地证书校验
• 思考解决方案
• 得出最终结论
• 实战破解探探APP，HTTPS网络请求
• 总结

---

一、背景说明

（1）举例

• 例如《探探》APP，抓 HTTPS 的接口
• 

• 可以看到 有些HTTPS请求能够抓到返回内容，有些不能够抓到返回内容。

• 我们知道 MAC 客户端可以通过Charles代理，安装信任Charles证书，然后抓取到HTTPS 请求返回内容。

（2）结论

• 但是还是发现很多APP，例如探探的接口，有的 HTTPS 接口能抓到返回，有的抓不到，很是奇怪，不知原因，所以猜想几个层面去解决。

一、猜测 - 连接为 CONNECT 原因导致。

有听说请求Method 为 CONNECT 就无法进行抓包。

• 实验：尝试抓取项目 HTTPS 请求
• 结论：Method 为 CONNECT
• 

• 实验：开启SSL代理信任证书后

CONNECT结论

• Method 变为 GET ，并且可以抓到HTTPS响应内容。

• 
• 

CONNECT 最终结论

• HTTP 1.1定义了8种方法，CONNECT 只是为其中之一，通常用于SSL加密服务器的链接。

• 当客户端向Proxy发起HTTP CONNECT Method的时候，就是告诉Proxy，先在Proxy和目标服务器之间先建立起连接，在这个连接建立起来之后，目标服务器会返回一个回复给Proxy，Proxy将这个回复转发给客户端，在此之后，客户端跟目标服务器的所有通信都将使用之前建立起来的建立。

• Proxy仅仅实现转发，而不会关心转发的数据。因为HTTPS的数据都是经过加密的，Proxy是无法对Https的数据进行解密的，所以只能使用CONNECT，仅仅对通信数据进行转发。

• HTTPS Method 基本均为 CONNECT （因为是加密的无法解析，只是建立一个通道而已）Charles 中间人攻击后，某些域名开启后可以抓到内容，某些域名依然抓取不到，所以跟 Method 为 CONNECT 没有直接的绝对关系。所以继续往下找原因。

二、Charles抓取HTTPS原理 （简述）

（1）探究

• 思考过后，想了下既然是要解决HTTPS抓包问题，那么也是应该了解下 Charles 抓 HTTPS的原理。

• 了解后知道 Charles 抓 HTTPS 的原理逻辑，其实很简单明了。

• 

• 主要利用中间人攻击原理，代理后Charles 会伪装为客户端和服务器，充当双面间谍。

• Charles作为“中间人代理”，客户端与服务器的交流通信都会经过Charles，所以Charles可以 拿到 服务器证书公钥， HTTPS连接的对称密钥等。

• 既然拿到了对称密钥，那么就可以内容一切都是透明的了。

（2）结论

• 知道了 Charles 抓包原理，并且客户端使用Charles进行中间人攻击，开启了SSL Proxying 代理，按照理论应该是能抓到HTTPS内容的，但是发现抓取 HTTPS 请求还是失败，所以继续探究问题。

三、逆向思考 - 如何预防Charles 抓 HTTPS 包

• 既然前两种方案都不可行，那么思考想了一下不如逆向思维，不去思考如何抓 HTTPS 包，而是去思考果是我们，我们该如何去预防别人 Charles 中间人攻击抓取HTTPS包呢。

进行思考与调研方案后，得出以下几种方法：

（1）判断是否代理访问

• 如果检测出客户端使用代理访问，那么就不允许访问。

（2）使用 HTTPS 双向认证

• 一般做法只有客户端验证服务端公钥证书是不是合法，服务器对来访的客户端身份不做任何限制。如果采用双向验证的方式，在通信过程中，不但客户端验证服务端公钥证书，服务端也会验证客户端 app 的公钥证书。

• 在双向验证中，客户端需要用到保存自己的私钥和证书，并且证书需要提前发给服务器，由服务器放到它的信任库中。

• 如果使用双向验证，这时候就没办法使用 Charles（中间人攻击的方式）进行抓包。

结论

（1）探探APP 防止抓包的方法 猜测

• 首先从表面来看不是客户端端判断是否代理，而禁止访问。
• 在开启SSL Proxying 后依然提示证书问题，所以感觉应该是使用了双向验证或者类似的工程内置证书，进行验证的一种方式。

（2）针对双向验证，破解的方法

• SSL Kill Switch
• didReceiveAuthenticationChallenge
• 修改HTTPS 请求

四、思考解决方案

思考后，准备破解方法，目前想到有几种：

（1）SSL Kill Switch 越狱插件

• 通过hook的方式将校验证书的结果返回true或者干脆不让其做校验。
• https://nabla-c0d3.github.io/blog/2016/02/21/ssl-kill-switch-twitter/
• 缺点：需要越狱。

（2）didReceiveChallenge 代理方法

• 既然客户端有验证证书的处理，那么如果客户端能够信任所有证书，不就解决了问题。
• NSURLSession有个代理方法 didReceiveChallenge ，只要访问的是HTTPS就会调用。
• 该方法的作用就是 处理服务器返回的证书 。
• 如果使用了双向验证和本地证书校验等，客户端应该会在里面进行证书验证处理。
• 如果HOOK 这个代理方法，信任所有证书，那么问题就可以解决了。
  例如一下代码：

- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler{
    //    NSURLSessionAuthChallengeUseCredential = 0, 使用（信任）证书
//    NSURLSessionAuthChallengePerformDefaultHandling = 1, 默认，忽略
//    NSURLSessionAuthChallengeCancelAuthenticationChallenge = 2,   取消
//    NSURLSessionAuthChallengeRejectProtectionSpace = 3,  这次取消，下载次再来问

    if([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]){
        NSURLCredential *credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
        if(completionHandler)
            completionHandler(NSURLSessionAuthChallengeUseCredential,credential);
    }
}

（4）修改Reuquest 请求schme

• 我们知道iOS可以利用NSURLProtocol 拦截请求进行修改.
• 如果能够拦截到所有 reuquest，进行修改HTTPS 为 HTTP 问题也可得到解决。

例如以下代码

    NSMutableURLRequest * mutableReq = [request mutableCopy];
    NSString *originUrlStr = mutableReq.URL.absoluteString;
    NSString *newURLStr =  [originUrlStr stringByReplacingOccurrencesOfString:@"https" withString:@"http"];
    mutableReq.URL = [NSURL URLWithString:newURLStr];

五、得出最终结论

（1）SSL Kill Switch 越狱插件

• 这种方法，需要设备越狱，比较费事，所以不采用。

（2）修改 Reuquest 和 信任所有证书办法可行，但是如何修改探探APP代码呢，是个问题。

• 利用逆向技术即可解决，利用逆向技术可以往APP中注入动态库，进行执行自己想要执行的代码，只要植入NSURLProtocol，在内部进行拦截拿到最高权限，进行信任证书和修改Request等可随意操作。
• 具体步骤可参考之前文章：https://drive.google.com/open?id=1fpesf7U4PnzA0pLajbpD8K2FQL0ko7zH914MMRP05d8

六、实战 - 破解探探APP HTTPS网络请求

（1）首先设备下载探探APP，然后对探探APP进行脱壳。

• 布置好 Frida 脱壳环境，连接设备SSH，对探探APP进行脱壳。

  
  

（2）对探探APP进行重签名，注入NSURLProtocol代码。

• 为了方便，直接利用MonkeyDev 进行重签名和注入。

（3）操作 - 把所有HTTPS 请求 转为 HTTP

• 可以看到所有HTTPS 请求 都转为了HTTP 请求，并且可以看到请求返回JSON内容了。

（4）操作 - 信任所有证书

• 可以看到这时候再次开启SSL Proxying 后，依然也是所有请求内容都能看到了。

总结

• 本篇文章针对越狱相关和加密相关没有特别深入去说明，主要探索出一种破解HTTPS请求的方案。
• 本人只测试了 探探 APP，如果还有不能搞定的，可能还需其它方案去探求解决。
• 目前做到这一步如果扩展思维，利用逆向可以到更多事情，修改探探网络请求，修改代码逻辑，等等。

相关文档

• HTTPS 验证: https://mp.weixin.qq.com/s/UiGEzXoCn3F66NRz_T9crA
• Monkey 使用：https://drive.google.com/open?id=1fpesf7U4PnzA0pLajbpD8K2FQL0ko7zH914MMRP05d8
• Frida脱壳：http://www.alonemonkey.com/2018/01/30/frida-ios-dump/