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.
| Champ | Détail |
|---|---|
| Identifiant CVE | CVE-2026-79298 |
| Type de vulnérabilité | Remédiation incomplète du contournement de UEFI Secure Boot (CWE-693 : Défaillance du mécanisme de protection) |
| Fournisseur | Howyar Technologies Inc. |
| Produit | SysReturn (fonctionnalité NetCopy) |
| Versions affectées | Versions antérieures à 11.3.034 (confirmé dans v11.2.031 et v11.3.033) |
| Version corrigée | v11.3.034 (juillet 2026) |
| Composant affecté | BOOTia32.efi (application UEFI IA-32 signée par Microsoft), chargeur PE personnalisé RxPE (UEFI\RxPE.cpp), cloak32.dat (charge utile chiffrée en XOR au format ALRM) |
| Type d'attaque | Locale |
| Impact | Exécution de code arbitraire, élévation de privilèges |
| Vecteur d'attaque | Un attaquant disposant d'un accès en écriture à la partition système EFI (administrateur local sous Windows, root sous Linux) peut placer BOOTia32.efi et un cloak32.dat forgé sur l'ESP. Au redémarrage, le binaire exécute la charge utile non signée via RxPE, contournant entièrement la vérification Secure Boot. Nécessite un système UEFI IA-32 avec Secure Boot activé qui fait confiance à la Microsoft Corporation UEFI CA 2011 et n'a pas appliqué la mise à jour de révocation dbx de janvier 2025. |
| Reconnaissance du fournisseur | Confirmée. Le fournisseur a reconnu lors de la divulgation coordonnée que le chemin de démarrage IA-32 n'a jamais été inclus dans la remédiation originale de CVE-2024-7344. |
Le processus de divulgation coordonnée de cette vulnérabilité a été mené directement avec Howyar Technologies sur une période d'environ deux mois.
Résumé de la chronologie :
Le contournement de Secure Boot a été reproduit dynamiquement à l'aide de QEMU/OVMF IA-32 avec Secure Boot activé. Les artefacts de reproduction complets, la documentation de rétro-ingénierie, la vérification du hachage Authenticode, les matériels de preuve de concept et chaque courriel échangé durant le processus de coordination sont inclus dans le dépôt de recherche principal.
Cet identifiant CVE a été attribué après que la recherche avait déjà été menée, documentée et partagée via deux dépôts dédiés. Ces dépôts contiennent toute la profondeur technique - les binaires vulnérables, la rétro-ingénierie, la correspondance avec le fournisseur, les outils de preuve de concept et les matériels de reproduction. Ce dépôt sert de point d'entrée indexé par CVE qui relie le tout.
➡️ UEFI-Security-Research-Howyar-SysReturn-NetCopy
Il s'agit du dépôt de recherche principal. Il contient :
BOOTia32.efi, cloak32.dat et composants associés)BOOTia32.efi : le format de charge utile ALRM, le déchiffrement XOR, le chargeur PE personnalisé RxPE, la vérification du hachage Authenticode par rapport au binaire révoqué, et l'analyse de ce qui a été modifié par rapport à ce qui est resté inchangédecode_cloak.py, authenticode_hash.py, create_cloak.py)Il s'agit du dépôt complémentaire documentant la vulnérabilité originale dont découle CVE-2026-79298. Il contient :
Vous travaillez sur quelque chose de similaire ? Vous faites de la recherche sur UEFI, la sécurité du noyau, l'exploitation, ou un autre sujet de sécurité intéressant ? Si vous avez besoin d'un coup de main pour développer un exploit, explorer une technique, ou simplement échanger des idées, n'hésitez pas à me contacter. Je suis toujours ouvert à discuter de recherche, à aider quand je le peux, et à collaborer sur des projets intéressants.
N'hésitez pas à me contacter sur LinkedIn.