iQOO Z9 5G / vivo T3 5G Jailbreak Root (GhostLock)

Un'applicazione Android e payload di jailbreak/root per iQOO Z9 5G e vivo T3 5G. Entrambi i dispositivi utilizzano la piattaforma MediaTek Dimensity 7200 (MT6886).

Sono supportati due metodi di esecuzione: l'APK Android con Shizuku, oppure l'helper nativo eseguito direttamente da una adb shell. Entrambi i metodi utilizzano lo stesso payload specifico del dispositivo e lo stesso daemon KernelSU.

CVE e ambito

Questa porta utilizza la catena di exploit del kernel Ghostlock CVE-2026-43499 per ottenere un root di bootstrap temporaneo, quindi carica in un secondo momento il daemon KernelSU corrispondente. È una build di ricerca jailbreak/root specifica per i dispositivi iQOO Z9 5G (modello I2302) e vivo T3 5G (modello V2334), che utilizza il kernel 5.15.178-android13-8-g0ebe6a5da65d. Non è uno strumento generico di rooting Android e deve essere usato solo su hardware di tua proprietà o per il quale sei autorizzato a fare test.

iQOO Z9 5G I2302 e vivo T3 5G V2334 sono trattati come lo stesso target per questa porta. Il loro SoC, il comportamento del firmware, la release del kernel, l'ABI, gli offset dell'exploit e l'abbinamento KernelSU sono identici; la differenza attesa è solo l'identità del build fingerprint. Pertanto utilizzano lo stesso payload e lo stesso profilo di supporto. L'app richiede comunque l'esatta release del kernel elencata sopra: 5.15.178-android13-8-g0ebe6a5da65d.

Per istruzioni su come adattare questo progetto a un altro dispositivo, consulta la guida Porting verso un altro dispositivo.

Supporta il progetto

Questo progetto ha richiesto molto impegno e denaro per essere completato. Se ti è stato utile, puoi sostenere il lavoro con un caffè:

Grazie a Codex per l'aiuto nello sviluppo.

Struttura del progetto

app/       Android/Compose application source and UI resources
payload/   iQOO exploit source, target profile, build script, and release inputs

Il flusso di esecuzione è:

L'app verifica che il modello del telefono sia I2302 o V2334, che il kernel in esecuzione sia 5.15.178-android13-8-g0ebe6a5da65d e che il dispositivo sia arm64.
Durante l'installazione scarica gli artefatti esatti dell'exploit e di KernelSU dall'ultima release dei payload su GitHub(salvare i file localmente nell'APK causa un crash a causa delle funzionalità di sicurezza del sistema).
Shizuku è richiesto: avvia l'helper nativo compilato da payload/src/su_daemon.c come servizio shell (UID 2000), che è il contesto di esecuzione richiesto da questa porta. L'app richiama il supervisore --run-payload dell'helper, lo stesso handoff di child/sessione usato dal runbook adb validato, e segue il suo log durevole dell'exploit.
Dopo che l'exploit ottiene il root temporaneo, l'helper prepara il ksud scaricato, esegue il late-load protetto di KernelSU e verifica il canale di controllo.

Nota importante sul ripristino: Se il telefono si blocca o non si avvia, tieni premuti insieme Volume Giù + Power finché non si riavvia forzatamente.

Scarica l'ultima APK dalla pagina GitHub Releases.

Scarica l'APK ufficiale di KernelSU Manager dalla pagina delle release di KernelSU.

Esecuzione dall'APK con Shizuku (Shizuku richiesto per il metodo APK)

Un'app Android normale viene eseguita nel dominio SELinux untrusted_app. Su questo dispositivo quel dominio non può leggere tracefs, quindi avviare l'helper direttamente dall'APK fa sì che il payload ripieghi sull'oracolo fisico e di solito fallisca al pipe gate. Shizuku è quindi richiesto per un'installazione APK funzionante. L'app avvia il supervisore --run-payload dell'helper tramite il servizio shell di Shizuku (UID 2000), che dà al percorso tracefs lo stesso contesto di esecuzione e lo stesso handoff di processo dell'esecuzione collaudata via adb shell.

La pagina Impostazioni espone ancora un interruttore senza Shizuku per la diagnostica e lo sviluppo futuro. È esplicitamente contrassegnato come non supportato; disattivarlo fa sì che l'installazione si interrompa prima che l'exploit inizi.

Configurazione richiesta

Installa Shizuku dalle sue release ufficiali.
Sul telefono, attiva le Opzioni sviluppatore e il Debug wireless.
Apri Shizuku, scegli Avvia tramite debug wireless, abbinalo con il codice di abbinamento mostrato da Android e tocca Avvia. Android richiede questo avvio di nuovo dopo un riavvio quando si utilizza il metodo del debug wireless; consulta la guida ufficiale alla configurazione di Shizuku.
Apri iQOO Z9 5G Jailbreak Root (GhostLock). Nelle Impostazioni → Privilegio di esecuzione, lascia abilitata l'opzione Usa Shizuku (richiesto) e approva la richiesta di autorizzazione dell'app in Shizuku.

Ogni tentativo di installazione

Riavvia prima il telefono; questa porta consente un tentativo di exploit per ogni avvio. Avvia Shizuku, conferma che l'app di jailbreak/root abbia ancora il permesso e che Usa Shizuku (richiesto) sia abilitato, quindi tocca Installa KernelSU. Il log in tempo reale dovrebbe contenere Shizuku permission granted prima che il payload inizi. Mantieni il telefono sveglio e collegato all'alimentazione mentre l'exploit è in esecuzione.

