🔎 Wie diese Recherche begann

Im Januar 2025 veröffentlichten Martin Smolár und das ESET Research Team die Offenlegung von CVE-2024-7344 (Under the cloak of UEFI Secure Boot), einer Secure-Boot-Umgehung, die mehrere Wiederherstellungssoftware-Produkte betraf, darunter Howyar SysReturn. Die Schwachstelle wurde durch eine von Microsoft signierte UEFI-Anwendung verursacht, die ihren eigenen benutzerdefinierten PE-Loader (RxPE) implementierte und dabei die standardmäßigen LoadImage- und StartImage-Dienste vollständig umging. Anstatt sich auf die integrierte Secure-Boot-Verifikation der Firmware zu verlassen, parste und führte die Anwendung manuell eine unsignierte Nutzlast aus einer Datei namens cloak.dat aus, XOR-verschlüsselt mit einem Ein-Byte-Schlüssel, ohne Signaturprüfung, mit vollständigem Vertrauen auf Firmware-Ebene.

Microsoft sperrte die betroffenen Binärdateien im Januar-2025-Patch-Tuesday-Update. Die Advisory wurde veröffentlicht. Die Sicherheitsgemeinschaft wandte sich anderen Themen zu. Ich jedoch nicht.

Ich habe Jahre damit verbracht, UEFI-Schwachstellen zu studieren - nicht nur CVE-2024-7344, sondern die gesamte Landschaft von Secure-Boot-Umgehungen, benutzerdefinierten PE-Loadern und Designfehlern in signierten UEFI-Komponenten. Und es gibt ein Muster, das ich immer wieder gesehen habe: Dieselben Kategorien fehlerhafter Designentscheidungen tauchen über Hersteller und Jahre hinweg immer wieder auf. Eine Schwachstelle wird offengelegt, eine Binärdatei wird gesperrt, und Monate oder Jahre später erscheint ein ähnlicher Fehler - manchmal im selben Produkt, manchmal in einem anderen Produkt desselben Herstellers, manchmal in der Codebasis eines völlig anderen Herstellers, die zufällig dieselben architektonischen Annahmen teilt.

Dieses Muster veranlasste mich, eine Frage zu stellen, die die Sicherheitsbranche meiner Meinung nach nicht oft genug stellt:

Wie sieht ein Produkt nach einem CVE aus? Nicht während des Patch-Sturms - achtzehn Monate später, wenn niemand mehr hinsieht.

Ich beschloss, es herauszufinden. Und das Produkt, das ich wählte, war Howyar SysReturn.

🔗 Verwandte Repositories

Diese CVE-Kennung wurde vergeben, nachdem die Recherche bereits durchgeführt, dokumentiert und über zwei dedizierte Repositories geteilt worden war. Diese Repositories enthalten die vollständige technische Tiefe - die anfälligen Binärdateien, das Reverse Engineering, die Herstellerkorrespondenz, die Proof-of-Concept-Tools und die Reproduktionsmaterialien. Dieses Repository dient als CVE-indizierter Einstiegspunkt, der alles miteinander verbindet.

🌊 UEFI Security Research - Howyar SysReturn NetCopy

➡️ UEFI-Security-Research-Howyar-SysReturn-NetCopy

Dies ist das primäre Forschungs-Repository. Es enthält:

• Herstellerhandbücher und offizielle Produktdokumentation, bereitgestellt von Howyar Technologies
• Wichtige Binärdateien, extrahiert aus dem Evaluierungspaket (BOOTia32.efi, cloak32.dat und zugehörige Komponenten)
• Die vollständige E-Mail-Korrespondenz mit Howyar Technologies während der Evaluierung und des koordinierten Offenlegungsprozesses
• Vollständiges Reverse Engineering von BOOTia32.efi: das ALRM-Nutzlastformat, XOR-Entschlüsselung, der benutzerdefinierte RxPE-PE-Loader, Authenticode-Hash-Verifikation gegen die gesperrte Binärdatei und die Analyse dessen, was geändert wurde gegenüber dem, was unangetastet blieb
• Python-Tooling für die ALRM/cloak.dat-Analyse (decode_cloak.py, authenticode_hash.py, create_cloak.py)
• Dynamische Reproduktion mit QEMU/OVMF IA-32 bei aktiviertem Secure Boot

🐞 CVE-2024-7344: Unsachgemäßes Laden von PE-Images

➡️ CVE-2024-7344

Dies ist das begleitende Repository, das die ursprüngliche Schwachstelle dokumentiert, aus der CVE-2026-79298 hervorgeht. Es enthält:

• Technische Analyse von CVE-2024-7344, wie ursprünglich von ESET Research offengelegt
• Ein vollständig kompilierbares Lehr-Proof-of-Concept, das dieselbe Schwachstellenklasse reproduziert
• Dokumentation der Secure-Boot-Vertrauenskette, der Architektur des benutzerdefinierten PE-Loaders und des Ausnutzungsprozesses