TimerRoot

Android-Frontend für CVE-2026-98260 (POSIX-CPU-Timer-Use-after-free), dieselbe Fehlerklasse wie CVE-2026-64560. Ein Tippen liefert eine Root-Shell und lädt danach verzögert KernelSU nach (u:r:ksu:s0).

Der Exploit selbst ist hier nicht enthalten. Dieses Repository ist die App-Hülle darum herum: UI, Zustandserkennung und die Shizuku-Anbindung, die nötig ist, um einen Shell-Domain-Exploit aus einer gewöhnlichen App heraus auszuführen.

Warum die App Shizuku benötigt

Eine App läuft als untrusted_app und kann /sys/kernel/tracing nicht lesen, was der Exploit für sein Leak und seinen Trigger benötigt. TimerRoot startet daher einen Shizuku-Benutzerdienst, den Shizuku als Shell-Benutzer (uid 2000, u:r:shell:s0) ausführt. Das Exploit-Binary läuft innerhalb dieses Prozesses und erhält somit dieselbe Umgebung, die es auch über adb shell hätte.

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

Voraussetzungen

• Android 12+ (minSdk 30), arm64
• Laufendes Shizuku (starte es aus der Shizuku-App über Wireless Debugging oder über ADB)
• Installierter KernelSU-Manager für den Load KernelSU-Pfad
• Ein Kernel-Build, auf den der Exploit portiert wurde. Das Upstream-Binary zielt auf 6.12.69-android16-6-g242e1a07f878-ab15865446-4k; siehe unten.

Das Exploit-Binary beschaffen

TimerRoot erwartet das kompilierte Exploit unter 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

oder

scripts/fetch-timer.ps1

Die Binärdatei ist von ihren Autoren unter der MIT-Lizenz lizenziert; verwenden Sie sie nur auf Hardware, die Ihnen gehört, und nur, wenn Ihr Kernel mit dem Build übereinstimmt, auf den sie portiert wurde.

Build

Android Studio / Gradle

Öffnen Sie das Projekt und bauen Sie es, oder:

./gradlew assembleDebug

Das Projekt benötigt das Android SDK mit Plattform 36 und build-tools 36. Die Shizuku-API wird von Maven bezogen (dev.rikka.shizuku:api).

Ohne Gradle

scripts/build.ps1 erstellt und signiert ein APK nur mit dem SDK, javac, d8, aapt2 und apksigner. Es bindet nichts ein: Es kompiliert die App zusammen mit den Shizuku-API-Quellen, daher müssen diese zuerst geklont werden:

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

Verwendung

1. Shizuku starten

Shizuku muss laufen, bevor TimerRoot irgendetwas tun kann: Es ist der Prozess, der dem Shell-Benutzer die Rechte bereitstellt, die der Exploit benötigt. Shizuku wird bei jedem Neustart beendet, daher ist dies jedes Mal der erste Schritt.

Drahtloses Debugging (kein PC nach dem ersten Pairing)

1. Entwickleroptionen aktivieren: Einstellungen -> Über das Telefon -> 7x auf Build-Nummer tippen.
2. Einstellungen -> System -> Entwickleroptionen -> Drahtloses Debugging -> ein.
3. Shizuku-App öffnen -> Starten -> Über drahtloses Debugging starten.
4. Die Benachrichtigung zulassen und dann unter Gerät mit Pairing-Code koppeln den 6-stelligen Code eingeben, der auf dem Telefon angezeigt wird.
5. Shizuku meldet „Shizuku läuft“ (die Benachrichtigung zeigt an, dass der Server aktiv ist).

Über USB

Mit angeschlossenem Telefon und autorisiertem USB-Debugging:

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

Neuere Shizuku-Versionen enthalten dieses Skript möglicherweise nicht mehr; falls es fehlt, verwende den oben beschriebenen Weg über die drahtlose Debugging-Funktion.

Prüfe, ob der Server läuft:

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

ps, das nur moe.shizuku.privileged.api anzeigt, bedeutet, dass die Manager-App geöffnet ist, aber der Server nicht läuft; der Exploit kann erst starten, wenn er läuft.

2. Erster Start

