用Charles配合WireShark找到元凶

       最近感觉自己把做客户端，玩成了做服务端的感觉。凌晨一两点老大还在群里吼，整个人都不好，每天精神都很敏感。一次线上的重大bug，app瘫痪了一个小时，彻底让人怀疑人生。这都是钱呀！/(ㄒoㄒ)/~~

　　起因

　　大概晚上九点多，服务端上线了一套新的功能。因为一般情况下不会对客户端造成什么影响就没有经过QA。但一上线不久，iOS客户端线上的一打开闪退，根本无法用。大佬气得都快炸了，后经服务端代码回滚，还是一打开就闪退。

　　由于线上的app是经过**企业重签名的渠道，非AppStore渠道，所以客户端无法联机调试。

　　现象很奇怪：

　　如果断网情况下，可以进入app，过一段时间重新联网就可以正常使用

　　服务端确实改了部分接口代码，但是已经回滚了，还是闪退。

　　之前上线AppStore的版本没有闪退

　　自己打的包根本就不会闪退，只有经过企业重签的才会闪退。

　　最开始猜测跟服务端回滚不彻底导致的，可是从AppStore下载的是可以正常使用。自己打的包又没有出现崩溃的现象。根据app是在启动的时候就会崩溃，定位到是app请求全局配置的时候就崩溃了，连signup都没走到。

　　因为无法连接崩溃版本直接测试，于是想到通过抓包工具，抓取到底是哪个接口反馈的数据出现了问题。问题转移到抓包解析错误结果。

　　抓包分析

　　首先用到了WireShark。一般使用Wireshark只能看到ip地址，但是看域名更方便更简明。想看域名需要简单去设置一下。

　　抓到的数据如下：

　　但是由于现在用的都是https，如果不解密根本看不了返回了什么内容。这他妈就尴尬了。

　　网上搜了一下究竟有什么办法可以让wireshark解密数据？大致可以通过下面几种方法来使wireshark能解密https数据包。

　　中间人攻击;

　　设置web服务器使用RSA作为交换密钥算法;

　　如果是用chrome,firefox，可以设置导出pre-master-secret log，然后wireshark设置pre-master-secret log路径，这样就可以解密了。

　　一看这种就得花大把时间去弄。于是转到了使用Charles抓包的思路上

　　虽然Charles并没有WireShark那么牛逼，但是在客户端抓包分析方面确实比WireShark简单不少。

　　使用Charles抓包https几个需要注意的地方这里提示一下。

　　没正确设置的时候左边显示如下：

　　设置正确之后：

　　一、安装SSL证书到手机设备

　　点击 Help -> SSL Proxying -> Install Charles Root Certificate on a Mobile Device

　　出现弹窗得到地址 chls.pro/ssl

　　在手机Safari浏览器输入地址 chls.pro/ssl，出现证书安装页面，点击安装

　　手机设置有密码的输入密码进行安装

　　iOS 10.3之后系统，需要在 设置→通用→关于本机→证书信任设置 里面启用完全信任Charles证书

　　二、Charles设置Proxy

　　Proxy -> SSL Proxying Settings...

　　勾选Enable SSL Proxying,点击Add

　　设置端口443

　　分析数据

　　通过分析请求的域名，对比发现自己打的包一起启动请求的数据和三个域名相关。而通过企业重签名的包和四个域名想。

　　自己打的包：

　　企业重签名的包：

　　对比下来最终确定是企业重签名的包多了一个www.开头的请求。

　　但是到这里还是无法保证就是这个请求这个域名导致的问题。接下来就是通过修改本地的host文件，把上面的几个域名重定向到本地127.0.01。一个一个去排查到底是哪个域名导致的。

　　通过更改本地Host，强制让请求这个域名的接口不返回数据。

　　最终的确没有发现崩溃了。

　　原因就是请求这个域名导致的。这个时候大家已经找大线索。顺藤摸瓜，肯定是重签名导致的，后来结果和对方沟通。是因为重签名在我们包里面加了一些hack代码，应该和注入dyld差不多，第一次感受到iOS还是要走正规渠道发布才行。

　　总结

　　市面上的重签名服务太不靠谱，莫名其妙给你插入一些不可靠的代码

　　控制变量法，??在解决问题上还是很管用的

　　常见的抓包技巧以及host的这些还是要掌握。比如可以通过Charles设置代理，然后修改host，达到中间人攻击的效果，给客户端返回自定义的数据。

　　

  上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8052)，我们将立即处理。