themalwareguardian/cve-2022-34302Demonstrates CVE-2022-34302, a Secure Boot bypass via the New Horizon Datasys signed bootloader whose built-in custom PE/COFF loader executes unsigned UEFI applications.
New Horizon Datasys Reboot Restore Boot Loader - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Secure Boot bypass via signed bootloader with built-in custom PE/COFF loader that loads unsigned UEFI applications.
This repository demonstrates the BYOVUA (Bring Your Own Vulnerable UEFI Application) technique by exploiting CVE-2022-34302, a Secure Boot bypass vulnerability in the New Horizon Datasys boot loader.
Unlike the UEFI Shell-based vulnerabilities (CVE-2022-34301 and CVE-2022-34303), this bootloader does not expose a UEFI Shell. Instead, shdloader.efi implements its own custom PE/COFF loader that loads a second-stage binary (shdmgr.ef_) without using the firmware's LoadImage() function and without performing any signature verification. An attacker only needs to replace shdmgr.ef_ with any compatible UEFI application to achieve arbitrary code execution with Secure Boot enabled.
This is the most dangerous of the three vulnerabilities disclosed in the "One Bootloader to Load Them All" research. As Eclypsium noted: the bypass is built-in, completely silent, and leaves no visual indication on the screen - making it invisible even on systems with a monitor and undetectable on headless systems such as servers or industrial equipment.
BYOVUA is the UEFI equivalent of the BYOVD (Bring Your Own Vulnerable Driver) technique used at the kernel level. Instead of bringing a signed kernel driver with a vulnerability, the attacker brings a signed UEFI application that contains functionality capable of undermining Secure Boot.
Because shdloader.efi is signed with a Microsoft-trusted certificate, it is accepted by Secure Boot without question, making it trusted on any system that includes this certificate in its Secure Boot database (db) - which is virtually every UEFI-capable PC shipped in the last decade. Once running, its built-in custom PE loader provides the attacker with the ability to load and execute arbitrary unsigned code before the operating system loads, in an environment where modern security controls (ASLR, DEP, kernel protections) simply do not exist.
shdloader.efi is a UEFI boot loader distributed as part of New Horizon Datasys' system restore and recovery products (Reboot Restore Rx, RollBack Rx). Its role in the legitimate boot chain is to load a pre-OS management component (shdmgr.ef_) that handles snapshot and restore operations before the operating system starts.
| Property | Value |
|---|---|
| File | shdloader.efi = EFI/Boot/bootx64.efi |
| Vendor | New Horizon Datasys Inc |
| Product | Reboot Restore Rx / RollBack Rx |
| CVE | CVE-2022-34302 |
| Signing | Microsoft Windows UEFI Driver Publisher → Microsoft Corporation UEFI CA 2011 |
| Discovery | Eclypsium (Mickey Shkatov, Jesse Michael) - August 2022 |
| Presentation | DEF CON 30 - "One Bootloader to Load Them All" |
| Revocation | Added to DBX via Microsoft KB5012170 (August 2022) |
The vulnerability is a design flaw in the boot loader's architecture. Rather than using the firmware's LoadImage() and StartImage() boot services - which enforce Secure Boot signature verification - shdloader.efi implements its own custom PE/COFF loader that reads, relocates, and executes shdmgr.ef_ directly from raw disk bytes, completely bypassing the firmware's security checks.
The core issue: a signed binary that is trusted by Secure Boot contains its own image loader that does not verify signatures. The firmware validates shdloader.efi as signed, but once it is running, it loads shdmgr.ef_ without any verification whatsoever. Replacing shdmgr.ef_ with an arbitrary UEFI application results in that application running with full hardware access, while Secure Boot reports as enabled.
This is fundamentally different from CVE-2022-34301 and CVE-2022-34303, where the attacker needs to interact with a UEFI Shell and manually corrupt gSecurity2 to disable verification. Here, the bypass is automatic and silent - no user interaction, no visible output, no shell prompt.
The signed shdloader.efi contains its own implementation of a PE/COFF image loader. Instead of calling the firmware's LoadImage() boot service, which would invoke the Security Architectural Protocols and verify the image's signature against the Secure Boot database, the bootloader:
\EFI\Boot\shdmgr.ef_ using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.reloc section and applies base relocationsAt no point in this process does the loader verify the image's Authenticode signature, check the Secure Boot database (db/dbx), or invoke the EFI_SECURITY2_ARCH_PROTOCOL. The image is loaded purely based on its PE/COFF structural validity.
// Pseudocode of what shdloader.efi does internally
//
// NOTE: This is a simplified representation. The actual
// implementation was derived from reverse engineering.
EFI_STATUS LoadShdmgr(VOID)
{
// Step 1: Open the file
File = OpenFile(L"\\EFI\\Boot\\shdmgr.ef_");
// Step 2: Read raw bytes (no signature check)
ReadFile(File, &Buffer, &Size);
// Step 3: Parse PE/COFF headers
DosHeader = (EFI_IMAGE_DOS_HEADER *)Buffer;
PeHeader = (EFI_IMAGE_NT_HEADERS *)(Buffer + DosHeader->e_lfanew);
// Step 4: Allocate memory and copy sections
ImageBase = AllocatePages(...);
CopySections(ImageBase, Buffer, PeHeader);
// Step 5: Apply base relocations from .reloc
Delta = ImageBase - PeHeader->OptionalHeader.ImageBase;
ApplyRelocations(ImageBase, PeHeader, Delta);