aniketlab/poco-m7-plus-jailbreakRecherche de root temporaire sur Poco M7 Plus (SM6375) via l'exploit Qualcomm GBL (CVE-2026-24088) + analyse du noyau GhostLock (CVE-2026-43499)
Avertissement : Ce document est rédigé uniquement à des fins éducatives et de recherche en sécurité. Tous les tests ont été effectués sur mon propre appareil. Je ne suis pas responsable des appareils brickés, des pertes de données ou de toute utilisation abusive de ces informations. Les vulnérabilités abordées ici sont déjà divulguées publiquement et corrigées. Ne tentez pas cela sur des appareils que vous ne possédez pas.
| Fichier | Description |
|---|---|
| GBL-AutoRoot.bat | Outil d'automatisation de l'exploit en un clic (Windows) |
Comment l'utiliser :
GBL-AutoRoot.bat depuis le lien ci-dessusCompatible avec tout appareil Qualcomm ABL affecté par CVE-2026-24088. Si votre appareil renvoie
OKAY, l'accès root est accordé automatiquement.
Cet outil cible la vulnérabilité Qualcomm ABL (CVE-2026-24088). Si votre appareil possède un SoC vulnérable et n'a pas encore reçu le firmware corrigé, cet outil fonctionnera.
| Statut | Appareil / Famille de SoC | Exemples d'appareils |
|---|---|---|
| ✅ Confirmé | Snapdragon 695 (SM6375) | POCO M7 Plus 5G, Redmi 15 5G |
| ⚠️ Potentiel | Snapdragon 8 Gen 3 (SM8650) | Xiaomi 14 / Pro / Ultra, Redmi K70 Pro |
| ⚠️ Potentiel | Snapdragon 8 Gen 2 (SM8550) | Xiaomi 13 / Pro, POCO F5 Pro, Redmi K60 Pro |
| ⚠️ Potentiel | Snapdragon 8+ Gen 1 (SM8475) | Xiaomi 12T Pro, POCO F5 |
| ⚠️ Potentiel | Snapdragon 888 (SM8350) | Mi 11, Mi 11X Pro, POCO F3 |
| ⚠️ Potentiel | Snapdragon 7+ Gen 3 (SM7675) | POCO F6 |
| ⚠️ Potentiel | Snapdragon 7 Gen 3 (SM7550) | Xiaomi Civi 4 |
| ⚠️ Potentiel | Snapdragon 695 5G (SM6375) | POCO X4 Pro 5G, Redmi Note 11 Pro 5G |
| ⚠️ Potentiel | Snapdragon 680 (SM6225) | Redmi Note 11, Redmi 10C |
| ⚠️ Potentiel | Snapdragon 662 (SM6115) | POCO M3, Redmi 9T |
| ❌ Non pris en charge | MediaTek (MTK) | POCO X6 Neo, Redmi Note 13 Pro+ |
| ❌ Non pris en charge | Firmware corrigé | HyperOS 3.0.304.0+ (correctif de sécurité appliqué) |
📢 Tests communautaires requis : Je ne dispose pas de tous ces appareils pour les tester. Si vous possédez l'un des appareils « potentiellement pris en charge », veuillez tester l'outil et me communiquer les résultats. Cela m'aidera à confirmer et à ajouter officiellement votre appareil à la liste « Confirmé fonctionnel » !
| Champ | Valeur |
|---|---|
| Appareil | Poco M7 Plus 5G (nom de code : spring) |
| Chipset | Qualcomm SM6375 (Snapdragon 6s Gen 3) |
| Architecture | AArch64, KASLR activé |
| SELinux | Enforcing (avant l'exploit) |
| Bootloader | VERROUILLÉ |
| Plateforme de test | Windows 11, ADB Platform Tools |
| Version HyperOS | Version du noyau | Résultat GhostLock | Résultat de l'exploit GBL |
|---|---|---|---|
| 2.0.202.0 | 6.1.118-android14-11-ga3b9c44908dd-ab13320413 | ❌ Kernel Panic | ✅ Fonctionnel |
| 2.0.208.0 | 6.1.138-android14-11-g51f8c580613d-ab13911623 | ❌ Kernel Panic | ✅ Fonctionnel |
Note de recherche : J'ai d'abord testé sur HyperOS 2.0.202.0 où GhostLock a provoqué un kernel panic. J'ai ensuite mis à jour vers 2.0.208.0 pour vérifier si la version plus récente du noyau (6.1.118 -> 6.1.138) résoudrait l'instabilité de GhostLock. Le panic a persisté - les deux versions partagent la même disposition interne
pselect/fd_setdu noyau 6.1 que GhostLock ne peut pas gérer. L'exploit GBL a fonctionné sur les deux versions.
Au cours de cette recherche, j'ai testé deux chemins d'exploitation indépendants pour obtenir un root temporaire sur cet appareil sans déverrouiller le bootloader :
| Approche A : Exploit GBL | Approche B : GhostLock | |
|---|---|---|
| Couche | Bootloader (ABL/fastboot) | Noyau (Linux 6.1) |
| CVE | CVE-2026-24088 | CVE-2026-43499 |
| Résultat sur cet appareil | ✅ Fonctionnel | ❌ Kernel Panic |
| Type de root | Temporaire (avec câble) | Temporaire (avec câble) |
| Nécessite ADB ? | Oui (mode fastboot) | Oui (accès shell) |
| Sensible à la version du noyau ? | Non | Oui - stable uniquement sur 6.6-6.12 |
L'exploit GBL a fonctionné. GhostLock a échoué avec un kernel panic en raison d'une incompatibilité de version du noyau. Les deux résultats sont documentés en détail ci-dessous.
CVE-2026-24088 affecte l'Android Boot Loader (ABL) de Qualcomm sur de multiples appareils.
Jan 2026 -> Vulnerability discovered during ABL unpacking & analysis
Feb 2026 -> Qualcomm patches: QcomModulePkg: Fix propagation of untrusted input into kernel cmdline
Mar 2026 -> Public PoC released; Xiaomi begins rolling out HyperOS 3.0.304.0 (patched)
Jun 2026 -> CVE-2026-24088 officially assigned in Qualcomm Security Bulletin
L'exploit fonctionne comme une chaîne en trois étapes au niveau du bootloader :
Dans Android 16, l'ABL de Qualcomm charge le Generic Bootloader (GBL) depuis la partition efisp. La faille critique : l'ABL vérifie uniquement si le binaire est une application UEFI valide - il ne vérifie PAS sa signature cryptographique. Cela signifie qu'une application UEFI personnalisée et non signée peut être placée dans efisp et qu'elle s'exécutera au stade du bootloader avec tous les privilèges.
La commande fastboot oem set-gpu-preemption ne dispose d'aucune sanitisation des entrées. L'ABL concatène directement l'argument fourni dans la ligne de commande du noyau sans filtrage.
En passant androidboot.selinux=permissive comme argument supplémentaire :
fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive
...le bootloader écrit androidboot.selinux=permissive dans la cmdline du noyau, que le processus init d'Android lit au démarrage - désactivant effectivement l'application de SELinux.
Une application UEFI personnalisée placée dans efisp peut définir les drapeaux is_unlocked et is_unlocked_critical pour déverrouiller définitivement le bootloader. (Cette étape n'a PAS été testée - comporte un risque de brick irréversible.)
⚠️ Arrêtez-vous avant de continuer : exécutez d'abord la vérification du correctif dans la section 7. Si votre appareil est corrigé, rien de tout cela ne fonctionnera.