themalwareguardian/uefi-security-research-howyar-sysreturn-netcopyPost CVE-2024-7344 analysis of Howyar SysReturn NetCopy - reverse engineering notes, vulnerable binaries, vendor correspondence, and proof-of-concept tooling for CVE-2026-79298 (IA-32 Secure Boot bypass via the RxPE custom PE loader in BOOTia32.efi).
Under the cloak of Secure Boot, some architectures sink deeper than the vulnerabilities that exposed them. Some binaries are revoked. Some patches are shipped. But deep below the surface, old habits leave traces. This is what remains when a vulnerability is disclosed, patched, and forgotten.
The findings documented in this repository have been assigned CVE-2026-79298.
During the coordinated disclosure process, the vendor confirmed that the remediation associated with CVE-2024-7344 only addressed the x64 boot path. The IA-32 boot path - including BOOTia32.efi distributed as part of the SysReturn NetCopy feature - was never included in the original remediation. As a result, the vulnerable IA-32 component continued to be distributed commercially until version 11.3.034 (July 2026).
The dedicated CVE repository links back here for the full technical depth: reverse engineering, binary analysis, vendor correspondence, reproduction artifacts, and proof-of-concept tooling.
Throughout 2026 I have been deep into UEFI security - bootkits development, Secure Boot bypasses, firmware exploitation, CVE analysis, developing offensive tooling, publishing research. It is the area I have chosen to specialise in and every week brings something new. Part of that work involves exploiting known CVEs in UEFI components. Part of it involves researching software that ships UEFI bootloaders but has received little public scrutiny. And part of it - the part this repository documents - involves asking a question that I think gets overlooked too often:
What does a product look like after a CVE?
Not during the patch rush. Not in the week the advisory drops. Eighteen months later, when the pressure is gone, when the researchers have moved on, when nobody is watching anymore.
This repository is my attempt to answer that question for one specific product: Howyar SysReturn NetCopy.
And I think what I found is going to surprise people.
Everything in security research connects to something else if you follow the threads far enough. This particular thread started at work. We were tasked with analysing the real-world risk of UEFI and bootkit attacks against a specific category of environment: educational centres. It sounds niche. It is not.
Here is the reality that most people outside this field do not fully appreciate. In a mid-sized city, there can easily be 70,000 or more shared devices deployed across schools - laptops and workstations used by students between eight and fifteen years old, running Linux distributions because Windows licensing at that scale is often prohibitive.
Now ask yourself: how many of those machines have Secure Boot properly enabled? The honest answer, in most places, is very few. And the reason is not negligence. It is operational reality.
Enabling Secure Boot properly in a Linux environment means signing every kernel. Every kernel update - and Linux kernel vulnerabilities have been coming fast in recent years - requires a new signed image to be deployed across every single machine. That means coordinated update pipelines, key management infrastructure, trained personnel, and ongoing maintenance across thousands of endpoints distributed across dozens of locations.
For organisations with those resources, it is manageable. For most school districts, it is not. There are simply not enough people, not enough budget, and not enough tooling to do it right at that scale. So Secure Boot stays disabled.
BIOS passwords do not get set - because rotating them across 70,000 machines with limited staff is impractical. And those machines sit there, fully exposed at the firmware level, used by hundreds of students every day.
What that actually means, from a security perspective, is that an attacker who understands UEFI exploitation can compromise one of those machines at the firmware layer - before the OS loads, before any security software starts, before any protection mechanism has a chance to intervene. A bootkit can persist across reboots, across OS reinstallations, across everything. I know this because I develop that kind of tooling myself. The techniques exist. They are not theoretical.
This is a known problem. It is widely acknowledged. And it is not going away soon.
The operational response to that problem - the thing that schools actually deploy instead of proper Secure Boot - is recovery software.
The idea is straightforward: whatever a student does during a session, everything returns to a known-clean state after the next reboot. Malware, configuration changes, broken system files, accidentally or intentionally deleted data - gone. This reduces maintenance costs dramatically and gives administrators a way to manage shared machines without needing perfect firmware-level security controls on every device.
When we started evaluating which products were being used in these environments, several names came up. One of them was Howyar SysReturn - a Taiwanese product specifically designed for educational deployments, with explicit support for school computer labs, shared workstations, and large-scale managed environments.
The moment I saw that name, I knew exactly what I wanted to do.
In January 2025, ESET Research published the disclosure of CVE-2024-7344 - a Secure Boot bypass affecting SysReturn and several other recovery products built on the same codebase.
The vulnerability was elegant in a deeply frustrating way. A Microsoft-signed UEFI application - trusted by the firmware, able to run even with Secure Boot enabled - implemented its own custom PE loader entirely from scratch. Instead of using the standard UEFI LoadImage and StartImage functions, which enforce Secure Boot signature verification, it parsed and executed EFI binaries manually from a file called cloak.dat. XOR-encrypted with a single-byte key. No signature check. Whatever was inside that file ran with full firmware-level trust.
Microsoft revoked the vulnerable binaries in the January 2025 Patch Tuesday update. The security industry moved on to the next thing. But I kept thinking about it.
Not because the vulnerability itself was unresolved - ESET documented it thoroughly and the revocation was clear. What kept pulling at me was a different question. The kind of question that only becomes answerable with time:
Did they actually fix it? Or did they just work around the pressure?
There is a difference. A real fix addresses the root cause - in this case, the use of a custom PE loader that bypasses Secure Boot. A workaround makes the immediate problem disappear while leaving the underlying architecture intact.
I wanted to know which one Howyar had done.
I contacted Howyar Technologies directly and requested an evaluation copy of SysReturn for a professional procurement assessment - which, given the professional context that created this research in the first place, was entirely accurate.
The vendor was helpful and responsive. They provided a full trial license, manuals, tutorial videos, and a complete evaluation package. They also answered detailed questions about Secure Boot compatibility, which turned out to be directly relevant to what I found later.
All of that correspondence is included in this repository, unedited.
I am not going to spoil the technical details here - that is what the Vulnerability Research directory is for, and I genuinely recommend reading it in full. But I will say this much.
UEFI is its own world. The developers who work in it are few. The security review processes that exist for application software or web services do not routinely reach firmware components. Bad practices, once established, tend to persist - not out of malice, but because the ecosystem is small, the scrutiny is rare, and the consequences of getting it wrong are often invisible to everyone except the handful of researchers paying attention.
What I found in SysReturn v11.2.031 - released in April 2026, more than fifteen months after Microsoft's revocation - is a clear example of exactly that dynamic.
The root cause was not fixed. The vulnerable binary was not replaced. What changed was operational: a different boot path for Secure Boot-enabled systems, leaving almost everything else untouched.
The custom PE loader - the RxPE component, named in the binary's own debug strings - is present in the April 2026 release, functioning identically to how it functioned in the version ESET analysed in 2024.
The Authenticode hash of the binary Howyar shipped in April 2026 matches, byte for byte, the hash that Microsoft revoked in January 2025.
I think that matters. I think people should know about it. And I think the technical documentation in this repository is detailed enough that anyone who wants to verify these findings themselves can do so.
| Directory | Description |
|---|---|
📚 00 Manual | Vendor manuals, brochures, and official product documentation provided by Howyar |
📦 01 Binaries | Key binaries extracted from the evaluation package for analysis |
📬 02 Disclosure | Full email correspondence with Howyar Technologies during the evaluation process |
🔬 03 Vulnerability Research | Reverse engineering, binary analysis, Authenticode verification, ALRM format analysis, scripts, and technical findings |
The technical story - the full reverse engineering of BOOTia32.efi, the ALRM payload format, the XOR decryption, the RxPE custom PE loader, the Authenticode hash match against the revoked binary, and the analysis of what Howyar actually changed versus what they left untouched - is all in:
If you want context on the CVE itself before diving into the post-"patch" analysis, the ESET advisory is a good reference. I also maintain a repository documenting CVE-2024-7344 and related UEFI vulnerabilities in more detail.
Start reading. The cloak is still there.
