它能解决什么问题

逆向一个 App 的网络通信，你会撞上一堵又一堵墙。r0capture 的存在，就是把这些墙一次性推倒。

抓 HTTPS 的"三座大山"

山一：SSL 加密——抓包看到的全是密文

普通的 tcpdump / Wireshark 抓的是网卡层的密文。TLS 1.2/1.3 加密后，你只能看到 17 03 03 ... 这样的密文头 + 乱码，完全不知道 App 在跟服务器说什么。r0capture 在 SSL_write（加密前）和 SSL_read（解密后）这两个点截获，拿到的天然是明文。

山二：SSL Pinning——中间人代理直接失败

想用 Charles/mitmproxy 做中间人？现代 App 几乎都做了证书绑定：

Pinning 的 App 在代码里硬编码了服务器证书的指纹，只认这个指纹，代理的假证书直接被拒。传统解法是针对每个 App 逆向找它的 Pinning 逻辑再 patch 掉——耗时、且不同 App 各不相同。

r0capture 完全绕开这个环节：Pinning 的校验发生在"拿到证书→校验→开始加密通信"这个流程里，而 r0capture 的 hook 点在 SSL_read/write，是校验通过之后才发生的事。校验过没过、绑没绑定，跟 r0capture 抓明文毫无关系。

山三：加固壳——找不到业务逻辑

很多 App 套了加固（整体壳、二代壳、VMP），业务代码被加密/混淆，连 App 在哪发包都定位不到。但加固动不到系统层的 OpenSSL 符号：

加固保护的是 DEX 层的 Java 代码，但 App 最终发包还是要调用系统库的 SSL_write。这个函数符号在 libssl.so / libcrypto.so 里是导出的、明文的，加固管不着。r0capture hook 的是这个点，所以加固 App 照样抓。

解决得如何——实测验证

下面这些场景都在云手机（redroid Android 13 x86_64）上实测通过：

场景	结果	证据
抓 HTTP/1.1 明文请求	✅	抓到 GET / HTTP/1.1 + 完整请求头
抓 HTTP/1.1 明文响应 + gzip 解压	✅	chunked gzip body 解压还原 HTML
抓真实 App（F-Droid）OkHttp 流量	✅	1.83MB pcap，82 SSL_read + 29 SSL_write
抓 HTTP/2 流量	✅ 抓到但二进制	PRI * HTTP/2.0 preface + h2 帧
多机并发抓包（3 台）	✅	三台同时各抓到 GET+200
pcap 用 Wireshark/tcpdump 打开	✅	link-type IPV4，seq/ack/flags 全对

详见 实战演练。

已知局限

诚实地说，r0capture 也有抓不到的：

• WebView / 小程序：Chromium 自带 BoringSSL，静态链接，符号不导出，hook 不到。
• Flutter App：Dart 自带独立的 SSL 实现（也是 BoringSSL 静态链接），同上。
• HTTP/2 / HTTP/3：能抓到 SSL 层载荷，但 h2 是二进制帧（HPACK 压缩头），不是明文 GET / 文本，需配合 Wireshark 的 HTTP/2 dissector 才能看懂。HTTP/3 走 QUIC（UDP），目前完全不支持。
• 模拟器：架构/环境复杂，建议用真机或 redroid 云手机。
• 子进程：:service / :push 等子进程暂未支持，可用 Frida 的 Child-gating。

与同类工具对比

工具	思路	证书校验	Pinning	加固	通用性
tcpdump/Wireshark	抓网卡密文	N/A(密文)	N/A	N/A	全协议但密文
Charles/mitmproxy	中间人代理	需装根证书	❌ 失败	❌ 失败	需逐 App 绕 Pinning
r0capture	Hook SSL 层	无视	无视	无视	通杀系统 SSL 栈

下一步：快速开始 →