Charles 原理和进阶使用(charles使用方法)
Charles 简介
Charles 是 PC 端常用的网络封包截取工具, 也可以抓取移动端的网络请求。除了调试接口外，Charles 也可以用于分析第三方应用的请求。配合 Charles 的 SSL 功能，Charles 还可以分析 Https 协议。 Charles 支持如下协议：
HTTP/1.1
HTTPS
HTTP/2
ws（WebSocket）
wss（WebSocket Secure，TLS 加密的 WebSocket） SOCKS
Charles 是收费软件，可以免费试用 30 天。试用期过后，未付费的用户仍然可以继续使用，但是每次使用时间不能超过 30 分钟，并且启动时将会有 10 秒种的延时。因此，该付费方案对广大用户还是相当友好的，即使你长期不付费，也能使用完整的软件功能。只是当你需要长时间进行封包调试时，会因为 Charles 强制关闭而遇到影响。
Charels 官网和文档
www.charlesproxy.com/
www.charlesproxy.com/documentati…
Charles 抓包原理
中间人攻击（Man-in-the-middle attack，缩写：MITM）
中间人攻击在密码学和计算机安全领域中是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。
HTTP 抓包原理
浏览器（Client）从端口号 56075 发起一个请求，请求发送到本地 Charles 监听的 8888 端口（MITM Server），这个连接直接在本机进行
收到浏览器的请求后，Charles 再从端口号 56076 （MITM Client）发起一个新的请求，因为这个网络包要入公网，所以 IP 为 192.168.31.44（我的电脑 IP 地址，下节会介绍）； cdn.staticfile.org （Server）的 IP 为 111.63.183.223，因为是 HTTP 请求，所以端口号为 80
111.63.183.223:80 返回一个 HTTP 响应到 Charles 的代理客户端 192.168.31.44:56076
Charles 内部做了一些处理（Capture & Analysis），然后把响应报文通过 8888 端口发送到 127.0.0.1:56075，到这里浏览器就收到了响应
HTTPS 流程
客户端发起 https 请求,连接到 server 的443接口
服务端收到请求后把证书+公钥传给客户端
客户端解析证书,如果没有问题,用加密算法生成一个对称密钥,然后用公钥加密这个密钥
把加密后的密钥+数据传给服务端
服务端用私钥解密得到对称密钥,之后进行对称通信
HTTPS 抓包原理
看起来很安全了吧,但中间人攻击又是怎么做到的呢?
客户端发起 SSL握手时,中间人劫持用户请求并伪装成客户端发起 SSL 握手.
服务端发送公钥给中间人,中间人截获这个公钥保存起来,并把自己的公钥发送给客户端.
客户端拿到替换后的公钥加密客户端的对称密钥发送请求给中间人, 中间人利用自己的私钥解出对称密钥,这时候中间人已经拿到公钥和对称密钥,再用服务端发给中间人的公钥来加密对称密钥,发送给服务器.
之后客户端和服务端所有的请求的数据都会被中间人利用对称密钥解密得到所有的信息.
所以要抓包 HTTPS, 前提是我们要安装并信任它的证书.
安装证书
选择菜单 Help -> SSL Proxying
Install Charles Root Certificate: PC 安装 Charles 证书并信任改证书
Install Charles Root Certificate On a Mobile Device or Remote Browser: 在移动设备抓包需要安装并信任 Charles 的证书
PC 进行抓包
选择菜单 Proxy -> 勾选 macOS Proxy
点击 Proxy Settings, 按照如下两张图片配置
选择 Proxy -> SSL Proxying Settings, 开启 SSL 代理, 并监听所有的 Host 和 Port 的请求
这样我们就在 8888 端口开启了抓包服务,所有的PC端请求都可以截获并显示了。
如果之前已经在PC端安装并信任了证书,也可以抓包并显示HTTPS请求了
移动端抓包
选择移动设备的 wifi 进入配置页面, 配置ip为统一局域网环境下的 pc 的 ip 地址, 和 charles 监听端口 8888.如果之前已经在移动设备上安装并信任了 Charles 证书, 就可以抓包并显示 HTTPS 请求了。
有些三方应用为啥无法抓包
证书固定（Certificate Pinning）
证书固定（Certificate Pinning） 是指客户端内置了服务端真正的公钥证书。
在 HTTPS 请求时，服务端发给客户端的公钥证书必须和客户端内置的公钥证书一致才能请求成功。一般对安全比较重视的公司会采取这种操作。
在这种情况下，利用 Charles 抓包时，Charles 的公钥证书和客户端的公钥证书不一样，伪造的请求就会被驳回，我们就抓包失败了。那么这种情况怎么解决？
Hack 之路，刷机 ROOT或者越狱，借助工具移除 APP 中固定的公钥证书；
另一条是正路，你拥有这个 APP 的开发权限，那么一般你也就拥有了公钥证书和随之配套的私钥，我们可以把证书和私钥导入到 Charles 中，解决证书固定引起的困扰。
Charles 导入公钥证书和私钥比较简单，点击 Charles -> Proxy -> SSL Proxying Setting -> Root Certificate，然后导入 .pem 或 p12 文件即可。
证书双向验证
大部分的情况下，TLS 都是客户端认证服务端的真实性的，但是在一些非常注重安全的场景下（例如匿名社交），部分 APP 会开启 TLS 的双向验证，也就是说服务端也要验证客户端的真实性。
在这种情况，客户端内置了一套公钥证书和私钥。相对于服务端，APP 有很大的砸壳风险，所以公钥证书和私钥一般都是极其隐蔽的，比如说写到库里，隐藏在一个混淆的随机数算法函数里，从而增大破译难度。
掘金 App 内置了证书, 所以无法抓包, 但是它的 web 端可以正常抓包。
修改 HTTP 请求和响应
针对符合条件的请求, 修改它的 header、parmater、path、host、query 和 Body 等
也可以修改响应的结果。
Protobuf 序列化
Protobuf 默认返回的是按照列 number 作为 key 的结果,并不直观, 无法精确知道这些数据的意义。
在 Charles 中选择 View -> Protobuf Settings, 并添加 proto 文件到 Charles在 Charles 中选择 View -> Viewer Mappings, 添加 Protobuf 匹配规则, 重启 Charles 后就可以看到解析之后的 Protobuf 请求了
作者：Bowen_Jin
链接：https://juejin.cn/post/7031438632938373157