最近感觉自己把做客户端，玩成了做服务端的感觉。凌晨一两点老大还在群里吼，整个人都不好，每天精神都很敏感。一次线上的重大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，达到中间人攻击的效果，给客户端返回自定义的数据。
