
Android kernel exploit for CVE-2026-43499 (Futex-PI use-after-free) that gains temporary root on Xiaomi XIG04 to enable ADB. Includes automated payload build and one-tap activation.
A minimal Android app that turns on ADB on an au/KDDI Xiaomi "aristotle" (XIG04, Android 12) whose developer options can't be reached, using a temporary root obtained from CVE-2026-43499. It is a device-owner tool in the same category as KingRoot: it roots your own phone to flip a setting.
Scope: your own XIG04 running
Xiaomi/XIG04_jp_kdi/XIG04:12/SP1A.210812.016/V14.0.3.0.TMFJPKD. Not a general-purpose or remote exploit.
One button, one job:
preload.so) out of the APK into the app's
private filesDir, chmod 0700./system/bin/true with
LD_PRELOAD pointing at that payload. The payload's ELF constructor triggers
the Futex-PI use-after-free, takes tmp-root, and self-installs an su
client + daemon.su -c id and checking for uid=0.settings put global development_settings_enabled 1settings put global adb_enabled 1stop adbd; start adbd (falls back to setprop ctl.restart adbd)Every step is echoed to an on-screen log.
CVE-2026-43499 — a use-after-free in the Linux kernel Futex-PI path
(kernel/locking/rtmutex.c, remove_waiter()). aristotle's
5.10.136-android12 kernel is affected (CONFIG_FUTEX_PI=y,
CONFIG_RT_MUTEXES=y). The exploit uses a data-only "direct-root" (swap cred,
flip SELinux enforcing) and brute-forces MTE tags to survive the device's
hardening. The exploit source and the measured aristotle offsets live in the
exploit/ git submodule of this repository.
preload.so is not committed. It is produced from the exploit/ submodule
and embedded into the APK at build time:
exploit/ — git submodule: the CVE-2026-43499 aristotle exploit (builds
preload.so).buildExploitSo (wired into preBuild) runs the exploit's
make ... API=31, then copies the resulting preload.so into
app/src/main/assets/exploit/preload.so before the APK is packaged.A normal ./gradlew assembleDebug therefore builds the payload and ships it,
provided the Android NDK is installed.
# 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
No NDK / just want the app shell? Skip the payload build (the app then reports "exploit payload NOT deployed" and changes nothing at runtime):
./gradlew assembleDebug -PskipExploitBuild
Wrapper jar: gradle-wrapper.jar is not committed. Generate it once with
gradle wrapper --gradle-version 8.2, or build with a system Gradle (CI uses a
system Gradle, so no wrapper jar is required there).
.github/workflows/build-release.yml (GitHub Actions) builds the APK on every
push and publishes it as a GitHub Release (tag build-<run>), with the
app-debug.apk attached. The workflow checks out the exploit submodule,
installs JDK 17 / Android SDK 34 / NDK r29, and runs gradle assembleDebug,
which builds and embeds preload.so (API=31).
One-time setup: push this repo and the exploit repo to the same GitHub owner
as sibling repositories, so the submodule's relative url resolves. If the
exploit repo is private, add a repo-scoped PAT as the secret SUBMODULE_PAT
and uncomment the token: line in the workflow.
.
├── 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
git submodule update --init --recursive, install the NDK, then
./gradlew assembleDebug.adb_enabled is now: 1.adb_enabled in global
settings usually persists, and adbd does not need root once enabled.LD_PRELOAD can be denied
depending on the app domain; the exploit's own strategy handles this, and any
denial is surfaced in the log rather than hidden.