TimerRoot

Front end Android per CVE-2026-98260 (use-after-free del timer CPU POSIX), la stessa classe di bug di CVE-2026-64560. Un tocco ti fornisce una shell root e poi carica in ritardo KernelSU (u:r:ksu:s0).

L'exploit stesso non è incluso qui. Questo repository è il guscio dell'app attorno ad esso: UI, rilevamento dello stato e il cablaggio Shizuku necessario per eseguire un exploit in dominio shell da un'app ordinaria.

Perché l'app necessita di Shizuku

Un'app viene eseguita come untrusted_app e non può leggere /sys/kernel/tracing, che l'exploit necessita per il suo leak e trigger. TimerRoot avvia quindi un servizio utente Shizuku, che Shizuku esegue come utente shell (uid 2000, u:r:shell:s0). Il binario dell'exploit viene eseguito all'interno di quel processo, quindi ottiene lo stesso ambiente che avrebbe da 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

Requisiti

• Android 12+ (minSdk 30), arm64
• Shizuku in esecuzione (avvialo dall'app Shizuku tramite debug wireless, oppure via ADB)
• Gestore KernelSU installato, per il percorso Load KernelSU
• Una build del kernel per cui l'exploit è stato portato. Il binario upstream è destinato a 6.12.69-android16-6-g242e1a07f878-ab15865446-4k; vedi sotto.

Ottenere il binario dell'exploit

TimerRoot si aspetta l'exploit compilato in 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

Il binario è distribuito con licenza MIT dai suoi autori; usalo solo su hardware di tua proprietà e solo quando il tuo kernel corrisponde alla build per cui è stato portato.

Build

Android Studio / Gradle

Apri il progetto ed esegui la build, oppure:

./gradlew assembleDebug

Il progetto richiede l'Android SDK con platform 36 e build-tools 36. L'API Shizuku viene recuperata da Maven (dev.rikka.shizuku:api).

Senza Gradle

scripts/build.ps1 compila e firma un APK con solo l'SDK, javac, d8, aapt2 e apksigner. Non include nulla di precompilato: compila l'app insieme ai sorgenti dell'API Shizuku, quindi clona prima questi ultimi:

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

Utilizzo

1. Avvia Shizuku

Shizuku deve essere in esecuzione prima che TimerRoot possa fare qualsiasi cosa: è il processo che fornisce all'utente shell ciò di cui l'exploit ha bisogno. Shizuku si arresta a ogni riavvio, quindi questo è il primo passo ogni volta.

Debug wireless (nessun PC dopo il primo accoppiamento)

1. Abilita le opzioni sviluppatore: Impostazioni -> Info dispositivo -> tocca Numero build 7 volte.
2. Impostazioni -> Sistema -> Opzioni sviluppatore -> Debug wireless -> attiva.
3. Apri l'app Shizuku -> Avvia -> Avvia tramite debug wireless.
4. Consenti la notifica, poi in Accoppia dispositivo con codice di accoppiamento inserisci il codice a 6 cifre mostrato sul telefono.
5. Shizuku segnala "Shizuku is running" (la notifica indica che il server è attivo).

Tramite USB

Con il telefono collegato e il debug USB autorizzato:

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

Le versioni più recenti di Shizuku potrebbero non includere più quello script; se manca, usa la procedura di debug wireless descritta sopra.

Verifica che il server sia attivo:

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

ps che mostra solo moe.shizuku.privileged.api significa che l'app manager è aperta ma il server non è in esecuzione; l'exploit non può avviarsi finché non lo è.

2. Primo avvio

1. Apri TimerRoot.
2. Quando Shizuku chiede Consentire a TimerRoot di accedere a Shizuku?, scegli Consenti sempre.
3. La scheda diventa Pronto (Shizuku connesso, ancora nessun root). Se continua a mostrare Non connesso, premi Shizuku nella riga degli strumenti per richiedere di nuovo.

3. Preparazione

Prepare estrae assets/timer in /data/local/tmp/timer:

installed 307192 bytes

4. Ottenere una shell root

Un tocco. L'app esegue l'escalation, mantiene una shell uid=0 all'interno del servizio e poi avvia automaticamente il late-load di KernelSU:

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

La scheda passa a Root shell -> Jailbreak mode (u:r:ksu:s0). Se la fase KernelSU perde la sua corsa, la scheda diventa rossa con KernelSU failed, e dovresti riavviare prima di riprovare.

5. Riavvio

Usa la pillola Reboot. Passa attraverso il servizio (svc power reboot), quindi funziona anche quando nessuna shell root è ancora aperta. Il riavvio è anche l'unico modo pulito per rimuovere i processi parcheggiati e per scaricare KernelSU.

Dopo il riavvio, ricomincia dal passo 1: Shizuku è fermo e KernelSU è sparito.

La scheda di stato riflette ciò che è effettivamente attivo, rilevato eseguendo su -c id e verificando la presenza di u:r:ksu:s0:

scheda	significato
Not connected	Shizuku non è in esecuzione / non è associato
Ready	Shizuku connesso, nessun root ancora
Root shell	uid=0, u:r:shell:s0
Jailbreak mode	KernelSU caricato, su funziona in u:r:ksu:s0

Risoluzione dei problemi

KernelSU failed e base calibration failed nel log

La fase delle credenziali false necessita della base della mappa lineare del kernel, che l'exploit deriva dagli eventi di traccia page-alloc. Presuppone pagine da 4 KB:

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

Controlla la dimensione della pagina del dispositivo:

```bash
adb shell getconf PAGE_SIZE

• 4096: il layout differisce per un altro motivo; raccogli uname -r, il modello e il log completo e segnalalo upstream.
• 16384: l'exploit non può funzionare su questo dispositivo così com'è. Deve essere ricostruito per pagine da 16 KB (page shift, maschere e dimensioni degli ordini), il che è un lavoro di porting piuttosto che un'impostazione dell'app.

La root shell può comunque avere successo su un dispositivo del genere, perché quel percorso necessita solo dell'indirizzo della credenziale trapelato, non della base della mappa lineare.

La scheda resta su Not connected

Shizuku non è in esecuzione. Avvialo di nuovo (si arresta a ogni riavvio) e vedi il passaggio 1.

Prepare non segnala nulla

Una finestra di dialogo di sistema potrebbe coprire l'app (pairing di Shizuku, scansione dell'installer OPPO). Chiudila e premi di nuovo Prepare.

Sicurezza

Questo è un exploit del kernel. Leggi questo prima di premere qualsiasi cosa.

• Non terminare un processo parcheggiato. L'exploit mantiene vivo un processo con la pagina delle credenziali falsa fissata nei buffer dei socket. Terminarlo può mandare in panic il kernel. Il riavvio è l'unico modo pulito per rimuoverlo.
• Un riavvio cancella tutto: KernelSU, la root shell e i processi parcheggiati. Questo è il modo previsto per fermarsi.
• SELinux viene lasciato in modalità permissive fino al riavvio successivo.
• Un tentativo fallito lascia un nodo timerqueue obsoleto; altre app potrebbero andare in crash fino al riavvio.
• Usa questo solo su un dispositivo di tua proprietà o che sei esplicitamente autorizzato a modificare.

Struttura