k80pro-miro-cve-2026-64560

Progetto di porting dell'escalation di privilegi locale in user space CVE-2026-64560 per Redmi K80 Pro (miro).

🚀 Non vuoi leggere tutta questa documentazione?

Se non vuoi approfondire o non vuoi leggere tutta questa pila di .md generati dall'AI, vai direttamente a dyc.md —— una guida rapida in parole povere: da zero al jailbreak (incluso KernelSU), spiega solo quali comandi digitare, non il perché.

L'exploit upstream e l'adattamento per Xiaomi 15 (dada) provengono da quyicheng03-boop, questo repository è il risultato del porting basato su di esso, con indirizzi e costanti ricalcolati per il K80 Pro.

Questo progetto si occupa solo del porting, non include la scoperta della vulnerabilità. Il principio della vulnerabilità e la progettazione della catena di exploit appartengono interamente all'autore upstream. Vedi docs/UPSTREAM.md e NOTICE.

一、Leggi prima questo: gli artefatti sono strettamente legati al firmware

Il codice sorgente e i binari in questo repository sono validi solo per questa versione di firmware:

Voce	Valore
Modello	Redmi K80 Pro (`ro.product.device` = `miro`)
Fingerprint	`Redmi/miro/miro:16/BP2A.250605.031.A3/OS3.0.304.0.WOMCNXM:user/release-keys`
Kernel	`6.6.118-android15-8-gc44b714366cc-abogki519650608-4k`
Data di build del kernel	Thu Jun 4 03:48:35 UTC 2026
Dimensione pagina	4096 (4K)

Qualsiasi altra versione OTA lo renderà inefficace. Gli offset delle strutture nel kernel, gli indirizzi dei simboli e gli intervalli KASLR sono tutti derivati da questa specifica Image, basta un carattere di differenza e non funzionerà.

Quando il fingerprint non corrisponde, il programma esce subito:

TARGET_PROFILE_GATE_FAIL fingerprint=...

Questo è un fallimento sicuro, non tocca il kernel. Se il tuo firmware non è la versione nella tabella sopra, esegui il porting da solo seguendo docs/05-technical.md, non applicare direttamente le costanti di questo repository.

二、Dichiarazione di non responsabilità

Questo codice legge e scrive direttamente nella memoria del kernel.
Durante l'exploit il dispositivo potrebbe bloccarsi o andare in sospensione, richiedendo una pressione prolungata del tasto di accensione per il riavvio forzato.
Il fallimento non causa danni permanenti (vedi l'analisi dei rischi in docs/04-troubleshooting.md), ma non eseguirlo su dispositivi che non possiedi o di cui non hai fatto il backup dei dati.
Il dispositivo di test è in stato BL sbloccato. Se il bootloader del tuo dispositivo è bloccato, assicurati prima di avere un mezzo di ripristino —— in stato bloccato non c'è canale fastboot.
Solo per ricerca sulla sicurezza, verifica di vulnerabilità e apprendimento su dispositivi propri. Verifica autonomamente i requisiti legali della tua regione.

三、Struttura delle directory

k80pro-miro-cve-2026-64560/
├── README.md               questo file
├── dyc.md                  guida rapida (in parole povere), i principianti leggano prima questo
├── LICENSE                 licenza upstream
├── NOTICE                  dichiarazione di attribuzione upstream
├── SHA256SUMS.txt          valori di checksum dei tre artefatti in release_build/
│
├── src/                    codice sorgente per la compilazione
│   ├── exploit-fanout-miro.c
│   ├── exploit-rotate-miro.c
│   ├── temp-su.c
│   ├── miro-profile.h      riferimento costanti (non partecipa alla compilazione)
│   ├── miro-integration.c  riferimento integrazione (non partecipa alla compilazione)
│   └── exploit-*.c         file originali upstream (input del generatore, non partecipano alla compilazione)
│
├── release_build/          artefatti precompilati (utilizzabili direttamente)
│   ├── cve-2026-64560-fanout
│   ├── cve-2026-64560-rotate
│   └── su
│
├── docs/
│   ├── 01-build.md         come compilare
│   ├── 02-usage.md         come usare in adb shell
│   ├── 03-tokens.md        tabella di riferimento dei token di output
│   ├── 04-troubleshooting.md  risoluzione problemi e note sui rischi
│   ├── 05-technical.md     note tecniche sul porting
│   └── UPSTREAM.md         origine upstream
│
└── tools/                  script di build e strumenti di riproduzione/diagnostica (non partecipano all'exploit)
    ├── build.sh            compilazione con un comando (sh tools/build.sh)
    └── *.py                script di riproduzione / diagnostica

四、Due percorsi di utilizzo

Percorso A: usare direttamente gli artefatti precompilati

Vedi docs/02-usage.md.

Prima verifica l'integrità degli artefatti:

sha256sum -c SHA256SUMS.txt        # Linux / macOS
certutil -hashfile <file> SHA256   # Windows, verifica uno per uno

Percorso B: compilare da soli

Vedi docs/01-build.md.

È necessario Android NDK (non si può usare gcc di sistema, motivo in quel documento). Il modo più semplice è usare lo script incluso nel repository, che trova da solo l'NDK, seleziona la toolchain corretta, compila e confronta uno per uno gli hash con SHA256SUMS.txt:

sh tools/build.sh              # compilazione + verifica
sh tools/build.sh --no-check   # solo compilazione

Lo script esegue solo la compilazione, non tocca il dispositivo, non esegue push, non esegue l'exploit.

Se non vuoi usare lo script, puoi anche digitare manualmente i tre comandi clang, producendo cve-2026-64560-fanout, cve-2026-64560-rotate, su.

Dopo la compilazione confronta se i byte corrispondono a quelli in release_build/:

sha256sum build/*              # confronta con i tre valori in SHA256SUMS.txt

五、Come appare il successo

L'unico criterio di successo è aprire una nuova adb shell e riuscire a ottenere uid=0 tramite /data/local/tmp/su:

$ printf 'id\nexit\n' | adb shell -T /data/local/tmp/su
uid=0(root) gid=0(root) groups=0(root),1004(input),... context=u:r:shell:s0

Nota context=u:r:shell:s0 —— identità root ma mantenendo il dominio shell, questo è voluto, non è un errore.

I token chiave che si vedranno durante il processo (tabella completa in docs/03-tokens.md):

BOOTID_WRITE_PASS attempt=5 q0=... q1=... slide=... kernel_base=...
STAGE0_GATE_PASS  slide=... kernel_base=...
MISC_BRIDGE_OPEN_PASS fd=... observed=...
STAGE8_CRED_STAGE_PASS task=... cred=... uid=0 context=shell
ROOT_CHILD_HOLD_PASS child=... uid=0 context=shell selinux_permissive=1

六、Tre caratteristiche comportamentali che devi conoscere

Il tasso di successo non è del 100%. Nella fase Stage0 il tasso di successo singolo misurato è di circa 1/5, quindi il programma ritenta 32 volte per fase per impostazione predefinita. L'intera catena è probabilistica.
Il fallimento può manifestarsi come blocco. È necessario tenere premuto il tasto di accensione per il riavvio forzato. Dopo il riavvio lo stato del kernel viene completamente azzerato, puoi ricominciare.
Dopo il successo rimangono due stati, fino al riavvio:
- SELinux diventa permissive
- /data/local/tmp/su diventa un daemon che apre root a qualsiasi identità shell

Più Popolari

K80Pro-miro-CVE-2026-64560