CVE-2026-43499 · Honor WIN RT (AAK-AN00) Notas de investigación de Root temporal

(todo escrito por deepseek, yo no entiendo nada) (después de darle vueltas unos días más, el progreso fue cero, me rendí) (actualmente se puede obtener root, pero es muy inestable, tras rootear se pierde la red, al desconectar el cable se reinicia) (todas las conclusiones de este repositorio solo aplican al Honor WIN RT, vulnerabilidad CVE-2026-43499, kernel 6.6.118-android15-8-gf17133276a57-abogki518694926-4k, no difundas las conclusiones al root temporal, el root temporal puede mantenerse y funcionar de forma relativamente estable)

Bootloader del dispositivo bloqueado permanentemente (ro.oem_unlock.supported vacío), sin fastboot, sin su persistente, sin Magisk. El único camino que queda es la vulnerabilidad del kernel. Este repositorio documenta el proceso completo desde «¿se puede atacar?» hasta «después de atacar, ¿qué tan estable es realmente?».

Naturaleza: root temporal, se pierde al reiniciar.

---

Descargo de responsabilidad

Este repositorio documenta un proceso de investigación de seguridad realizado en mi propio dispositivo, con el objetivo de comprender las causas y los límites de estabilidad de una carrera PI del kernel.

• No contiene ningún binario exploit ni payload de explotación ejecutable directamente — el payload y el framework provienen de proyectos públicos upstream, este repositorio solo los referencia, no los redistribuye.
• No proporciona tutoriales para evadir mecanismos de ningún fabricante específico, ni fomenta su uso en dispositivos no autorizados.
• Los offsets y direcciones de símbolos dentro del repositorio solo son válidos para el único build de kernel listado en este documento, cambiar de kernel los invalida por completo.
• Los defectos relacionados ya están corregidos en upstream (ver abajo). El valor a largo plazo de este documento reside en «este registro en sí mismo» — un análisis real de una vulnerabilidad de carrera en condiciones no ideales, incluyendo todos sus incómodos efectos secundarios.

---

0. Conclusión en una frase

La única ruta que funcionó es:

CVE-2026-43499 (carrera futex PI write-what-where) + portador rt_sigreturn
  → inyección LD_PRELOAD en proceso del dominio shell
  → en dos etapas: primero poner SELinux en Permissive, luego cambiar task->real_cred / cred a init_cred
  → uid=0(root) context=u:r:kernel:s0, e implantar el daemon su

Pero lo que realmente vale la pena escribir no es «cómo obtener root» — es lo que ocurre después de obtenerlo.

Lo que se obtiene no es un root estable, sino un «estado que puede detonar en cualquier momento».

La primitiva de escritura del exploit inserta un rt_mutex_waiter falsificado en la cadena futex PI real, y el portador de este waiter es una pila del kernel / página rociada que será reutilizada por llamadas al sistema posteriores. Así, desde el momento en que root aterriza, cualquier cambio de planificación o prioridad a nivel de sistema puede pisarlo, provocando directamente un kernel panic y reinicio. Esto no es un bug, es el coste inherente de esta técnica de explotación — ver docs/03.

---

1. Límites de aplicabilidad (si no coinciden, todo el plan queda invalidado)

Elemento	Valor	Descripción
Modelo	Honor WIN RT, modelo AAK-AN00	Nombre comercial «Honor WIN RT»
SoC	Snapdragon 8 Elite SM8750-AB	Firmware no compatible con Honor WIN (AAP-AN00, SM8850-AC)
Sistema	Android 16 / MagicOS 10	—
Kernel	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ Condición estricta, coincidencia carácter por carácter
Configuración del kernel	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	Premisa de la geometría del portador
Paquete de firmware	.170	.160 / .175 no probados
Bootloader	Bloqueado permanentemente	Sin fastboot / sin su persistente

Por qué es imprescindible fijar la versión del kernel: el defecto se corrigió en 6.6.140, este dispositivo tiene 6.6.118 < 6.6.140 por lo que sigue presente; además, todas las direcciones de símbolos del kernel del exploit y la «geometría del portador» están ancladas a este único build, tras cambiar de kernel la tabla de offsets queda invalidada de inmediato, y generalmente no es posible revertir.

---

2. Panorama completo de la ruta de escalada de privilegios

┌─ Materiales ──────────────────────────────────────────┐
│ boot.img + xbl_config.elf (extraídos del firmware del dispositivo) │
│        ↓ resolución de símbolos                        │
│ target.h (direcciones de símbolos del kernel, verificadas byte a byte con kallsyms) │
│        ↓ compilación                                   │
│ preload.so ──► en el dispositivo /data/local/tmp/*.so  │
└────────────────────────────────────────────────────────┘
                 ↓  inyección LD_PRELOAD
     ┌──────────── dos etapas (requiere dos procesos independientes) ────────────┐
     │ Etapa A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ Etapa B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred (realizado por el proceso "escritor preestablecido") │
     │         → setresuid(0,0,0) normalización                    │
     │         → implantar su embebido + daemon                    │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

Tres cosas que hay que hacer bien obligatoriamente (si se hacen mal, se bloquea o directamente hay panic):

1. Regla de orden inquebrantable: primero real_cred, después cred. El orden inverso provoca privilegios completos al instante y pérdida de control de los hilos.
2. Entre los dos cortes existe inevitablemente un estado transitorio con cred ≠ real_cred. En ese momento cualquier sched_setaffinity dará EPERM → bloqueo total de la ronda. La solución correcta es hacer fork del proceso "escritor preestablecido" antes del primer corte (con credenciales limpias), el proceso padre ejecuta el primer corte, el escritor ejecuta el segundo, y ninguno realiza syscalls en el estado transitorio.
3. El modelo de direcciones no tiene relación con KASLR. Toda la explotación solo usa el alias de mapeo lineal alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), estable entre reinicios; el verdadero valor de la llamada "fase slide" es la autocomprobación de la primitiva de escritura, no evadir KASLR.

Framework upstream: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. Nota: esto no es GhostLock — GhostLock sigue la ruta pselect, que no coincide con la geometría del punto de caída del waiter de este build, ver docs/06.

---

3. Índice