O3 Root

Chinesische Übersetzung: README.zh-CN.md — eine Übersetzung dieser Datei; bei Abweichungen ist diese englische Datei maßgeblich.

Lokale Privilegieneskalation + KernelSU für die Xiaomi-Familie yingtian (Pad 9 Pro Max) und lhasa (Xiaomi 18 Fold) unter HyperOS 4 (Android 17, Kernel 6.18.21). Die gesamte Kette wird als normale Android-App ausgeliefert, die Shizuku im Shell-Modus ansteuert, CVE-2026-98260 ausnutzt und das KernelSU-Familien-LKM lädt, das zum installierten Manager passt (KernelSU / KernelSU-Next / SukiSU) — kein PC, kein entsperrter Bootloader, keine Partitionsänderungen.

Forschungs- / Bildungs- / Gerätereparaturprojekt. Nur für den aktuellen Boot (ein Neustart entfernt es). Nur auf Geräten ausführen, die dir gehören. Lies docs/SECURITY.md vor der Verwendung.

Agenten / automatisierte Beitragende: Beginne mit AGENTS.md (Einstiegspunkt: Invarianten, Build-/Test-Rezepte, Fallstricke, Hygiene), dann docs/AGENT_HANDOFF.md (verifizierter Zustand, fehlgeschlagene Experimente, offene Arbeiten). Führe bash scripts/verify.sh vor dem Committen aus; es baut auch die Payload/APK neu, wenn die Toolchain-Umgebung gesetzt ist.

中文版： AGENTS.zh-CN.md / docs/AGENT_HANDOFF.zh-CN.md

Status

Release	v3.2 (release/o3root2-v3.2.apk, 14.239.248 B, sha256 64bbc654…)
O1-Testbuild	v3.3.3-o1-test (release/test/o3root2-v3.3.3-o1-test.apk, 14.247.440 B, sha256 62411f72…): v3.2 plus ein experimentelles O1-(XRING)-Profil (dijun / jinghu / violin) und die versteckte Root-Konsole. Akzeptiert jeden OS4.0.0.x-Build auf der Kernel-Serie 6.18.21-android17…-4k: der analysierte Build ist der verifizierte Pfad, andere Builds laufen im entspannten Modus mit einer Warnung; nur für Tester, nie auf Hardware validiert
Vorheriger Testbuild	v3.2.1-console (release/beta/o3root2-v3.2.1-console.apk, 14.243.344 B, sha256 9cba365a…): stabiles v3.2 plus eine versteckte Root-Konsole (langes Drücken auf die Versionszeile; drei Bestätigungen)
O1-Geräte	Xiaomi O1 SoC dijun / jinghu / violin unter OS4.0.0.x: alle drei liefern den gleichen 6.18.21-Kernel (sha256 0d9917ca…, g1d099fcb35e0); die statische Analyse sagt, dass die Kette anwendbar ist, noch kein Gerätetest
Benutzerdefiniertes LKM	optionales, vom Benutzer bereitgestelltes KernelSU-Familien-.ko (grundlegende Kompatibilitätsprüfung; fällt auf das integrierte adaptive Modul zurück; die Auswahl wird gespeichert und beim Start wiederhergestellt — langes Drücken auf die Zeile zum Löschen)
Kette	Shizuku-Shell → CVE-2026-98260 → uid=0 + volle Caps → passendes KernelSU-LKM (KernelSU / KernelSU-Next / SukiSU) → rootd
Persistenz	keine (nur aktueller Boot)
Getestetes Gerät	Xiaomi Pad 9 Pro Max yingtian, HyperOS OS4.0.16.0.XBMCNXM
Zweites Gerät	lhasa (Xiaomi 18 Fold, OS4.0.26.0.XPNCNXM): der Boot-Kernel ist bit-identisch mit dem von yingtian (sha256 cde87cd7…), daher gilt dieselbe Payload; nicht auf dem Gerät getestet

Funktionsweise (Kurzfassung)

1. Die App startet /system/bin/sh -c … über Shizuku's newProcess, sodass die Payload in u:r:shell:s0 (uid=2000) läuft.
2. Die Payload löst das Rennen zwischen CLOCK_THREAD_CPUTIME_ID und execve/de_thread aus (CVE-2026-98260), beansprucht die freigegebene posix_timers_cache-Slab-Seite der Ordnung 1 mit einem gesprayten kmalloc-8k-Puffer zurück, der einen gefälschten RB-Tree-Knoten enthält, und nutzt das zweite timerqueue_del → rb_erase, um einen 8-Byte-Wert an eine beliebige Kernel-Adresse zu schreiben.
3. Stage 0 löscht enforcing mit einem 8-Byte-unaligned-Write bei selinux_state-7 (dies löscht auch die angrenzenden notif_lock-Pending/Tail- Bytes; initialized/policycap bleiben intakt); Stage 1 schreibt task_struct.cred in eine gefälschte Cred-Seite (uid 0, volle Caps).
4. Die Payload lädt das eingebettete KernelSU-LKM: Undefinierte Symbole werden zur Laufzeit über /proc/kallsyms aufgelöst (Fallback: 248-Symbol-Union-Relink + der aktuelle KASLR-Slide), mit keinem Init-Patch — da policycap sauber blieb, ist KernelSUs eigenes setenforce(1) harmlos und das Gerät endet im Enforcing-Modus. Dann wird es per insmod geladen und ein rootd-Daemon bleibt zurück (abstrakter Socket @o3p_rootd, Peer-uid 0/2000). Upstream KernelSU, KernelSU-Next und SukiSU LKMs funktionieren alle (Legacy: O3P_CODEPATCH=1 patcht das setenforce-Immediate). Seit v3.1 kann die App stattdessen ein von dir gewähltes .ko laden (grundlegende ELF/.modinfo-Kompatibilitätsprüfung, automatischer Fallback auf das eingebaute LKM, wenn es abgelehnt wird oder nicht lädt). Seit v3.1.1 wird diese Auswahl persistiert (files/custom-ko.ko + custom-ko.meta) und beim Start wiederhergestellt; eine veraltete Datei, die nicht mehr validiert, wird verworfen, und ein langer Druck auf die Modulzeile löscht sie. Seit v3.2 ist das Log-Feld selektierbar und hat eine 复制-Aktion, die das gesamte Log kopiert; es scrollt nur automatisch, solange du bereits nahe am Ende bist. Auf einem erkannten O1-Gerät verlangt der Test-Build eine zweistufige Risikobestätigung, bevor die Payload startet. Der Test- Build versteckt zusätzlich eine Root-Konsole hinter einem langen Druck auf die Versionszeile: drei nicht überspringbare Bestätigungen, dann werden Befehle als Root über den rootd-Socket ausgeführt (erfordert einen Payload-Lauf im aktuellen Boot). Der stabile Build enthält die Konsolen-Klassen nicht.

Siehe docs/ARCHITECTURE.md für Offsets, das Write- Primitive, den KernelSU-Patch und die Portierungsanleitung.

Schnellstart

1. Auf dem Gerät: Entwickleroptionen aktivieren → Drahtloses Debugging (oder ADB). Installiere Shizuku / ShizukuX und starte es im Shell-Modus: shizuku_plus_server muss als uid=2000, u:r:shell:s0 laufen.
2. Installiere release/o3root2-v3.2.apk (MIUI benötigt möglicherweise die Erlaubnis „Installation via USB").
3. Öffne O3 Root, erteile die Shizuku-Berechtigung, drücke Continue to UID 0. Das Log zeigt ★ UIDNOW uid=0, ★ KSU_MODULE LIVE, und der KernelSU-Manager öffnet sich automatisch.