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).
themalwareguardian/uefi-security-research-howyar-sysreturn-netcopy
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.
La vulnerabilidad era elegante de una manera profundamente frustrante. Una aplicación UEFI firmada por Microsoft - confiada por el firmware, capaz de ejecutarse incluso con Secure Boot habilitado - implementaba su propio cargador PE personalizado completamente desde cero. En lugar de usar las funciones estándar de UEFI LoadImage y StartImage, que aplican la verificación de firma de Secure Boot, analizaba y ejecutaba binarios EFI manualmente desde un archivo llamado cloak.dat. Cifrado XOR con una clave de un solo byte. Sin verificación de firma. Lo que fuera que estuviera dentro de ese archivo se ejecutaba con total confianza a nivel de firmware.
Microsoft revocó los binarios vulnerables en la actualización del Patch Tuesday de enero de 2025. La industria de la seguridad siguió adelante con lo siguiente. Pero yo seguí pensando en ello.
No porque la vulnerabilidad en sí misma no estuviera resuelta - ESET la documentó exhaustivamente y la revocación fue clara. Lo que seguía tirando de mí era una pregunta diferente. El tipo de pregunta que solo se vuelve respondible con el tiempo:
¿Realmente lo arreglaron? ¿O simplemente sortearon la presión?
Hay una diferencia. Un arreglo real aborda la causa raíz - en este caso, el uso de un cargador PE personalizado que evade Secure Boot. Un parche temporal hace desaparecer el problema inmediato mientras deja intacta la arquitectura subyacente.
Quería saber cuál de las dos había hecho Howyar.
Contacté directamente a Howyar Technologies y solicité una copia de evaluación de SysReturn para una evaluación profesional de adquisición - lo cual, dado el contexto profesional que originó esta investigación, era completamente cierto.
El proveedor fue servicial y receptivo. Proporcionaron una licencia de prueba completa, manuales, videos tutoriales y un paquete de evaluación completo. También respondieron preguntas detalladas sobre la compatibilidad con Secure Boot, lo cual resultó ser directamente relevante para lo que encontré después.
Toda esa correspondencia está incluida en este repositorio, sin editar.
No voy a arruinar los detalles técnicos aquí - para eso está el directorio Vulnerability Research, y recomiendo genuinamente leerlo completo. Pero diré esto.
UEFI es su propio mundo. Los desarrolladores que trabajan en él son pocos. Los procesos de revisión de seguridad que existen para software de aplicación o servicios web no llegan rutinariamente a los componentes de firmware. Las malas prácticas, una vez establecidas, tienden a persistir - no por malicia, sino porque el ecosistema es pequeño, el escrutinio es raro, y las consecuencias de equivocarse a menudo son invisibles para todos excepto para el puñado de investigadores que prestan atención.
Lo que encontré en SysReturn v11.2.031 - publicado en abril de 2026, más de quince meses después de la revocación de Microsoft - es un ejemplo claro de exactamente esa dinámica.
La causa raíz no fue arreglada. El binario vulnerable no fue reemplazado. Lo que cambió fue operativo: una ruta de arranque diferente para sistemas con Secure Boot habilitado, dejando casi todo lo demás intacto.
El cargador PE personalizado - el componente , nombrado en las propias cadenas de depuración del binario - está presente en la versión de abril de 2026, funcionando de manera idéntica a como funcionaba en la versión que ESET analizó en 2024.
RxPEEl hash Authenticode del binario que Howyar distribuyó en abril de 2026 coincide, byte por byte, con el hash que Microsoft revocó en enero de 2025.
Creo que eso importa. Creo que la gente debería saberlo. Y creo que la documentación técnica en este repositorio es lo suficientemente detallada como para que cualquiera que quiera verificar estos hallazgos por sí mismo pueda hacerlo.
| Directorio | Descripción |
|---|---|
📚 00 Manual | Manuales del proveedor, folletos y documentación oficial del producto proporcionada por Howyar |
📦 01 Binaries | Binarios clave extraídos del paquete de evaluación para su análisis |
📬 02 Disclosure | Correspondencia completa por correo electrónico con Howyar Technologies durante el proceso de evaluación |
🔬 03 Vulnerability Research | Ingeniería inversa, análisis de binarios, verificación Authenticode, análisis del formato ALRM, scripts y hallazgos técnicos |
La historia técnica - la ingeniería inversa completa de BOOTia32.efi, el formato de payload ALRM, el descifrado XOR, el cargador PE personalizado RxPE, la coincidencia del hash Authenticode con el binario revocado, y el análisis de lo que Howyar realmente cambió versus lo que dejó intacto - está toda en:
Si quieres contexto sobre el CVE en sí antes de sumergirte en el análisis posterior al "parche", el aviso de ESET es una buena referencia. También mantengo un repositorio que documenta CVE-2024-7344 y vulnerabilidades UEFI relacionadas con más detalle.
Empieza a leer. El manto sigue ahí.