themalwareguardian/cve-2026-79298Research repository documenting CVE-2026-79298, an incomplete UEFI Secure Boot bypass remediation in Howyar SysReturn's IA-32 boot path, with reverse engineering and PoC materials.
A vulnerability was patched. A binary was revoked. But only half the architecture was fixed. Eighteen months later, the IA-32 boot path still carried the same custom PE loader, the same bypassed Secure Boot verification, and the same revoked Authenticode hash - shipping commercially in every copy of SysReturn NetCopy until July 2026. This is CVE-2026-79298.
I am an offensive security researcher specialising in UEFI firmware exploitation, bootkit/rootkit development, and vulnerability research. This is the field I have chosen to dedicate my career to, and it shapes everything I publish.
I co-authored UEFI Bootkits and Kernel-Mode Rootkits Development - a pioneering book on developing offensive firmware-level implants. I built and released Abyss, a complete Windows UEFI bootkit, and Antarctic, the first publicly available UEFI bootkit framework for Linux. Both are open-source tools designed for red team operators and security researchers to understand, simulate, and defend against real-world firmware threats. Alongside them, I developed Benthic, a Windows kernel-mode rootkit, and Behemoth, a tool for automated UEFI binary analysis.
Building offensive tooling at this level means understanding not just how bootkits work, but how they get installed. That is where UEFI vulnerabilities come in. Every Secure Boot bypass, every improperly signed bootloader, every custom PE loader that skips verification - these are the doors that firmware-level malware walks through. Researching and exploiting those vulnerabilities is a natural extension of the work. You cannot build realistic offensive tooling without understanding the real attack surface.
That research path - developing UEFI malware, then studying the vulnerabilities that enable its deployment - is what led me to CVE-2024-7344 and ultimately to the findings documented here.
In January 2025, Martin Smolár and the ESET Research Team published the disclosure of CVE-2024-7344 (Under the cloak of UEFI Secure Boot), a Secure Boot bypass affecting multiple recovery software products, including Howyar SysReturn. The vulnerability was caused by a Microsoft-signed UEFI application that implemented its own custom PE loader (RxPE), bypassing the standard LoadImage and StartImage services entirely. Instead of relying on the firmware's built-in Secure Boot verification, the application manually parsed and executed an unsigned payload from a file called cloak.dat, XOR-encrypted with a single-byte key, no signature check, full firmware-level trust.
Microsoft revoked the affected binaries in the January 2025 Patch Tuesday update. The advisory was published. The security community moved on. But I did not.
I have spent years studying UEFI vulnerabilities - not just CVE-2024-7344, but the entire landscape of Secure Boot bypasses, custom PE loaders, and design-level flaws in signed UEFI components. And there is a pattern I have seen over and over again: the same categories of incorrect design decisions resurface across vendors and across years. A vulnerability gets disclosed, a binary gets revoked, and months or years later a similar flaw appears - sometimes in the same product, sometimes in a different product from the same vendor, sometimes in a completely different vendor's codebase that happens to share the same architectural assumptions.
That pattern made me ask a question that I think the security industry does not ask often enough:
What does a product look like after a CVE? Not during the patch rush - eighteen months later, when nobody is watching anymore.
I decided to find out. And the product I chose was Howyar SysReturn.
I contacted Howyar Technologies directly and obtained an evaluation copy of SysReturn for a professional procurement assessment - a legitimate context that originated from real-world work evaluating recovery software for large-scale educational deployments.
What I found in SysReturn v11.2.031, released in April 2026 - more than fifteen months after Microsoft's revocation - confirmed exactly what the pattern had suggested.
The x64 boot path had been addressed. But the IA-32 boot path had never been remediated. The binary BOOTia32.efi, distributed as part of the SysReturn NetCopy feature, still contained the same custom PE loader (RxPE), still loaded unsigned payloads from a file called cloak32.dat using the same ALRM format and single-byte XOR encryption, and still carried the exact same Authenticode hash that Microsoft had revoked in January 2025.
The root cause was never fixed in the IA-32 architecture. What had changed was operational - the x64 path had been updated, and the immediate pressure from the disclosure had been addressed - but the underlying architecture persisted untouched in the 32-bit component, shipping commercially in every copy of the product.
| Field | Detail |
|---|
| CVE ID | CVE-2026-79298 |
| Vulnerability Type | Incomplete Remediation of UEFI Secure Boot Bypass (CWE-693: Protection Mechanism Failure) |
| Vendor | Howyar Technologies Inc. |
| Product | SysReturn (NetCopy feature) |
| Affected Versions | Versions prior to 11.3.034 (confirmed in v11.2.031 and v11.3.033) |
| Fixed Version | v11.3.034 (July 2026) |
| Affected Component | BOOTia32.efi (Microsoft-signed IA-32 UEFI application), RxPE custom PE loader (UEFI\RxPE.cpp), cloak32.dat (ALRM format XOR-encrypted payload) |
| Attack Type | Local |
| Impact | Arbitrary code execution, escalation of privileges |
| Attack Vector | An attacker with write access to the EFI System Partition (local Administrator on Windows, root on Linux) can place BOOTia32.efi and a crafted cloak32.dat on the ESP. Upon reboot, the binary executes the unsigned payload via RxPE, bypassing Secure Boot verification entirely. Requires an IA-32 UEFI system with Secure Boot enabled that trusts the Microsoft Corporation UEFI CA 2011 and has not applied the January 2025 dbx revocation update. |
| Vendor Acknowledgement | Confirmed. The vendor acknowledged during the coordinated disclosure that the IA-32 boot path was never included in the original CVE-2024-7344 remediation. |
The coordinated disclosure process for this vulnerability was conducted directly with Howyar Technologies over a period of approximately two months.
Timeline summary:
The Secure Boot bypass was dynamically reproduced using QEMU/OVMF IA-32 with Secure Boot enabled. Complete reproduction artifacts, reverse engineering documentation, Authenticode hash verification, proof-of-concept materials and every email exchanged during the coordination process is included in the primary research repository.
This CVE identifier was assigned after the research had already been conducted, documented, and shared through two dedicated repositories. Those repositories contain the full technical depth - the vulnerable binaries, the reverse engineering, the vendor correspondence, the proof-of-concept tools, and the reproduction materials. This repository serves as the CVE-indexed entry point that ties everything together.
➡️ UEFI-Security-Research-Howyar-SysReturn-NetCopy
This is the primary research repository. It contains:
BOOTia32.efi, cloak32.dat, and related components)BOOTia32.efi: the ALRM payload format, XOR decryption, the RxPE custom PE loader, Authenticode hash verification against the revoked binary, and the analysis of what was changed versus what was left untoucheddecode_cloak.py, authenticode_hash.py, create_cloak.py)This is the companion repository documenting the original vulnerability that CVE-2026-79298 stems from. It contains:
Working on something similar? Researching UEFI, kernel security, exploitation, or another interesting security topic? If you need a hand developing an exploit, exploring a technique, or just want to exchange ideas, don't hesitate to reach out. I am always open to discussing research, helping where I can, and collaborating on interesting projects.
Feel free to contact me on LinkedIn.