Investigación sobre el desbloqueo del bootloader de Huawei P10 CVE-2017-8890

Este repositorio documenta un proyecto de investigación autorizado por el propietario que portó CVE-2017-8890 a un firmware de Huawei P10, convirtió el use-after-free del kernel en lectura/escritura arbitraria del kernel y root temporal, reconstruyó el diario NVE de Huawei, instaló una credencial de bootloader de reemplazo mediante el controlador NVE legítimo y verificó que fastboot aceptó el código de texto plano elegido.

El objetivo probado fue:

• Huawei P10 VTR-L29, región C432
• firmware VTR-L29C432B151
• Android 7.0 / EMUI 5.1
• kernel 4.1.18-gbed9f04
• nivel de parche de seguridad 2017-05-05

Esto no es un desbloqueador universal del P10. El perfil de kernel incluido contiene direcciones absolutas para esa compilación exacta. Usarlo en otro kernel puede provocar un panic en el teléfono y puede corromper el almacenamiento persistente. Las actualizaciones de firmware también pueden cambiar el perfil incluso cuando el modelo comercial no cambia.

La narrativa completa y apta para su publicación está disponible como el informe en PDF.

Resultado

La cadena que tuvo éxito fue:

CVE-2017-8890 multicast UAF
  -> controlled overlap with ip_mc_socklist
  -> forced RCU grace period in the exploit's address space
  -> AArch64 JOP arbitrary store
  -> ptmx_fops.check_flags temporarily redirected
  -> address limit widened to KERNEL_DS
  -> pipe-based arbitrary kernel read/write
  -> check_flags restored
  -> current task credentials and SELinux SID patched
  -> protected NVME partition acquired
  -> replacement SHA-256 verifier written with /dev/nve0
  -> complete 128 KiB generation read back and compared
  -> controlled reboot
  -> fastboot unlock accepted the chosen plaintext

La credencial del bootloader sobrevivió a una posterior actualización oficial de Android 8 / EMUI 8 aunque el bootloader se volvió a bloquear, y el mismo texto plano elegido lo desbloqueó de nuevo. Esto indica que la credencial reside en los datos NVE persistentes del dispositivo y no en el sistema Android ni en la imagen de arranque.

Empieza aquí

1. Lee SAFETY.md.
2. Confirma el firmware y el kernel exactos indicados arriba.
3. Lee docs/exploit-development.md para entender por qué el exploit público original no era fiable de inmediato.
4. Sigue docs/reproduction.md en orden.
5. No realices la etapa de escritura persistente hasta que el root temporal, una copia de seguridad NVME completa, la validación de candidatos sin conexión y la planificación de la recuperación hayan tenido éxito.

Estructura del repositorio

exploit/CVE-2017-8890/1003/  modified exploit implementation
utils/                       GPLv3 androotzf support code
jni/                         Android NDK build files
tools/p10_nve_journal.py     read-only inspector and offline candidate builder
docs/exploit-development.md  technical exploit journey
docs/nve-format.md            Huawei NVE journal and credential semantics
docs/reproduction.md         staged reproduction procedure
report/                       redacted long-form PDF

No se incluye ningún exploit compilado, imagen de firmware, volcado de partición, imagen de arranque, utilidad comercial propietaria, código de desbloqueo, identificador de dispositivo ni digesto de credencial derivado del dispositivo.

Origen y licencia

El exploit comenzó con la implementación GPLv3 idhyt/androotzf en el commit 63dfe5556e1a8cdbf6a2d3dd0ee929b07bfb48b7. Este repositorio conserva los avisos de copyright del upstream y la licencia GPLv3. Los cambios de fiabilidad del P10 B151, diagnóstico, lectura/escritura del kernel, root temporal, volcado de particiones y transacciones NVE protegidas se identifican como modificaciones realizadas durante este proyecto de investigación en julio de 2026.

Consulta NOTICE.md para ver los detalles de atribución y modificaciones.

Uso responsable

Usa este trabajo únicamente en hardware que poseas o cuya prueba tengas autorizada explícitamente. El desbloqueo del bootloader borra los datos de usuario. El exploit corrompe deliberadamente objetos del kernel y normalmente provoca un panic de limpieza posterior a menos que alcance una ruta de reinicio controlado. No hay garantía ni se asegura la recuperación.