O3 Root

Traduction chinoise : README.zh-CN.md — une traduction de ce fichier ; en cas de divergence, ce fichier anglais fait foi.

Élévation de privilèges locale + KernelSU pour la famille Xiaomi yingtian (Pad 9 Pro Max) et lhasa (Xiaomi 18 Fold) sous HyperOS 4 (Android 17, noyau 6.18.21). L'ensemble de la chaîne est livré sous forme d'une application Android normale qui pilote Shizuku en mode shell, exploite CVE-2026-98260, et charge le LKM de la famille KernelSU correspondant au gestionnaire installé (KernelSU / KernelSU-Next / SukiSU) — sans PC, sans bootloader déverrouillé, sans modification de partition.

Projet de recherche / d'éducation / de réparation d'appareils. Valable uniquement jusqu'au redémarrage (un redémarrage le supprime). À exécuter uniquement sur des appareils que vous possédez. Lisez docs/SECURITY.md avant de l'utiliser.

Agents / contributeurs automatisés : commencez par AGENTS.md (point d'entrée : invariants, recettes de build/test, pièges, hygiène), puis docs/AGENT_HANDOFF.md (état vérifié, expériences échouées, travaux en cours). Exécutez bash scripts/verify.sh avant de committer ; il reconstruit également la payload/l'APK lorsque l'environnement de la chaîne d'outils est défini.

Version chinoise : AGENTS.zh-CN.md / docs/AGENT_HANDOFF.zh-CN.md

État

version	v3.2 (release/o3root2-v3.2.apk, 14 239 248 o, sha256 64bbc654…)
build de test O1	v3.3.3-o1-test (release/test/o3root2-v3.3.3-o1-test.apk, 14 247 440 o, sha256 62411f72…) : v3.2 plus un profil O1 (XRING) expérimental (dijun / jinghu / violin) et la console root masquée. Accepte toute build OS4.0.0.x de la série de noyaux 6.18.21-android17…-4k : la build analysée est le chemin vérifié, les autres builds s'exécutent en mode assoupli avec un avertissement ; réservé aux testeurs, jamais validé sur matériel
build de test précédente	v3.2.1-console (release/beta/o3root2-v3.2.1-console.apk, 14 243 344 o, sha256 9cba365a…) : v3.2 stable plus une console root masquée (appui long sur la ligne de version ; trois confirmations)
appareils O1	SoC Xiaomi O1 dijun / jinghu / violin sous OS4.0.0.x : les trois embarquent le même noyau 6.18.21 (sha256 0d9917ca…, g1d099fcb35e0) ; l'analyse statique indique que la chaîne s'applique, aucun test sur appareil pour l'instant
LKM personnalisé	.ko de la famille KernelSU fourni facultativement par l'utilisateur (vérification de compatibilité basique ; retour au module adaptatif intégré ; le choix est enregistré et restauré au lancement — appui long sur la ligne pour l'effacer)
chaîne	shell Shizuku → CVE-2026-98260 → uid=0 + toutes les capacités → LKM KernelSU correspondant (KernelSU / KernelSU-Next / SukiSU) → rootd
persistance	aucune (boot actuel uniquement)
appareil testé	Xiaomi Pad 9 Pro Max yingtian, HyperOS OS4.0.16.0.XBMCNXM
second appareil	lhasa (Xiaomi 18 Fold, OS4.0.26.0.XPNCNXM) : le noyau de démarrage est bit à bit identique à celui du yingtian (sha256 cde87cd7…), donc la même payload s'applique ; non testé sur appareil

Fonctionnement (version courte)

1. L'application lance /system/bin/sh -c … via newProcess de Shizuku, de sorte que la charge utile s'exécute en u:r:shell:s0 (uid=2000).
2. La charge utile déclenche la course CLOCK_THREAD_CPUTIME_ID + execve/de_thread (CVE-2026-98260), récupère la page de slab d'ordre 1 posix_timers_cache libérée à l'aide d'un tampon kmalloc-8k pulvérisé contenant un nœud RB-tree forgé, et utilise le second timerqueue_del → rb_erase pour écrire une valeur de 8 octets à une adresse noyau arbitraire.
3. L'étape 0 efface enforcing par une écriture non alignée de 8 octets à selinux_state-7 (cela efface aussi les octets pending/tail adjacents de notif_lock ; initialized/policycap restent intacts) ; l'étape 1 écrit task_struct.cred dans une fausse page cred (uid 0, toutes les capacités).
4. La charge utile charge le LKM KernelSU embarqué : les symboles non définis sont résolus à l'exécution via /proc/kallsyms (repli : relink d'une union de 248 symboles + le décalage KASLR courant), avec aucun patch d'init — comme policycap est resté propre, le setenforce(1) de KernelSU est inoffensif et l'appareil termine en Enforcing. Ensuite il est chargé via insmod et un démon rootd est laissé en place (socket abstrait @o3p_rootd, peer-uid 0/2000). Les LKM KernelSU upstream, KernelSU-Next et SukiSU fonctionnent tous (héritage : O3P_CODEPATCH=1 patche l'immédiat de setenforce). Depuis la v3.1, l'application peut à la place charger un .ko que vous choisissez (vérification basique de compatibilité ELF/.modinfo, repli automatique sur le LKM intégré lorsqu'il est rejeté ou échoue au chargement). Depuis la v3.1.1, cette sélection est persistée (files/custom-ko.ko + custom-ko.meta) et restaurée au lancement ; un fichier obsolète qui ne valide plus est supprimé, et un appui long sur la ligne du module l'efface. Depuis la v3.2, la zone de log est sélectionnable et dispose d'une action 复制 qui copie l'intégralité du log ; elle ne défile automatiquement que lorsque vous êtes déjà près du bas. Sur un appareil O1 reconnu, la version de test demande une confirmation de risque en deux étapes avant le démarrage de la charge utile. La version de test masque en outre une console root derrière un appui long sur la ligne de version : trois confirmations non contournables, puis les commandes s'exécutent en root via la socket rootd (nécessite une exécution de la charge utile dans le boot courant). La version stable ne contient pas les classes de la console.

Voir docs/ARCHITECTURE.md pour les offsets, la primitive d'écriture, le patch KernelSU et le guide de portage.

Démarrage rapide

1. Sur l'appareil : activez Options pour les développeurs → Débogage sans fil (ou ADB). Installez Shizuku / ShizukuX et démarrez-le en mode shell : shizuku_plus_server doit s'exécuter en uid=2000, u:r:shell:s0.
2. Installez release/o3root2-v3.2.apk (MIUI peut nécessiter d'autoriser « Installer via USB »).
3. Ouvrez O3 Root, accordez la permission Shizuku, appuyez sur Continue to UID 0. Le log affiche ★ UIDNOW uid=0, ★ KSU_MODULE LIVE, et le gestionnaire KernelSU s'ouvre automatiquement.