GhostLock — OnePlus

Exploit noyau ciblant les appareils OnePlus avec bootloader verrouillé. Utilise CVE-2026-43499 pour obtenir un accès root sans déverrouiller le bootloader ni modifier boot.img.

Recherche en sécurité autorisée et usage éducatif uniquement.

---

Table des matières

• Aperçu de la vulnérabilité
• Appareils supportés
• Prérequis
• Compilation
• Utilisation
• Modes d'exécution
• Détails techniques
• Structure des fichiers
• Ajout de nouveaux appareils
• FAQ

---

Aperçu de la vulnérabilité

Élément	Détail
CVE	CVE-2026-43499
Type	Futex PI (Héritage de priorité) Use-After-Free
Portée	Noyau Linux 2.6.39 ~ 7.1
Corrigé dans	Mainline 7.1 (commit 3bfdc63936dd)
Statut Android	GKI 6.12.x toujours vulnérable

Cause racine

L'appel système pselect6 copie fd_set sur la pile du noyau. Combiné au mécanisme d'attente futex PI, une trame de pile libérée peut être réallouée en tant que structure rt_mutex_waiter. Lors du parcours de la chaîne PI, le rééquilibrage de l'arbre rouge-noir écrit des données contrôlées à des adresses noyau arbitraires.

Chaîne

futex PI UAF (CVE-2026-43499)
  ├─ Forger un objet rt_mutex_waiter
  ├─ Contrôler la pile noyau via la disposition fd_set de pselect/select
  ├─ Déclencher une opération PI rt_mutex pour écriture arbitraire
  ├─ Écriture 1 : selinux_state.enforcing = 0
  └─ Écriture 2 : cred → init_cred (uid=0, capacités complètes)

---

Appareils supportés

Appareil	Nom de code	SoC	Noyau	Firmware	Statut
OnePlus Ace 6T	PLR110	SM8845 (Snapdragon 8s Elite)	6.12.38-android16-5-...-ab14275539-4k	ColorOS 16.0.2.403	✅ Vérifié
OnePlus Ace 6T	PLR110	SM8845 (Snapdragon 8s Elite)	6.12.38-android16-5-...-ab14552068-4k	ColorOS 16.0.8.301	✅ Vérifié
OnePlus 15	PLK110	SM8845 (Snapdragon 8s Elite)	6.12.23-android16-5-...-ab14541642-4k	—	✅ Vérifié

D'autres appareils OnePlus de la même famille SoC, Android 16 ou noyau 6.12.x peuvent être adaptés via l'extraction des offsets de boot.img.

---

Prérequis

ksud (Requis pour KernelSU)

GhostLock gère l'élévation de privilèges. L'installation de KernelSU nécessite ksud (fourni avec kernelsu.ko spécifique au KMI) :

Source	Notes
APK ReSukiSU (recommandé)	Installer ReSukiSU ; l'APK inclut libksud.so
Version CI	Télécharger depuis ReSukiSU CI (ksud-aarch64-linux-android.zip)

Sans ksud, l'exploit obtient toujours un shell root uid=0, mais KernelSU ne sera pas installé et su ne persistera pas.

---

Compilation

Prérequis

• Android NDK (r25+)
• Définir ANDROID_NDK_HOME ou ANDROID_NDK_ROOT

Compilation

# Par défaut (API 35)
make

# Spécifier le niveau API
make API=34

# Spécifier le chemin NDK
NDK=/chemin/vers/android-ndk make

Artefact

ghostlock — exécutable ARM64 ELF lié statiquement.

---

Utilisation

Configuration unique

# 1. Activer le mode ADB TCP
adb tcpip 5555

# 2. Transférer la clé ADB (nécessaire pour le mode bootstrap)
adb push ~/.android/adbkey /data/local/tmp/a/adbkey

# 3. Transférer l'exploit
adb push ghostlock /data/local/tmp/a/e
adb shell chmod 755 /data/local/tmp/a/e

Après le premier succès, resetprop définit automatiquement persist.adb.tcp.port=5555, permettant des exécutions entièrement automatiques lors des redémarrages suivants.

---

Modes d'exécution

Exploit complet (contexte shell ADB)

