CVE-2026-43499 · Honor WIN RT (AAK-AN00) Notes de recherche sur le root temporaire

(tout a été écrit par deepseek, je n'y comprends rien) (encore quelques jours de galère, aucun progrès, abandonné) (actuellement il est possible d'obtenir root, mais c'est très instable, après root le réseau tombe, débrancher le câble provoque un redémarrage) (toutes les conclusions de ce dépôt ne s'appliquent qu'au Honor WIN RT, à la vulnérabilité CVE-2026-43499, au noyau 6.6.118-android15-8-gf17133276a57-abogki518694926-4k, ne généralisez pas les conclusions au root temporaire, le root temporaire peut durer et fonctionner de manière relativement stable)

Le Bootloader de l'appareil est verrouillé de façon permanente (ro.oem_unlock.supported est vide), pas de fastboot, pas de su persistant, pas de Magisk. Le seul chemin encore praticable est la vulnérabilité du noyau. Ce dépôt documente le processus complet, de « est-ce exploitable » à « à quel point c'est stable après exploitation ».

Nature : root temporaire, invalide après redémarrage.

---

Avertissement

Ce dépôt documente un processus de recherche de sécurité mené sur mon propre appareil, dans le but de comprendre les causes et les limites de stabilité d'une course critique (race condition) PI du noyau.

• Ne contient aucun binaire exploit ni charge utile directement exécutable —— les charges utiles et le framework proviennent de projets publics en amont, ce dépôt ne fait que les citer, sans les rediffuser.
• Ne fournit pas de tutoriel sur les méthodes de contournement propres à un fabricant donné, et n'encourage pas l'utilisation sur des appareils non autorisés.
• Les offsets et adresses de symboles dans ce dépôt ne sont valides que pour le seul build de noyau listé dans cet article, tout changement de noyau les invalide entièrement.
• Les défauts concernés sont déjà corrigés en amont (voir ci-dessous). La valeur à long terme de cet article réside dans « ce document lui-même » —— un retour d'expérience réel sur une vulnérabilité de course critique dans des conditions non idéales, y compris tous ses effets secondaires désagréables.

---

0. Conclusion en une phrase

Le seul chemin qui a fonctionné est :

CVE-2026-43499 (course critique futex PI write-what-where) + porteuse rt_sigreturn
  → injection LD_PRELOAD dans un processus du domaine shell
  → en deux étapes : d'abord passer SELinux en Permissive, puis modifier task->real_cred / cred en init_cred
  → uid=0(root) context=u:r:kernel:s0, et implanter un démon su

Mais ce qui mérite vraiment d'être écrit, ce n'est pas « comment obtenir root » —— c'est ce qui se passe après.

Ce qu'on obtient n'est pas un root stable, mais un « état susceptible d'exploser à tout moment ».

La primitive d'écriture de l'exploit accroche un rt_mutex_waiter falsifié dans la vraie chaîne futex PI, et le support de ce waiter est une pile noyau / page spray qui sera réutilisée par les appels système suivants. Ainsi, dès l'instant où root est obtenu, tout changement d'ordonnancement ou de priorité au niveau système peut marcher dessus, provoquant directement un panic du noyau et un redémarrage. Ce n'est pas un bug, c'est le coût inhérent de cette technique d'exploitation —— voir docs/03.

---

1. Limites d'applicabilité (toute non-conformité invalide tout le schéma)

Élément	Valeur	Remarque
Modèle	Honor WIN RT, modèle AAK-AN00	Nom commercial « Honor WIN RT »
SoC	Snapdragon 8 Elite SM8750-AB	Firmware non compatible avec le Honor WIN (AAP-AN00, SM8850-AC)
Système	Android 16 / MagicOS 10	—
Noyau	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ Condition stricte, correspondance caractère par caractère
Configuration noyau	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	Prérequis de la géométrie de la porteuse
Paquet firmware	.170	.160 / .175 non testés
Bootloader	Verrouillé de façon permanente	Pas de fastboot / pas de su persistant

Pourquoi il faut impérativement fixer la version du noyau : le défaut est corrigé en 6.6.140, la machine locale est en 6.6.118 < 6.6.140 donc il est encore présent ; de plus, toutes les adresses de symboles du noyau et la « géométrie de la porteuse » de l'exploit sont ancrées sur ce seul build, après changement de noyau la table d'offsets est immédiatement invalidée, et généralement sans retour possible.

---

2. Panorama du chemin d'élévation de privilèges

┌─ Matériaux ───────────────────────────────────────────┐
│ boot.img + xbl_config.elf (extraits du firmware de l'appareil) │
│        ↓ résolution de symboles                        │
│ target.h (adresses de symboles du noyau, vérifiées octet par octet avec kallsyms) │
│        ↓ construction                                  │
│ preload.so ──► côté appareil /data/local/tmp/*.so      │
└────────────────────────────────────────────────────────┘
                 ↓  injection LD_PRELOAD
     ┌──────────── en deux étapes (nécessite deux processus indépendants) ────────────┐
     │ Étape A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Étape B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (réalisé par le processus « écrivain pré-positionné ») │
     │         → setresuid(0,0,0) normalisation                    │
     │         → implantation du su embarqué + daemon              │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Trois points à ne pas rater (une erreur bloque ou provoque directement un panic) :

1. Règle d'ordre absolue : d'abord real_cred, ensuite cred. L'ordre inverse donne instantanément tous les privilèges, les threads deviennent incontrôlables.
2. Entre les deux coups il existe nécessairement un état transitoire où cred ≠ real_cred. À ce moment tout sched_setaffinity renvoie EPERM → blocage complet du cycle. La bonne solution est de forker le processus « écrivain pré-positionné » avant le premier coup (identifiants propres), le processus parent écrit le premier coup, l'écrivain écrit le second, aucun des deux n'émet d'appel système pendant l'état transitoire.
3. Le modèle d'adresses est indépendant de KASLR. Toute l'exploitation ne passe que par l'alias de mapping linéaire alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), stable à travers les redémarrages ; la vraie valeur de la soi-disant « phase slide » est l'auto-vérification de la primitive d'écriture, pas le contournement de KASLR.

Framework amont : Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Attention, ce n'est pas GhostLock —— GhostLock passe par la voie pselect, incompatible avec la géométrie du point de chute du waiter de ce build, voir docs/06.

---

3. Sommaire