GhostLock - Wrapper de Android (indev.ghostlock.s26)

Wrapper de Android con un solo clic para 1ndevelopment/ghostlock-s26: GhostLock (CVE-2026-43499) portado a toda la serie Samsung Galaxy S26 (Android 16 / GKI 6.12). Un APK, tres líneas de kernel, coincidencia de parámetros en tiempo de ejecución - sin variantes de app por compilación.

Úsalo solo en dispositivos que poseas o para los que tengas autorización explícita de probar. El root temporal desaparece al reiniciar. Una segunda ejecución del exploit en el mismo arranque puede bloquear el dispositivo - reinicia antes de reintentar.

Cobertura: toda la familia S26

El exploit coincide por línea de kernel, no por compilación individual (exploit/src/params_table.c es la fuente autoritativa; ParamsTable.kt la refleja solo para el veredicto de la UI):

Compilaciones probadas (17): S9420ZCS4AZG1, S9470ZCS4AZG1, S9480ZCS3AZF1, S9480ZCS4AZG1, S942BXXS4AZG5, S947BXXS3AZF1, S947BXXS4AZG5, S942QOPU1AZDE, S942U1UES4AZG3, S942USQS4AZG3, S947USQS4AZG3, S9480ZHS4AZG1, S948BXXS4AZG5/6, S948NKSS4AZG3, S948U1UES2AZE1, S948USQS4AZG3.

Las OTA desconocidas recurren exactamente igual que el params.c original: primero la compilación exacta, luego el mismo modelo + CSC de 3 caracteres (reutilización de OTA), luego la última entrada del mismo dispositivo (marcada como no verificada), o bien fail-closed (la app muestra UNSUPPORTED y la capa nativa sale con código 2). Los modelos completamente desconocidos se rechazan - nunca se fuerzan.

Qué hace la app

Un gran botón - Root my S26 - ejecuta todo el pipeline y va narrando en la tarjeta Output:

1. Comprobación del dispositivo - modelo/device/incremental/fingerprint más el veredicto de la serie (exacto / reutilización de OTA / conjetura no verificada / no soportado). Las compilaciones no soportadas se detienen aquí (fail-closed, sin quemar boot-claim).
2. Shizuku - se usa automáticamente cuando está conectado (uid 2000 shell, misma familia de contexto que el flujo adb shell del README). El permiso se solicita una vez al iniciar (y de nuevo si el servidor se reinicia); el flujo Root espera la concesión en lugar de abortar. Si el servidor está caído, la app abre el gestor de Shizuku para que puedas iniciarlo, y luego recurre al shell integrado. Añadir la app a la lista de permitidos de Shizuku elimina el aviso por completo.
3. Stage - copia preload.so, su_daemon, ksud a /data/local/tmp (preload.so, cve-2026-43499-root, ksud) y les aplica chmod. Si ya has hecho adb push de los archivos según el README original, se recogen en su sitio.
4. Run - ejecuta exactamente lo que documenta el upstream: env LD_PRELOAD=/data/local/tmp/preload.so sh (el constructor del ejecuta la cadena y hace ; stdout el log del exploit), hasta 5 intentos - la carrera es probabilística. Hay un interruptor disponible, pero reiniciar es más seguro.

Debajo de eso: una única fila de campo de comando + Run as root (comandos de un solo uso mediante el protocolo C del daemon su; el PTY interactivo queda fuera del alcance de la v1), y un pequeño enlace Reset que limpia /data/local/tmp/ghostlock-boot.log para poder reintentar una ejecución sin reiniciar (el upstream advierte que esto puede provocar un pánico - reiniciar es la vía segura).

Estructura del proyecto

exploit/                  upstream vendorizado (Makefile + src/, autoritativo)
ksud                      loader KernelSU precompilado del upstream (ARM64 PIE, también en assets)
app/src/main/assets/ksud  copia preparada incluida en el APK
app/src/main/assets/      + preload.so / su_daemon tras stage-assets.sh
app/src/main/cpp/         recompilación CMake opcional de preload.so desde exploit/src
app/src/main/java/indev/ghostlock/s26/
  MainActivity.kt         UI (device / stage / run / shell / boot guard)
  ParamsTable.kt          espejo de la tabla de series (17 compilaciones, 3 líneas, 5 códigos)
  DeviceCompat.kt         identidad Build.* + veredicto de serie
  ShellRunner.kt          Shizuku (uid 2000) + fallback local, staging
  SuClient.kt             cliente en modo 'C' de /data/local/tmp/temp_su.sock
  GhostlockManager.kt     intérprete de códigos de salida (0/1/2/3/4)