/data/local/tmp/a/e

• perf disponible, fuite précise de task_struct enfant
• Deux étapes : W1 désactive SELinux → W2 élévation de privilèges → chargement KernelSU

Mode Bootstrap (contexte application, seccomp restreint)

/data/local/tmp/a/e --bootstrap

1. Écriture 1 → désactiver SELinux
2. Utiliser les permissions libérées pour setprop activer ADB TCP 5555
3. Client Mini ADB intégré se connecte à 127.0.0.1:5555
4. Authentification RSA avec la clé pré-transférée
5. Exécution complète de l'exploit via ADB shell (sans seccomp)

Écriture 1 uniquement

/data/local/tmp/a/e --write1

• Jusqu'à 20 tentatives
• Utile pour le débogage ou une désactivation temporaire de SELinux

---

Détails techniques

1. Correspondance du noyau à l'exécution

Les offsets sont stockés dans src/devices/offsets.h sous forme de table de correspondance, indexée par uname -r. Le programme effectue la correspondance automatiquement au démarrage ; les noyaux inconnus sont rejetés.

static const struct kernel_offsets known_offsets[] = {
  OFFSETS_ENTRY("6.12.38-android16-5-...-ab14275539-4k", ...),
  OFFSETS_ENTRY("6.12.38-android16-5-...-ab14552068-4k", ...),
  OFFSETS_ENTRY("6.12.23-android16-5-...-ab14541642-4k", ...),
  { .uname_r = NULL }  /* sentinelle */
};

Sources d'offsets

Type	Nombre	Extraction
Symboles globaux kallsyms	28	tools/extract_target.py
Champs de structs BTF	57	tools/extract_btf.py
Valeurs dérivées	9	Calcul automatique
Constantes fixes	12	Codées en dur

Structs vérifiées par BTF

Struct	Champs	Objectif
task_struct	17	Descripteur de processus, cred, seccomp
rt_mutex_waiter	6	Cible de forgerie UAF
cred	4	Identifiants, capacités
seccomp	3	État du filtre seccomp
pipe_inode_info	11	Opérations sur les buffers de tube
file_operations	13	Table fops factice
mm_struct	1	Propriétaire du descripteur mémoire

2. Contournement de KASLR

Mode SLIDE — Fuite de boot_id

Lorsque les pointeurs noyau sont restreints (kptr_restrict), divulguer l'adresse de base via boot_id écrasé avec une adresse noyau :

Lire /proc/sys/kernel/random/boot_id
  └─ L'UUID contient l'adresse nfulnl_logger
      └─ Décalage KASLR = adresse_fuite - image_offset
          └─ kaslr_base

Mode FOPS/CFI — Fuite de la table fops

Lorsque le périphérique ashmem est accessible, utiliser les primitives de lecture/écriture configfs pour lire les pointeurs de fonction de la table fops ashmem et calculer le décalage KASLR.

3. Arrosage du tas noyau

Forger des objets noyau sur des pages d'ordre 3 (32 Ko) :

• Fake file_operations — détourner le pointeur fops du miscdevice ashmem
• Fake rt_mutex_waiter — simuler un nœud d'attente dans la chaîne PI
• Fake task_struct — référence de tâche pendant le parcours PI
• Fake rt_mutex (verrou) — informations correctes waiter/owner

Implémenté via SKB (socket buffer) + KernelSnitch :

• KernelSnitch — collision de hachage futex pour divulguer les adresses mm_struct
• Arrosage SKB — sendmsg pour remplir le tas noyau

4. Lecture/écriture mémoire physique (Tube)

Après avoir obtenu la base KASLR, utiliser les buffers de tube pour un accès mémoire au niveau physique :

1. Localiser le buffer de tube dans la physmap
2. Forger la table d'opérations pipe_buffer pointant vers pipe_buf_ops connue
3. Détourner pipe_buffer.page vers l'adresse physique cible
4. Lecture/écriture physique arbitraire via les opérations normales de tube

Supporté : pipe_read64, pipe_write64, pipe_phys_read_data, pipe_phys_write_data

5. Écriture en deux étapes

Écriture 1 — Désactiver SELinux