thiasap/oppo-pgem10-ghostlockOPPO Find X6 Pro GhostLock (CVE-2026-43499) adaptation d'exploit
Ce projet cible la vulnérabilité CVE-2026-43499 (GhostLock) en effectuant une recherche d'adaptation sur l'OPPO Find X6 Pro (PGEM10).
Basé sur l'architecture d'exploit originale de NebuSec CyberMeowfia, avec référence à l'approche d'adaptation de oppo-ghostlock.
| Élément | Valeur |
|---|---|
| Appareil | OPPO Find X6 Pro (PGEM10) |
| Puce | Snapdragon 8 Gen 2 (SM8550) |
| Noyau | Linux 5.15.149-android13 #1 SMP PREEMPT |
| Date de compilation | Thu Feb 13 2025 |
| Android | 15 (ColorOS 15.0) |
| Version ROM | PGEM10_15.0.0.600(CN01) |
| PAC | CONFIG_ARM64_PTR_AUTH_KERNEL=y |
| BTI | CONFIG_ARM64_BTI_KERNEL=y |
| KASLR | CONFIG_RANDOMIZE_BASE=y |
| VA_BITS | 39 |
| Décalage VA | P0_PAGE_OFFSET = 0xffffff8000000000 |
| Module | État | Description |
|---|---|---|
| Contournement KASLR par Perf | ✅ | Percée clé — via perf_event_open + échantillonnage callchain, obtient le slide KASLR actuel en <1s |
| Correction MM_STRUCT_SZ | ✅ | Corrigé de 0x500 à 0x400 (1024B), KernelSnitch réussit immédiatement |
| Validation complète des offsets IDA | ✅ | Tous les symboles/structures/fonctions clés ont été validés par IDA cross-validation |
| FUTEX_CMP_REQUEUE_PI | ✅ | Déclenchement de l'UAF GhostLock réussi |
| Vérification ashmem | ✅ | C ashmem disponible, chemin type confusion théoriquement possible |
| Analyse de chaîne d'appel | ✅ | Confirmé qu'aucune chaîne d'appel dans le noyau n'a une profondeur ≥ 0x800 |
| Scan de configuration du noyau | ✅ | Évaluation complète de la surface d'attaque |
| Module | État | Cause racine |
|---|---|---|
| Débordement de pile SLIDE | ❌ | PAC provoque une expansion de la trame de pile futex à 0xA70, pselect seulement 0x620 |
| Écrasement fops | ❌ | Nécessite SLIDE, bloqué par PAC |
| Type confusion | ❌ | Dépend de l'écrasement fops |
| Pipe physrw | ❌ | Dépend de type confusion |
| Root | ❌ | Dépend de la chaîne ci-dessus |
oppo-pgem10-ghostlock/
├── README.md # Ce fichier
├── 问题描述.md # Analyse détaillée du problème
├── docs/
│ ├── architecture.md # Conception de l'architecture et chaîne d'appel
│ └── adaptation-guide.md # Guide d'adaptation du noyau PAC
├── reports/
│ ├── offsets.md # Rapport de validation des offsets IDA
│ ├── kaslr.md # Rapport d'analyse KASLR
│ └── summary.md # Résumé final
├── src/
│ ├── kaslr_perf.h # Module réutilisable Perf KASLR
│ └── kaslr_perf.c # Implémentation Perf KASLR
└── analysis/
└── chains/ # Scripts d'analyse de chaîne d'appel
CONFIG_ARM64_PTR_AUTH_KERNEL=y # ← Différence clé : PAC entraîne directement l'expansion de la trame
CONFIG_ARM64_BTI_KERNEL=y # BTI augmente encore la surcharge
CONFIG_SHADOW_CALL_STACK=y # SCS augmente la trame de pile
CONFIG_VMAP_STACK=y # Pile remappable
CONFIG_KASAN_HW_TAGS=y # Activé à la compilation
CONFIG_ARM64_VA_BITS=39 # VA 39 bits (pas 48 bits)
Fonction Pixel 10 (sans PAC) PGEM10 (avec PAC)
__arm64_sys_futex 0x90 0x4C0
do_futex 0x70 0x420
futex_wait_requeue_pi 0x1A0 0x1B0
─────────────────────────────────────────────────────────
Profondeur totale chaîne futex 0x300 0xA70 ← 3,5×
Profondeur pile pselect 0x620 0x620
Débordement possible ? ✅ OUI ❌ NON (0xA70 > 0x620)
Analyse de la chaîne d'appel confirme : 0 chaîne d'appel dans le noyau avec une profondeur ≥ 0x800 (2048B). Trame individuelle maximale : 0x1F0 (496B).