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

Wrapper Android con un solo clic per polygraphene/ghostlock-s26: GhostLock (CVE-2026-43499) portato sull'intera serie Samsung Galaxy S26 (Android 16 / GKI 6.12). Un solo APK, tre linee di kernel, corrispondenza dei parametri a runtime - nessuna variante dell'app per singola build.

Usare solo su dispositivi di propria proprietà o per i quali si è esplicitamente autorizzati a eseguire test. Il root temporaneo scompare al riavvio. Una seconda esecuzione dell'exploit nello stesso avvio può mandare in crash il dispositivo - riavviare prima di riprovare.

Avvertenza: sperimentare con questo software comporta l'uso di exploit di kernel di basso livello, root e rivendicazioni all'avvio. È fornito COSÌ COM'È, senza garanzia di alcun tipo. L'uso è interamente a proprio rischio; l'autore non è responsabile per dispositivi brickati, in boot loop o altrimenti danneggiati, né per eventuali perdite di dati, garanzie invalidate o danni derivanti dal suo utilizzo.

Copertura: l'intera famiglia S26

L'exploit effettua la corrispondenza per linea di kernel, non per singola build (exploit/src/params_table.c è la fonte autorevole; ParamsTable.kt la rispecchia solo per il verdetto mostrato nell'interfaccia):

Nome in codice del dispositivo	Nome commerciale	SoC	Linea di kernel
m1q	Galaxy S26 (SM-S942x)	Snapdragon	`cn` o `intl` (in base al CSC)
m2q	Galaxy S26+ (SM-S947x)	Snapdragon	`cn` o `intl` (in base al CSC)
m3q	Galaxy S26 Ultra (SM-S948x)	Snapdragon	`cn` o `intl` (in base al CSC)
m1s	Galaxy S26 (SM-S942B)	Exynos	`exynos`
m2s	Galaxy S26+ (SM-S947B)	Exynos	`exynos`

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

Gli OTA sconosciuti ricadono esattamente come in params.c upstream: prima la build esatta, poi stesso modello + CSC di 3 caratteri (riuso OTA), poi l'ultima voce per lo stesso dispositivo (contrassegnata come non verificata), altrimenti fail-closed (l'app mostra UNSUPPORTED e il layer nativo esce con codice 2). I modelli completamente sconosciuti vengono rifiutati - mai forzati.

Cosa fa l'app

Un unico grande pulsante - Root my S26 - esegue l'intera pipeline e ne racconta l'andamento nella card Output:

Controllo dispositivo - modello/device/incremental/fingerprint più il verdetto per la serie (esatto / riuso OTA / ipotesi non verificata / non supportato). Le build non supportate si fermano qui (fail-closed, nessuna rivendicazione di avvio consumata).
Shizuku - usato automaticamente quando connesso (shell uid 2000, stessa famiglia di contesto del flusso adb shell del README). Il permesso viene richiesto una volta all'avvio (e di nuovo se il server si riavvia); il flusso Root attende la concessione invece di interrompersi. Se il server è inattivo l'app apre il gestore Shizuku così da poterlo avviare, poi ricade sulla shell interna all'app. Aggiungere l'app alla allowlist di Shizuku elimina del tutto la richiesta.
Preparazione - copia preload.so, su_daemon, ksud in /data/local/tmp (preload.so, cve-2026-43499-root, ksud) ed esegue chmod su di essi. Se i file sono già stati inviati con adb push secondo il README upstream, vengono presi sul posto.
Esecuzione - esegue esattamente ciò che documenta upstream: env LD_PRELOAD=/data/local/tmp/preload.so sh (il costruttore della .so esegue la catena e chiama _exit; stdout è il log dell'exploit), fino a 5 tentativi - la race è probabilistica. È disponibile un interruttore BOOT_FORCE=1 ma riavviare è più sicuro.
Verifica - conferma che id riporti uid=0 attraverso qualsiasi canale: prima il socket del demone temporaneo, poi su in stile KernelSU. Questo è importante perché in caso di successo completo su_daemon rimuove il proprio socket ed esce per progetto (passaggio di consegne a KernelSU) - un socket temporaneo morto con su funzionante significa rooted, non guasto. Stampa la coda del log di rivendicazione dell'avvio e riporta rooted / consigli sul codice di uscita.

Sotto di esso: una singola riga campo comando + Esegui come root (comandi one-shot tramite il protocollo C del demone su; la PTY interattiva è fuori ambito per la v1), e un piccolo link Reset che cancella /data/local/tmp/ghostlock-boot.log così un'esecuzione può essere ritentata senza riavviare (l'upstream avverte che ciò potrebbe causare un panic - il riavvio è la via sicura).

Struttura del progetto

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)

Build

Requisiti: 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 è già incluso nel vendor (ksud + app/src/main/assets/ksud), quindi i passaggi 1–2 producono solo i due output NDK. Il target CMake in app/src/main/cpp/CMakeLists.txt può inoltre ricompilare libpreload.so dagli stessi sorgenti all'interno dell'APK come fallback.

Build CI (personalizzata per dispositivo / SoC)

Il workflow .github/workflows/build.yml compila l'app personalizzata per il codename del dispositivo / tipo di processore di destinazione - non serve SDK, NDK o Docker in locale. Fai un fork del repo, poi dalla scheda Actions del repo → GhostLock-S26 Device Build → Run workflow, quindi imposta:

ghostlock-s26

Più Popolari