PORTING.upstream.md       notas de portado (nuevo firmware = nueva fila en device_map)

Compilación

Requisitos: Android Studio (JBR 21) / SDK 35 / NDK r26+ / CMake 3.22.1 / JDK 17.

# 1. Build the native payloads with the NDK (upstream flow):
cd exploit && make preload
#   -> build/bin/preload.so, build/embed/su_daemon_aarch64_pie

# 2. Stage them into the APK assets:
./stage-assets.sh

# 3. Build the app:
./gradlew :app:assembleDebug
#   -> app/build/outputs/apk/debug/app-debug.apk

ksud ya está vendorizado (ksud + app/src/main/assets/ksud), así que los pasos 1–2 solo producen las dos salidas del NDK. El objetivo CMake en app/src/main/cpp/CMakeLists.txt puede además recompilar libpreload.so desde las mismas fuentes dentro del APK como fallback.

Compilación en el dispositivo (Termux, aarch64)

El aapt2/NDK del SDK son x86_64 y no pueden ejecutarse en el dispositivo. Procedimiento verificado (SDK en ~/android-sdk, Gradle 8.9 - AGP 8.5.2 rechaza el Gradle 9.x del sistema):

# Native payloads with the Termux toolchain (API 35 target, system liblog):
cd exploit
clang -O2 --target=aarch64-linux-android35 -fPIE -pie -Isrc src/su_daemon.c \
  -o build/embed/su_daemon_aarch64_pie
clang -O2 --target=aarch64-linux-android35 -fPIC -Isrc \
  -Wno-unused-parameter -Wno-sign-compare -Wno-unused-function -Wno-macro-redefined \
  src/main.c src/util.c src/bootclaim.c src/slide.c src/fops.c src/attr.c \
  src/root.c src/params.c src/params_table.c src/preload.c \
  -L/system/lib64 -llog -shared -o build/bin/preload.so
cd .. && ./stage-assets.sh

# APK (CMake native step auto-skips without SDK cmake; Termux aarch64 aapt2
# is injected via -P so checked-in files stay workstation-clean):
env ANDROID_HOME=~/android-sdk ANDROID_SDK_ROOT=~/android-sdk \
  JAVA_HOME=$PREFIX/lib/jvm/java-21-openjdk \
  ~/gradle-dists/gradle-8.9/bin/gradle :app:assembleDebug --console=plain \
  -Pandroid.aapt2FromMavenOverride=$(command -v aapt2)

Ejecución

1. Instala el APK en el dispositivo S26 + instala/inicia Shizuku (depuración inalámbrica o PC).
2. Abre GhostLock - el permiso de Shizuku se solicita automáticamente al iniciar; apruébalo una vez (dura hasta que el servidor Shizuku se reinicie).
3. Comprueba que la tarjeta Device indique SUPPORTED/LIKELY para tu compilación.
4. Pulsa Stage, luego Run once. La carrera es probabilística - usa Retry ×5; varios intentos son normales.
5. Check root → espera uid=0 …. Luego ejecuta comandos en la tarjeta Root shell.
6. Tras el éxito, instala/disfruta de KernelSU Manager (me.weishu.kernelsu); el daemon carga ksud automáticamente en modo tardío (ver el modo K de su_daemon.c).

Shizuku es opcional pero muy recomendable: el flujo del upstream se ejecuta desde un adb shell (uid 2000, contexto SELinux shell), y el fallback integrado en la app (untrusted_app) tiene muchas más probabilidades de ser bloqueado para LD_PRELOAD/exec en /data/local/tmp.

Códigos de salida (mostrados tras cada intento)

Procedencia

• Exploit: exploit/ + PORTING.upstream.md + ksud de 1ndevelopment/ghostlock-s26 (Apache-2.0; ver LICENSE.upstream, NOTICE.upstream). La app no enlaza ningún código del exploit en su propio proceso - prepara los archivos compilados con el NDK y lanza el shell LD_PRELOAD documentado.
• Créditos (upstream): Nebula Security (descubrimiento del CVE), polygraphene (baseline), monovibe (UMH root / boot-claim), lukasmaar (kernelsnitch), veritas501 (concepto de pipe), BuSung-dev (base de la app complementaria).