收发包函数定位

逆向时最常见的需求：App 发了这个请求，但到底是哪行代码发的？ r0capture 在每次 SSL_write 时打印 Java 调用栈，一眼锁定发包函数——加密/签名算法通常就在调用栈上方不远处。

调用栈是怎么来的

SSL_write 是 native 函数，但它的调用方是 Java（通过 JNI）。r0capture 在 hook 里调用 Thread.currentThread().getStackTrace()，把从业务代码到 SSL_write 的整条链路打出来。

看一条真实的调用栈

抓 F-Droid 发包时，输出大概长这样：

[SSL_write] 0.0.0.0:0 --> 0.0.0.0:0
GET /fdroid/repo/index.xml HTTP/1.1
Host: f-droid.org
...
调用栈:
  at libssl.so SSL_write (Native)
  at org.conscrypt.NativeCrypto.SSL_write(Native Method)
  at org.conscrypt.ConscryptFileDescriptorSocket
  at okhttp3.internal.connection.RealCall.execute(...)
  at org.fdroid.fdroid.data.RepoUpdater.update(...)
  at org.fdroid.fdroid.UpdateService.onHandleIntent(...)

从下往上看：UpdateService → RepoUpdater.update → OkHttp → Conscrypt → SSL_write。业务发包逻辑在 RepoUpdater.update 里。

定位加密/签名算法的套路

很多 App 的请求带签名头（X-Sign / sign= 参数）。这些签名是在发包前算好塞进 header 的，所以签名函数一定在调用栈里 SSL_write 的上方：

操作流程：

1. r0capture 抓包，定位到带签名的那个 SSL_write
2. 看它的调用栈，找到最上面那个 App 自己的类方法（不是 OkHttp/Conscrypt 的）
3. 那个方法附近就是签名算法所在
4. 配合 frida / jadx 进去细看那个方法

输出重定向过滤

抓包日志很多，把输出重定向到文件再过滤：

python3 r0capture.py -U -f cn.soulapp.android -v >> soul.txt
grep -A20 "SSL_write" soul.txt      # 看每次发包的调用栈
grep "at cn.soulapp" soul.txt       # 只看 App 自己的栈帧

默认就开

收发包函数定位在 Spawn 和 Attach 模式下默认都开启，不用额外参数。

下一步：客户端证书导出 →