一个配合 mitmproxy 的 iOS 和 Android 端 HTTP&HTTPS 抓包 APP(非设置系统代理方式)

系统代理方式和虚拟网卡方式

一直比较习惯命令行的工具, 所以一直在用 mitmproxy 抓包

但是通常都是设置手机系统代理的方式, 以及其他很多抓包工具比如 Charles, 都是设置手机系统代理
一些 iOS 端手机端 HTTP 抓包工具即使使用了 Network Extension (VPN), 也是通过设置了系统代理. 而且不如在桌面上查看分析包的可操作性强

通过设置系统代理的方式, 有些 APP 会无视系统代理(APP 开发人员一行代码就可以). 所以自然导致无法抓取那些不走系统代理的 APP

所以写了这个 client 配合 mitmproxy 使用, 原理不是设置系统代理. 而是从网卡级**系统 Transport 层(TCP)**接管流量然后给 mitmproxy, 所以也能抓那些跳过系统代理的 APP.

简单问题和根证书问题

一直喜欢自己写的东西都使用都很简单. 一条命令一个按钮之类的. 但是大家都知道解密 TLS 需要安装根证书. 这个 iOS 和 Android 有很大差别, 而且不同的系统版本也有很大差别, 而且有时安装完 CA, 可能 APP 需要重启才生效. 很多细节吧. 所以如果没研究过的同学这个步骤可能大家需要 google 下.. 而且 Android 新版本好像还区分 User CA 和 System CA, 而安装为 System CA 需要 root, 抓包需求比较多的话还是建议大家单独准备个 root 了的开发机.

录了个视频

所以昨天录了一个视频放在 youtube 上了, (第一次弄录屏视频, 不太专业, 就是用自带的录屏软件录了就传上去了, 多担待):

https://www.youtube.com/watch?v=puES_ayJkEo

下载地址

下面是 AppStore 和 Google Play 的链接, 分别都设了个$4.99 的价格, 没有内购(商店如果展示 App 含内购, 估计是我引入了内购 SDK 忘了移除了). 因为不可抗因素, 苹果说使用了一些技术不让在大陆区 AppStore 上架, 所以 iOS 同学需要非大陆 AppleID 下载

iOS(>=14) https://apps.apple.com/us/app/id1528537342

Android (>=8) https://play.google.com/store/apps/details?id=com.txthinking.mitmproxy

兑换码

如果感觉这个应用能给你帮助的话, 这里针对 iOS 和 Android 分别准备了 20 个兑换码.

领取规则:

这里想请大家帮个忙. 刚申请了 Stripe 支付, 需要 20 笔交易, 来过他们判定规则, 所以我随便 fork 了个查看 IP 的 chrome 扩展(Apache Licence 2.0)加上了国家信息, 收费$1. 想用来攒够 20 笔交易.

https://chrome.google.com/webstore/detail/ipvbar/copjmgogifdfjkaenpallapiidcpkjbm

安装扩展后
点击图标
呈现出来 popup 后(不确定接口速度如何), 点击 Pro
输入 Email, 获取验证码后, 输入验证码(可能在垃圾箱)
支付$1 (不确定 Stripe 支付是不是支持大陆信用卡?)

我收到支付信息后, 会往你的 Email 里发送两个兑换码: 一个 iOS 兑换码和一个 Android 兑换码. 共 20 个人吧. 如果有问题或没收到可以下面 @我.

(那个$1 是月订阅制, 如果你支付了, 建议不要那么快手动结束订阅, 可以在下一个扣费日的前几天停止订阅, 或者方便的话可以支付 2 刀后手动结束订阅 [是结束订阅, 可别申请退款哈], 因为不太了解 Stripe 的判定机制, 所以先谢谢大家)

thisismr2

2020-10-16 15:57:19 +08:00

我尽量系统的解释下抓包的各种情况.

## 首先是拦截流量, 两种情况

* 第一种是配置系统代理

这种方式呢通常是创建一个 http proxy, 然后配置到系统代理上, 如果 app 选择走系统代理(大部分会走, 但是 app 不走系统代理也是开发人员一行代码的事). 所以这种方式有一定的局限性. 不走的就是直连了.

* 第二种是拦截所有 TCP 和 UDP 流量

这是 mitmproxy client 选择的方式, 这种方式的好处是所有流量都能够拦截, 开发人员无视系统代理也没用(因为不工作在系统代理那块).
这里拦截了所有的 TCP 和 UDP 流量(这里刻意排除了 DNS 流量)给 mitmproxy
坏处是 mitmproxy 只能处理 http 和 https 流量, 所以如果某个 app 走的私有 TCP 协议, 那么这部分流量 mitmproxy 就无法处理了, 可能 app 就显示无法连接之类的. 当然介于当前讨论的主题也是 HTTP 和 HTTPS 抓包, 可以理解. (这种情况如果 mitmproxy 后期可以将非 HTTP(S)协议的代理请求也正常处理哪怕不分析包就更好了)

## 关于(SSL)TLS 和单独对称加密的数据

解密 TLS 的原理就是中间人劫持, 所以需要那个根证书.

TLS 又分单向和双向认证

单向认证: 通常 https 的网站啊接口什么的都是单向认证, 所以可以我们用根证书辅助来拦截, 可以正常解包.

双向认证: 也就是服务端会验证客户端的证书, 所以这种是无法解密的(不好理解, 可以理解下面要描述的情况)

单独对称加密: 可以理解为服务端和客户端约定一个密钥, 客户端将密钥编译进代码里. 这种情况, 只有你知道编译进代码里的密钥你才能解密. 所以根证书也是无能为力的.