themalwareguardian/cve-2022-34301Demonstrates CVE-2022-34301 Secure Boot bypass via Eurosoft signed UEFI Shell (esdiags.efi), using the mm command to nullify gSecurity2 and load unsigned UEFI applications.
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Secure Boot bypass via signed UEFI Shell and gSecurity2 corruption.
This repository demonstrates the BYOVUA (Bring Your Own Vulnerable UEFI Application) technique by exploiting CVE-2022-34301, a Secure Boot bypass vulnerability in the Eurosoft Pc-Check UEFI diagnostic environment.
In this case, the component trusted by Secure Boot is esdiags.efi, a UEFI Shell distributed as part of Eurosoft's Pc-Check UEFI hardware diagnostics product, signed by a certificate chain trusted by Microsoft's UEFI Third Party Certificate Authority. Once executed, this shell exposes the mm (memory modify) command and therefore provides arbitrary memory read and write capabilities during the pre-OS boot phase.
This primitive can then be used to locate and nullify the gSecurity2 global pointer in the DXE core. As a result, subsequent UEFI image verification is disabled, allowing unsigned UEFI applications, bootkits, to be loaded despite Secure Boot being enabled.
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 - in this case, a full UEFI Shell - that contains functionality capable of undermining Secure Boot.
Because the application is signed with a certificate chain trusted by Secure Boot, it is accepted without question, making it trusted on any system that includes the Microsoft UEFI Third Party Certificate Authority in its Secure Boot database (db) - which is virtually every UEFI-capable PC shipped in the last decade. Once running, its built-in commands provide the attacker with direct hardware and memory access that operates before the operating system loads, in an environment where modern security controls (ASLR, DEP, kernel protections) simply do not exist.
esdiags.efi is a UEFI Shell distributed as part of Eurosoft's Pc-Check UEFI, a pre-boot hardware diagnostics product used by PC manufacturers, service organizations, and IT teams for bare-metal system testing.
| Property | Value |
|---|---|
| File | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| Vendor | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| Signing | Microsoft Corporation UEFI CA 2011 (Third Party) |
| 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 not a bug - it is a design flaw. UEFI Shells are legitimate diagnostic tools that were never intended to run in Secure Boot environments. However, by signing them with a Microsoft-trusted certificate and distributing them as part of commercial products, the vendors inadvertently created a signed bypass for Secure Boot.
The core issue: a signed binary that is trusted by Secure Boot provides unrestricted memory read/write capabilities through its built-in commands. This combination breaks the entire Secure Boot trust model.
The mm (memory modify) command is a standard UEFI Shell built-in command that provides direct read and write access to system memory. It is documented in the UEFI Shell Specification (Section 5.3).
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parameter | Description |
|---|---|
Address | Target memory address |
Value | Value to write (omit for read-only) |
-w | Width: 1, 2, 4, or 8 bytes |
-MEM | System memory access |
-MMIO | Memory-mapped I/O |
-IO | I/O port access |
-n | Non-interactive (no prompt for next address) |
Secure Boot image verification in UEFI is enforced through the Security Architectural Protocols, defined in the UEFI Platform Initialization (PI) Specification.
The DXE core (DxeMain) maintains a global pointer called gSecurity2, which points to the EFI_SECURITY2_ARCH_PROTOCOL structure. This protocol contains a single function pointer - FileAuthenticationState - which is called by LoadImage() every time a UEFI image is loaded:
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
When LoadImage() is called, the DXE core checks:
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
By setting gSecurity2 = NULL, the if check fails and FileAuthenticationState is never called. Image verification is completely skipped - Secure Boot remains "enabled" but is no longer enforced. Unsigned UEFI applications can then be loaded freely.
For a deep technical understanding of this technique, including a purpose-built UEFI application that automatically locates and patches gSecurity2, see the companion project: Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption.
The structural parallel between UEFI BYOVUA and kernel BYOVD is exact: