TimerRoot

Interfaz de Android para CVE-2026-98260 (use-after-free en temporizadores de CPU POSIX), la misma clase de fallo que CVE-2026-64560. Un solo toque te da una shell de root y luego carga en diferido KernelSU (u:r:ksu:s0).

El exploit en sí no está incluido aquí. Este repositorio es la envoltura de la aplicación alrededor de él: interfaz de usuario, detección de estado y la infraestructura de Shizuku necesaria para ejecutar un exploit en el dominio shell desde una aplicación normal.

Por qué la aplicación necesita Shizuku

Una aplicación se ejecuta como untrusted_app y no puede leer /sys/kernel/tracing, que el exploit necesita para su fuga de información y su activación. Por lo tanto, TimerRoot inicia un servicio de usuario de Shizuku, que Shizuku ejecuta como el usuario shell (uid 2000, u:r:shell:s0). El binario del exploit se ejecuta dentro de ese proceso, por lo que obtiene el mismo entorno que tendría desde adb shell.

MainActivity (untrusted_app)
  └─ Shizuku user service (uid 2000, u:r:shell:s0)
       ├─ extracts assets/timer to /data/local/tmp/timer
       └─ runs it; on success keeps /system/bin/sh alive

Requisitos

• Android 12+ (minSdk 30), arm64
• Shizuku en ejecución (inícialo desde la aplicación Shizuku mediante depuración inalámbrica, o a través de ADB)
• Gestor de KernelSU instalado, para la ruta Load KernelSU
• Una compilación del kernel a la que se haya portado el exploit. El binario original tiene como objetivo 6.12.69-android16-6-g242e1a07f878-ab15865446-4k; consulta más abajo.

Obtener el binario del exploit

TimerRoot espera el exploit compilado en app/src/main/assets/timer:

git clone https://github.com/YuKongA/CVE-2026-98260
cp CVE-2026-98260/timer/timer app/src/main/assets/timer

o

scripts/fetch-timer.ps1

El binario está licenciado bajo MIT por sus autores; úsalo solo en hardware que sea de tu propiedad, y solo cuando tu kernel coincida con la compilación a la que fue portado.

Compilación

Android Studio / Gradle

Abre el proyecto y compílalo, o:

./gradlew assembleDebug

El proyecto necesita el Android SDK con la plataforma 36 y las build-tools 36. La API de Shizuku se obtiene desde Maven (dev.rikka.shizuku:api).

Sin Gradle

scripts/build.ps1 compila y firma un APK solo con el SDK, javac, d8, aapt2 y apksigner. No incluye nada de terceros: compila la aplicación junto con las fuentes de la API de Shizuku, así que clónalas primero:

git clone https://github.com/RikkaApps/Shizuku-API
scripts/build.ps1 -Sdk "C:\Users\<you>\AppData\Local\Android\Sdk"

Uso

1. Iniciar Shizuku

Shizuku debe estar en ejecución antes de que TimerRoot pueda hacer algo: es el proceso que proporciona el usuario de shell que necesita el exploit. Shizuku se detiene en cada reinicio, así que este es el primer paso cada vez.

Depuración inalámbrica (sin PC después del primer emparejamiento)

1. Activa las opciones de desarrollador: Ajustes -> Acerca del dispositivo -> toca Número de compilación 7 veces.
2. Ajustes -> Sistema -> Opciones de desarrollador -> Depuración inalámbrica -> activado.
3. Abre la aplicación Shizuku -> Iniciar -> Iniciar mediante depuración inalámbrica.
4. Permite la notificación y luego, en Emparejar dispositivo con código de emparejamiento, introduce el código de 6 dígitos que se muestra en el teléfono.
5. Shizuku informa "Shizuku is running" (la notificación indica que el servidor está activo).

Por USB

Con el teléfono conectado y la depuración USB autorizada:

adb shell sh /sdcard/Android/data/moe.shizuku.privileged.api/start.sh

Las versiones más recientes de Shizuku pueden ya no incluir ese script; si no está, utiliza la ruta de depuración inalámbrica descrita anteriormente.

Comprueba que el servidor esté activo:

adb shell ps -A | grep shizuku_server
# shell  12345  1  ...  shizuku_server

ps mostrando solo moe.shizuku.privileged.api significa que la aplicación del gestor está abierta pero el servidor no está en ejecución; el exploit no puede iniciarse hasta que lo esté.

2. Primer inicio

1. Abre TimerRoot.
2. Cuando Shizuku pregunte ¿Permitir que TimerRoot acceda a Shizuku?, elige Permitir todo el tiempo.
3. La tarjeta cambia a Ready (Shizuku conectado, aún sin root). Si sigue diciendo Not connected, pulsa Shizuku en la fila de herramientas para solicitarlo de nuevo.

3. Preparación

Prepare extrae assets/timer a /data/local/tmp/timer:

installed 307192 bytes

4. Obtener shell de root

Un toque. La app escala privilegios, mantiene un shell con uid=0 dentro del servicio y luego inicia la carga tardía de KernelSU automáticamente:

[child] woke uid=0
root shell ready - loading KernelSU...
Loading KernelSU... 12s
KSU_LOADED

La tarjeta pasa a Root shell -> Jailbreak mode (u:r:ksu:s0). Si la etapa de KernelSU pierde su carrera, la tarjeta se vuelve roja con KernelSU failed, y deberías reiniciar antes de volver a intentarlo.

5. Reiniciar

Usa la píldora Reboot. Pasa por el servicio (svc power reboot), por lo que funciona incluso cuando aún no hay un shell de root abierto. Reiniciar también es la única forma limpia de eliminar los procesos estacionados y descargar KernelSU.

Después de reiniciar, comienza de nuevo desde el paso 1: Shizuku está detenido y KernelSU ya no está.

La tarjeta de estado refleja lo que está realmente activo, detectado ejecutando su -c id y comprobando u:r:ksu:s0:

tarjeta	significado
Not connected	Shizuku no se está ejecutando / no está vinculado
Ready	Shizuku conectado, aún sin root
Root shell	uid=0, u:r:shell:s0
Jailbreak mode	KernelSU cargado, su funciona en u:r:ksu:s0

Solución de problemas

KernelSU failed y base calibration failed en el registro

La etapa de credenciales falsas necesita la base del mapa lineal del kernel, que el exploit deriva de los eventos de rastreo de asignación de páginas. Asume páginas de 4 KB:

[base] made=512 best=0 count=0
[-] base calibration failed

Comprueba el tamaño de página del dispositivo:

adb shell getconf PAGE_SIZE

• 4096: el diseño difiere por otra razón; recopila uname -r, el modelo y el registro completo y repórtalo upstream.
• 16384: el exploit no puede funcionar en este dispositivo tal como viene. Tiene que ser reconstruido para páginas de 16 KB (desplazamientos de página, máscaras y tamaños de orden), lo cual es un trabajo de portabilidad en lugar de un ajuste de la aplicación.

El shell root aún puede tener éxito en un dispositivo así, porque esa ruta solo necesita la dirección de credencial filtrada, no la base del mapa lineal.

La tarjeta permanece en Not connected

Shizuku no está en ejecución. Inícialo de nuevo (se detiene en cada reinicio) y consulta el paso 1.

Prepare no informa nada

Un diálogo del sistema puede estar cubriendo la aplicación (emparejamiento de Shizuku, escaneo del instalador de OPPO). Ciérralo y pulsa Prepare de nuevo.

Seguridad

Este es un exploit de kernel. Lee esto antes de pulsar cualquier cosa.

• No elimines un proceso estacionado. El exploit mantiene un proceso vivo con la página de credenciales falsa fijada en los búferes de socket. Recolectarlo puede provocar un pánico del kernel. El reinicio es la única forma limpia de eliminarlo.
• Un reinicio lo borra todo: KernelSU, el shell root y los procesos estacionados. Esa es la forma prevista de detenerlo.
• SELinux se deja en modo permisivo hasta el siguiente reinicio.
• Un intento fallido deja un nodo de timerqueue obsoleto; otras aplicaciones pueden fallar hasta que reinicies.
• Utiliza esto solo en un dispositivo que poseas o que tengas permiso explícito de modificar.