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

Ein-Klick-Android-Wrapper für polygraphene/ghostlock-s26: GhostLock (CVE-2026-43499) portiert auf die gesamte Samsung Galaxy S26-Serie (Android 16 / GKI 6.12). Eine APK, drei Kernel-Linien, Laufzeit-Parameter- Abgleich - keine App-Varianten pro Build.

Nur auf Geräten verwenden, die dir gehören oder für die du ausdrücklich autorisiert bist, sie zu testen. Temporäres Root verschwindet beim Neustart. Ein zweiter Exploit-Lauf im selben Boot kann das Gerät zum Absturz bringen - vor einem erneuten Versuch neu starten.

Haftungsausschluss: Das Experimentieren mit dieser Software beinhaltet Low-Level-Kernel-Exploits, Root und Boot-Time-Claims. Sie wird WIE BESEHEN bereitgestellt, ohne jegliche Gewährleistung. Du verwendest sie vollständig auf eigenes Risiko; der Autor ist nicht verantwortlich für gebrickte, in Boot-Loops hängende oder anderweitig beschädigte Geräte, für Datenverlust, erloschene Garantien oder Schäden, die aus ihrer Verwendung entstehen.

Abdeckung: die gesamte S26-Familie

Der Exploit gleicht nach Kernel-Linie ab, nicht nach individuellem Build (exploit/src/params_table.c ist maßgeblich; ParamsTable.kt spiegelt sie nur für das UI-Urteil wider):

Geräte-Codename	Vermarktung	SoC	Kernel-Linie
m1q	Galaxy S26 (SM-S942x)	Snapdragon	`cn` oder `intl` (je nach CSC)
m2q	Galaxy S26+ (SM-S947x)	Snapdragon	`cn` oder `intl` (je nach CSC)
m3q	Galaxy S26 Ultra (SM-S948x)	Snapdragon	`cn` oder `intl` (je nach CSC)
m1s	Galaxy S26 (SM-S942B)	Exynos	`exynos`
m2s	Galaxy S26+ (SM-S947B)	Exynos	`exynos`

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

Unbekannte OTAs fallen genau wie im Upstream params.c zurück: zuerst exakter Build, dann gleiches Modell + 3-stellige CSC (OTA-Wiederverwendung), dann der neueste Eintrag desselben Geräts (als unverifiziert markiert), sonst fail-closed (die App zeigt UNSUPPORTED und die native Schicht beendet sich mit 2). Vollständig unbekannte Modelle werden abgelehnt - niemals erzwungen.

Was die App macht

Ein großer Button - Root my S26 - führt die gesamte Pipeline aus und erzählt in die Output-Karte:

Geräteprüfung - Modell/Gerät/Incremental/Fingerprint plus das Serien-Urteil (exakt / OTA-Wiederverwendung / unverifizierte Vermutung / nicht unterstützt). Nicht unterstützte Builds stoppen hier (fail-closed, kein Boot-Claim verbraucht).
Shizuku - wird automatisch verwendet, wenn verbunden (uid 2000 Shell, dieselbe Kontextfamilie wie der adb shell-Ablauf im README). Die Berechtigung wird einmal beim Start angefragt (und erneut, wenn der Server neu startet); der Root-Ablauf wartet auf die Erteilung, statt abzubrechen. Wenn der Server nicht läuft, öffnet die App den Shizuku-Manager, damit du ihn starten kannst, und fällt dann auf die In-App-Shell zurück. Das Hinzufügen der App zur Allowlist von Shizuku entfernt die Abfrage vollständig.
Staging - kopiert preload.so, su_daemon, ksud nach /data/local/tmp (preload.so, cve-2026-43499-root, ksud) und führt chmod darauf aus. Wenn du die Dateien bereits gemäß dem Upstream-README per adb push übertragen hast, werden sie an Ort und Stelle übernommen.
Ausführen - führt genau das aus, was der Upstream dokumentiert: env LD_PRELOAD=/data/local/tmp/preload.so sh (der .so-Konstruktor führt die Kette aus und ruft _exit auf; stdout ist das Exploit-Log), bis zu 5 Versuche - das Race ist probabilistisch. Ein BOOT_FORCE=1-Schalter ist verfügbar, aber ein Neustart ist sicherer.
Verifizieren - bestätigt, dass id uid=0 über jeden Kanal meldet: zuerst den Temp-Daemon-Socket, dann KernelSU-artiges su. Das ist wichtig, weil su_daemon bei vollem Erfolg seinen Socket entlinkt und sich per Design beendet (Übergabe an KernelSU) - ein toter Temp-Socket mit funktionierendem su bedeutet rooted, nicht kaputt. Gibt das Ende des Boot-Claim-Logs aus und meldet rooted / Ratschläge zum Exit-Code.

Darunter: eine einzelne Zeile Befehlsfeld + Als root ausführen (Einmal-Befehle über das C-Protokoll des su-Daemons; interaktives PTY ist für v1 nicht vorgesehen), und ein kleiner Zurücksetzen-Link, der /data/local/tmp/ghostlock-boot.log löscht, damit ein Lauf ohne Neustart wiederholt werden kann (Upstream warnt, dass dies zu einem Panic führen kann - ein Neustart ist der sichere Weg).

Projektstruktur

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

Voraussetzungen: 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 ist bereits eingebunden (ksud + app/src/main/assets/ksud), sodass Schritt 1–2 nur die beiden NDK-Ausgaben erzeugen. Das CMake-Target in app/src/main/cpp/CMakeLists.txt kann zusätzlich libpreload.so aus denselben Quellen innerhalb der APK als Fallback neu bauen.

CI-Build (zugeschnitten auf Gerät / SoC)

Der Workflow .github/workflows/build.yml baut die App zugeschnitten auf den Zielgeräte-Codename / Prozessortyp – kein SDK, NDK oder Docker lokal erforderlich. Forke das Repo und gehe dann im Repo zum Actions-Tab → GhostLock-S26 Device Build → Run workflow und lege fest:

Eingabe	Auswahl	Standard	Wirkung
`device`	`all` / `m1q` / `m2q` / `m3q` / `m1s` / `m2s`	`all`	Geräte-Codename (Build-Ziel)
`processor`	`all` / `snapdragon` / `exynos`	`all`	SoC-Familie (filtert Kernel-Zeilen)
`kernel_line`	`auto` / `cn` / `intl` / `exynos`	`auto`	Legt die exakte Params-Zeile fest (`auto` leitet sie aus Gerät/Prozessor ab)
`tailor`	on / off	off	Beschneidet `params_table.c` + `ParamsTable.kt` auf das ausgewählte Gerät/die Zeile für eine kleinere Single-Target-Payload
`build_type`	`debug` / `release`	`debug`	APK-Variante
`rebuild_ksud`	on / off	on	Baut `ksud` + `kernelsu.ko` aus `polygraphene/KernelSU` bei `ksud_ref` neu oder behält das eingebundene Prebuilt
`kmi`	`android16-6.12` / `android15-6.6`	`android16-6.12`	KMI, für das das Modul kompiliert wird (S26 = GKI 6.12)
`samsung_hardening`	on / off	on	`CONFIG_KSU_SAMSUNG_KDP/RKP/DEFEX=y` (Samsung-kdp-Credentials, RKP/DEFEX-Sync)
`no_patch_text`	on / off	off	Deaktiviert Live-Text-Patching (Samsung Exynos EL2-Ziele)

ghostlock-s26

Beliebteste