APV-Leak-gestützte ROP — Pixel 9 / media.swcodec

Kleines, eigenständiges Forschungspaket für CVE-2026-0006 (APV-Decoder-Heap-Overflow). Es demonstriert einen kontrollierten nativen Aufruf in media.swcodec, der in __android_log_assert(NULL, NULL, "RCE-7F3A92C1") endet, wobei die Nonce in einem echten Tombstone sichtbar ist (Abort message: 'RCE-7F3A92C1').

Schnellstart

Voraussetzungen: Pixel 9 gerootet (/debug_ramdisk/su), adb, Python 3.12 mit NumPy. Das Gerät muss die Stock-libobs.so verwenden (kein Instrumentierungs-Overlay).

scripts/build_device.sh   # installiert thumb3.dex und apvscan
scripts/run.sh 12         # bis zu 12 frische Versuche

Bei Erfolg wird RCE PROVATA ausgegeben und out/APVRCE_success.txt geschrieben. artifacts/tombstone_rce.txt ist der aufgezeichnete Erfolg aus dem Referenzlauf.

Kette

Ein frischer media.swcodec-Prozess dekodiert CLEAN_MSG.mp4 (Metadaten, die die Nonce tragen).
Das Nur-Lese-Orakel (apvscan) leitet die Live-Werte ab:
- release@448 - 0x29044 → Codec-Basis;
- GOT[malloc] @ codec+0x2d448 → malloc@libc+0x596f0 → libc-Basis.
gen/gen_forge.py erstellt die APV-Comb-Nutzlast:
- release@448 = libc + 0xede9c (__libunwind_Registers_arm64_jumpto);
- PC = liblog + 0xc250 (__android_log_assert);
- x0=x1=0, x2 = Adresse der Metadaten, die RCE-7F3A92C1` tragen;
- SP zeigt auf eine gültige Plane.
Derselbe Daemon dekodiert JT_LOG.mp4. Das gefälschte release erreicht jumpto, das die Register wiederherstellt und den kontrollierten Log-/Assert-Aufruf ausführt.

Dies ist eine End-to-End-ROP-Demonstration im Zielprozess, kein reiner PC/SP-Nachweis.

Bedrohungsmodell und Grenzen

Modell A: Eine Anwendung dekodiert die präparierte Datei und der Forscher kann die Ausgabe beobachten und die nächste Stufe anpassen. Es ist kein Zero-Click-Exploit.
Der Runner verwendet apvscan als Nur-Lese-Leak-Orakel für release und die beiden GOT- Lesezugriffe. Das hdr10-plus-info-Ausgabe-Leak wurde separat in den Forschungsnotizen validiert; der Runner behauptet nicht, dass die Datei allein diese Werte an eine entfernte Partei exfiltriert.
Der Nachweis ist native Codeausführung in media.swcodec, keine Sandbox-Escape oder Kernel-LPE.
artifacts/JT_LOG.mp4 ist zeiger-/layout-spezifischer Nachweis. Pro Lauf neu generieren; nicht erwarten, dass er universell ist.
Die Zuverlässigkeit ist layoutabhängig. Der Runner wiederholt mit einem frischen Daemon und meldet jeden Fehlschlag, statt eine feste Erfolgsrate zu behaupten.

Aufbau

scripts/pipeline_logprint.py — Leak/Orakel, Generierung, Angriff und Nachweiserfassung.
scripts/build_device.sh — installiert die Laufzeitdateien auf dem Gerät.
scripts/run.sh — startet die vollständige Kette.
gen/ — Nutzlast-Generator und Thumb3-Quellcode/dex.
scanner/ — apvscan-Quellcode und vorgebautes arm64-Binary.
artifacts/ — Referenz-MP4s und der erfolgreiche Tombstone.
docs/ — englische und italienische Blog-Entwürfe sowie build-spezifische Offsets.

Italiano (Zusammenfassung)

Das Paket demonstriert einen kontrollierten nativen Aufruf in media.swcodec, nicht nur die Kontrolle von PC/SP. Der Ablauf ist: frischer Decoder → Ableitung der Adressen → jumpto → __android_log_assert mit der Nonce RCE-7F3A92C1 im Tombstone. Es ist weder eine Zero-Click-Demonstration noch ein Ausbruch aus der Sandbox: Es ist ein ROP-Nachweis im Codec-Prozess, mit den oben beschriebenen Einschränkungen und dem Bedrohungsmodell.

CVE-2026-0006-step-2

Beliebteste