ankitrawatgit/iqoo-z9_5g-vivo-t3_5g-root-ghostlockEine Android-Anwendung und Payloads für einen Jailbreak/Root von iQOO Z9 5G und vivo T3 5G über CVE-2026-43499. Beide Geräte verwenden die MediaTek-Dimensity-7200-Plattform (MT6886). Kernel-Version 5.15.178.
Eine Jailbreak-/Root-Android-Anwendung und Payloads für das iQOO Z9 5G und das vivo T3 5G. Beide Geräte verwenden die MediaTek-Dimensity-7200-Plattform (MT6886).
Es gibt zwei unterstützte Ausführungsmethoden: die Android-APK mit Shizuku oder den nativen Helfer, der direkt aus einer adb shell ausgeführt wird. Beide Methoden verwenden denselben gerätespezifischen Payload und denselben KernelSU-Daemon.
Dieser Port verwendet die CVE-2026-43499-Ghostlock-Kernel-Exploit-Kette, um temporären Bootstrap-Root zu erlangen, und lädt anschließend den passenden KernelSU-Daemon nach. Es handelt sich um einen gerätespezifischen Jailbreak-/Root-Forschungs-Build für das iQOO Z9 5G (Modell I2302) und das vivo T3 5G (Modell V2334) mit dem Kernel 5.15.178-android13-8-g0ebe6a5da65d. Es ist kein allgemeines Android-Rooting-Tool und darf nur auf Hardware verwendet werden, die dir gehört oder für die du zur Testung autorisiert bist.
Das iQOO Z9 5G I2302 und das vivo T3 5G V2334 werden für diesen Port als dasselbe Ziel behandelt. Ihr SoC, Firmware-Verhalten, Kernel-Release, ABI, Exploit-Offsets und die KernelSU-Kopplung sind identisch; der Build-Fingerprint ist der erwartete Identitätsunterschied. Daher verwenden sie denselben Payload und dasselbe Support-Profil. Die App erfordert weiterhin das exakt oben aufgeführte Kernel-Release: 5.15.178-android13-8-g0ebe6a5da65d.
Anweisungen zur Anpassung dieses Projekts an ein anderes Gerät findest du im Leitfaden Port auf ein anderes Gerät.
Dieses Projekt erforderte viel Aufwand und Geld. Wenn es dir geholfen hat, kannst du die Arbeit mit einem Kaffee unterstützen:
Dank an Codex für die Hilfe bei der Entwicklung.
app/ Android/Compose application source and UI resources
payload/ iQOO exploit source, target profile, build script, and release inputs
Der Laufzeitablauf ist:
I2302 oder V2334 ist, der laufende Kernel 5.15.178-android13-8-g0ebe6a5da65d ist und das Gerät arm64 ist.payload/src/su_daemon.c kompiliert wurde, als Shell-Dienst (UID 2000), was den Ausführungskontext darstellt, den dieser Port benötigt. Die App ruft den --run-payload-Supervisor des Helfers auf, dieselbe Kind-/Sitzungs-Übergabe, die im validierten adb-Runbook verwendet wird, und verfolgt dessen persistentes Exploit-Protokoll.ksud vor, führt das abgesicherte KernelSU-Late-Load durch und verifiziert den Kontrollkanal.Wichtiger Wiederherstellungshinweis: Wenn das Telefon hängen bleibt oder nicht bootet, halte Lautstärke leiser + Ein/Aus gedrückt, bis es zwangsweise neu startet.
Lade die neueste APK von der Seite GitHub Releases herunter.
Lade die offizielle KernelSU Manager APK von der KernelSU-Releases-Seite herunter.
Eine gewöhnliche Android-App läuft in der SELinux-Domäne untrusted_app. Auf diesem Gerät kann diese Domäne tracefs nicht lesen. Wenn der Helfer also direkt aus der APK gestartet wird, fällt der Payload auf das physische Orakel zurück und scheitert normalerweise am Pipe-Gate. Shizuku ist daher für eine funktionierende APK-Installation erforderlich. Die App startet den --run-payload-Supervisor des Helfers über den Shizuku-Shell-Dienst (UID 2000), wodurch die tracefs-Route denselben Ausführungskontext und dieselbe Prozess-Übergabe erhält wie der bewährte adb shell-Lauf.
Die Einstellungsseite bietet weiterhin einen Schalter ohne Shizuku für Diagnose und zukünftige Entwicklung. Er ist ausdrücklich als nicht unterstützt markiert; das Deaktivieren führt dazu, dass die Installation gestoppt wird, bevor der Exploit startet.
Starte das Telefon zuerst neu; dieser Port erlaubt einen Exploit-Versuch pro Boot. Starte Shizuku, bestätige, dass die Jailbreak-/Root-App weiterhin die Berechtigung hat und Shizuku verwenden (erforderlich) aktiviert ist, und tippe dann auf KernelSU installieren. Das Live-Protokoll sollte Shizuku permission granted enthalten, bevor der Payload startet. Halte das Telefon während des Exploit-Laufs wach und an die Stromversorgung angeschlossen.
Wenn Shizuku gestoppt wird, die Berechtigung entzogen wird oder das Gerät während des laufenden Vorgangs neu gestartet wird, stoppe und starte neu, bevor du es erneut versuchst. Wiederhole den Exploit nicht mehrfach beim selben Boot. Der Shizuku-Modus ändert nur, wie der Helfer gestartet wird; er macht diesen gerätespezifischen Payload nicht auf ein anderes Modell oder einen anderen Kernel übertragbar.
Die APK ist optional. Eine adb shell läuft bereits als Android-Shell-UID und bietet damit den tracefs-Zugriff, den die APK über Shizuku erhält. Dies ist der ursprüngliche Diagnose-/Runbook-Pfad und erfordert kein Shizuku.
Verwende für jeden Versuch einen frischen Boot. Der Stack-Writer ist nur einmal pro Boot verfügbar; führe den Exploit nicht erneut aus, nachdem stack writer ran; refusing retry on this boot erscheint.
Bereite vom Repository-Stammverzeichnis aus die passenden iQOO-Binärdateien vor:
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
Starte den Supervisor des Helfers. Halte dieses Terminal geöffnet und warte, bis er fertig ist; ein normaler Lauf kann mehrere Minuten dauern:
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'
Die Exploit-Phase ist erst abgeschlossen, wenn das Protokoll sowohl exploit completed als auch root=1 enthält. Wenn der Bootstrap-Root erfolgreich ist, lade den passenden KernelSU-Daemon mit der exakten Ein-Argument-Operation des Helfers nach:
adb shell '/data/local/tmp/cve-2026-43499-root --late-load'
Hänge keine KMI- oder Manager-Argumente an --late-load an; der Helfer dieses Ziels hat die iQOO-KMI, den Lader-Pfad und die KernelSU-Optionen bereits einkompiliert. Ein erfolgreiches Late-Load gibt eine KernelSU-Kontrollverifizierungsmeldung aus.
Anforderungen: Android SDK 37, NDK 28.2.13676358 und CMake 3.22.1.
Setze den NDK-Pfad einmalig und erstelle dann die eigenständigen Payload-Artefakte:
export ANDROID_NDK_HOME="/path/to/android-sdk/ndk/28.2.13676358"
make -C payload all
make apk-release
Das Release-Ziel baut die lokalen eigenständigen Payload-Artefakte bei Bedarf neu; die APK lädt ihre Laufzeit-Payloads weiterhin aus dem neuesten GitHub-Release herunter.
Die signierte APK wird nach app/build/outputs/apk/release/app-release.apk geschrieben.
Kernel-Quellcode, Modulobjekte und Init-Begleiter bleiben außerhalb dieses sauberen Checkouts.
Dies ist ein hochgradig gerätespezifischer Port. Die Exploit-Offsets, PAC/KASLR-Logik, Stack-Geometrie, Kernel-ABI, Modul-Metadaten und der KernelSU-Daemon stimmen alle mit den getesteten iQOO-Z9-5G- (I2302) und vivo-T3-5G-Geräten (V2334) mit dem oben genannten Kernel überein. Es ist nicht zu erwarten, dass die Binärdateien auf einem anderen Modell, einer anderen Firmware, einem anderen Kernel-Release oder einem materiell abweichenden Build funktionieren; sie können ein inkompatibles Gerät zum Abbruch, Einfrieren oder Panic bringen. Ein anderes Gerät benötigt ein eigenes Zielprofil, eine eigene Quellcode-Prüfung und Hardware-Validierung.
KernelSU wird einmal pro Boot nachgeladen und ist keine dauerhafte Boot-Image-Modifikation. Befolge beim Testen des Geräts das Runbook in der ursprünglichen Port-Dokumentation und halte immer Zugriff auf den Recovery-Modus verfügbar.
Verwende es nur auf Hardware, die dir gehört oder für die du ausdrücklich zur Testung autorisiert bist.
Dieser Quellcode unterstützt derzeit das iQOO Z9 5G (I2302) und das vivo T3 5G (V2334) mit der aufgeführten Kernel-Familie. Für ein anderes Gerät derselben Kernel-Familie verwende ihn als Ausgangspunkt und ersetze die gerätespezifischen Werte, nachdem du sie auf diesem Gerät validiert hast. Für eine andere Kernel-Familie wie 5.10 oder 6.x finde zunächst eine passende öffentliche Quelle, einen Exploit-Port oder eine Referenz auf GitHub und passe das Profil für diesen Kernel an.
Du benötigst das exakte boot.img des Geräts und den passenden Kernel-Quellbaum. KI-Codierungsagenten können helfen, diese Dateien zu untersuchen, den Build vorzubereiten und den Port zu aktualisieren. Codex mit dem Luna-Modell ist meine Empfehlung. Baue und teste zuerst mit der direkten adb-Methode, nicht mit der APK. Führe den Build des Agenten aus, führe ihn auf deinem eigenen Gerät aus und gib dem Agenten dann die vollständige Ausgabe sowie alle Panic-Protokolle zurück. Wiederhole diesen Build-/Test-/Protokoll-Zyklus, bis der Port erfolgreich ist.