TimerRoot

Front-end Android pour CVE-2026-98260 (use-after-free sur les minuteurs CPU POSIX), la même classe de bug que CVE-2026-64560. Une seule touche vous donne un shell root, puis charge tardivement KernelSU (u:r:ksu:s0).

L'exploit lui-même n'est pas inclus ici. Ce dépôt est la coquille applicative autour de celui-ci : l'interface utilisateur, la détection d'état et la plomberie Shizuku nécessaire pour exécuter un exploit en domaine shell depuis une application ordinaire.

Pourquoi l'application a besoin de Shizuku

Une application s'exécute en tant que untrusted_app et ne peut pas lire /sys/kernel/tracing, dont l'exploit a besoin pour sa fuite et son déclenchement. TimerRoot démarre donc un service utilisateur Shizuku, que Shizuku exécute en tant qu'utilisateur shell (uid 2000, u:r:shell:s0). Le binaire de l'exploit s'exécute à l'intérieur de ce processus, il obtient donc le même environnement que celui qu'il aurait via 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

Prérequis

• Android 12+ (minSdk 30), arm64
• Shizuku en cours d'exécution (lancez-le depuis l'application Shizuku via le débogage sans fil, ou via ADB)
• Le gestionnaire KernelSU installé, pour le chemin Load KernelSU
• Une compilation du noyau vers laquelle l'exploit a été porté. Le binaire upstream cible 6.12.69-android16-6-g242e1a07f878-ab15865446-4k ; voir ci-dessous.

Obtenir le binaire de l'exploit

TimerRoot attend l'exploit compilé à l'emplacement 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

ou

scripts/fetch-timer.ps1

Le binaire est sous licence MIT par ses auteurs ; ne l'utilisez que sur du matériel que vous possédez, et uniquement lorsque votre noyau correspond à la version pour laquelle il a été porté.

Compilation

Android Studio / Gradle

Ouvrez le projet et compilez, ou :

./gradlew assembleDebug

Le projet nécessite le SDK Android avec la plateforme 36 et les build-tools 36. L'API Shizuku est récupérée depuis Maven (dev.rikka.shizuku:api).

Sans Gradle

scripts/build.ps1 compile et signe un APK avec uniquement le SDK, javac, d8, aapt2 et apksigner. Il n'intègre aucune dépendance tierce : il compile l'application avec les sources de l'API Shizuku, il faut donc d'abord cloner celles-ci :

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

Utilisation

1. Démarrer Shizuku

Shizuku doit être en cours d'exécution avant que TimerRoot puisse faire quoi que ce soit : c'est le processus qui fournit l'utilisateur shell dont l'exploit a besoin. Shizuku s'arrête à chaque redémarrage, c'est donc la première étape à chaque fois.

Débogage sans fil (aucun PC après le premier appairage)

1. Activer les options pour les développeurs : Paramètres -> À propos de l'appareil -> appuyer 7 fois sur Numéro de build.
2. Paramètres -> Système -> Options pour les développeurs -> Débogage sans fil -> activé.
3. Ouvrir l'application Shizuku -> Démarrer -> Démarrer via le débogage sans fil.
4. Autoriser la notification, puis dans Associer l'appareil avec un code d'association saisir le code à 6 chiffres affiché sur le téléphone.
5. Shizuku indique « Shizuku is running » (la notification indique que le serveur est actif).

Via USB

Avec le téléphone connecté et le débogage USB autorisé :

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

Les versions plus récentes de Shizuku peuvent ne plus fournir ce script ; s'il est absent, utilisez la méthode de débogage sans fil ci-dessus.

Vérifiez que le serveur est démarré :

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

ps n'affichant que moe.shizuku.privileged.api signifie que l'application gestionnaire est ouverte mais que le serveur **n'**est pas en cours d'exécution ; l'exploit ne peut pas démarrer tant que ce n'est pas le cas.

2. Premier lancement

1. Ouvrez TimerRoot.
2. Lorsque Shizuku demande Allow TimerRoot to access Shizuku?, choisissez Allow all the time.
3. La carte passe à Ready (Shizuku connecté, pas encore de root). Si elle affiche toujours Not connected, appuyez sur Shizuku dans la rangée d'outils pour effectuer une nouvelle demande.

3. Préparation

Prepare extrait assets/timer vers /data/local/tmp/timer :

installed 307192 bytes

4. Obtenir un shell root

Une seule touche. L'application élève ses privilèges, conserve un shell uid=0 à l'intérieur du service, puis démarre automatiquement le chargement tardif de KernelSU :

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

La carte passe en Root shell -> Jailbreak mode (u:r:ksu:s0). Si l'étape KernelSU perd sa course, la carte devient rouge avec KernelSU failed, et vous devez redémarrer avant de réessayer.

5. Redémarrer

Utilisez la pilule Reboot. Elle passe par le service (svc power reboot), donc elle fonctionne même lorsqu'aucun shell root n'est encore ouvert. Le redémarrage est également le seul moyen propre de supprimer les processus parqués et de décharger KernelSU.

Après le redémarrage, recommencez à l'étape 1 : Shizuku est arrêté et KernelSU a disparu.

La carte de statut reflète ce qui est réellement actif, détecté en exécutant su -c id et en vérifiant la présence de u:r:ksu:s0 :

carte	signification
Not connected	Shizuku n'est pas en cours d'exécution / n'est pas lié
Ready	Shizuku connecté, pas encore de root
Root shell	uid=0, u:r:shell:s0
Jailbreak mode	KernelSU chargé, su fonctionne dans u:r:ksu:s0

Dépannage

KernelSU failed et base calibration failed dans le journal

L'étape des faux identifiants a besoin de la base de la table linéaire du noyau, que l'exploit dérive des événements de trace d'allocation de pages. Il suppose des pages de 4 Ko :

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

Vérifiez la taille de page de l'appareil :

adb shell getconf PAGE_SIZE

• 4096 : la disposition diffère pour une autre raison ; collectez uname -r, le modèle et le journal complet et signalez-le en amont.
• 16384 : l'exploit ne peut pas fonctionner sur cet appareil tel qu'il est livré. Il doit être reconstruit pour des pages de 16 Ko (décalages de page, masques et tailles d'ordre), ce qui est un travail de portage plutôt qu'un réglage d'application.

Le shell root peut néanmoins réussir sur un tel appareil, car ce chemin ne nécessite que l'adresse du credential divulguée, pas la base de la carte linéaire.

La carte reste sur Not connected

Shizuku n'est pas en cours d'exécution. Relancez-le (il s'arrête à chaque redémarrage) et consultez l'étape 1.

Prepare ne signale rien

Une boîte de dialogue système peut recouvrir l'application (appairage Shizuku, analyse de l'installateur OPPO). Fermez-la et appuyez à nouveau sur Prepare.

Sécurité

Il s'agit d'un exploit noyau. Lisez ceci avant d'appuyer sur quoi que ce soit.