APV 泄漏辅助 ROP — Pixel 9 / media.swcodec

针对 CVE-2026-0006（APV 解码器堆溢出）的小型、自包含研究包。 它演示了在 media.swcodec 中进行受控的原生调用，最终以 __android_log_assert(NULL, NULL, "RCE-7F3A92C1") 结束，且该 nonce 在真实的 tombstone 中可见（Abort message: 'RCE-7F3A92C1'）。

快速开始

要求：已 root 的 Pixel 9（/debug_ramdisk/su）、adb、带 NumPy 的 Python 3.12。 设备必须使用原厂 libobs.so（无插桩覆盖层）。

scripts/build_device.sh   # 安装 thumb3.dex 和 apvscan
scripts/run.sh 12         # 最多 12 次全新尝试

成功时会打印 RCE PROVATA 并写入 out/APVRCE_success.txt。 artifacts/tombstone_rce.txt 是参考运行中捕获的成功结果。

攻击链

1. 全新的 media.swcodec 解码 CLEAN_MSG.mp4（元数据携带该 nonce）。
2. 只读 oracle（apvscan）推导出实时数值：
   • release@448 - 0x29044 → codec 基址；
   • GOT[malloc] @ codec+0x2d448 → malloc@libc+0x596f0 → libc 基址。
3. gen/gen_forge.py 构建 APV comb 载荷：
   • release@448 = libc + 0xede9c（__libunwind_Registers_arm64_jumpto）；
   • PC = liblog + 0xc250（__android_log_assert）；
   • x0=x1=0，x2 = 携带 RCE-7F3A92C1` 的元数据地址；
   • SP 指向一个有效的 plane。
4. 同一守护进程解码 JT_LOG.mp4。伪造的 release 到达 jumpto， 后者恢复寄存器并执行受控的 log/assert 调用。

这是目标进程中的端到端 ROP 演示，而不仅仅是 PC/SP 层面的证据。

威胁模型与限制

• 模型 A：应用程序解码构造的文件，研究者可以观察 输出并调整后续阶段。这不是零点击漏洞利用。
• 运行器使用 apvscan 作为只读泄漏 oracle，用于获取 release 和两次 GOT 读取。hdr10-plus-info 输出泄漏已在研究笔记中单独验证； 运行器并不声称仅凭该文件就能将这些数值外泄给远程方。
• 该证明是 media.swcodec 中的原生代码执行，而非沙箱逃逸或内核 LPE。
• artifacts/JT_LOG.mp4 是特定于指针/布局的证据。每次运行需重新生成；不要 期望它具有通用性。
• 可靠性取决于布局。运行器会使用全新的守护进程重试，并报告每一次 失败，而不是声称固定的成功率。

目录结构

• scripts/pipeline_logprint.py — 泄漏/oracle、生成、攻击和证据捕获。
• scripts/build_device.sh — 在设备上安装运行时文件。
• scripts/run.sh — 启动完整攻击链。
• gen/ — 载荷生成器以及 Thumb3 源码/dex。
• scanner/ — apvscan 源码和预构建的 arm64 二进制文件。
• artifacts/ — 参考 MP4 和成功的 tombstone。
• docs/ — 英文和意大利文博客草稿以及特定构建的偏移量。

Italiano（摘要）

该包演示了在 media.swcodec 中受控的原生调用，而不仅仅是 PC/SP 的控制。路径为：全新解码器 → 地址推导 → jumpto → 在 tombstone 中带有 nonce RCE-7F3A92C1 的 __android_log_assert。这不是零点击演示，也不是沙箱逃逸：这是编解码器进程中的 ROP 验证，具有上述限制和威胁模型。