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

Ein-Klick-Android-Wrapper für 1ndevelopment/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 du besitzt oder für die du ausdrücklich autorisiert bist zu testen. Temp-Root verschwindet beim Neustart. Ein zweiter Exploit-Lauf im selben Boot kann das Gerät zum Absturz bringen - vor einem erneuten Versuch neu starten.

Abdeckung: die vollständige 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):

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

Unbekannte OTAs fallen exakt wie upstream params.c zurück: zuerst exakter Build, dann gleiches Modell + 3-stellige CSC (OTA-Wiederverwendung), dann letzter 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 hinein:

1. 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).
2. 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 Shizuku-Allowlist entfernt die Abfrage vollständig.
3. Stage - kopiert preload.so, su_daemon, ksud nach /data/local/tmp (preload.so, cve-2026-43499-root, ksud) und setzt chmod darauf. Wenn du die Dateien bereits per adb push gemäß dem Upstream-README übertragen hast, werden sie an Ort und Stelle übernommen.
4. Run - führt exakt das aus, was upstream dokumentiert: (der -Konstruktor führt die Kette aus und ruft auf; stdout das Exploit-Log), bis zu 5 Versuche - das Race ist probabilistisch. Ein - Schalter ist verfügbar, aber ein Neustart ist sicherer.

Darunter: eine einzelne Befehlsfeld + Als Root ausführen-Zeile (One-Shot- Befehle über das C-Protokoll des su-Daemons; interaktives PTY liegt außerhalb des Umfangs von v1), und ein kleiner Reset-Link, der /data/local/tmp/ghostlock-boot.log löscht, damit ein Lauf ohne Neustart wiederholt werden kann (upstream warnt, dass dies panisch werden kann - Neustart ist der sichere Weg).

Projektstruktur

exploit/                  vendored upstream (Makefile + src/, maßgeblich)
ksud                      upstream vorgebauter KernelSU-Loader (ARM64 PIE, auch in assets)
app/src/main/assets/ksud  bereitgestellte Kopie, im APK ausgeliefert
app/src/main/assets/      + preload.so / su_daemon nach stage-assets.sh
app/src/main/cpp/         optionaler CMake-Rebuild von preload.so aus exploit/src
app/src/main/java/indev/ghostlock/s26/
  MainActivity.kt         UI (Gerät / Stage / Run / Shell / Boot-Guard)
  ParamsTable.kt          Serientabellen-Spiegel (17 Builds, 3 Linien, 5 Codenames)
  DeviceCompat.kt         Build.*-Identität + Serien-Urteil
  ShellRunner.kt          Shizuku (uid 2000) + lokaler Fallback, Staging
  SuClient.kt             /data/local/tmp/temp_su.sock 'C'-Modus-Client
  GhostlockManager.kt     Exit-Code-Interpreter (0/1/2/3/4)
PORTING.upstream.md       Portierungsnotizen (neue Firmware = neue device_map-Zeile)

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

On-Device-Build (Termux, aarch64)

Die aapt2/NDK des SDK sind x86_64 und können auf dem Gerät nicht ausgeführt werden. Verifiziertes Verfahren (SDK unter ~/android-sdk, Gradle 8.9 - AGP 8.5.2 lehnt das System-Gradle 9.x ab):

# 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)

Ausführen

1. Installiere die APK auf dem S26-Gerät + installiere/starte Shizuku (Wireless Debugging oder PC).
2. Öffne GhostLock - die Shizuku-Berechtigung wird automatisch beim Start angefragt; bestätige sie einmal (sie gilt, bis der Shizuku-Server neu startet).
3. Prüfe, ob die Device-Karte SUPPORTED/LIKELY für deinen Build anzeigt.
4. Tippe auf Stage, dann Run once. Das Race ist probabilistisch - verwende Retry ×5; mehrere Versuche sind normal.
5. Check root → erwarte uid=0 …. Führe dann Befehle in der Root-Shell- Karte aus.
6. Nach Erfolg installiere/verwende den KernelSU Manager (me.weishu.kernelsu); der Daemon lädt ksud automatisch nach (siehe su_daemon.c K-Modus).

Shizuku ist optional, aber dringend empfohlen: Der Upstream-Ablauf läuft aus einer adb shell (uid 2000, shell-SELinux-Kontext), und der In-App-Fallback (untrusted_app) wird weit wahrscheinlicher von LD_PRELOAD/exec auf /data/local/tmp blockiert.

Exit-Codes (nach jedem Versuch angezeigt)

Herkunft

• Exploit: exploit/ + PORTING.upstream.md + ksud aus 1ndevelopment/ghostlock-s26 (Apache-2.0; siehe LICENSE.upstream, NOTICE.upstream). Die App linkt keinen Exploit-Code in ihren eigenen Prozess - sie stellt die NDK-gebauten Dateien bereit und startet die dokumentierte LD_PRELOAD-Shell.
• Credits (upstream): Nebula Security (CVE-Entdeckung), polygraphene (Baseline), monovibe (UMH Root / Boot-Claim), lukasmaar (kernelsnitch), veritas501 (Pipe-Konzept), BuSung-dev (Companion-App-Basis).