mobilehackinglab/ghostlock-a17Exploit del kernel per la CVE-2026-43499 su Samsung Galaxy A17 che consente di ottenere i privilegi di root tramite bypass di KDP, recupero di KASLR ed esecuzione di una workqueue contraffatta, con shell persistente.
Catena di exploit completa da utente a root per CVE-2026-43499 ("GhostLock") sul Samsung Galaxy A17 SM-A175F, con Android 16 / GKI 6.12.
La catena parte dalle primitive pubbliche di GhostLock e termina con un helper in usermode eseguito come:
uid=0(root) gid=0(root) groups=0(root)
context=u:r:kernel:s0
Avvia anche una shell root persistente per ogni avvio tramite g4d / g4sh e termina senza un kernel panic.
📖 Analisi tecnica completa:
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell
Nota di ricerca
Non abbiamo scoperto CVE-2026-43499. Il merito della vulnerabilità originale e della ricerca IonStack va a Nebula Security.
Questo repository documenta il nostro porting indipendente per il Samsung Galaxy A17, le modifiche necessarie per le protezioni del kernel Samsung e una nuova fase finale di sfruttamento.
Solo per ricerca di sicurezza autorizzata e scopi educativi.
| CVE | CVE-2026-43499 — "ghostlock" |
| Dispositivo | Samsung Galaxy A17 (SM-A175F, mt6789) |
| GPU | Mali-G57 |
| Kernel | 6.12.23-android16-5-abA175FXXS3BZA5-4k |
| Risultato | uid=0(root) / u:r:kernel:s0 |
| Shell root | daemon g4d + client g4sh |
| Persistenza | Per ogni avvio |
| Uscita dell'exploit | Pulita, nessun kernel panic |
| Mitigazioni incontrate | Samsung KDP, DEFEX, SELinux, PANIC_ON_OOPS, arm64 KASLR |
| Firmware supportato | A175FXXS3BZA5 (kernel 6.12.23) e A175FXXS6CZG1 (kernel 6.12.38, SPL 2026-07-05) — entrambi verificati sul dispositivo, stessa catena |
La ricerca originale su ghostlock fornisce le primitive di ingresso:
pselect reclaim
↓
fake rt_mutex_waiter
↓
constrained rb-tree pointer write
Su Galaxy A17, tuttavia, il consueto epilogo basato sulla modifica delle credenziali non funziona.
KDP protegge i dati del kernel relativi alle credenziali a livello EL2.
Su questa build, i tentativi di modificare le credenziali dei task venivano scartati silenziosamente anche quando gli indirizzi di destinazione erano corretti.
Quindi, invece di scrivere credenziali di root, questo port fa sì che il kernel venga eseguito con le credenziali privilegiate esistenti.
La fase finale:
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
Un work item falsificato viene inserito in un pool system_wq associato e attivato con una tempesta di allocazione/deallocazione di ptmx.
L'helper in usermode risultante viene eseguito con le credenziali di init.
Non è richiesta alcuna sovrascrittura delle credenziali del task.
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
Rispetto alla porta pubblica per OnePlus, la maggior parte delle fasi successive alla primitiva di scrittura iniziale è stata rielaborata.
La fase finale di patching delle credenziali è stata sostituita con un elemento workqueue falsificato che prende di mira il percorso di esecuzione di usermode-helper.
Ciò evita del tutto la scrittura di strutture cred protette.
Il precedente approccio di ancoraggio agli eventi perf era inaffidabile su questo dispositivo.
Invece, l'exploit utilizza tre puntatori slid dalla voce ctl_table di boot_id:
procname
data
proc_handler
Tutti e tre vengono convalidati in modo incrociato prima di accettare lo slide.
cpu_pwq viene scoperto percorrendo:
system_wq → pwqs
invece di affidarsi a un offset fisso specifico del dispositivo.
Il canale originale lascia modifiche collaterali allo stato di struct page che possono attivare PANIC_ON_OOPS durante il teardown.
La catena attuale evita il crash di teardown ed è stato dimostrato che esce in modo pulito dopo il root.
L'helper in usermode avvia:
g4d
che ascolta sullo socket Unix astratto:
@ghostlockd
g4sh si connette ad essa e fornisce una shell root interattiva oppure l'esecuzione di un singolo comando.
/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"
Questo target combina diverse protezioni che infrangono le comuni tecniche di sfruttamento del kernel Android:
Ciò ha imposto una strategia di exploit diversa da quella abituale:
arbitrary RW → patch cred → disable SELinux
Invece:
arbitrary RW → recover runtime state → forge kernel work → execute usermode helper
Richiede un Android NDK recente.
make # BZA5 firmware (kernel 6.12.23)
make czg1 # CZG1 firmware (kernel 6.12.38): per-target slide anchors,
# offsets are uname-keyed at runtime
Produce:
ghostlock # exploit (ghostlock-czg1 for the CZG1 build)
g4d # static root-shell daemon
g4sh # root-shell client
Carica i binari:
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'
Esegui il ciclo di exploit consapevole del riavvio:
./scripts/rr_loop4.sh
Dopo ROOTED:
adb shell /data/local/tmp/a/g4sh
Oppure esegui un singolo comando:
adb shell '/data/local/tmp/a/g4sh -c "id"'
Risultato atteso:
uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
La primitiva è probabilistica e fortemente dipendente dalle condizioni di avvio.
Un'attività di sfruttamento riuscita può richiedere tentativi ripetuti. Lo script rr_loop4.sh incluso gestisce automaticamente i tentativi ripetuti e i cicli di riavvio.
Questo è un exploit di ricerca, non uno strumento di rooting istantaneo in un solo colpo.
qemu-e2e/ contiene un harness di validazione end-to-end che utilizza il kernel Samsung estratto.
L'harness è stato utilizzato per testare:
g4d / g4shL'immagine del kernel Samsung stessa non è inclusa.
Vedi:
qemu-e2e/
per le istruzioni di configurazione.