k80pro-miro-cve-2026-64560

Projet de portage de l'élévation de privilèges locale en espace utilisateur CVE-2026-64560 pour le Redmi K80 Pro (miro).

🚀 Pas envie de lire toute cette documentation ?

Si vous ne voulez pas approfondir, ou ne voulez pas lire cette pile de .md générés par IA, consultez directement dyc.md —— un guide de démarrage rapide en langage clair : de zéro au jailbreak (avec KernelSU), on explique seulement quelles commandes taper, pas pourquoi.

L'exploit upstream et l'adaptation pour Xiaomi 15 (dada) proviennent de quyicheng03-boop, ce dépôt est le fruit du portage vers le K80 Pro, avec ré-élaboration des adresses et constantes sur cette base.

Ce projet ne fait que du portage, il ne contient pas la découverte de la vulnérabilité. Le principe de la vulnérabilité et la conception de la chaîne d'exploitation appartiennent entièrement à l'auteur upstream. Voir docs/UPSTREAM.md et NOTICE.

一、À lire en premier : les artefacts sont strictement liés au firmware

Les sources et binaires de ce dépôt ne sont valides que pour cette unique version de firmware :

Toute autre version OTA rendra le tout inopérant. Les offsets de structures dans le noyau, les adresses de symboles et les plages KASLR sont tous dérivés de cette unique Image ; un seul caractère d'écart empêche l'exécution.

En cas de non-concordance de l'empreinte, le programme s'arrête dès l'entrée :

TARGET_PROFILE_GATE_FAIL fingerprint=...

C'est un échec sécurisé, il ne touche pas au noyau. Si votre firmware n'est pas la version du tableau ci-dessus, reportez-vous à docs/05-technical.md pour effectuer votre propre portage, n'appliquez pas directement les constantes de ce dépôt.

二、Avertissement

