ROP assistito da leak APV — Pixel 9 / media.swcodec

Pacchetto di ricerca piccolo e autonomo per CVE-2026-0006 (heap overflow del decoder APV). Dimostra una chiamata nativa controllata in media.swcodec, che termina in __android_log_assert(NULL, NULL, "RCE-7F3A92C1") con il nonce visibile in un vero tombstone (Abort message: 'RCE-7F3A92C1').

Avvio rapido

Requisiti: Pixel 9 con root (/debug_ramdisk/su), adb, Python 3.12 con NumPy. Il dispositivo deve usare il libobs.so stock (nessun overlay di strumentazione).

scripts/build_device.sh   # installs thumb3.dex and apvscan
scripts/run.sh 12         # up to 12 fresh attempts

In caso di successo stampa RCE PROVATA e scrive out/APVRCE_success.txt. artifacts/tombstone_rce.txt è la cattura del successo della run di riferimento.

Catena

1. Un nuovo media.swcodec decodifica CLEAN_MSG.mp4 (metadati che trasportano il nonce).
2. L'oracolo in sola lettura (apvscan) ricava i valori live:
   • release@448 - 0x29044 → base del codec;
   • GOT[malloc] @ codec+0x2d448 → malloc@libc+0x596f0 → base di libc.
3. gen/gen_forge.py costruisce il payload comb APV:
   • release@448 = libc + 0xede9c (__libunwind_Registers_arm64_jumpto);
   • PC = liblog + 0xc250 (__android_log_assert);
   • x0=x1=0, x2 = address of the metadata carrying RCE-7F3A92C1`;
   • SP punta a un plane valido.
4. Lo stesso daemon decodifica JT_LOG.mp4. Il release forgiato raggiunge jumpto, che ripristina i registri ed effettua la chiamata log/assert controllata.

Questa è una dimostrazione ROP end-to-end nel processo target, non una prova basata solo su PC/SP.

Modello di minaccia e limiti

• Modello A: un'applicazione decodifica il file craftato e il ricercatore può osservare l'output e adattare lo stadio successivo. Non è un exploit zero-click.
• Il runner usa apvscan come oracolo di leak in sola lettura per release e per le due letture GOT. Il leak dell'output hdr10-plus-info è stato validato separatamente nelle note di ricerca; il runner non afferma che il solo file esfiltri quei valori verso una parte remota.
• La prova è l'esecuzione di codice nativo in media.swcodec, non un sandbox escape o un LPE del kernel.
• artifacts/JT_LOG.mp4 è un'evidenza specifica per puntatori/layout. Rigeneralo a ogni run; non aspettarti che sia universale.
• L'affidabilità dipende dal layout. Il runner riprova con un daemon nuovo e riporta ogni fallimento invece di dichiarare un tasso di successo fisso.

Struttura

• scripts/pipeline_logprint.py — leak/oracolo, generazione, attacco e cattura delle evidenze.
• scripts/build_device.sh — installa i file runtime sul dispositivo.
• scripts/run.sh — avvia l'intera catena.
• gen/ — generatore di payload e sorgente/dex di Thumb3.
• scanner/ — sorgente di apvscan e binario arm64 precompilato.
• artifacts/ — MP4 di riferimento e il tombstone del successo.
• docs/ — bozze di blog in inglese e italiano più gli offset specifici della build.

Italiano (sintesi)

Il pacchetto dimostra una chiamata nativa controllata in media.swcodec, non solo il controllo di PC/SP. Il percorso è: fresco decoder → derivazione degli indirizzi → jumpto → __android_log_assert con il nonce RCE-7F3A92C1 nel tombstone. Non è una dimostrazione zero-click né un escape dal sandbox: è una prova ROP nel processo codec, con i limiti e il modello minaccioso sopra descritti.