GhostLock — CVE-2026-43499 auf Samsung Galaxy A17

Vollständige User-to-Root-Exploit-Kette für CVE-2026-43499 („GhostLock“) auf dem Samsung Galaxy A17 SM-A175F mit Android 16 / GKI 6.12.

Die Kette beginnt mit den öffentlichen GhostLock-Primitiven und endet mit einem Usermode-Helper, der wie folgt ausgeführt wird:

uid=0(root) gid=0(root) groups=0(root)
context=u:r:kernel:s0

Sie startet außerdem eine persistente Root-Shell pro Boot über g4d / g4sh und beendet sich ohne Kernel-Panic.

📖 Vollständiger technischer Artikel:
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell

Forschungshinweis

Wir haben CVE-2026-43499 nicht entdeckt. Die Anerkennung für die ursprüngliche Schwachstelle und die IonStack-Forschung gebührt Nebula Security.

Dieses Repository dokumentiert unseren unabhängigen Port auf das Samsung Galaxy A17, die für Samsungs Kernel-Schutzmechanismen erforderlichen Änderungen sowie eine neue finale Ausnutzungsphase.

Nur für autorisierte Sicherheitsforschung und Bildungszwecke.

Zielgerät

Was macht diesen Port anders?

Die ursprüngliche GhostLock-Forschung liefert die Einstiegsprimitiven:

pselect reclaim
      ↓
fake rt_mutex_waiter
      ↓
constrained rb-tree pointer write

Auf dem Galaxy A17 funktioniert das Standard-Endspiel des Credential-Patchings jedoch nicht.

Samsung KDP blockiert das übliche Cred-Write

KDP schützt credential-bezogene Kernel-Daten auf EL2.

In diesem Build wurden Versuche, die Task-Credentials zu ändern, still verworfen, selbst wenn die Zieladressen korrekt waren.

Statt also Root-Credentials zu schreiben, bringt dieser Port den Kernel dazu, mit vorhandenen privilegierten Credentials zu arbeiten.

Neues Endspiel: Ausführung über gefälschte Workqueue

Die letzte Stufe:

constrained kernel write
        ↓
physical read/write channel
        ↓
KASLR slide recovery
        ↓
discover system_wq / cpu_pwq
        ↓
forge work_struct
        ↓
call_usermodehelper_exec_work
        ↓
/system/bin/sh
        ↓
uid=0(root), u:r:kernel:s0

Ein gefälschtes Work-Item wird in einen gebundenen system_wq-Pool eingefügt und durch einen ptmx-Allokations-/Freigabe-Sturm ausgelöst.

Der resultierende Usermode-Helper wird mit den Init-Credentials ausgeführt.

Es ist kein Überschreiben von Task-Credentials erforderlich.

Exploit-Kette

userspace shell (uid 2000)
        │
        ▼
pselect / PI-futex primitive
        │
        ▼
constrained aligned kernel pointer write
        │
        ▼
forged pipe_buffer channel
        │
        ▼
arbitrary physical read/write
        │
        ├── recover KASLR slide
        │
        ├── locate system_wq / cpu_pwq
        │
        └── prepare forged work_struct
        │
        ▼
queue usermode-helper work
        │
        ▼
ptmx storm wakes worker
        │
        ▼
/system/bin/sh runs with init creds
        │
        ▼
uid=0(root)
        │
        ▼
g4d → @ghostlockd → g4sh

Wichtigste technische Änderungen

Im Vergleich zum öffentlichen OnePlus-Port wurden die meisten Stufen nach der anfänglichen Write-Primitive überarbeitet.

1. Neue KDP-kompatible Root-Stufe

Das Endspiel des Credential-Patchings wurde durch ein gefälschtes Workqueue-Element ersetzt, das auf den Ausführungspfad des Usermode-Helpers abzielt.

Dadurch wird das Schreiben in geschützte cred-Strukturen vollständig vermieden.

2. Neues KASLR-Slide-Orakel

Der bisherige Ansatz der Perf-Event-Verankerung war auf diesem Gerät unzuverlässig.

Stattdessen verwendet der Exploit drei verschobene Pointer aus dem boot_id-ctl_table-Eintrag:

procname
data
proc_handler

Alle drei werden gegenseitig validiert, bevor der Slide akzeptiert wird.

3. Laufzeit-Erkennung der Workqueue

cpu_pwq wird ermittelt, indem man Folgendes durchläuft:

system_wq → pwqs

anstatt sich auf einen festen gerätespezifischen Offset zu verlassen.

4. Sauberer Exploit-Ausstieg

Der ursprüngliche Kanal hinterlässt Kollateralschäden am Zustand von struct page, die während des Abbaus PANIC_ON_OOPS auslösen können.

