Fuite APV assistée par ROP — Pixel 9 / media.swcodec

Petit package de recherche autonome pour CVE-2026-0006 (débordement de tas du décodeur APV). Il démontre un appel natif contrôlé dans media.swcodec, se terminant par __android_log_assert(NULL, NULL, "RCE-7F3A92C1") avec le nonce visible dans un vrai tombstone (Abort message: 'RCE-7F3A92C1').

Démarrage rapide

Prérequis : Pixel 9 rooté (/debug_ramdisk/su), adb, Python 3.12 avec NumPy. L'appareil doit utiliser le libobs.so d'origine (sans overlay d'instrumentation).

scripts/build_device.sh   # installe thumb3.dex et apvscan
scripts/run.sh 12         # jusqu'à 12 tentatives fraîches

En cas de succès, affiche RCE PROVATA et écrit out/APVRCE_success.txt. artifacts/tombstone_rce.txt est la capture du succès de l'exécution de référence.

Chaîne

1. Un media.swcodec frais décode CLEAN_MSG.mp4 (métadonnées portant le nonce).
2. L'oracle en lecture seule (apvscan) dérive les valeurs live :
   • release@448 - 0x29044 → base du codec ;
   • GOT[malloc] @ codec+0x2d448 → malloc@libc+0x596f0 → base de libc.
3. gen/gen_forge.py construit la charge utile comb APV :
   • release@448 = libc + 0xede9c (__libunwind_Registers_arm64_jumpto) ;
   • PC = liblog + 0xc250 (__android_log_assert) ;
   • x0=x1=0, x2 = adresse des métadonnées portant RCE-7F3A92C1` ;
   • SP pointe vers un plan valide.
4. Le même daemon décode JT_LOG.mp4. Le release forgé atteint jumpto, qui restaure les registres et effectue l'appel log/assert contrôlé.

Il s'agit d'une démonstration ROP de bout en bout dans le processus cible, et non d'une preuve limitée à PC/SP.

Modèle de menace et limites

• Modèle A : une application décode le fichier forgé et le chercheur peut observer la sortie et adapter l'étape suivante. Ce n'est pas un exploit zero-click.
• Le runner utilise apvscan comme oracle de fuite en lecture seule pour release et les deux lectures GOT. La fuite de sortie hdr10-plus-info a été validée séparément dans les notes de recherche ; le runner ne prétend pas que le fichier seul exfiltre ces valeurs vers un tiers distant.
• La preuve est une exécution de code natif dans media.swcodec, pas une évasion de sandbox ni un LPE noyau.
• artifacts/JT_LOG.mp4 est une preuve spécifique aux pointeurs/à la disposition. Régénérez-le à chaque exécution ; ne vous attendez pas à ce qu'il soit universel.
• La fiabilité dépend de la disposition. Le runner réessaie avec un daemon frais et rapporte chaque échec au lieu de revendiquer un taux de succès fixe.

Arborescence

• scripts/pipeline_logprint.py — fuite/oracle, génération, attaque et capture de preuves.
• scripts/build_device.sh — installe les fichiers d'exécution sur l'appareil.
• scripts/run.sh — lance la chaîne complète.
• gen/ — générateur de charge utile et source/dex Thumb3.
• scanner/ — source apvscan et binaire arm64 précompilé.
• artifacts/ — MP4 de référence et le tombstone réussi.
• docs/ — brouillons de blog en anglais et en italien plus les offsets spécifiques à la build.

Italiano (sintesi)

Le paquet démontre un appel natif contrôlé dans media.swcodec, pas seulement le contrôle de PC/SP. Le chemin est : décodeur frais → dérivation des adresses → jumpto → __android_log_assert avec le nonce RCE-7F3A92C1 dans le tombstone. Ce n'est pas une démonstration zero-click ni une évasion du bac à sable : c'est une preuve ROP dans le processus codec, avec les limites et le modèle de menace décrits ci-dessus.