Aristotle ADB Aktivieren

Eine minimale Android-App, die ADB auf einem au/KDDI Xiaomi "aristotle" (XIG04, Android 12) aktiviert, dessen Entwickleroptionen nicht erreichbar sind, unter Verwendung eines temporären Roots, der über CVE-2026-43499 erlangt wurde. Es ist ein Gerätebesitzer-Tool in derselben Kategorie wie KingRoot: Es rootet Ihr eigenes Telefon, um eine Einstellung zu ändern.

Bereich: Ihr eigenes XIG04 mit Xiaomi/XIG04_jp_kdi/XIG04:12/SP1A.210812.016/V14.0.3.0.TMFJPKD. Kein allgemeiner oder Fern-Exploit.

Was es tut

Ein Knopf, eine Aufgabe:

Das Exploit-Payload (preload.so) aus der APK in das private filesDir der App legen, chmod 0700.
Den Kernel-Fehler auslösen, indem ein kurzlebiges /system/bin/true mit LD_PRELOAD gestartet wird, das auf dieses Payload zeigt. Der ELF-Konstruktor des Payloads löst den Futex-PI Use-After-Free aus, nimmt tmp-root und installiert selbst einen su-Client + Daemon.
Root bestätigen, indem su -c id ausgeführt und auf uid=0 geprüft wird.
ADB als Root aktivieren:
- settings put global development_settings_enabled 1
- settings put global adb_enabled 1
- stop adbd; start adbd (fällt zurück auf setprop ctl.restart adbd)

Jeder Schritt wird in einem Bildschirmprotokoll ausgegeben.

Die Sicherheitslücke

CVE-2026-43499 — ein Use-After-Free im Linux-Kernel-Futex-PI-Pfad (kernel/locking/rtmutex.c, remove_waiter()). aristotles 5.10.136-android12-Kernel ist betroffen (CONFIG_FUTEX_PI=y, CONFIG_RT_MUTEXES=y). Der Exploit verwendet ein reines Daten-'Direct-Root' (tauscht cred, schaltet SELinux enforcing um) und brute-forct MTE-Tags, um die Härtung des Geräts zu überleben. Der Exploit-Quellcode und die gemessenen aristotle-Offsets befinden sich im exploit/ git submodule dieses Repositorys.

Das Payload wird automatisch erstellt

preload.so wird nicht mitcommittiert. Es wird aus dem exploit/-Submodul erstellt und zur Build-Zeit in die APK eingebettet:

exploit/ — Git-Submodul: der CVE-2026-43499 aristotle-Exploit (erstellt preload.so).
Gradle-Task buildExploitSo (in preBuild eingebunden) führt das make ... API=31 des Exploits aus und kopiert dann das resultierende preload.so in app/src/main/assets/exploit/preload.so, bevor die APK gepackt wird.

Ein normales ./gradlew assembleDebug erstellt daher das Payload und liefert es aus, sofern das Android NDK installiert ist.

Erstellen

# 1. fetch the exploit submodule
git submodule update --init --recursive

# 2. install the Android NDK r29 (the exploit Makefile auto-detects it,
#    or export ANDROID_NDK_ROOT), plus JDK 17 and Android SDK platform 34

# 3. build — auto-builds preload.so (API=31) and embeds it
./gradlew assembleDebug          # -> app/build/outputs/apk/debug/app-debug.apk

Kein NDK / nur die App-Shell gewünscht? Überspringen Sie den Payload-Build (die App meldet dann "exploit payload NOT deployed" und ändert zur Laufzeit nichts):

./gradlew assembleDebug -PskipExploitBuild

Wrapper-JAR: gradle-wrapper.jar wird nicht mitcommittiert. Generieren Sie es einmal mit gradle wrapper --gradle-version 8.2, oder bauen Sie mit einem systemweiten Gradle (CI verwendet ein systemweites Gradle, daher ist dort kein Wrapper-JAR erforderlich).

CI / Releases

.github/workflows/build-release.yml (GitHub Actions) erstellt die APK bei jedem Push und veröffentlicht sie als GitHub-Release (Tag build-<run>), mit angehängter app-debug.apk. Der Workflow checkt das exploit-Submodul aus, installiert JDK 17 / Android SDK 34 / NDK r29 und führt gradle assembleDebug aus, welches preload.so (API=31) erstellt und einbettet.

Einmalige Einrichtung: Pushen Sie dieses Repo und das Exploit-Repo in den gleichen GitHub-Besitzer als Schwester-Repositories, damit die relative URL des Submoduls aufgelöst wird. Wenn das Exploit-Repo privat ist, fügen Sie ein repo-scoped PAT als Secret SUBMODULE_PAT hinzu und kommentieren Sie die token:-Zeile im Workflow aus.

Aufbau

.
├── settings.gradle / build.gradle / gradle.properties   Gradle-Einrichtung
├── gradlew(.bat) + gradle/wrapper/                       Wrapper
├── exploit/                                              Git-Submodul (erstellt preload.so)
└── app/
    ├── build.gradle          minSdk 31 / targetSdk 31 / compileSdk 34, arm64-v8a; buildExploitSo-Task
    └── src/main/
        ├── AndroidManifest.xml         einzelne Launcher-Activity, keine gefährlichen Berechtigungen
        ├── java/.../MainActivity.kt    Schaltfläche + scrollbares Protokoll
        ├── java/.../ExploitRunner.kt   Stage → LD_PRELOAD → su -c "settings ..."
        ├── res/{layout,values}/        UI, Zeichenketten, Theme
        └── assets/exploit/             preload.so wird hier zur Build-Zeit eingebettet

Ausführen

git submodule update --init --recursive, NDK installieren, dann ./gradlew assembleDebug.
Auf dem XIG04 installieren und starten. Wenn Sie ADB aktivieren möchten, installieren Sie die APK vom Gerät selbst (Dateimanager / Browser-Download) und öffnen Sie sie über den Launcher.
Tippen Sie auf ADB aktivieren (tmp-root) und beobachten Sie das Protokoll. Bei Erfolg endet es mit adb_enabled is now: 1.
Verbinden Sie ADB wie gewohnt von Ihrem PC.

Einschränkungen / Hinweise

Einmaliger Build. Offsets sind auf das obige ROM festgelegt; ein anderer Build benötigt ein neu portiertes Payload.
tmp-root ist flüchtig. Root geht nach einem Neustart verloren. adb_enabled in den globalen Einstellungen bleibt normalerweise bestehen, und adbd benötigt nach der Aktivierung kein Root mehr.
SELinux / W^X. Das Ausführen einer app-privaten Datei über LD_PRELOAD kann je nach App-Domain verweigert werden; die eigene Strategie des Exploits behandelt dies, und jede Verweigerung wird im Protokoll angezeigt und nicht versteckt.
Nur für Gerätebesitzer. Dies dient zum Freischalten von ADB auf eigener Hardware.

CVE-2026-43499-aristotle-apk build-43

Kategorien