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 to disable verification. Here, the bypass is - no user interaction, no visible output, no shell prompt.
gSecurity2The 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);
// Step 6: Jump to entry point
// NO SIGNATURE VERIFICATION ANYWHERE
EntryPoint = ImageBase + PeHeader->OptionalHeader.AddressOfEntryPoint;
((EFI_IMAGE_ENTRY_POINT)EntryPoint)(ImageHandle, SystemTable);
}
The difference between the firmware's LoadImage() and the custom loader is the critical security gap:
┌─────────────────────────────────────────────────────────────────────────┐
│ Firmware LoadImage() - How legitimate boot chains work │
│ │
│ bootx64.efi ──> LoadImage("shdmgr.ef_") │
│ │ │
│ ├── Parse PE/COFF headers │
│ ├── Verify Authenticode signature │
│ ├── Check signature against db (allowed) │
│ ├── Check hash against dbx (revoked) │
│ ├── Call gSecurity2->FileAuthenticationState() │
│ │ │ │
│ │ ├── Signature valid? ── YES ──> Load image │
│ │ └── Signature invalid? ── NO ──> REJECT │
│ └── StartImage() │
│ │
├─────────────────────────────────────────────────────────────────────────┤
│ Custom PE Loader - What shdloader.efi does │
│ │
│ shdloader.efi ──> OpenFile("shdmgr.ef_") │
│ │ │
│ ├── ReadFile() into buffer │
│ ├── Parse PE/COFF headers │
│ ├── Allocate memory │
│ ├── Copy sections │
│ ├── Apply .reloc relocations │
│ ├── *** NO SIGNATURE CHECK *** │
│ └── Jump to EntryPoint │
│ │
│ Result: ANY valid PE/COFF EFI application runs, signed or not │
└─────────────────────────────────────────────────────────────────────────┘
The custom PE loader is a simplified implementation and expects a specific PE/COFF layout. Binaries that do not conform are rejected with errors:
Reloc table overflows binary
Relocation failed
Invalid entry point
A binary missing any of these will be rejected by the custom loader.
| Field | Required Value | Reason |
|---|---|---|
| Machine | 0x8664 (x64) | The loader only supports x86-64 images |
| Subsystem | 10 (EFI Application) | Must be an EFI Application |
| .reloc section | .reloc must exist with valid base relocation entries | The loader performs its own image relocation. Without .reloc, it fails with "Reloc table overflows binary" |
| Relocation Directory | VirtualAddress != 0, Size != 0 (DATA_DIRECTORY[5]) | The directory entry must point to valid relocation data |
A verification script (Scripts/VerifyPE.py) is provided to check compatibility before deployment.
The structural parallel between UEFI BYOVUA and kernel BYOVD is exact, though CVE-2022-34302 represents the most direct form - the signed component itself loads unsigned code, rather than providing a primitive to disable verification:
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA - CVE-2022-34302 (Custom PE Loader) │
│ │
│ Signed Bootloader ──> Custom PE Loader ──> Load unsigned │
│ (trusted by (no sig check) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ UEFI BYOVUA - CVE-2022-34301/34303 (Shell + gSecurity2) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
CVE-2022-34302 is the most dangerous variant because the bypass is inherent to the bootloader's design - there is no intermediate step where the attacker needs to corrupt a security mechanism. The signed component directly loads unsigned code as its normal operation.
The signed shdloader.efi is placed on the EFI System Partition (ESP) as the default boot loader. Because it is signed by Microsoft's UEFI Driver Publisher certificate, Secure Boot validates and loads it without issue.
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── bootx64.efi (shdloader.efi) ← Signed by Microsoft Windows UEFI Driver Publisher
└── shdmgr.ef_ (PAYLOAD) ← Unsigned, loaded by shdloader's custom PE loader
When the system boots, the firmware:
bootx64.efi from the ESPLoadImage() which verifies the Authenticode signature against the Secure Boot databasedb → image is acceptedStartImage() to transfer execution to shdloader.efiOnce shdloader.efi has control, it prints a diagnostic message and immediately activates its custom PE/COFF loader:
Booting in insecure mode
The bootloader then:
\EFI\Boot\shdmgr.ef_ using the filesystem protocol.text, .data, .reloc, etc.) to the allocated memoryLoadAddress - ImageBase) and applies all base relocations from the .reloc sectionLoadAddress + AddressOfEntryPoint as the execution targetNo signature verification occurs at any point in this process. The loader does not call LoadImage(), does not invoke gSecurity2->FileAuthenticationState(), and does not check the db or dbx databases. The file is loaded purely based on structural validity.
If the file is not found, the bootloader reports:
Failed to open \EFI\Boot\shdmgr.ef_ - 800000000000000E
Failed to load image
The custom loader jumps to the entry point of shdmgr.ef_. The unsigned UEFI application now runs with:
The attack is completely silent. Unlike CVE-2022-34301 and CVE-2022-34303, which display a visible UEFI Shell prompt, this exploit produces no visual output beyond the "Booting in insecure mode" message (which, on a legitimate system, appears briefly and is quickly replaced by the OS boot screen). On headless systems (servers, IoT, industrial equipment), there is no indication whatsoever.
The attack is persistent by default. As long as shdloader.efi remains at \EFI\Boot\bootx64.efi and the attacker's payload remains at \EFI\Boot\shdmgr.ef_ on the ESP, the unsigned payload executes on every boot.
No startup.nsh script is needed. No gSecurity2 address needs to be recalculated across firmware updates. The custom PE loader loads whatever shdmgr.ef_ it finds, unconditionally.
The system continues to report Secure Boot as "enabled" - only the trust chain has been broken at the bootloader level. This makes the attack invisible to OS-level Secure Boot status queries and to any security software that relies on Secure Boot attestation.
Important: Persistence is broken only if the DBX is updated with the revocation entry for
shdloader.efi(KB5012170), which causes the firmware to rejectshdloader.efiitself before the custom loader ever activates.
The Exploit/ directory contains everything needed to build a compatible shdmgr.ef_:
Exploit/
|
├── README.md ← Build guide and PE/COFF requirements
|
├── PayloadShdmgr/
| |
│ ├── ForceReloc.nasm ← Force .reloc section generation
│ ├── shdmgr.ef_.c ← UEFI application source (EDK2)
│ ├── shdmgr.ef_.inf ← EDK2 module definition
│ ├── shdmgr.ef_.dsc ← EDK2 platform build configuration
│ └── shdmgr.ef_.dec ← EDK2 package declaration
|
└── Scripts/
└── VerifyPE.py ← PE/COFF compatibility verifier
The signed bootloader has been added to Microsoft's DBX revocation list via KB5012170 (August 2022). On updated systems, the bootloader will be rejected by Secure Boot before the custom PE loader ever activates.
For the lab environment, you need a system where:
The QEMU UEFI Research Environment provides an automated setup for this.
CVE-2022-34302 is simpler to exploit than CVE-2022-34301 and CVE-2022-34303:
| Aspect | CVE-2022-34302 (Custom Loader) | CVE-2022-34301/34303 (Shell) |
|---|---|---|
| Technique | Replace shdmgr.ef_ with payload | Corrupt gSecurity2 via mm command |
| Interaction | None (fully automatic) | Manual shell commands or startup.nsh |
| Visibility | Silent ("Booting in insecure mode") | Visible UEFI Shell prompt |
| Firmware dependency | None (payload is self-contained) | gSecurity2 address changes per firmware build |
| Complexity | Low (file replacement) | Medium (memory scanning and patching) |
| Stealth | High (no visual output on headless) | Low (shell visible on screen) |