ankitrawatgit/iqoo-z9_5g-vivo-t3_5g-root-ghostlockUna aplicación Android y payloads de jailbreak/root para iQOO Z9 5G y vivo T3 5G del CVE-2026-43499. Ambos dispositivos utilizan la plataforma MediaTek Dimensity 7200 (MT6886). Versión de kernel 5.15.178.
Una aplicación de Android jailbreak/root y payloads para iQOO Z9 5G y vivo T3 5G. Ambos dispositivos usan la plataforma MediaTek Dimensity 7200 (MT6886).
Hay dos métodos de ejecución compatibles: la APK de Android con Shizuku, o el helper nativo ejecutado directamente desde un adb shell. Ambos métodos usan el mismo payload específico del dispositivo y el daemon de KernelSU.
Este puerto utiliza la cadena de exploits de kernel Ghostlock CVE-2026-43499 para obtener root bootstrap temporal y luego carga tardíamente el daemon KernelSU correspondiente. Es una compilación de investigación jailbreak/root específica del dispositivo para el iQOO Z9 5G (modelo I2302) y el vivo T3 5G (modelo V2334), con el kernel 5.15.178-android13-8-g0ebe6a5da65d. No es una herramienta general de root para Android y solo debe usarse en hardware propio o autorizado para probar.
El iQOO Z9 5G I2302 y el vivo T3 5G V2334 se tratan como el mismo objetivo para este puerto. Su SoC, comportamiento de firmware, versión de kernel, ABI, offsets del exploit y emparejamiento con KernelSU son los mismos; la diferencia de identidad esperada es la huella de compilación (build fingerprint). Por lo tanto, usan el mismo payload y perfil de soporte. La aplicación sigue requiriendo la versión exacta de kernel indicada arriba: 5.15.178-android13-8-g0ebe6a5da65d.
Para instrucciones sobre cómo adaptar este proyecto a otro dispositivo, consulta la guía Portar a otro dispositivo.
Este proyecto requirió mucho esfuerzo y dinero para completarse. Si te fue útil, puedes apoyar el trabajo con un café:
Gracias a Codex por ayudar con el desarrollo.
app/ Android/Compose application source and UI resources
payload/ iQOO exploit source, target profile, build script, and release inputs
El flujo en tiempo de ejecución es:
I2302 o V2334, que el kernel en ejecución sea 5.15.178-android13-8-g0ebe6a5da65d y que el dispositivo sea arm64.payload/src/su_daemon.c como servicio shell (UID 2000), que es el contexto de ejecución que requiere este puerto. La aplicación invoca al supervisor --run-payload del helper, el mismo traspaso de hijo/sesión que usa el runbook adb validado, y sigue su registro de exploit persistente.ksud descargado, realiza la carga tardía protegida de KernelSU y verifica el canal de control.Nota importante de recuperación: Si el teléfono se bloquea o no arranca, mantén pulsados Bajar volumen + Encendido juntos hasta que se reinicie a la fuerza.
Descarga la última APK desde la página de GitHub Releases.
Descarga la APK oficial de KernelSU Manager desde la página de releases de KernelSU.
Una aplicación Android normal se ejecuta en el dominio SELinux untrusted_app. En este dispositivo, ese dominio no puede leer tracefs, por lo que lanzar el helper directamente desde la APK hace que el payload recurra al oráculo físico y normalmente falle en la compuerta de pipe. Por lo tanto, Shizuku es necesario para que la instalación por APK funcione. La aplicación inicia el supervisor --run-payload del helper a través del servicio shell de Shizuku (UID 2000), lo que le da a la ruta tracefs el mismo contexto de ejecución y traspaso de proceso que la ejecución probada con adb shell.
La página de Ajustes todavía expone un interruptor sin Shizuku para diagnósticos y desarrollo futuro. Está marcado explícitamente como no compatible; desactivarlo hace que la instalación se detenga antes de que comience el exploit.
Reinicia primero el teléfono; este puerto permite un intento de exploit por arranque. Inicia Shizuku, confirma que la aplicación jailbreak/root sigue teniendo permiso y que Usar Shizuku (requerido) está habilitado, y luego pulsa Instalar KernelSU. El registro en vivo debe contener Shizuku permission granted antes de que comience el payload. Mantén el teléfono despierto y conectado a la corriente mientras se ejecuta el exploit.
Si Shizuku se detiene, se revoca el permiso o el dispositivo se reinicia mientras la ejecución está en curso, detente y reinicia antes de volver a intentarlo. No reintentes el exploit repetidamente en el mismo arranque. El modo Shizuku solo cambia la forma en que se lanza el helper; no hace que este payload específico del dispositivo sea portable a otro modelo o kernel.
La APK es opcional. Un adb shell ya se ejecuta como UID shell de Android, por lo que proporciona el acceso a tracefs que la APK obtiene mediante Shizuku. Esta es la ruta original de diagnóstico/runbook y no requiere Shizuku.
Usa un arranque limpio para cada intento. El escritor de pila es de un solo uso por arranque; no vuelvas a ejecutar el exploit después de stack writer ran; refusing retry on this boot.
Desde la raíz del repositorio, prepara los binarios iQOO correspondientes:
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
Inicia el supervisor del helper. Mantén esta terminal abierta y espera a que termine; una ejecución normal puede tardar varios minutos:
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 etapa del exploit solo está completa cuando el registro contiene tanto exploit completed como root=1. Si el root bootstrap tiene éxito, realiza la carga tardía del daemon KernelSU correspondiente con la operación exacta de un argumento del helper:
adb shell '/data/local/tmp/cve-2026-43499-root --late-load'
No agregues argumentos KMI ni de manager a --late-load; el helper de este objetivo ya tiene compilados el KMI de iQOO, la ruta del cargador y las opciones de KernelSU. Una carga tardía exitosa imprime un mensaje de verificación del control de KernelSU.
Requisitos: Android SDK 37, NDK 28.2.13676358 y CMake 3.22.1.
Configura la ruta del NDK una vez y luego compila los artefactos de payload independientes:
export ANDROID_NDK_HOME="/path/to/android-sdk/ndk/28.2.13676358"
make -C payload all
make apk-release
El objetivo release reconstruye los artefactos de payload independientes locales cuando es necesario; la APK sigue descargando sus payloads en tiempo de ejecución desde la última release de GitHub.
La APK firmada se escribe en app/build/outputs/apk/release/app-release.apk.
El código fuente del kernel, los objetos de módulo y los acompañantes de init permanecen fuera de esta copia de trabajo limpia.
Este es un puerto muy específico del dispositivo. Los offsets del exploit, la lógica PAC/KASLR, la geometría de pila, el ABI del kernel, los metadatos de módulo y el daemon de KernelSU coinciden con los dispositivos probados iQOO Z9 5G (I2302) y vivo T3 5G (V2334) con el kernel indicado. No debe esperarse que los binarios funcionen en otro modelo, firmware, versión de kernel o compilación materialmente diferente; pueden abortar, congelar o provocar un pánico en un dispositivo incompatible. Un dispositivo diferente necesita su propio perfil de objetivo, auditoría de código fuente y validación de hardware.
KernelSU se carga tardíamente una vez por arranque y no es una modificación persistente de la imagen de arranque. Sigue el runbook de la documentación original del puerto al probar el dispositivo y mantén siempre disponible el acceso a recovery.
Úsalo solo en hardware que poseas o que esté explícitamente autorizado para probar.
Este código fuente actualmente es compatible con el iQOO Z9 5G (I2302) y el vivo T3 5G (V2334) con la familia de kernel indicada. Para otro dispositivo de la misma familia de kernel, úsalo como punto de partida y reemplaza los valores específicos del dispositivo después de validarlos en ese dispositivo. Para una familia de kernel diferente, como 5.10 o 6.x, primero busca en GitHub una fuente pública, un puerto de exploit o una referencia que coincida y adapta el perfil para ese kernel.
Necesitarás el boot.img exacto del dispositivo y el árbol de código fuente del kernel correspondiente. Los agentes de codificación con IA pueden ayudar a inspeccionar esos archivos, preparar la compilación y actualizar el puerto. Mi recomendación es Codex con el modelo Luna. Compila y prueba primero con el método directo de adb, no con la APK. Ejecuta la compilación del agente, pruébala en tu propio dispositivo y luego devuelve al agente la salida completa y cualquier registro de pánico. Repite ese ciclo de compilación/prueba/registro hasta que el puerto tenga éxito.