themalwareguardian/uefi-security-research-howyar-sysreturn-netcopyPost-CVE-2024-7344-Analyse von Howyar SysReturn NetCopy - Reverse-Engineering-Notizen, verwundbare Binärdateien, Herstellerkorrespondenz und Proof-of-Concept-Tooling für CVE-2026-79298 (IA-32 Secure-Boot-Bypass über den benutzerdefinierten RxPE-PE-Loader in BOOTia32.efi).
Unter dem Mantel von Secure Boot sinken manche Architekturen tiefer als die Schwachstellen, die sie offengelegt haben. Manche Binärdateien werden widerrufen. Manche Patches werden ausgeliefert. Doch tief unter der Oberfläche hinterlassen alte Gewohnheiten Spuren. Das ist es, was zurückbleibt, wenn eine Schwachstelle offengelegt, gepatcht und vergessen wurde.
Die in diesem Repository dokumentierten Erkenntnisse wurden als CVE-2026-79298 zugewiesen.
Während des koordinierten Offenlegungsprozesses bestätigte der Hersteller, dass die mit CVE-2024-7344 verbundene Behebung nur den x64-Boot-Pfad adressierte. Der IA-32-Boot-Pfad - einschließlich BOOTia32.efi, das als Teil der SysReturn NetCopy-Funktion ausgeliefert wird - war nie in die ursprüngliche Behebung einbezogen. Infolgedessen wurde die anfällige IA-32-Komponente bis Version 11.3.034 (Juli 2026) weiterhin kommerziell vertrieben.
Das dedizierte CVE-Repository verlinkt hierher für die vollständige technische Tiefe: Reverse Engineering, Binäranalyse, Herstellerkorrespondenz, Reproduktionsartefakte und Proof-of-Concept-Tooling.
Das ganze Jahr 2026 über habe ich mich intensiv mit UEFI-Sicherheit beschäftigt - Bootkit-Entwicklung, Secure-Boot-Bypässe, Firmware-Exploitation, CVE-Analyse, Entwicklung offensiver Tooling, Veröffentlichung von Forschung. Es ist der Bereich, auf den ich mich spezialisiert habe, und jede Woche bringt etwas Neues. Ein Teil dieser Arbeit besteht darin, bekannte CVEs in UEFI-Komponenten auszunutzen. Ein Teil besteht darin, Software zu untersuchen, die UEFI-Bootloader ausliefert, aber wenig öffentliche Prüfung erfahren hat. Und ein Teil - der Teil, den dieses Repository dokumentiert - besteht darin, eine Frage zu stellen, die meiner Meinung nach zu oft übersehen wird:
Wie sieht ein Produkt nach einem CVE aus?
Nicht während des Patch-Ansturms. Nicht in der Woche, in der die Advisory erscheint. Achtzehn Monate später, wenn der Druck weg ist, wenn die Forscher weitergezogen sind, wenn niemand mehr hinschaut.
Dieses Repository ist mein Versuch, diese Frage für ein bestimmtes Produkt zu beantworten: Howyar SysReturn NetCopy.
Und ich denke, was ich gefunden habe, wird die Leute überraschen.
Alles in der Sicherheitsforschung hängt mit etwas anderem zusammen, wenn man den Fäden weit genug folgt. Dieser spezielle Faden begann bei der Arbeit. Wir wurden beauftragt, das reale Risiko von UEFI- und Bootkit-Angriffen gegen eine bestimmte Kategorie von Umgebungen zu analysieren: Bildungszentren. Es klingt nischig. Ist es nicht.
Hier ist die Realität, die die meisten Menschen außerhalb dieses Bereichs nicht vollständig würdigen. In einer mittelgroßen Stadt können leicht 70.000 oder mehr gemeinsam genutzte Geräte an Schulen im Einsatz sein - Laptops und Workstations, die von Schülern zwischen acht und fünfzehn Jahren genutzt werden und Linux-Distributionen ausführen, weil Windows-Lizenzierung in diesem Maßstab oft prohibitiv ist.
Fragen Sie sich nun: Wie viele dieser Maschinen haben Secure Boot ordnungsgemäß aktiviert? Die ehrliche Antwort ist an den meisten Orten: sehr wenige. Und der Grund ist nicht Nachlässigkeit. Es ist operative Realität.
Secure Boot in einer Linux-Umgebung ordnungsgemäß zu aktivieren bedeutet, jeden Kernel zu signieren. Jedes Kernel-Update - und Linux-Kernel-Schwachstellen kamen in den letzten Jahren schnell - erfordert ein neues signiertes Image, das auf jeder einzelnen Maschine bereitgestellt werden muss. Das bedeutet koordinierte Update-Pipelines, Schlüsselverwaltungsinfrastruktur, geschultes Personal und laufende Wartung über Tausende von Endpunkten, die über Dutzende von Standorten verteilt sind.
Für Organisationen mit diesen Ressourcen ist es machbar. Für die meisten Schulbezirke ist es das nicht. Es gibt einfach nicht genug Leute, nicht genug Budget und nicht genug Tooling, um es in diesem Maßstab richtig zu machen. Also bleibt Secure Boot deaktiviert.
BIOS-Passwörter werden nicht gesetzt - weil deren Rotation über 70.000 Maschinen mit begrenztem Personal unpraktisch ist. Und diese Maschinen stehen dort, vollständig exponiert auf Firmware-Ebene, und werden täglich von Hunderten von Schülern genutzt.
Was das aus Sicherheitsperspektive tatsächlich bedeutet, ist, dass ein Angreifer, der UEFI-Exploitation versteht, eine dieser Maschinen auf der Firmware-Ebene kompromittieren kann - bevor das Betriebssystem lädt, bevor irgendeine Sicherheitssoftware startet, bevor irgendein Schutzmechanismus eingreifen kann. Ein Bootkit kann über Neustarts hinweg, über Neuinstallationen des Betriebssystems hinweg, über alles hinweg persistent bleiben. Ich weiß das, weil ich solche Tooling selbst entwickle. Die Techniken existieren. Sie sind nicht theoretisch.
Das ist ein bekanntes Problem. Es ist weithin anerkannt. Und es wird nicht so schnell verschwinden.
Die operative Antwort auf dieses Problem - das, was Schulen tatsächlich anstelle von ordnungsgemäßem Secure Boot einsetzen - ist Wiederherstellungssoftware.
Die Idee ist unkompliziert: Was auch immer ein Schüler während einer Sitzung tut, alles kehrt nach dem nächsten Neustart in einen bekanntermaßen sauberen Zustand zurück. Malware, Konfigurationsänderungen, beschädigte Systemdateien, versehentlich oder absichtlich gelöschte Daten - weg. Das reduziert Wartungskosten drastisch und gibt Administratoren eine Möglichkeit, gemeinsam genutzte Maschinen zu verwalten, ohne perfekte Sicherheitskontrollen auf Firmware-Ebene auf jedem Gerät zu benötigen.
Als wir begannen zu evaluieren, welche Produkte in diesen Umgebungen verwendet wurden, kamen mehrere Namen auf. Einer davon war Howyar SysReturn - ein taiwanesisches Produkt, das speziell für Bildungseinsätze entwickelt wurde, mit expliziter Unterstützung für Schulcomputerlabore, gemeinsam genutzte Workstations und großflächig verwaltete Umgebungen.
In dem Moment, als ich diesen Namen sah, wusste ich genau, was ich tun wollte.
Im Januar 2025 veröffentlichte ESET Research die Offenlegung von CVE-2024-7344 - einem Secure-Boot-Bypass, der SysReturn und mehrere andere Wiederherstellungsprodukte betrifft, die auf derselben Codebasis aufbauen.
Die Schwachstelle war auf eine zutiefst frustrierende Weise elegant. Eine von Microsoft signierte UEFI-Anwendung - vom Firmware vertraut, in der Lage zu laufen, selbst wenn Secure Boot aktiviert ist - implementierte ihren eigenen benutzerdefinierten PE-Loader vollständig von Grund auf. Anstatt die standardmäßigen UEFI-Funktionen LoadImage und StartImage zu verwenden, die die Secure-Boot-Signaturüberprüfung erzwingen, parste und führte sie EFI-Binärdateien manuell aus einer Datei namens cloak.dat aus. XOR-verschlüsselt mit einem Ein-Byte-Schlüssel. Keine Signaturprüfung. Was auch immer in dieser Datei war, lief mit vollem Vertrauen auf Firmware-Ebene.
Microsoft widerrief die anfälligen Binärdateien im Januar 2025 Patch Tuesday-Update. Die Sicherheitsbranche zog weiter zum nächsten Thema. Aber ich dachte weiter darüber nach.
Nicht weil die Schwachstelle selbst ungelöst war - ESET dokumentierte sie gründlich und der Widerruf war eindeutig. Was mich weiter beschäftigte, war eine andere Frage. Die Art von Frage, die erst mit der Zeit beantwortbar wird:
Haben sie es tatsächlich behoben? Oder haben sie nur den Druck umgangen?
Es gibt einen Unterschied. Eine echte Behebung adressiert die Grundursache - in diesem Fall die Verwendung eines benutzerdefinierten PE-Loaders, der Secure Boot umgeht. Ein Workaround lässt das unmittelbare Problem verschwinden, während die zugrunde liegende Architektur intakt bleibt.
Ich wollte wissen, welches von beiden Howyar getan hatte.
Ich kontaktierte Howyar Technologies direkt und bat um eine Evaluierungskopie von SysReturn für eine professionelle Beschaffungsbewertung - was angesichts des professionellen Kontexts, der diese Forschung ursprünglich hervorgebracht hatte, völlig zutreffend war.
Der Hersteller war hilfsbereit und reaktionsschnell. Sie stellten eine vollständige Testlizenz, Handbücher, Tutorial-Videos und ein komplettes Evaluierungspaket bereit. Sie beantworteten auch detaillierte Fragen zur Secure-Boot-Kompatibilität, was sich später als direkt relevant für das erwies, was ich fand.
Der gesamte Schriftverkehr ist in diesem Repository unverändert enthalten.
Ich werde hier nicht die technischen Details verderben - dafür ist das Verzeichnis Vulnerability Research da, und ich empfehle aufrichtig, es vollständig zu lesen. Aber so viel sei gesagt.
UEFI ist seine eigene Welt. Die Entwickler, die darin arbeiten, sind wenige. Die Sicherheitsüberprüfungsprozesse, die für Anwendungssoftware oder Webdienste existieren, erreichen Firmware-Komponenten nicht routinemäßig. Schlechte Praktiken, einmal etabliert, neigen dazu zu bestehen - nicht aus Bosheit, sondern weil das Ökosystem klein ist, die Prüfung selten ist und die Konsequenzen von Fehlern oft für alle außer einer Handvoll aufmerksamer Forscher unsichtbar sind.
Was ich in SysReturn v11.2.031 gefunden habe - veröffentlicht im April 2026, mehr als fünfzehn Monate nach Microsofts Widerruf - ist ein klares Beispiel für genau diese Dynamik.
Die Grundursache wurde nicht behoben. Die anfällige Binärdatei wurde nicht ersetzt. Was sich änderte, war operativ: ein anderer Boot-Pfad für Systeme mit aktiviertem Secure Boot, wobei fast alles andere unangetastet blieb.
Der benutzerdefinierte PE-Loader - die RxPE-Komponente, benannt in den eigenen Debug-Strings der Binärdatei - ist in der April 2026-Version vorhanden und funktioniert identisch zu der Art und Weise, wie er in der Version funktionierte, die ESET 2024 analysierte.
Der Authenticode-Hash der Binärdatei, die Howyar im April 2026 auslieferte, stimmt Byte für Byte mit dem Hash überein, den Microsoft im Januar 2025 widerrief.
Ich denke, das ist wichtig. Ich denke, die Leute sollten davon wissen. Und ich denke, die technische Dokumentation in diesem Repository ist detailliert genug, dass jeder, der diese Erkenntnisse selbst überprüfen möchte, dies tun kann.
| Verzeichnis | Beschreibung |
|---|---|
📚 00 Manual | Vom Hersteller bereitgestellte Handbücher, Broschüren und offizielle Produktdokumentation von Howyar |
📦 01 Binaries | Wichtige Binärdateien, die aus dem Evaluierungspaket zur Analyse extrahiert wurden |
📬 02 Disclosure | Vollständiger E-Mail-Schriftverkehr mit Howyar Technologies während des Evaluierungsprozesses |
🔬 03 Vulnerability Research | Reverse Engineering, Binäranalyse, Authenticode-Verifikation, ALRM-Format-Analyse, Skripte und technische Erkenntnisse |
Die technische Geschichte - das vollständige Reverse Engineering von BOOTia32.efi, das ALRM-Payload-Format, die XOR-Entschlüsselung, der benutzerdefinierte RxPE-PE-Loader, die Übereinstimmung des Authenticode-Hashes mit der widerrufenen Binärdatei und die Analyse dessen, was Howyar tatsächlich geändert hat gegenüber dem, was sie unangetastet ließen - steht alles in:
Wenn Sie Kontext zum CVE selbst wünschen, bevor Sie in die Post-"Patch"-Analyse eintauchen, ist die ESET-Advisory eine gute Referenz. Ich pflege auch ein Repository, das CVE-2024-7344 dokumentiert und verwandte UEFI-Schwachstellen detaillierter behandelt.
Fangen Sie an zu lesen. Der Mantel ist immer noch da.