• Ce code lit et écrit directement dans la mémoire du noyau.
• Pendant l'exploitation, l'appareil peut planter ou se figer, nécessitant un appui long sur le bouton d'alimentation pour forcer le redémarrage.
• Un échec ne cause pas de dommage permanent (voir l'analyse des risques dans docs/04-troubleshooting.md), mais ne l'exécutez pas sur un appareil que vous ne possédez pas ou dont les données ne sont pas sauvegardées.
• L'appareil de test est en état BL déverrouillé. Si le bootloader de votre appareil est verrouillé, assurez-vous d'abord de disposer d'un moyen de récupération —— en état verrouillé, il n'y a pas de voie fastboot.
• Usage réservé à la recherche en sécurité, à la validation de vulnérabilités et à l'apprentissage sur vos propres appareils. Veuillez vérifier vous-même les exigences légales de votre région.

三、Structure du répertoire

k80pro-miro-cve-2026-64560/
├── README.md               ce fichier
├── dyc.md                  démarrage rapide (version langage clair), à lire en premier pour les débutants
├── LICENSE                 licence upstream
├── NOTICE                  attribution upstream
├── SHA256SUMS.txt          sommes de contrôle des trois artefacts dans release_build/
│
├── src/                    sources pour la compilation
│   ├── exploit-fanout-miro.c
│   ├── exploit-rotate-miro.c
│   ├── temp-su.c
│   ├── miro-profile.h      référence des constantes (ne participe pas à la compilation)
│   ├── miro-integration.c  référence d'intégration (ne participe pas à la compilation)
│   └── exploit-*.c         fichiers originaux upstream (entrées du générateur, ne participent pas à la compilation)
│
├── release_build/          artefacts précompilés (utilisables directement)
│   ├── cve-2026-64560-fanout
│   ├── cve-2026-64560-rotate
│   └── su
│
├── docs/
│   ├── 01-build.md         comment compiler
│   ├── 02-usage.md         comment utiliser dans adb shell
│   ├── 03-tokens.md        table de référence des tokens de sortie
│   ├── 04-troubleshooting.md  dépannage et description des risques
│   ├── 05-technical.md     notes techniques de portage
│   └── UPSTREAM.md         source upstream
│
└── tools/                  scripts de build et outils de reproduction/diagnostic (ne participent pas à l'exploitation)
    ├── build.sh            compilation en une commande (sh tools/build.sh)
    └── *.py                scripts de reproduction / diagnostic

四、Deux parcours d'utilisation

Parcours A : utiliser directement les artefacts précompilés

Voir docs/02-usage.md.

Vérifiez d'abord l'intégrité des artefacts :

sha256sum -c SHA256SUMS.txt        # Linux / macOS
certutil -hashfile <fichier> SHA256   # Windows, à vérifier un par un

Parcours B : compiler soi-même

Voir docs/01-build.md.

Nécessite le NDK Android (le gcc système ne convient pas, raisons dans ce document). La méthode la plus simple est d'utiliser le script fourni avec le dépôt, il trouve le NDK tout seul, choisit la bonne toolchain, compile, et compare un par un les hachages avec SHA256SUMS.txt :

sh tools/build.sh              # compilation + vérification
sh tools/build.sh --no-check   # compilation seule

Le script ne fait que compiler, il ne touche pas à l'appareil, ne pousse rien, n'exécute pas l'exploit.

Si vous ne voulez pas utiliser le script, vous pouvez aussi taper manuellement les trois commandes clang, produisant cve-2026-64560-fanout, cve-2026-64560-rotate, su.

Après compilation, comparez si les octets correspondent à ceux de release_build/ :

sha256sum build/*              # à comparer avec les trois valeurs de SHA256SUMS.txt

五、À quoi ressemble un succès

Le seul critère de succès est d'ouvrir un nouveau adb shell et d'obtenir uid=0 via /data/local/tmp/su :

$ printf 'id\nexit\n' | adb shell -T /data/local/tmp/su
uid=0(root) gid=0(root) groups=0(root),1004(input),... context=u:r:shell:s0

Notez context=u:r:shell:s0 —— identité root mais conservation du domaine shell, c'est voulu, ce n'est pas une erreur.

Les tokens clés visibles pendant le processus (table complète dans docs/03-tokens.md) :

BOOTID_WRITE_PASS attempt=5 q0=... q1=... slide=... kernel_base=...
STAGE0_GATE_PASS  slide=... kernel_base=...
MISC_BRIDGE_OPEN_PASS fd=... observed=...
STAGE8_CRED_STAGE_PASS task=... cred=... uid=0 context=shell
ROOT_CHILD_HOLD_PASS child=... uid=0 context=shell selinux_permissive=1

六、Trois caractéristiques de comportement à connaître impérativement

1. Le taux de succès n'est pas de 100 %. En phase Stage0, le taux de réussite en un essai mesuré est d'environ 1/5, c'est pourquoi le programme réessaie par défaut 32 fois par phase. La chaîne complète est probabiliste.

2. Un échec peut se manifester par un plantage. Nécessite un appui long sur le bouton d'alimentation pour forcer le redémarrage. Après redémarrage, l'état du noyau est entièrement réinitialisé, vous pouvez recommencer.

3. En cas de succès, deux états subsistent jusqu'au redémarrage :

   • SELinux passe en permissive
   • /data/local/tmp/su devient un démon ouvrant root à toute identité shell

   Voir la fin de docs/02-usage.md pour le nettoyage.

Le mode permissive n'est pas un bug résiduel, mais un prérequis au chargement de modules noyau (KernelSU LKM, etc.). Détails dans docs/04-troubleshooting.md.

七、Remerciements

• Découverte de la vulnérabilité et implémentation de l'exploit : NebuSec / CyberMeowfia
• Adaptation Xiaomi 15 (dada) : auteur du dépôt upstream
• Portage K80 Pro (miro) : voir CHANGELOG

Licence et attribution : voir LICENSE et NOTICE.