Cosa è stato fatto

1. Analisi del codice sorgente → estrazione degli offset delle strutture

Estratto da arch/arm64/include/asm/memory.h + include/linux/fs.h + android/abi_gki_aarch64.xml:

• Layout di memoria: KIMAGE_TEXT_BASE = 0xffffffc008000000, VA_BITS=39, DIRECT_MAP=256GB
• task_struct: 36864 bit, completamente analizzato (ABI XML layout-offset-in-bits)
• file_operations: nessun iopoll (android13 GKI), IOCTL=0x48, open=0x68
• cred: atomic_t usage = 4 byte, uid=0x04
• struct page: 64 byte, slab_cache=0x18

Scoperta chiave: il sorgente è android15 GKI, il dispositivo è android13 GKI — gli offset di task_struct differiscono di 0x40~0x88 byte, non si possono copiare direttamente dal sorgente.

2. Decompressione del firmware → estrazione dei simboli

Simboli estratti da due versioni di firmware (15.2.7.6 / 15.2.10.2) — lo stesso simbolo differisce di 10KB~200KB tra le due versioni, è necessario usare la versione corretta.

3. Verifica tramite disassemblaggio → capstone conferma gli offset critici

Questo conferma che il layout di task_struct è il ramo android15, non l'android13 di frankel.

4. Compilazione → superata

NDK r29, make PROJECT=android_15.0_kernel_MT6985 → preload.so (150KB).

5. Esecuzione → crash ripetuti

Istruzione del crash (capstone):

Perché è fallito

Causa principale 1: KernelSnitch non affidabile su MTK

KernelSnitch è il punto di ingresso dell'intero exploit — sfrutta la differenza di timing nei bucket hash di futex per rivelare l'indirizzo di mm_struct:

1. Rilevamento collisioni riuscito — trovati 5 collisioni con soglia bassa
2. Corrispondenza bruteforce fallisce quasi sempre — il problema principale è:

I dispositivi Pixel non hanno KASAN_HW_TAGS, questo meccanismo funziona. Su MTK no.

Causa principale 2: CONFIG_PANIC_ON_OOPS è il killer

E il bootloader è bloccato (flash.locked=1) → non è possibile flashare un kernel personalizzato per rimuovere questa opzione.

Causa principale 3: Deriva della versione del kernel

Sebbene il numero di versione principale sia lo stesso 5.15.178, i rami GKI differiscono (android13 vs android15), quindi il layout delle strutture critiche come task_struct/cred non è coerente. Dopo ripetuti tentativi di passare tra gli offset frankel/android15, solo il disassemblaggio ha permesso di fissare la versione corretta.

Regolazioni tentate (tutte inutili)

Stato attuale di target.h

In exploit/targets/android_15.0_kernel_MT6985/target.h:

L'assembly compila, l'esecuzione parte, si perde solo nell'ultimo chilometro.

Se vuoi continuare

Requisiti necessari (indispensabili)

1. Rimuovere CONFIG_PANIC_ON_OOPS — o flashare un kernel personalizzato (richiede sblocco del bootloader), oppure trovare un dispositivo MT6985 con questa opzione disattivata di default
2. Risolvere KernelSnitch — serve una calibrazione del timing della cache per MTK Dimensity 9200, oppure sostituire completamente KernelSnitch nell'exploit con un altro metodo di leak di mm_struct

Possibili approcci alternativi

• /proc/self/pagemap — limitato su questo dispositivo (restituisce tutti zeri)
• Interfacce di debug specifiche MTK (/proc/mtk_*) — esistono ma richiedono ulteriore analisi
• Vulnerabilità ioctl nei driver camera/GPU MTK — percorso di privilege escalation più semplice
• Attendere un adattamento della community per la variante MTK

Valore residuo di questo repository

• symbols/kallsyms_PD2241_15.2.10.2.txt — tabella simboli completa della 15.2.10.2, utilizzabile direttamente da altri
• device_config.txt — configurazione reale del kernel del dispositivo, mostra cosa ha modificato il vendor
• exploit/targets/android_15.0_kernel_MT6985/target.h — offset delle strutture verificati
• scripts/server_compile.py — compilazione automatizzata, ricompilazione rapida dopo modifiche ai parametri

Elenco delle trappole incontrate (per evitarle in futuro)