Se Shizuku viene arrestato, il permesso viene revocato o il dispositivo viene riavviato mentre l'esecuzione è in corso, fermati e riavvia prima di riprovare. Non ritentare ripetutamente l'exploit nello stesso avvio. La modalità Shizuku cambia solo il modo in cui viene avviato l'helper; non rende questo payload specifico del dispositivo portabile su un altro modello o kernel.

Esecuzione diretta da una adb shell (senza l'APK)

L'APK è opzionale. Una adb shell viene già eseguita come UID shell di Android, quindi fornisce l'accesso a tracefs che l'APK ottiene tramite Shizuku. Questo è il percorso diagnostico/runbook originale e non richiede Shizuku.

Usa un avvio pulito per ogni tentativo. Lo stack writer è monouso per ogni avvio; non rieseguire l'exploit dopo stack writer ran; refusing retry on this boot.

Dalla radice del repository, prepara i binari iQOO corrispondenti:

adb reboot

# Wait for Android to finish booting, then push the payload and helper.
adb push payload/build/cve-2026-43499-app.so \
  /data/local/tmp/iqoo-app.so
adb push payload/build/cve-2026-43499-root \
  /data/local/tmp/cve-2026-43499-root
adb push payload/artifacts/ksud-iqoo-z9-5g \
  /data/local/tmp/ksud-iqoo-z9-5g

adb shell chmod 755 \
  /data/local/tmp/cve-2026-43499-root \
  /data/local/tmp/ksud-iqoo-z9-5g
adb shell rm -f /data/local/tmp/iqoo-app-run.log

Avvia il supervisore dell'helper. Tieni questo terminale aperto e attendi che finisca; un'esecuzione normale può richiedere diversi minuti:

adb shell 'SLIDE_SOURCE=tracefs EXPLOIT_ATTEMPTS=1 \
  P0_ATTEMPT_TIMEOUT_SEC=115 EXPLOIT_ATTEMPT_TIMEOUT_SEC=600 \
  /data/local/tmp/cve-2026-43499-root --run-payload \
  /data/local/tmp/iqoo-app.so /data/local/tmp/cve-2026-43499-root \
  /data/local/tmp/iqoo-app-run.log'

La fase dell'exploit è completa solo quando il log contiene entrambe le stringhe exploit completed e root=1. Se il root di bootstrap ha successo, esegui il late-load del daemon KernelSU corrispondente con l'esatta operazione a un argomento dell'helper:

adb shell '/data/local/tmp/cve-2026-43499-root --late-load'

Non aggiungere argomenti KMI o del manager a --late-load; l'helper di questo target ha già il KMI iQOO, il percorso del loader e le opzioni KernelSU compilati al suo interno. Un late-load riuscito stampa un messaggio di verifica del controllo KernelSU.

Compilazione del payload

Requisiti: Android SDK 37, NDK 28.2.13676358 e CMake 3.22.1.

Imposta una volta il percorso dell'NDK, quindi compila gli artefatti standalone del payload:

export ANDROID_NDK_HOME="/path/to/android-sdk/ndk/28.2.13676358"
make -C payload all

Compilazione dell'APK di release

make apk-release

Il target di release ricompila gli artefatti standalone locali del payload quando necessario; l'APK scarica comunque i suoi payload runtime dall'ultima release GitHub.

L'APK firmata viene scritta in app/build/outputs/apk/release/app-release.apk.

Il sorgente del kernel, gli oggetti dei moduli e i companion init rimangono al di fuori di questo checkout pulito.

Avviso di compatibilità

Questa è una porta altamente specifica per il dispositivo. Gli offset dell'exploit, la logica PAC/KASLR, la geometria dello stack, l'ABI del kernel, i metadati dei moduli e il daemon KernelSU corrispondono tutti ai dispositivi testati iQOO Z9 5G (I2302) e vivo T3 5G (V2334) con il kernel sopra indicato. Non ci si deve aspettare che i binari funzionino su un altro modello, firmware, release del kernel o build sostanzialmente diversa; potrebbero causare abort, freeze o panic su un dispositivo incompatibile. Un dispositivo diverso richiede il proprio profilo target, audit del sorgente e validazione hardware.

KernelSU viene caricato in late-load una volta per avvio e non è una modifica persistente dell'immagine di boot. Segui il runbook nella documentazione originale della porta quando testi il dispositivo e mantieni sempre disponibile l'accesso alla recovery.

Usa solo su hardware di tua proprietà o per il quale sei esplicitamente autorizzato a fare test.

Guida al porting

Questo sorgente supporta attualmente iQOO Z9 5G (I2302) e vivo T3 5G (V2334) con la famiglia di kernel elencata. Per un altro dispositivo della stessa famiglia di kernel, usalo come punto di partenza e sostituisci i valori specifici del dispositivo dopo averli validati su quel dispositivo. Per una famiglia di kernel diversa, come 5.10 o 6.x, trova prima un sorgente pubblico, una porta dell'exploit o un riferimento corrispondente su GitHub e adatta il profilo a quel kernel.

Avrai bisogno dell'esatto boot.img del dispositivo e dell'albero dei sorgenti del kernel corrispondente. Gli agenti di codifica AI possono aiutare a ispezionare questi file, preparare la build e aggiornare la porta. La mia raccomandazione è Codex con il modello Luna. Compila e testa prima con il metodo adb diretto, non con l'APK. Esegui la build dell'agente, eseguila sul tuo dispositivo, quindi restituisci all'agente l'output completo e qualsiasi log di panic. Ripeti questo ciclo build/test/log finché la porta non riesce.

iQOO-Z9_5G-vivo-T3_5G-Root-GhostLock

Più Popolari