1. Öffne TimerRoot.
2. Wenn Shizuku fragt Allow TimerRoot to access Shizuku?, wähle Allow all the time.
3. Die Karte wechselt zu Ready (Shizuku verbunden, noch kein Root). Wenn dort weiterhin Not connected steht, drücke Shizuku in der Werkzeugleiste, um erneut anzufragen.

3. Vorbereiten

Prepare extrahiert assets/timer nach /data/local/tmp/timer:

installed 307192 bytes

4. Root-Shell erhalten

Ein Tippen. Die App eskaliert, behält eine uid=0-Shell innerhalb des Dienstes und startet dann automatisch das Late-Load von KernelSU:

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

Die Karte wechselt zu Root-Shell -> Jailbreak-Modus (u:r:ksu:s0). Wenn die KernelSU-Stufe ihr Rennen verliert, wird die Karte rot mit KernelSU failed, und du solltest neu starten, bevor du es erneut versuchst.

5. Neustart

Verwende die Reboot-Pille. Sie läuft über den Dienst (svc power reboot), funktioniert also auch dann, wenn noch keine Root-Shell geöffnet ist. Ein Neustart ist auch der einzige saubere Weg, geparkte Prozesse zu entfernen und KernelSU zu entladen.

Nach dem Neustart beginne wieder bei Schritt 1: Shizuku ist gestoppt und KernelSU ist weg.

Die Statuskarte spiegelt wider, was tatsächlich aktiv ist, erkannt durch Ausführen von su -c id und Prüfen auf u:r:ksu:s0:

Karte	Bedeutung
Nicht verbunden	Shizuku läuft nicht / ist nicht gebunden
Bereit	Shizuku verbunden, noch kein Root
Root-Shell	uid=0, u:r:shell:s0
Jailbreak-Modus	KernelSU geladen, su funktioniert in u:r:ksu:s0

Fehlerbehebung

KernelSU failed und base calibration failed im Log

Die Fake-Credential-Stufe benötigt die lineare Kernel-Map-Basis, die der Exploit aus Page-Alloc-Trace-Events ableitet. Er geht von 4-KB-Seiten aus:

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

Prüfen Sie die Seitengröße des Geräts:

adb shell getconf PAGE_SIZE

• 4096: das Layout unterscheidet sich aus einem anderen Grund; sammle uname -r, das Modell und das vollständige Log und melde es upstream.
• 16384: Der Exploit kann auf diesem Gerät im Auslieferungszustand nicht funktionieren. Er muss für 16-KB-Seiten neu gebaut werden (Page-Shifts, Masken und Order-Größen), was eine Portierungsarbeit und keine App-Einstellung ist.

Die Root-Shell kann auf einem solchen Gerät trotzdem erfolgreich sein, weil dieser Pfad nur die geleakte Credential-Adresse benötigt, nicht die Basis der linearen Abbildung.

Die Karte bleibt auf Not connected

Shizuku läuft nicht. Starte es erneut (es stoppt bei jedem Neustart) und siehe Schritt 1.

Prepare meldet nichts

Ein Systemdialog könnte die App überdecken (Shizuku-Kopplung, OPPO-Installer-Scan). Schließe ihn und drücke erneut Prepare.

Sicherheit

Dies ist ein Kernel-Exploit. Lies dies, bevor du irgendetwas drückst.

• Beende keinen geparkten Prozess. Der Exploit hält einen Prozess am Leben, wobei die gefälschte Credential-Seite in Socket-Puffern festgehalten wird. Das Reapen kann den Kernel in eine Panik versetzen. Ein Neustart ist der einzige saubere Weg, ihn zu entfernen.
• Ein Neustart löscht alles: KernelSU, die Root-Shell und die geparkten Prozesse. Das ist der vorgesehene Weg zum Beenden.
• SELinux bleibt permissiv bis zum nächsten Neustart.
• Ein fehlgeschlagener Versuch hinterlässt einen veralteten Timerqueue-Knoten; andere Apps können abstürzen, bis du neu startest.
• Verwende dies nur auf einem Gerät, das dir gehört oder das du ausdrücklich ändern darfst.

Layout