Conscrypt 与 0.0.0.0 现象
抓包时常看到 src/dst 是 0.0.0.0:0——明文数据有了，地址却丢了。这是 Android 13+ 的 Conscrypt 引起的，本篇讲清楚来龙去脉。
现象
明文载荷完整，但 src/dst 全是 0——丢失的只是地址元数据，不影响内容分析。
根因：SSL_get_fd 拿不到 fd
r0capture 算 src/dst 的方式是：拿到 SSL 对象 → 调 SSL_get_fd 得到底层 socket fd → 用 getsockname/getpeername 查地址。
问题出在 Android 13 的 ConscryptEngineSocket。它用 BIO_s_mem（内存 BIO）替代了真实的 socket fd：
新架构下，SSL 对象不直接关联 socket fd，SSL_get_fd 返回 -1 或无效值，于是地址查不出来，填成 0.0.0.0:0。
ConscryptEngineSocket 的两种模式
更细地看，握手前后走的路径不同：
- 握手阶段：走 Java 层
socketWrite0，r0capture 的 Java hook 能抓到，但内容是密文握手包（ClientHello 等），地址是真实的。 - 握手后：走 native
SSL_read/SSL_write，抓到的是解密明文，但SSL_get_fd无效→地址0.0.0.0:0。
这就是 pcap 双层结构的来源：密文层（真实地址）+ 明文层（0.0.0.0）。
影响：明文 OK，地址缺失
怎么补救地址
虽然 0.0.0.0:0 看着碍眼，但内容分析不受影响，且有几条补救路径：
- 看密文层：pcap 里 Socket hook 抓的密文记录有真实 IP，可对照。
- 从明文里读 Host 头：
Host: example.com直接告诉你对端是谁。 - 从 TLS SNI 读：握手包里的 Server Name Indication 字段有域名（密文层握手包可解析）。
不是所有连接都 0.0.0.0
--selftest 用 HttpsURLConnection，有时走的是传统 SSLSocketImpl（非 EngineSocket），这种情况 SSL_get_fd 能拿到 fd，地址是真实的 172.17.0.5 → 104.20.23.154。实测 selftest pcap 里两种都有。
结论
0.0.0.0:0 是 Android 13+ Conscrypt 的已知现象，不是 bug。明文数据完整可用，地址缺失可从密文层或 Host 头补救。这是 r0capture 在新安卓上的固有限制，不影响绝大多数分析场景。
下一篇：多机并发抓包 →