Analyse post-CVE-2024-7344 de Howyar SysReturn NetCopy - notes de rétro-ingénierie, binaires vulnérables, correspondance avec le fournisseur et outillage de preuve de concept pour CVE-2026-79298 (contournement de Secure Boot IA-32 via le chargeur PE personnalisé RxPE dans BOOTia32.efi).
themalwareguardian/uefi-security-research-howyar-sysreturn-netcopy
Sous le manteau du Secure Boot, certaines architectures s'enfoncent plus profondément que les vulnérabilités qui les ont exposées. Certains binaires sont révoqués. Certains correctifs sont déployés. Mais sous la surface, de vieilles habitudes laissent des traces. Voici ce qui subsiste lorsqu'une vulnérabilité est divulguée, corrigée et oubliée.
Les conclusions documentées dans ce dépôt ont été attribuées à CVE-2026-79298.
Lors du processus de divulgation coordonnée, le fournisseur a confirmé que la remédiation associée à CVE-2024-7344 ne concernait que le chemin de démarrage x64. Le chemin de démarrage IA-32 - incluant BOOTia32.efi distribué dans le cadre de la fonctionnalité SysReturn NetCopy - n'a jamais été inclus dans la remédiation initiale. Par conséquent, le composant IA-32 vulnérable a continué d'être distribué commercialement jusqu'à la version 11.3.034 (juillet 2026).
Le dépôt CVE dédié renvoie ici pour toute la profondeur technique : rétro-ingénierie, analyse binaire, correspondance avec le fournisseur, artefacts de reproduction et outillage de preuve de concept.
Tout au long de 2026, je me suis plongé dans la sécurité UEFI - développement de bootkits, contournements de Secure Boot, exploitation de firmware, analyse de CVE, développement d'outils offensifs, publication de recherches. C'est le domaine dans lequel j'ai choisi de me spécialiser et chaque semaine apporte son lot de nouveautés. Une partie de ce travail consiste à exploiter des CVE connues dans des composants UEFI. Une autre partie consiste à étudier des logiciels qui embarquent des bootloaders UEFI mais qui ont reçu peu d'examen public. Et une autre partie encore - celle que documente ce dépôt - consiste à poser une question qui, je pense, est trop souvent négligée :
À quoi ressemble un produit après une CVE ?
Pas pendant la course aux correctifs. Pas la semaine où l'avis est publié. Dix-huit mois plus tard, quand la pression est retombée, quand les chercheurs sont passés à autre chose, quand plus personne ne regarde.
Ce dépôt est ma tentative de répondre à cette question pour un produit précis : Howyar SysReturn NetCopy.
Et je pense que ce que j'ai découvert va surprendre.
Tout, en recherche en sécurité, se relie à autre chose si l'on suit les fils assez loin. Ce fil particulier a commencé au travail. On nous a chargés d'analyser le risque réel des attaques UEFI et bootkit contre une catégorie d'environnement précise : les centres éducatifs. Cela semble de niche. Ça ne l'est pas.
Voici la réalité que la plupart des gens extérieurs à ce domaine ne mesurent pas pleinement. Dans une ville de taille moyenne, il peut facilement y avoir 70 000 appareils partagés ou plus déployés dans les écoles - ordinateurs portables et stations de travail utilisés par des élèves de huit à quinze ans, sous des distributions Linux parce que les licences Windows à cette échelle sont souvent prohibitifs.
Maintenant, demandez-vous : combien de ces machines ont le Secure Boot correctement activé ? La réponse honnête, dans la plupart des endroits, est : très peu. Et la raison n'est pas la négligence. C'est la réalité opérationnelle.
Activer correctement le Secure Boot dans un environnement Linux implique de signer chaque noyau. Chaque mise à jour du noyau - et les vulnérabilités du noyau Linux se sont succédé rapidement ces dernières années - nécessite le déploiement d'une nouvelle image signée sur chaque machine. Cela implique des pipelines de mise à jour coordonnés, une infrastructure de gestion des clés, du personnel formé et une maintenance continue sur des milliers de postes répartis sur des dizaines de sites.
Pour les organisations qui disposent de ces ressources, c'est gérable. Pour la plupart des circonscriptions scolaires, ça ne l'est pas. Il n'y a tout simplement pas assez de personnel, pas assez de budget et pas assez d'outils pour bien faire les choses à cette échelle. Alors le Secure Boot reste désactivé.
Les mots de passe BIOS ne sont pas définis - parce que les faire tourner sur 70 000 machines avec un personnel limité est impraticable. Et ces machines restent là, totalement exposées au niveau du firmware, utilisées par des centaines d'élèves chaque jour.
Ce que cela signifie réellement, d'un point de vue sécurité, c'est qu'un attaquant qui maîtrise l'exploitation UEFI peut compromettre l'une de ces machines au niveau du firmware - avant le chargement de l'OS, avant le démarrage de tout logiciel de sécurité, avant que tout mécanisme de protection ait la moindre chance d'intervenir. Un bootkit peut persister à travers les redémarrages, à travers les réinstallations de l'OS, à travers tout. Je le sais parce que je développe moi-même ce type d'outils. Les techniques existent. Elles ne sont pas théoriques.
C'est un problème connu. Il est largement reconnu. Et il n'est pas près de disparaître.
La réponse opérationnelle à ce problème - ce que les écoles déploient réellement à la place d'un Secure Boot correct - ce sont les logiciels de restauration.
L'idée est simple : quoi qu'un élève fasse pendant une session, tout revient à un état propre connu après le redémarrage suivant. Logiciels malveillants, modifications de configuration, fichiers système corrompus, données supprimées accidentellement ou intentionnellement - tout disparaît. Cela réduit considérablement les coûts de maintenance et donne aux administrateurs un moyen de gérer des machines partagées sans avoir besoin de contrôles de sécurité parfaits au niveau du firmware sur chaque appareil.
Lorsque nous avons commencé à évaluer quels produits étaient utilisés dans ces environnements, plusieurs noms sont apparus. L'un d'eux était Howyar SysReturn - un produit taïwanais spécialement conçu pour les déploiements éducatifs, avec un support explicite pour les salles informatiques scolaires, les postes de travail partagés et les environnements gérés à grande échelle.
Dès que j'ai vu ce nom, j'ai su exactement ce que je voulais faire.
En janvier 2025, ESET Research a publié la divulgation de CVE-2024-7344 - un contournement de Secure Boot affectant SysReturn et plusieurs autres produits de restauration construits sur la même base de code.
La vulnérabilité était élégante d'une manière profondément frustrante. Une application UEFI signée par Microsoft - approuvée par le firmware, capable de s'exécuter même avec Secure Boot activé - implémentait son propre chargeur PE personnalisé entièrement à partir de zéro. Au lieu d'utiliser les fonctions standard UEFI LoadImage et StartImage, qui imposent la vérification de signature Secure Boot, elle analysait et exécutait manuellement des binaires EFI depuis un fichier appelé cloak.dat. Chiffré en XOR avec une clé d'un seul octet. Aucune vérification de signature. Tout ce que contenait ce fichier s'exécutait avec une confiance totale au niveau du firmware.
Microsoft a révoqué les binaires vulnérables dans la mise à jour Patch Tuesday de janvier 2025. L'industrie de la sécurité est passée à autre chose. Mais je n'arrêtais pas d'y penser.
Non pas parce que la vulnérabilité elle-même n'était pas résolue - ESET l'a documentée en détail et la révocation était claire. Ce qui me taraudait, c'était une question différente. Le genre de question à laquelle seul le temps permet de répondre :
Ont-ils réellement corrigé le problème ? Ou ont-ils simplement contourné la pression ?
Il y a une différence. Un vrai correctif s'attaque à la cause racine - dans ce cas, l'utilisation d'un chargeur PE personnalisé qui contourne le Secure Boot. Un contournement fait disparaître le problème immédiat tout en laissant l'architecture sous-jacente intacte.
Je voulais savoir laquelle des deux approches Howyar avait choisie.
J'ai contacté directement Howyar Technologies et demandé une copie d'évaluation de SysReturn pour une évaluation professionnelle d'acquisition - ce qui, compte tenu du contexte professionnel à l'origine de cette recherche, était tout à fait exact.
Le fournisseur a été serviable et réactif. Ils ont fourni une licence d'essai complète, des manuels, des vidéos tutorielles et un package d'évaluation complet. Ils ont également répondu à des questions détaillées sur la compatibilité Secure Boot, ce qui s'est avéré directement pertinent par rapport à ce que j'ai découvert par la suite.
Toute cette correspondance est incluse dans ce dépôt, sans modification.
Je ne vais pas divulgâcher les détails techniques ici - c'est le rôle du répertoire Vulnerability Research, et je recommande sincèrement de le lire en entier. Mais je dirai ceci.
L'UEFI est un monde à part. Les développeurs qui y travaillent sont peu nombreux. Les processus de revue de sécurité qui existent pour les logiciels applicatifs ou les services web n'atteignent pas systématiquement les composants firmware. Les mauvaises pratiques, une fois établies, ont tendance à persister - non par malveillance, mais parce que l'écosystème est petit, l'examen est rare, et les conséquences d'une erreur sont souvent invisibles pour tout le monde sauf la poignée de chercheurs qui y prêtent attention.
Ce que j'ai découvert dans SysReturn v11.2.031 - publié en avril 2026, plus de quinze mois après la révocation de Microsoft - est un exemple clair de cette dynamique.
La cause racine n'a pas été corrigée. Le binaire vulnérable n'a pas été remplacé. Ce qui a changé est opérationnel : un chemin de démarrage différent pour les systèmes avec Secure Boot activé, laissant presque tout le reste intact.
Le chargeur PE personnalisé - le composant RxPE, nommé dans les propres chaînes de débogage du binaire - est présent dans la version d'avril 2026, fonctionnant exactement comme il fonctionnait dans la version analysée par ESET en 2024.
Le hash Authenticode du binaire livré par Howyar en avril 2026 correspond, octet pour octet, au hash que Microsoft a révoqué en janvier 2025.
Je pense que cela compte. Je pense que les gens devraient le savoir. Et je pense que la documentation technique de ce dépôt est suffisamment détaillée pour que quiconque souhaite vérifier ces conclusions par lui-même puisse le faire.
| Répertoire | Description |
|---|---|
📚 00 Manual | Manuels du fournisseur, brochures et documentation produit officielle fournis par Howyar |
📦 01 Binaries | Binaires clés extraits du package d'évaluation pour analyse |
📬 02 Disclosure | Correspondance électronique complète avec Howyar Technologies durant le processus d'évaluation |
🔬 03 Vulnerability Research | Rétro-ingénierie, analyse binaire, vérification Authenticode, analyse du format ALRM, scripts et conclusions techniques |
L'histoire technique - la rétro-ingénierie complète de BOOTia32.efi, le format de payload ALRM, le déchiffrement XOR, le chargeur PE personnalisé RxPE, la correspondance du hash Authenticode avec le binaire révoqué, et l'analyse de ce que Howyar a réellement changé par rapport à ce qu'ils ont laissé intact - se trouve dans :
Si vous souhaitez du contexte sur la CVE elle-même avant de plonger dans l'analyse post-« correctif », l'avis d'ESET est une bonne référence. Je maintiens également un dépôt documentant CVE-2024-7344 et les vulnérabilités UEFI associées plus en détail.
Commencez à lire. Le manteau est toujours là.
