Activer ADB sur Aristotle

Une application Android minimale qui active ADB sur un au/KDDI Xiaomi « aristotle » (XIG04, Android 12) dont les options de développeur sont inaccessibles, à l'aide d'un root temporaire obtenu grâce à CVE-2026-43499. Il s'agit d'un outil de propriétaire d'appareil dans la même catégorie que KingRoot : il roote votre propre téléphone pour modifier un paramètre.

Périmètre : votre propre XIG04 fonctionnant sous Xiaomi/XIG04_jp_kdi/XIG04:12/SP1A.210812.016/V14.0.3.0.TMFJPKD. Pas un exploit à usage général ou à distance.

Ce qu'elle fait

Un bouton, une seule tâche :

1. Placez la charge utile de l'exploit (preload.so) extraite de l'APK dans le filesDir privé de l'application, chmod 0700.
2. Déclenchez le bug du noyau en lançant un /system/bin/true éphémère avec LD_PRELOAD pointant vers cette charge utile. Le constructeur ELF de la charge utile déclenche l'use-after-free Futex-PI, obtient un root temporaire et installe automatiquement un client su + un démon.
3. Confirmez le root en exécutant su -c id et en vérifiant la présence de uid=0.
4. Activez ADB en tant que root :
   • settings put global development_settings_enabled 1
   • settings put global adb_enabled 1
   • stop adbd; start adbd (repli sur setprop ctl.restart adbd)

Chaque étape est affichée dans un journal à l'écran.

La vulnérabilité

CVE-2026-43499 — une utilisation après libération (use-after-free) dans le chemin Futex-PI du noyau Linux (kernel/locking/rtmutex.c, remove_waiter()). Le noyau 5.10.136-android12 d'aristotle est concerné (CONFIG_FUTEX_PI=y, CONFIG_RT_MUTEXES=y). L'exploit utilise un « direct-root » data-only (échange du cred, bascule du mode enforcing de SELinux) et effectue un brute-force des balises MTE pour survivre au durcissement de l'appareil. Le code source de l'exploit et les offsets mesurés d'aristotle se trouvent dans le sous-module git exploit/ de ce dépôt.

La charge utile est construite automatiquement

preload.so n'est pas commité. Il est produit à partir du sous-module exploit/ et intégré dans l'APK au moment de la compilation :

• exploit/ — sous-module git : l'exploit aristotle CVE-2026-43499 (construit preload.so).
• La tâche Gradle buildExploitSo (branchée sur preBuild) exécute le make ... API=31 de l'exploit, puis copie le preload.so obtenu dans app/src/main/assets/exploit/preload.so avant l'empaquetage de l'APK.

Un simple ./gradlew assembleDebug construit donc la charge utile et l'embarque, à condition que le NDK Android soit installé.

Compilation

# 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

Pas de NDK / vous voulez seulement l'enveloppe de l'application ? Ignorez la compilation de la charge utile (l'application signale alors « exploit payload NOT deployed » et ne modifie rien à l'exécution) :

./gradlew assembleDebug -PskipExploitBuild

Wrapper jar : gradle-wrapper.jar n'est pas commité. Générez-le une fois avec gradle wrapper --gradle-version 8.2, ou compilez avec un Gradle système (la CI utilise un Gradle système, donc aucun wrapper jar n'y est nécessaire).

CI / versions

.github/workflows/build-release.yml (GitHub Actions) compile l'APK à chaque push et le publie sous forme de GitHub Release (tag build-<run>), avec l'app-debug.apk joint. Le workflow récupère le sous-module exploit, installe JDK 17 / Android SDK 34 / NDK r29, et exécute gradle assembleDebug, qui compile et intègre preload.so (API=31).

Configuration initiale : poussez ce dépôt et le dépôt de l'exploit vers le même propriétaire GitHub en tant que dépôts frères, afin que l'URL relative du sous-module soit résolue. Si le dépôt de l'exploit est privé, ajoutez un PAT doté du scope repo comme secret SUBMODULE_PAT et décommentez la ligne token: dans le workflow.

Arborescence

.
├── settings.gradle / build.gradle / gradle.properties   Gradle wiring
├── gradlew(.bat) + gradle/wrapper/                       wrapper
├── exploit/                                              git submodule (builds preload.so)
└── app/
    ├── build.gradle          minSdk 31 / targetSdk 31 / compileSdk 34, arm64-v8a; buildExploitSo task
    └── src/main/
        ├── AndroidManifest.xml         single launcher Activity, no dangerous perms
        ├── java/.../MainActivity.kt    button + scrolling log
        ├── java/.../ExploitRunner.kt   stage → LD_PRELOAD → su -c "settings ..."
        ├── res/{layout,values}/        UI, strings, theme
        └── assets/exploit/             preload.so is embedded here at build time

Exécution

1. git submodule update --init --recursive, installez le NDK, puis ./gradlew assembleDebug.
2. Installez et lancez l'application sur le XIG04. Si ADB est ce que vous essayez d'activer, installez l'APK depuis l'appareil lui-même (gestionnaire de fichiers / téléchargement depuis le navigateur) et ouvrez l'application depuis le lanceur.
3. Touchez Enable ADB (tmp-root) et suivez le journal. En cas de succès, il se termine par adb_enabled is now: 1.
4. Connectez ADB depuis votre PC comme d'habitude.

Limitations / avertissements

• Compilation unique. Les offsets sont liés à la ROM ci-dessus ; une autre compilation nécessite une charge utile re-portée.
• Le root temporaire est volatile. Le root est perdu au redémarrage. adb_enabled dans les paramètres globaux persiste généralement, et adbd n'a pas besoin de root une fois activé.
• SELinux / W^X. L'exécution d'un fichier privé de l'application via LD_PRELOAD peut être refusée selon le domaine de l'application ; la stratégie propre de l'exploit gère ce cas, et tout refus est affiché dans le journal plutôt que masqué.
• Utilisation sur appareil personnel uniquement. Cela sert à déverrouiller ADB sur du matériel que vous possédez.