Aristotle ADB Enable

Um aplicativo Android mínimo que ativa o ADB em um au/KDDI Xiaomi "aristotle" (XIG04, Android 12) cujas opções de desenvolvedor não podem ser acessadas, usando um root temporário obtido da CVE-2026-43499. É uma ferramenta de device owner na mesma categoria do KingRoot: faz root no seu próprio telefone para alterar uma configuração.

Escopo: seu próprio XIG04 executando Xiaomi/XIG04_jp_kdi/XIG04:12/SP1A.210812.016/V14.0.3.0.TMFJPKD. Não é um exploit de uso geral ou remoto.

O que ele faz

Um botão, uma tarefa:

1. Prepare o payload do exploit (preload.so) do APK para o filesDir privado do app, chmod 0700.
2. Dispare o bug do kernel executando um /system/bin/true de curta duração com LD_PRELOAD apontando para esse payload. O construtor ELF do payload aciona o use-after-free do Futex-PI, obtém tmp-root e auto-instala um cliente e daemon su.
3. Confirme o root executando su -c id e verificando uid=0.
4. Ative o ADB como root:
   • settings put global development_settings_enabled 1
   • settings put global adb_enabled 1
   • stop adbd; start adbd (recorre a setprop ctl.restart adbd)

Cada etapa é exibida em um log na tela.

A vulnerabilidade

CVE-2026-43499 — um use-after-free no caminho Futex-PI do kernel Linux (kernel/locking/rtmutex.c, remove_waiter()). O kernel 5.10.136-android12 do aristotle é afetado (CONFIG_FUTEX_PI=y, CONFIG_RT_MUTEXES=y). O exploit usa um "direct-root" somente com dados (troca o cred, alterna o SELinux enforcing) e força bruta nas tags MTE para sobreviver ao hardening do dispositivo. O código-fonte do exploit e os offsets medidos do aristotle estão no submódulo git exploit/ deste repositório.

O payload é construído automaticamente

O preload.so não é commitado. Ele é produzido a partir do submódulo exploit/ e embutido no APK no momento da compilação:

• exploit/ — submódulo git: o exploit CVE-2026-43499 para aristotle (gera preload.so).
• A tarefa Gradle buildExploitSo (ligada ao preBuild) executa o make ... API=31 do exploit e copia o preload.so resultante para app/src/main/assets/exploit/preload.so antes de o APK ser empacotado.

Portanto, um ./gradlew assembleDebug normal compila o payload e o envia, desde que o Android NDK esteja instalado.

Compilação

# 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

Sem NDK / só quer o shell do app? Pule a compilação do payload (o app então informa "exploit payload NOT deployed" e não altera nada em tempo de execução):

./gradlew assembleDebug -PskipExploitBuild

Jar do wrapper: o gradle-wrapper.jar não é commitado. Gere-o uma vez com gradle wrapper --gradle-version 8.2, ou compile com um Gradle do sistema (a CI usa um Gradle do sistema, portanto nenhum wrapper jar é necessário nesse caso).

CI / lançamentos

O .github/workflows/build-release.yml (GitHub Actions) compila o APK em cada push e o publica como uma GitHub Release (tag build-<run>), com o app-debug.apk anexado. O workflow faz checkout do submódulo exploit, instala JDK 17 / Android SDK 34 / NDK r29 e executa gradle assembleDebug, que compila e embute o preload.so (API=31).

Configuração única: faça push deste repositório e do repositório do exploit para o mesmo dono do GitHub como repositórios irmãos, para que a URL relativa do submódulo seja resolvida. Se o repositório do exploit for privado, adicione um PAT com escopo repo como o secret SUBMODULE_PAT e remova o comentário da linha token: no workflow.

Estrutura

.
├── 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

Execução

1. git submodule update --init --recursive, instale o NDK e depois ./gradlew assembleDebug.
2. Instale e execute no XIG04. Se o ADB é o que você está tentando ativar, instale o APK pelo próprio dispositivo (gerenciador de arquivos / download do navegador) e abra-o pelo launcher.
3. Toque em Enable ADB (tmp-root) e observe o log. Em caso de sucesso, ele termina com adb_enabled is now: 1.
4. Conecte o ADB a partir do seu PC como de costume.

Limitações / ressalvas

• Compilação única. Os offsets estão fixados para a ROM acima; uma compilação diferente exige um payload re-portado.
• tmp-root é volátil. O root é perdido na reinicialização. O adb_enabled nas configurações globais geralmente persiste, e o adbd não precisa de root depois de ativado.
• SELinux / W^X. Executar um arquivo privado do app via LD_PRELOAD pode ser bloqueado dependendo do domínio do app; a própria estratégia do exploit lida com isso, e qualquer negação é exibida no log em vez de ser ocultada.
• Uso somente como device owner. Isto é para desbloquear o ADB em hardware que você possui.