Dépôt de recherche documentant CVE-2026-79298, une remédiation incomplète du contournement de UEFI Secure Boot dans le chemin de démarrage IA-32 de Howyar SysReturn, avec du reverse engineering et du matériel PoC.
Une vulnérabilité a été corrigée. Un binaire a été révoqué. Mais seule la moitié de l'architecture a été corrigée. Dix-huit mois plus tard, le chemin de démarrage IA-32 portait toujours le même chargeur PE personnalisé, la même vérification Secure Boot contournée, et le même hachage Authenticode révoqué - livré commercialement dans chaque copie de SysReturn NetCopy jusqu'en juillet 2026. Il s'agit de CVE-2026-79298.
Je suis un chercheur en sécurité offensive spécialisé dans l'exploitation du firmware UEFI, le développement de bootkits/rootkits et la recherche de vulnérabilités. C'est le domaine auquel j'ai choisi de consacrer ma carrière, et il façonne tout ce que je publie.
J'ai co-écrit UEFI Bootkits and Kernel-Mode Rootkits Development - un livre pionnier sur le développement d'implants offensifs au niveau du firmware. J'ai conçu et publié Abyss, un bootkit UEFI Windows complet, et Antarctic, le premier framework de bootkit UEFI disponible publiquement pour Linux. Les deux sont des outils open-source conçus pour les opérateurs red team et les chercheurs en sécurité afin de comprendre, simuler et se défendre contre les menaces réelles au niveau du firmware. À côté de ceux-ci, j'ai développé Benthic, un rootkit en mode noyau Windows, et Behemoth, un outil d'analyse automatisée de binaires UEFI.
Construire de l'outillage offensif à ce niveau implique de comprendre non seulement comment les bootkits fonctionnent, mais aussi comment ils s'installent. C'est là que les vulnérabilités UEFI entrent en jeu. Chaque contournement de Secure Boot, chaque bootloader mal signé, chaque chargeur PE personnalisé qui saute la vérification - ce sont les portes par lesquelles passe le malware au niveau du firmware. Rechercher et exploiter ces vulnérabilités est une extension naturelle de ce travail. On ne peut pas construire d'outillage offensif réaliste sans comprendre la surface d'attaque réelle.
Ce parcours de recherche - développer des malwares UEFI, puis étudier les vulnérabilités qui permettent leur déploiement - est ce qui m'a conduit à CVE-2024-7344 et finalement aux conclusions documentées ici.
En janvier 2025, Martin Smolár et l'équipe de recherche ESET ont publié la divulgation de CVE-2024-7344 (Under the cloak of UEFI Secure Boot), un contournement de Secure Boot affectant plusieurs produits logiciels de récupération, dont Howyar SysReturn. La vulnérabilité était causée par une application UEFI signée par Microsoft qui implémentait son propre chargeur PE personnalisé (RxPE), contournant entièrement les services standard LoadImage et StartImage. Au lieu de s'appuyer sur la vérification Secure Boot intégrée au firmware, l'application analysait et exécutait manuellement une charge utile non signée à partir d'un fichier appelé cloak.dat, chiffré en XOR avec une clé d'un seul octet, aucune vérification de signature, une confiance totale au niveau du firmware.
Microsoft a révoqué les binaires affectés dans la mise à jour Patch Tuesday de janvier 2025. L'avis a été publié. La communauté de la sécurité est passée à autre chose. Mais pas moi.
J'ai passé des années à étudier les vulnérabilités UEFI - pas seulement CVE-2024-7344, mais tout le paysage des contournements de Secure Boot, des chargeurs PE personnalisés et des failles de conception dans les composants UEFI signés. Et il y a un schéma que j'ai vu se répéter encore et encore : les mêmes catégories de décisions de conception incorrectes refont surface chez différents fournisseurs et au fil des années. Une vulnérabilité est divulguée, un binaire est révoqué, et des mois ou des années plus tard une faille similaire apparaît - parfois dans le même produit, parfois dans un produit différent du même fournisseur, parfois dans la base de code d'un fournisseur complètement différent qui partage les mêmes hypothèses architecturales.
Ce schéma m'a poussé à poser une question que l'industrie de la sécurité ne pose, je pense, pas assez souvent :
À quoi ressemble un produit après un CVE ? Pas pendant la précipitation du correctif - dix-huit mois plus tard, quand plus personne ne regarde.
J'ai décidé de le découvrir. Et le produit que j'ai choisi était Howyar SysReturn.
J'ai contacté directement Howyar Technologies et obtenu une copie d'évaluation de SysReturn pour une évaluation professionnelle d'approvisionnement - un contexte légitime issu d'un travail réel d'évaluation de logiciels de récupération pour des déploiements éducatifs à grande échelle.
Ce que j'ai trouvé dans SysReturn v11.2.031, publié en avril 2026 - plus de quinze mois après la révocation de Microsoft - a confirmé exactement ce que le schéma avait suggéré.
Le chemin de démarrage x64 avait été traité. Mais le chemin de démarrage IA-32 n'avait jamais été remédié. Le binaire BOOTia32.efi, distribué dans le cadre de la fonctionnalité SysReturn NetCopy, contenait toujours le même chargeur PE personnalisé (RxPE), chargeait toujours des charges utiles non signées à partir d'un fichier appelé cloak32.dat en utilisant le même format ALRM et le même chiffrement XOR à un seul octet, et portait toujours exactement le même hachage Authenticode que Microsoft avait révoqué en janvier 2025.
La cause racine n'a jamais été corrigée dans l'architecture IA-32. Ce qui avait changé était opérationnel - le chemin x64 avait été mis à jour, et la pression immédiate de la divulgation avait été traitée - mais l'architecture sous-jacente persistait intacte dans le composant 32 bits, livrée commercialement dans chaque copie du produit.
