
Análisis posterior a CVE-2024-7344 de Howyar SysReturn NetCopy: notas de ingeniería inversa, binarios vulnerables, correspondencia con el proveedor y herramientas de prueba de concepto para CVE-2026-79298 (omisión de Secure Boot en IA-32 mediante el cargador PE personalizado RxPE en BOOTia32.efi).
Bajo el manto de Secure Boot, algunas arquitecturas se hunden más profundo que las vulnerabilidades que las expusieron. Algunos binarios son revocados. Algunos parches son distribuidos. Pero muy por debajo de la superficie, los viejos hábitos dejan rastros. Esto es lo que queda cuando una vulnerabilidad es divulgada, parcheada y olvidada.
Los hallazgos documentados en este repositorio han sido asignados a CVE-2026-79298.
Durante el proceso de divulgación coordinada, el proveedor confirmó que la remediación asociada con CVE-2024-7344 solo abordó la ruta de arranque x64. La ruta de arranque IA-32 - incluyendo BOOTia32.efi distribuido como parte de la función SysReturn NetCopy - nunca fue incluida en la remediación original. Como resultado, el componente IA-32 vulnerable continuó siendo distribuido comercialmente hasta la versión 11.3.034 (julio de 2026).
El repositorio dedicado al CVE enlaza de vuelta aquí para la profundidad técnica completa: ingeniería inversa, análisis de binarios, correspondencia con el proveedor, artefactos de reproducción y herramientas de prueba de concepto.
➡️ Investigación: CVE-2026-79298
A lo largo de 2026 he estado inmerso en la seguridad UEFI - desarrollo de bootkits, evasiones de Secure Boot, explotación de firmware, análisis de CVE, desarrollo de herramientas ofensivas, publicación de investigaciones. Es el área en la que he elegido especializarme y cada semana trae algo nuevo. Parte de ese trabajo implica explotar CVE conocidos en componentes UEFI. Parte implica investigar software que distribuye bootloaders UEFI pero que ha recibido poca atención pública. Y parte - la parte que documenta este repositorio - implica hacer una pregunta que creo que se pasa por alto con demasiada frecuencia:
¿Cómo se ve un producto después de un CVE?
No durante la carrera por parchear. No en la semana en que se publica el aviso. Dieciocho meses después, cuando la presión se ha ido, cuando los investigadores han seguido adelante, cuando ya nadie está mirando.
Este repositorio es mi intento de responder esa pregunta para un producto específico: Howyar SysReturn NetCopy.
Y creo que lo que encontré va a sorprender a la gente.
Todo en la investigación de seguridad se conecta con algo más si sigues los hilos lo suficiente. Este hilo en particular comenzó en el trabajo. Se nos encomendó analizar el riesgo real de ataques UEFI y bootkit contra una categoría específica de entorno: centros educativos. Suena nicho. No lo es.
Esta es la realidad que la mayoría de las personas fuera de este campo no aprecian del todo. En una ciudad de tamaño medio, puede haber fácilmente 70.000 o más dispositivos compartidos desplegados en escuelas - portátiles y estaciones de trabajo usados por estudiantes de entre ocho y quince años, ejecutando distribuciones Linux porque el licenciamiento de Windows a esa escala suele ser prohibitivo.
Ahora pregúntate: ¿cuántas de esas máquinas tienen Secure Boot habilitado correctamente? La respuesta honesta, en la mayoría de los lugares, es muy pocas. Y la razón no es negligencia. Es la realidad operativa.
Habilitar Secure Boot correctamente en un entorno Linux significa firmar cada kernel. Cada actualización del kernel - y las vulnerabilidades del kernel de Linux han estado llegando rápido en los últimos años - requiere una nueva imagen firmada que se despliegue en cada máquina. Eso significa pipelines de actualización coordinados, infraestructura de gestión de claves, personal capacitado y mantenimiento continuo en miles de endpoints distribuidos en docenas de ubicaciones.
Para organizaciones con esos recursos, es manejable. Para la mayoría de los distritos escolares, no lo es. Simplemente no hay suficientes personas, ni suficiente presupuesto, ni suficientes herramientas para hacerlo bien a esa escala. Así que Secure Boot permanece deshabilitado.
Las contraseñas de BIOS no se configuran - porque rotarlas en 70.000 máquinas con personal limitado es poco práctico. Y esas máquinas están ahí, completamente expuestas a nivel de firmware, usadas por cientos de estudiantes cada día.
Lo que eso significa realmente, desde una perspectiva de seguridad, es que un atacante que entiende la explotación UEFI puede comprometer una de esas máquinas en la capa de firmware - antes de que cargue el SO, antes de que arranque cualquier software de seguridad, antes de que cualquier mecanismo de protección tenga la oportunidad de intervenir. Un bootkit puede persistir a través de reinicios, a través de reinstalaciones del SO, a través de todo. Sé esto porque yo mismo desarrollo ese tipo de herramientas. Las técnicas existen. No son teóricas.
Este es un problema conocido. Es ampliamente reconocido. Y no va a desaparecer pronto.
La respuesta operativa a ese problema - lo que las escuelas realmente despliegan en lugar de un Secure Boot adecuado - es el software de recuperación.
La idea es sencilla: cualquier cosa que haga un estudiante durante una sesión, todo vuelve a un estado conocido y limpio después del siguiente reinicio. Malware, cambios de configuración, archivos de sistema dañados, datos eliminados accidental o intencionalmente - desaparecen. Esto reduce drásticamente los costos de mantenimiento y da a los administradores una forma de gestionar máquinas compartidas sin necesitar controles de seguridad perfectos a nivel de firmware en cada dispositivo.
Cuando comenzamos a evaluar qué productos se usaban en estos entornos, surgieron varios nombres. Uno de ellos fue Howyar SysReturn - un producto taiwanés diseñado específicamente para despliegues educativos, con soporte explícito para laboratorios de computación escolares, estaciones de trabajo compartidas y entornos gestionados a gran escala.
En el momento en que vi ese nombre, supe exactamente lo que quería hacer.
En enero de 2025, ESET Research publicó la divulgación de CVE-2024-7344 - una evasión de Secure Boot que afecta a SysReturn y a otros productos de recuperación construidos sobre la misma base de código.