O3 Root

Traduzione in cinese: README.zh-CN.md — una traduzione di questo file; in caso di discrepanze, fa fede questo file in inglese.

Escalation locale dei privilegi + KernelSU per la famiglia Xiaomi yingtian (Pad 9 Pro Max) e lhasa (Xiaomi 18 Fold) su HyperOS 4 (Android 17, kernel 6.18.21). L'intera catena viene distribuita come una normale app Android che pilota Shizuku in modalità shell, sfrutta CVE-2026-98260 e carica l'LKM della famiglia KernelSU corrispondente al manager installato (KernelSU / KernelSU-Next / SukiSU) — nessun PC, nessun bootloader sbloccato, nessuna modifica alle partizioni.

Progetto di ricerca / didattica / riparazione dispositivi. Solo per il boot corrente (un riavvio lo rimuove). Eseguire solo su dispositivi di propria proprietà. Leggere docs/SECURITY.md prima dell'uso.

Agenti / contributori automatizzati: iniziare da AGENTS.md (punto di ingresso: invarianti, ricette di build/test, trappole, igiene), poi docs/AGENT_HANDOFF.md (stato verificato, esperimenti falliti, lavoro aperto). Eseguire bash scripts/verify.sh prima di fare commit; ricostruisce anche il payload/APK quando l'ambiente della toolchain è impostato.

Versione cinese: AGENTS.zh-CN.md / docs/AGENT_HANDOFF.zh-CN.md

Stato

release	v3.2 (release/o3root2-v3.2.apk, 14.239.248 B, sha256 64bbc654…)
build di test O1	v3.3.3-o1-test (release/test/o3root2-v3.3.3-o1-test.apk, 14.247.440 B, sha256 62411f72…): v3.2 più un profilo O1 (XRING) sperimentale (dijun / jinghu / violin) e la console root nascosta. Accetta qualsiasi build OS4.0.0.x sulla serie di kernel 6.18.21-android17…-4k: la build analizzata è il percorso verificato, le altre build vengono eseguite in modalità rilassata con un avviso; solo per tester, mai validata su hardware
build di test precedente	v3.2.1-console (release/beta/o3root2-v3.2.1-console.apk, 14.243.344 B, sha256 9cba365a…): v3.2 stabile più una console root nascosta (pressione prolungata sulla riga della versione; tre conferme)
dispositivi O1	SoC Xiaomi O1 dijun / jinghu / violin su OS4.0.0.x: tutti e tre montano lo stesso kernel 6.18.21 (sha256 0d9917ca…, g1d099fcb35e0); l'analisi statica indica che la catena è applicabile, nessun test su dispositivo finora
LKM personalizzato	.ko opzionale della famiglia KernelSU fornito dall'utente (controllo di compatibilità di base; in caso contrario si ricorre al modulo adattivo integrato; la scelta viene salvata e ripristinata all'avvio — pressione prolungata sulla riga per cancellarla)
catena	shell Shizuku → CVE-2026-98260 → uid=0 + tutte le capability → LKM KernelSU corrispondente (KernelSU / KernelSU-Next / SukiSU) → rootd
persistenza	nessuna (solo il boot corrente)
dispositivo testato	Xiaomi Pad 9 Pro Max yingtian, HyperOS OS4.0.16.0.XBMCNXM
secondo dispositivo	lhasa (Xiaomi 18 Fold, OS4.0.26.0.XPNCNXM): il kernel di boot è bit-identico a quello di yingtian (sha256 cde87cd7…), quindi lo stesso payload è applicabile; non testato su dispositivo

Come funziona (versione breve)

1. L'app avvia /system/bin/sh -c … tramite newProcess di Shizuku, quindi il payload viene eseguito in u:r:shell:s0 (uid=2000).
2. Il payload innesca la race CLOCK_THREAD_CPUTIME_ID + execve/de_thread (CVE-2026-98260), recupera la pagina slab order-1 di posix_timers_cache liberata con un buffer kmalloc-8k sprayato contenente un nodo RB-tree contraffatto, e usa il secondo timerqueue_del → rb_erase per scrivere un singolo valore di 8 byte a un indirizzo kernel arbitrario.
3. Lo stage 0 azzera enforcing con una scrittura non allineata di 8 byte a selinux_state-7 (questo azzera anche i byte pending/tail adiacenti di notif_lock; initialized/policycap restano intatti); lo stage 1 scrive task_struct.cred in una pagina cred falsa (uid 0, tutti i cap).
4. Il payload carica il LKM KernelSU incorporato: i simboli non definiti vengono risolti a runtime tramite /proc/kallsyms (fallback: relink dell'unione di 248 simboli + lo slide KASLR corrente), senza patch init — poiché policycap è rimasto pulito, il setenforce(1) di KernelSU è innocuo e il dispositivo termina in Enforcing. Poi viene eseguito insmod e viene lasciato un daemon rootd (socket astratto @o3p_rootd, peer-uid 0/2000). I LKM upstream KernelSU, KernelSU-Next e SukiSU funzionano tutti (legacy: O3P_CODEPATCH=1 applica una patch all'immediato di setenforce). Dalla v3.1 l'app può invece caricare un .ko scelto da te (controllo di compatibilità ELF/.modinfo di base, fallback automatico al LKM integrato quando viene rifiutato o non si carica). Dalla v3.1.1 tale selezione è persistita (files/custom-ko.ko + custom-ko.meta) e ripristinata all'avvio; un file obsoleto che non è più valido viene scartato, e una pressione prolungata sulla riga del modulo lo cancella. Dalla v3.2 la casella del log è selezionabile e dispone di un'azione 复制 che copia l'intero log; lo scorrimento automatico avviene solo quando sei già vicino al fondo. Su un dispositivo O1 riconosciuto la build di test richiede una conferma del rischio in due passaggi prima che il payload parta. La build di test nasconde inoltre una console root dietro una pressione prolungata sulla riga della versione: tre conferme non aggirabili, poi i comandi vengono eseguiti come root tramite il socket rootd (richiede un'esecuzione del payload nel boot corrente). La build stabile non contiene le classi della console.

Consulta docs/ARCHITECTURE.md per gli offset, la primitiva di scrittura, la patch KernelSU e la guida al porting.

Avvio rapido

1. Sul dispositivo: abilita Opzioni sviluppatore → Debug wireless (o ADB). Installa Shizuku / ShizukuX e avvialo in modalità shell: shizuku_plus_server deve essere eseguito come uid=2000, u:r:shell:s0.
2. Installa release/o3root2-v3.2.apk (MIUI potrebbe richiedere l'abilitazione di "Installa via USB").
3. Apri O3 Root, concedi il permesso Shizuku, premi Continue to UID 0. Il log mostra ★ UIDNOW uid=0, ★ KSU_MODULE LIVE, e il manager KernelSU si apre automaticamente.