Die aktuelle Kette vermeidet den Absturz beim Abbau und wurde nachweislich nach Erlangen von Root sauber beendet.

5. Root-Shell

Der Usermode-Helper startet:

g4d

welcher auf dem abstrakten Unix-Socket lauscht:

@ghostlockd

g4sh verbindet sich damit und bietet entweder eine interaktive Root-Shell oder die einmalige Ausführung von Befehlen.

/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"

Warum das Galaxy A17 interessant ist

Dieses Zielgerät kombiniert mehrere Schutzmechanismen, die gängige Android-Kernel-Exploitation-Techniken aushebeln:

Samsung KDP — schützt credential-bezogene Kernel-Daten auf EL2
DEFEX — beschränkt privilegierte Ausführung aus nicht vertrauenswürdigen Pfaden
SELinux
PANIC_ON_OOPS / PANIC_ON_BUG
Große arm64-KASLR-Slides
Eingeschränkte Nur-Pointer-Write-Primitive

Das erzwang eine andere Exploit-Strategie als die übliche:

arbitrary RW → patch cred → disable SELinux

Stattdessen:

arbitrary RW → recover runtime state → forge kernel work → execute usermode helper

Erstellen

Erfordert ein aktuelles Android-NDK.

make

Erzeugt:

ghostlock   # exploit
g4d         # static root-shell daemon
g4sh        # root-shell client

Ausführen

Übertrage die Binärdateien:

adb push ghostlock /data/local/tmp/a/g4
adb push g4d /data/local/tmp/a/g4d
adb push g4sh /data/local/tmp/a/g4sh

adb shell 'chmod 755 /data/local/tmp/a/g4 /data/local/tmp/a/g4d /data/local/tmp/a/g4sh'

Führe die Neustart-bewusste Exploit-Schleife aus:

./scripts/rr_loop4.sh

Nach ROOTED:

adb shell /data/local/tmp/a/g4sh

Oder führe einen einzelnen Befehl aus:

adb shell '/data/local/tmp/a/g4sh -c "id"'

Erwartetes Ergebnis:

uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0

Zuverlässigkeit

Die Primitive ist probabilistisch und stark von den Boot-Bedingungen abhängig.

Eine erfolgreiche Ausnutzung kann wiederholte Versuche erfordern. Das enthaltene rr_loop4.sh-Skript übernimmt Wiederholungen und Neustartzyklen automatisch.

Dies ist ein Forschungs-Exploit, kein sofort einsatzbereites One-Shot-Rooting-Werkzeug.

QEMU-Validierung

qemu-e2e/ enthält eine End-to-End-Validierungsumgebung mit dem extrahierten Samsung-Kernel.

Die Umgebung wurde verwendet, um Folgendes zu testen:

Änderungen an der Exploit-Kette
KASLR-Behandlung
Workqueue-Fälschung
Usermode-Helper-Ausführung
sauberer Exploit-Abbau
g4d / g4sh-Roundtrips

Das Samsung-Kernel-Image selbst ist nicht enthalten.

Siehe:

qemu-e2e/

für Einrichtungsanweisungen.

Repository-Struktur

Makefile
src/                  exploit source and device profiles
src/daemon/           g4d root daemon + g4sh client
docs/OFFSETS.md       validated device offsets
docs/PORTING.md       porting notes
examples/             proof-of-root artifacts
scripts/rr_loop4.sh   reboot-aware exploit loop
qemu-e2e/             end-to-end QEMU validation

Root-Nachweis

Artefakte von echten Geräten sind verfügbar unter:

examples/

einschließlich Exploit-Protokollen und Verifikation des Root-Kontexts.

Beispiel:

uid=0(root)
gid=0(root)
groups=0(root)
context=u:r:kernel:s0

Haftungsausschluss

Dieser Proof of Concept wird ausschließlich für Bildungs- und autorisierte Sicherheitsforschungszwecke bereitgestellt.

Verwenden Sie ihn nur auf Geräten und in Umgebungen, die Ihnen gehören oder für die Sie ausdrücklich die Erlaubnis zum Testen haben.

CVE	CVE-2026-43499 — "ghostlock"
Gerät	Samsung Galaxy A17 (SM-A175F, mt6789)
GPU	Mali-G57
Kernel	`6.12.23-android16-5-abA175FXXS3BZA5-4k`
Ergebnis	`uid=0(root)` / `u:r:kernel:s0`
Root-Shell	`g4d`-Daemon + `g4sh`-Client
Persistenz	Pro Boot
Exploit-Beendigung	Sauber, kein Kernel-Panic
Angetroffene Schutzmechanismen	Samsung KDP, DEFEX, SELinux, PANIC_ON_OOPS, arm64 KASLR

Beliebteste

ghostlock-a17