// 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);

---

<div id='LoadImageVsCustomLoader'/>

### ***LoadImage 与自定义加载器***

固件的 `LoadImage()` 与自定义加载器之间的差异，正是关键的安全缺口：```
┌─────────────────────────────────────────────────────────────────────────┐
│  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          │
└─────────────────────────────────────────────────────────────────────────┘

当系统启动时，固件会：
1. 从 ESP 读取 `bootx64.efi`
2. 调用 `LoadImage()`，该函数会根据 Secure Boot 数据库验证 Authenticode 签名
3. 签名与 `db` 中的 Microsoft UEFI CA 2011 证书匹配 → 映像被接受
4. 调用 `StartImage()` 将执行权转移给 `shdloader.efi`

---

<div id='Phase2'/>

### ***阶段 2 - 自定义 PE 加载器激活***

一旦 `shdloader.efi` 获得控制权，它会打印一条诊断消息，并立即激活其自定义 PE/COFF 加载器：```
Booting in insecure mode

---

<div id='Phase3'/>

### ***阶段 3 - 未签名代码执行***

自定义加载器跳转到 `shdmgr.ef_` 的入口点。这个未签名的 UEFI 应用程序现在以以下条件运行：

- 完全硬件访问权限（直接内存、I/O 端口、PCI、MMIO）
- 尚未加载操作系统
- 无 ASLR、DEP 或内核保护
- 无 EDR 或端点安全监控
- 对任何后续操作系统查询均报告 Secure Boot 为**已启用**

该攻击完全静默。与 CVE-2022-34301 和 CVE-2022-34303 不同（它们会显示可见的 UEFI Shell 提示符），此漏洞利用除了 "Booting in insecure mode" 消息外不产生任何视觉输出（在合法系统上，该消息会短暂出现并很快被操作系统启动画面取代）。在无头系统（服务器、IoT、工业设备）上，则完全没有迹象。

---

<div id='Phase4'/>

### ***阶段 4 - 持久化***

该攻击默认具有持久性。只要 `shdloader.efi` 保留在 ESP 上的 `\EFI\Boot\bootx64.efi`，且攻击者的载荷保留在 `\EFI\Boot\shdmgr.ef_`，未签名的载荷就会在每次启动时执行。

不需要 `startup.nsh` 脚本。不需要在固件更新后重新计算 gSecurity2 地址。自定义 PE 加载器会无条件加载它找到的任何 `shdmgr.ef_`。

系统继续报告 Secure Boot 为 "已启用"——只有信任链在引导加载程序层面被破坏。这使得该攻击对操作系统级别的 Secure Boot 状态查询以及任何依赖 Secure Boot 认证的安全软件都不可见。

> **重要：** 只有当 DBX 更新了 `shdloader.efi` 的吊销条目（KB5012170）时，持久化才会被破坏，这会导致固件在自定义加载器激活之前就拒绝 `shdloader.efi` 本身。



---
---
---



<div id='Exploit'/>

## ***漏洞利用***

`Exploit/` 目录包含构建兼容 `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