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

Wrapper Android com um clique para 1ndevelopment/ghostlock-s26: GhostLock (CVE-2026-43499) portado para toda a série Samsung Galaxy S26 (Android 16 / GKI 6.12). Um APK, três linhas de kernel, correspondência de parâmetros em tempo de execução - sem variantes de app por build.

Use apenas em dispositivos que você possui ou está explicitamente autorizado a testar. O root temporário desaparece ao reiniciar. Uma segunda execução do exploit no mesmo boot pode travar o dispositivo - reinicie antes de tentar novamente.

Cobertura: toda a família S26

O exploit corresponde por linha de kernel, não por build individual (exploit/src/params_table.c é autoritativo; ParamsTable.kt o espelha apenas para o veredito da UI):

Codinome do dispositivo	Marketing	SoC	Linha de kernel
m1q	Galaxy S26 (SM-S942x)	Snapdragon	`cn` ou `intl` (por CSC)
m2q	Galaxy S26+ (SM-S947x)	Snapdragon	`cn` ou `intl` (por CSC)
m3q	Galaxy S26 Ultra (SM-S948x)	Snapdragon	`cn` ou `intl` (por CSC)
m1s	Galaxy S26 (SM-S942B)	Exynos	`exynos`
m2s	Galaxy S26+ (SM-S947B)	Exynos	`exynos`

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

OTAs desconhecidas fazem fallback exatamente como o params.c upstream: build exata primeiro, depois mesmo modelo + CSC de 3 caracteres (reuso de OTA), depois a entrada mais recente do mesmo dispositivo (marcada como não verificada), senão fail-closed (o app mostra UNSUPPORTED e a camada nativa sai com código 2). Modelos completamente desconhecidos são recusados - nunca forçados.

O que o app faz

Um botão grande - Root my S26 - executa todo o pipeline e narra no card Output:

Verificação do dispositivo - modelo/device/incremental/fingerprint mais o veredito da série (exata / reuso de OTA / palpite não verificado / não suportado). Builds não suportadas param aqui (fail-closed, nenhum boot-claim consumido).
Shizuku - usado automaticamente quando conectado (uid 2000 shell, mesma família de contexto do fluxo adb shell do README). A permissão é solicitada uma vez no lançamento (e novamente se o servidor reiniciar); o fluxo Root aguarda a concessão em vez de abortar. Se o servidor estiver fora do ar, o app abre o gerenciador do Shizuku para você iniciá-lo, depois faz fallback para o shell interno do app. Adicionar o app à allowlist do Shizuku remove o prompt completamente.
Stage - copia preload.so, su_daemon, ksud para /data/local/tmp (preload.so, cve-2026-43499-root, ksud) e aplica chmod neles. Se você já fez adb push dos arquivos conforme o README upstream, eles são usados no local.
Run - executa exatamente o que o upstream documenta: env LD_PRELOAD=/data/local/tmp/preload.so sh (o construtor do executa a cadeia e faz ; stdout o log do exploit), até 5 tentativas - a corrida é probabilística. Um switch está disponível, mas reiniciar é mais seguro.

Abaixo disso: uma única linha de campo de comando + Run as root (comandos one-shot via protocolo C do daemon su; PTY interativo está fora do escopo da v1), e um pequeno link Reset que limpa /data/local/tmp/ghostlock-boot.log para que uma execução possa ser repetida sem reiniciar (o upstream avisa que isso pode causar panic - reiniciar é o caminho seguro).

Estrutura do projeto

exploit/                  vendored upstream (Makefile + src/, autoritativo)
ksud                      loader KernelSU pré-compilado upstream (ARM64 PIE, também em assets)
app/src/main/assets/ksud  cópia preparada incluída no APK
app/src/main/assets/      + preload.so / su_daemon após stage-assets.sh
app/src/main/cpp/         rebuild CMake opcional de preload.so a partir de exploit/src
app/src/main/java/indev/ghostlock/s26/
  MainActivity.kt         UI (device / stage / run / shell / boot guard)
  ParamsTable.kt          espelho da tabela da série (17 builds, 3 linhas, 5 codinomes)
  DeviceCompat.kt         identidade Build.* + veredito da série
  ShellRunner.kt          Shizuku (uid 2000) + fallback local, staging
  SuClient.kt             cliente modo 'C' de /data/local/tmp/temp_su.sock
  GhostlockManager.kt     interpretador de código de saída (0/1/2/3/4)
PORTING.upstream.md       notas de portabilidade (novo firmware = nova linha em device_map)

Build

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 já está vendorizado (ksud + app/src/main/assets/ksud) então os passos 1–2 apenas produzem as duas saídas do NDK. O alvo CMake em app/src/main/cpp/CMakeLists.txt pode adicionalmente reconstruir libpreload.so a partir das mesmas fontes dentro do APK como fallback.

Build no dispositivo (Termux, aarch64)

O aapt2/NDK do SDK são x86_64 e não podem executar no dispositivo. Procedimento verificado (SDK em ~/android-sdk, Gradle 8.9 - AGP 8.5.2 rejeita o Gradle 9.x do 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)

Execução

Instale o APK no dispositivo S26 + instale/inicie o Shizuku (depuração sem fio ou PC).
Abra o GhostLock - a permissão do Shizuku é solicitada automaticamente no lançamento; aprove uma vez (dura até o servidor Shizuku reiniciar).
Verifique se o card Device diz SUPPORTED/LIKELY para sua build.
Toque em Stage, depois em Run once. A corrida é probabilística - use Retry ×5; várias tentativas são normais.
Check root → espere uid=0 …. Depois execute comandos no card Root shell.
Após o sucesso, instale/aproveite o KernelSU Manager (me.weishu.kernelsu); o daemon carrega ksud automaticamente em late-load (veja o modo K em su_daemon.c).

O Shizuku é opcional mas fortemente recomendado: o fluxo upstream roda a partir de um adb shell (uid 2000, contexto SELinux shell), e o fallback interno do app (untrusted_app) tem muito mais chance de ser bloqueado de LD_PRELOAD/exec em /data/local/tmp.

Códigos de saída (mostrados após cada tentativa)

Procedência

Exploit: exploit/ + PORTING.upstream.md + ksud de 1ndevelopment/ghostlock-s26 (Apache-2.0; veja LICENSE.upstream, NOTICE.upstream). O app não vincula nenhum código de exploit em seu próprio processo - ele prepara os arquivos compilados com o NDK e gera o shell LD_PRELOAD documentado.
Créditos (upstream): Nebula Security (descoberta do CVE), polygraphene (baseline), monovibe (UMH root / boot-claim), lukasmaar (kernelsnitch), veritas501 (conceito de pipe), BuSung-dev (base do app companion).

0	sucesso (socket ativo, late-load do ksud OK)	Check root, use o shell
1	corrida perdida / verificação falhou	apenas tente novamente (normal)
2	build não suportada (fail-closed)	pare; o firmware precisa de uma porta
3	carrier/root falhou	reinicie antes da próxima tentativa
4	já executou neste boot	reinicie; `BOOT_FORCE=1` sobrescreve mas pode travar

ghostlock-s26

Mais Populares

GhostLock - Wrapper Android (indev.ghostlock.s26)