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

Wrapper Android com um clique para polygraphene/ghostlock-s26: GhostLock (CVE-2026-43499) portado para a série inteira 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 do 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.

Aviso legal: experimentar este software envolve exploits de kernel de baixo nível, root e alegações em tempo de boot. Ele é fornecido COMO ESTÁ, sem garantia de qualquer tipo. Você o usa inteiramente por sua conta e risco; o autor não é responsável por dispositivos inutilizados, presos em boot loop ou de outra forma danificados, nem por qualquer perda de dados, garantias anuladas ou danos decorrentes de seu uso.

Cobertura: toda a família S26

O exploit faz a correspondência por linha de kernel, não por build individual (exploit/src/params_table.c é a fonte autoritativa; 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 testados (17): S9420ZCS4AZG1, S9470ZCS4AZG1, S9480ZCS3AZF1, S9480ZCS4AZG1, S942BXXS4AZG5, S947BXXS3AZF1, S947BXXS4AZG5, S942QOPU1AZDE, S942U1UES4AZG3, S942USQS4AZG3, S947USQS4AZG3, S9480ZHS4AZG1, S948BXXS4AZG5/6, S948NKSS4AZG3, S948U1UES2AZE1, S948USQS4AZG3.

OTAs desconhecidas seguem exatamente o fallback do params.c upstream: primeiro build exato, 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 único botão grande - Root my S26 - executa todo o pipeline e narra no cartão Output:

Verificação do dispositivo - modelo/dispositivo/incremental/fingerprint mais o veredito do modelo (exato / reuso de OTA / suposição não verificada / não suportado). Builds não suportados param aqui (fail-closed, nenhuma alegação de boot é consumida).
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 na inicialização (e novamente se o servidor reiniciar); o fluxo Root aguarda a concessão em vez de abortar. Se o servidor estiver inativo, o app abre o gerenciador do Shizuku para você iniciá-lo, depois recorre ao shell interno do app. Adicionar o app à allowlist do Shizuku elimina completamente o prompt.
Preparação - 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 detectados no local.
Execução - executa exatamente o que o upstream documenta: env LD_PRELOAD=/data/local/tmp/preload.so sh (o construtor do .so executa a cadeia e chama _exit; o stdout é o log do exploit), até 5 tentativas - a corrida é probabilística. Um interruptor BOOT_FORCE=1 está disponível, mas reiniciar é mais seguro.
Verificação - confirma que id reporta uid=0 por qualquer canal: primeiro o socket do daemon temporário, depois su no estilo KernelSU. Isso importa porque em um sucesso completo o su_daemon desvincula seu socket e sai por design (transferência para o KernelSU) - um socket temporário morto com su funcional significa rooteado, não quebrado. Imprime o final do log de alegação de boot e relata rooteado / orientação sobre código de saída.

Abaixo disso: uma única linha de campo de comando + Executar como root (comandos pontuais via protocolo C do daemon su; PTY interativo está fora do escopo da v1), e um pequeno link Redefinir 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/, authoritative)
ksud                      upstream prebuilt KernelSU loader (ARM64 PIE, also in assets)
app/src/main/assets/ksud  staged copy shipped in the APK
app/src/main/assets/      + preload.so / su_daemon after stage-assets.sh
app/src/main/cpp/         optional CMake rebuild of preload.so from exploit/src
app/src/main/java/indev/ghostlock/s26/
  MainActivity.kt         UI (device / stage / run / shell / boot guard)
  ParamsTable.kt          series table mirror (17 builds, 3 lines, 5 codenames)
  DeviceCompat.kt         Build.* identity + series verdict
  ShellRunner.kt          Shizuku (uid 2000) + local fallback, staging
  SuClient.kt             /data/local/tmp/temp_su.sock 'C'-mode client
  GhostlockManager.kt     exit-code interpreter (0/1/2/3/4)
PORTING.upstream.md       porting notes (new firmware = new device_map row)

Compilação

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á incluído no repositório (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 recompilar libpreload.so a partir das mesmas fontes dentro do APK como fallback.

Build de CI (adaptado ao dispositivo / SoC)

O workflow .github/workflows/build.yml compila o app adaptado ao codename do dispositivo / tipo de processador alvo - sem necessidade de SDK, NDK ou Docker localmente. Faça um fork do repositório e, na aba Actions do repositório → GhostLock-S26 Device Build → Run workflow, defina:

Entrada	Opção	Padrão	Efeito
`device`	`all` / `m1q` / `m2q` / `m3q` / `m1s` / `m2s`	`all`	Codename do dispositivo (alvo de build)
`processor`	`all` / `snapdragon` / `exynos`	`all`	Família de SoC (filtra linhas de kernel)
`kernel_line`	`auto` / `cn` / `intl` / `exynos`	`auto`	Fixa a linha exata de parâmetros (`auto` deriva de device/processor)
`tailor`	on / off	off	Reduz `params_table.c` + `ParamsTable.kt` ao dispositivo/linha selecionado para um payload menor de alvo único
`build_type`	`debug` / `release`	`debug`	Variante do APK
`rebuild_ksud`	on / off	on	Recompila `ksud` + `kernelsu.ko` a partir de `polygraphene/KernelSU` em `ksud_ref`, ou mantém o prebuilt incluído
`kmi`	`android16-6.12` / `android15-6.6`	`android16-6.12`	KMI para o qual o módulo é compilado (S26 = GKI 6.12)
`samsung_hardening`	on / off	on	`CONFIG_KSU_SAMSUNG_KDP/RKP/DEFEX=y` (credenciais kdp da Samsung, sincronização RKP/DEFEX)
`no_patch_text`	on / off	off	Desativa o patch de texto em tempo real (alvos Samsung Exynos EL2)

ghostlock-s26

Mais Populares