1. Decompressione di file su Windows: tar -xf può fallire su zip di grandi dimensioni, usare Python zipfile o decomprimere prima manualmente
2. Conflitto di versione protobuf in payload_dumper: il update_metadata_pb2.py generato richiede protobuf 5.x, è necessario rimuovere manualmente la riga di importazione runtime_version
3. Eseguire direttamente ./preload.so causa segfault: è obbligatorio usare /system/bin/linker64 /data/local/tmp/preload.so
4. L'ABI XML è più accurato del codice sorgente: layout-offset-in-bits è calcolato dal compilatore, 100 volte più preciso che contare manualmente 5000 byte
5. Il ramo GKI influenza il layout: task_struct è diverso tra android13/14/15, non si possono copiare offset tra rami diversi
6. Versioni firmware diverse → offset simboli diversi: 15.2.7.6 e 15.2.10.2 differiscono di 10KB~200KB
7. Il vendor vivo ha aggiunto molti campi OEM: CONFIG_ANDROID_VENDOR_OEM_DATA=y, CONFIG_SCHED_INFO=y, CONFIG_RSC_* → devia dal GKI standard
8. Toolchain di estrazione simboli end-to-end: boot.img → kernel.bin → decompressione LZ4 → Image → kallsyms-finder → tabella simboli

Cronologia

2026-07-29, sopravvissuto per raccontarlo

2026-07-31 Aggiornamento: verifica e correzione dopo l'arrivo del codice sorgente

Dopo aver ottenuto android_15.0_kernel_MT6985.tar.gz (albero sorgente 5.15.178 + ABI XML) è stata eseguita una verifica incrociata completa, dettagli in VERIFICATION.md. Riepilogo:

1. MT6985 = Dimensity 9200 (MT6989 è il 9300), corretto nel testo precedente.
2. Offset simboli 23/23 corretti (verifica kallsyms), offset di task_struct / cred / waiter / page / pipe / configfs tutti coerenti con l'ABI dell'albero sorgente.
3. Gli offset FOPS erano errati: i valori originali copiati da frankel (android13 GKI, senza iopoll, ioctl=0x48); ma il layout di task_struct del dispositivo (pi_blocked_on=0x8b0, confermato da disassemblaggio a runtime) è coerente con questo albero sorgente, quindi lo stesso kernel dovrebbe avere file_operations con iopoll@0x30, ioctl=0x50, open=0x70 ecc. — target.h è stato corretto, con autoverifica di fallback sul dispositivo reale tramite leak_kernel_base() integrato nell'exploit.
4. Patch di compatibilità MTK per KernelSnitch (patches/kernelsnitch_mtk_fixes.patch):
   • La dimensione della tabella hash futex in spazio utente è ora allineata al kernel (possible CPU + 2 arrotondato a potenza di 2), evitando il fallimento certo del bruteforce quando possible≠online;
   • L'iterazione dei tag MTE ora include 0xf (untagged) e KSNITCH_MTE_ENABLED=1 è realmente effettivo (il util.c originale aveva mte=0 hardcoded);
   • Nessun impatto sui target non MTK.
5. Il punto di crash rt_mutex_adjust_prio_chain+0x1b0 si trova nella fase pselect/pi chain, prima dell'autoverifica FOPS; dopo le correzioni sopra vale la pena rieseguire la verifica sul dispositivo.

2026-07-31 Test su dispositivo reale: KernelSnitch funziona, la fase slide è ancora un muro

Dispositivo (PD2241, compiler251203103903) testato in 8+ round:

• KernelSnitch riparato e verificato: MM_STRUCT_SZ=0x400 (l'originale 0x500 causava una griglia di scansione disallineata e solo falsi positivi) + iterazione tag MTE 0..15 (il tag del puntatore mm del dispositivo cambia) + untag degli indirizzi falsificati. Ora trova stabilmente il vero mm_struct.
• Ogni round crasha ancora in rt_mutex_adjust_prio_chain+0x1b0: competizione di timing nella catena pselect/pi (il waiter falsificato non raggiunge l'offset corretto nello stack del kernel). Lo scheduler RSC di vivo ha modificato il percorso futex/pi, probabilmente rompendo alla radice questa race condition. L'allineamento dello stack slide è stato parametrizzato come variabile d'ambiente SLIDE_SHIFT, scansione non completata.
• Le fasi FOPS/pipe/cred non sono ancora state raggiunte, la verifica su dispositivo reale è in sospeso.

Scelta finale: downgrade a sblocco bootloader a pagamento (non si dipende più da questo percorso).