mobilehackinglab/ghostlock-a17Exploit noyau pour CVE-2026-43499 sur Samsung Galaxy A17 permettant d'obtenir root via un bypass de KDP, une récupération de KASLR et l'exécution d'une workqueue forgée avec un shell persistant.
Chaîne d'exploitation complète de l'utilisateur vers root pour CVE-2026-43499 (« GhostLock ») sur le Samsung Galaxy A17 SM-A175F, sous Android 16 / GKI 6.12.
La chaîne part des primitives GhostLock publiques et se termine par un helper en mode utilisateur s'exécutant avec :
uid=0(root) gid=0(root) groups=0(root)
context=u:r:kernel:s0
Elle lance également un shell root persistant à chaque démarrage via g4d / g4sh et se termine sans panique du noyau.
📖 Documentation technique complète :
https://www.mobilehackinglab.com/blog/cve-2026-43499-ghostlock-a17-root-shell
Note de recherche
Nous n'avons pas découvert CVE-2026-43499. Le crédit de la vulnérabilité d'origine et de la recherche IonStack revient à Nebula Security.
Ce dépôt documente notre portage indépendant vers le Samsung Galaxy A17, les modifications requises par les protections du noyau Samsung, ainsi qu'une nouvelle étape finale d'exploitation.
Réservé à la recherche en sécurité autorisée et à des fins pédagogiques uniquement.
| CVE | CVE-2026-43499 — « ghostlock » |
| Appareil | Samsung Galaxy A17 (SM-A175F, mt6789) |
| GPU | Mali-G57 |
| Noyau | 6.12.23-android16-5-abA175FXXS3BZA5-4k |
| Résultat | uid=0(root) / u:r:kernel:s0 |
| Shell root | démon g4d + client g4sh |
| Persistance | À chaque démarrage |
| Sortie de l'exploit | Propre, sans panique du noyau |
| Contremesures rencontrées | Samsung KDP, DEFEX, SELinux, PANIC_ON_OOPS, arm64 KASLR |
La recherche originale sur ghostlock fournit les primitives d'entrée :
pselect reclaim
↓
fake rt_mutex_waiter
↓
constrained rb-tree pointer write
Sur le Galaxy A17, cependant, la phase finale standard de patch des credentials ne fonctionne pas.
KDP protège les données du noyau liées aux credentials au niveau EL2.
Sur cette build, les tentatives de modification des credentials de tâche ont été silencieusement ignorées, même lorsque les adresses cibles étaient correctes.
Ainsi, au lieu d'écrire des credentials root, ce portage fait en sorte que le noyau s'exécute avec des credentials privilégiés existants.
L'étape 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 élément de travail forgé est placé sur un pool lié system_wq et déclenché par une rafale d'allocations/libérations ptmx.
Le helper en mode utilisateur qui en résulte s'exécute avec les credentials d'init.
Aucune réécriture des credentials de tâche n'est nécessaire.
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
Comparé au portage public OnePlus, la plupart des étapes après la primitive d'écriture initiale ont été retravaillées.
La phase finale de patch des credentials a été remplacée par un élément de workqueue forgé ciblant le chemin d'exécution du helper en mode utilisateur.
Cela évite entièrement d'écrire dans les structures cred protégées.
L'approche d'ancrage précédente par perf-event était peu fiable sur cet appareil.
À la place, l'exploit utilise trois pointeurs décalés de l'entrée ctl_table de boot_id :
procname
data
proc_handler
Les trois sont recoupés avant d'accepter le décalage.
cpu_pwq est découvert en parcourant :
system_wq → pwqs
plutôt qu'en s'appuyant sur un décalage fixe spécifique à l'appareil.
Le canal d'origine laisse des modifications collatérales de l'état de struct page qui peuvent déclencher PANIC_ON_OOPS lors du démontage.
La chaîne actuelle évite le crash au démontage et a été démontrée sortant proprement après le root.
Le helper en mode utilisateur lance :
g4d
qui écoute sur la socket Unix abstraite :
@ghostlockd
g4sh s'y connecte et fournit soit un shell root interactif, soit l'exécution d'une commande unique.
/data/local/tmp/a/g4sh
/data/local/tmp/a/g4sh -c "id"
Cette cible combine plusieurs protections qui neutralisent les techniques courantes d'exploitation du noyau Android :
Cela a imposé une stratégie d'exploitation différente de l'habituelle :
arbitrary RW → patch cred → disable SELinux
À la place :
arbitrary RW → recover runtime state → forge kernel work → execute usermode helper
Nécessite un NDK Android récent.
make
Produit :
ghostlock # exploit
g4d # static root-shell daemon
g4sh # root-shell client
Poussez les binaires :
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'
Lancez la boucle d'exploitation avec gestion des redémarrages :
./scripts/rr_loop4.sh
Après ROOTED :
adb shell /data/local/tmp/a/g4sh
Ou exécutez une seule commande :
adb shell '/data/local/tmp/a/g4sh -c "id"'
Résultat attendu :
uid=0(root) gid=0(root) groups=0(root) context=u:r:kernel:s0
La primitive est probabiliste et fortement dépendante des conditions de démarrage.
Une exploitation réussie peut nécessiter plusieurs tentatives. Le script rr_loop4.sh inclus gère les nouvelles tentatives et les cycles de redémarrage automatiquement.
C'est un exploit de recherche, pas un outil de root instantané en un coup.
qemu-e2e/ contient un harnais de validation de bout en bout utilisant le noyau Samsung extrait.
Le harnais a été utilisé pour tester :
g4d / g4shL'image du noyau Samsung elle-même n'est pas incluse.
Voir :
qemu-e2e/
pour les instructions de configuration.
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
NebuSec:
Un regard plus approfondi sur le portage Samsung Galaxy A17, les limitations de KDP, la récupération du KASLR, l'étape finale basée sur une workqueue et l'implémentation du shell root :
Les artefacts recueillis sur un appareil réel sont disponibles dans :
examples/
notamment les journaux d'exploitation et la vérification du contexte root.
Exemple :
uid=0(root)
gid=0(root)
groups=0(root)
context=u:r:kernel:s0
Cette preuve de concept est fournie uniquement à des fins éducatives et de recherche en sécurité autorisée.
Ne l'utilisez que sur des appareils et environnements que vous possédez ou que vous avez l'autorisation explicite de tester.