O3 Root

Traducción al chino: README.zh-CN.md — una traducción de este archivo; si ambos difieren, este archivo en inglés es la versión autoritativa.

Escalada local de privilegios + KernelSU para la familia Xiaomi yingtian (Pad 9 Pro Max) y lhasa (Xiaomi 18 Fold) en HyperOS 4 (Android 17, kernel 6.18.21). Toda la cadena se entrega como una app Android normal que controla Shizuku en modo shell, explota CVE-2026-98260 y carga el LKM de la familia KernelSU que coincide con el gestor instalado (KernelSU / KernelSU-Next / SukiSU) — sin PC, sin bootloader desbloqueado, sin cambios de particiones.

Proyecto de investigación / educación / reparación de dispositivos. Solo para el arranque actual (un reinicio lo elimina). Ejecútalo únicamente en dispositivos de tu propiedad. Lee docs/SECURITY.md antes de usarlo.

Agentes / colaboradores automatizados: empieza por AGENTS.md (punto de entrada: invariantes, recetas de compilación/pruebas, trampas, higiene), luego docs/AGENT_HANDOFF.md (estado verificado, experimentos fallidos, trabajo pendiente). Ejecuta bash scripts/verify.sh antes de hacer commit; también recompila el payload/APK cuando el entorno del toolchain está configurado.

Versión en chino: AGENTS.zh-CN.md / docs/AGENT_HANDOFF.zh-CN.md

Estado

release	v3.2 (release/o3root2-v3.2.apk, 14,239,248 B, sha256 64bbc654…)
compilación de prueba O1	v3.3.3-o1-test (release/test/o3root2-v3.3.3-o1-test.apk, 14,247,440 B, sha256 62411f72…): v3.2 más un perfil O1 (XRING) experimental (dijun / jinghu / violin) y la consola root oculta. Acepta cualquier compilación OS4.0.0.x en la serie de kernel 6.18.21-android17…-4k: la compilación analizada es la ruta verificada, otras compilaciones se ejecutan en modo relajado con una advertencia; solo para testers, nunca validada en hardware
compilación de prueba anterior	v3.2.1-console (release/beta/o3root2-v3.2.1-console.apk, 14,243,344 B, sha256 9cba365a…): v3.2 estable más una consola root oculta (mantén pulsada la fila de versión; tres confirmaciones)
dispositivos O1	SoC Xiaomi O1 dijun / jinghu / violin en OS4.0.0.x: los tres incluyen el mismo kernel 6.18.21 (sha256 0d9917ca…, g1d099fcb35e0); el análisis estático indica que la cadena es aplicable, aún sin prueba en dispositivo
LKM personalizado	.ko opcional de la familia KernelSU proporcionado por el usuario (comprobación básica de compatibilidad; recurre al módulo adaptativo integrado; la elección se guarda y se restaura al iniciar — mantén pulsada la fila para borrarla)
cadena	shell de Shizuku → CVE-2026-98260 → uid=0 + todas las caps → LKM de KernelSU coincidente (KernelSU / KernelSU-Next / SukiSU) → rootd
persistencia	ninguna (solo el arranque actual)
dispositivo probado	Xiaomi Pad 9 Pro Max yingtian, HyperOS OS4.0.16.0.XBMCNXM
segundo dispositivo	lhasa (Xiaomi 18 Fold, OS4.0.26.0.XPNCNXM): el kernel de arranque es idéntico bit a bit al de yingtian (sha256 cde87cd7…), por lo que el mismo payload es aplicable; no probado en dispositivo

Cómo funciona (versión corta)

1. La aplicación lanza /system/bin/sh -c … a través de newProcess de Shizuku, por lo que el payload se ejecuta en u:r:shell:s0 (uid=2000).
2. El payload desencadena la carrera CLOCK_THREAD_CPUTIME_ID + execve/de_thread (CVE-2026-98260), recupera la página slab de orden 1 posix_timers_cache liberada con un búfer kmalloc-8k rociado que contiene un nodo de árbol RB falsificado, y utiliza el segundo timerqueue_del → rb_erase para escribir un valor de 8 bytes en una dirección de kernel arbitraria.
3. La etapa 0 borra enforcing con una escritura no alineada de 8 bytes en selinux_state-7 (esto también borra los bytes pendientes/cola adyacentes de notif_lock; initialized/policycap permanecen intactos); la etapa 1 escribe task_struct.cred en una página cred falsa (uid 0, todas las capacidades).
4. El payload carga el LKM de KernelSU embebido: los símbolos indefinidos se resuelven en tiempo de ejecución a través de /proc/kallsyms (alternativa: reenlace de unión de 248 símbolos + el desplazamiento KASLR actual), sin parche de init — porque policycap permaneció limpio, el propio setenforce(1) de KernelSU es inofensivo y el dispositivo termina en Enforcing. Luego se hace insmod y se deja un daemon rootd atrás (socket abstracto @o3p_rootd, peer-uid 0/2000). Los LKM de KernelSU, KernelSU-Next y SukiSU upstream funcionan todos (heredado: O3P_CODEPATCH=1 parchea el inmediato de setenforce). Desde v3.1 la aplicación puede en su lugar cargar un .ko que elijas (verificación básica de compatibilidad ELF/.modinfo, con reversión automática al LKM integrado cuando es rechazado o falla al cargar). Desde v3.1.1 esa selección se persiste (files/custom-ko.ko + custom-ko.meta) y se restaura al iniciar; un archivo obsoleto que ya no se valida se descarta, y una pulsación larga en la fila del módulo lo borra. Desde v3.2 el cuadro de registro es seleccionable y tiene una acción 复制 que copia todo el registro; solo se desplaza automáticamente mientras ya estás cerca del final. En un dispositivo O1 reconocido, la compilación de prueba solicita una confirmación de riesgo en dos pasos antes de que se inicie el payload. La compilación de prueba además oculta una consola root tras una pulsación larga de la fila de versión: tres confirmaciones no omitibles, luego los comandos se ejecutan como root a través del socket rootd (requiere una ejecución del payload en el arranque actual). La compilación estable no contiene las clases de la consola.

Consulta docs/ARCHITECTURE.md para los desplazamientos, la primitiva de escritura, el parche de KernelSU y la guía de portabilidad.

Inicio rápido

1. En el dispositivo: activa Opciones de desarrollador → Depuración inalámbrica (o ADB). Instala Shizuku / ShizukuX e inícialo en modo shell: shizuku_plus_server debe ejecutarse como uid=2000, u:r:shell:s0.
2. Instala release/o3root2-v3.2.apk (MIUI puede requerir permitir "Instalar por USB").
3. Abre O3 Root, concede el permiso de Shizuku, pulsa Continue to UID 0. El registro muestra ★ UIDNOW uid=0, ★ KSU_MODULE LIVE, y el gestor de KernelSU se abre automáticamente.