Wack0/bitlocker-attacks
GitHub: Wack0/bitlocker-attacks
这是一个系统整理 BitLocker 加密攻击手法的开源技术知识库，涵盖硬件与软件层面的多种绕过与密钥提取方法。
Stars: 453 | Forks: 30
# BitLocker 攻击
一份公开的 BitLocker 攻击列表。任何具有攻击 BitLocker *潜力*但具体方法尚未公开的攻击（如 baton drop）均不在本文范围内。
大多数攻击针对的是 VMK 仅由 TPM 密封的情况，这是默认设置，也是[自动 BitLocker](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker) 与恢复密钥托管到 Microsoft 账户一起使用的配置。
默认情况下，从 Windows 8 开始，如果启用了 Secure Boot，则会使用 Secure Boot 完整性验证。
如果必须仅由 TPM 密封 VMK，此场景下最安全的配置是使用旧版完整性验证并配合 PCR 0、2、4、7、11（同时保持系统完全更新）。
请注意，这只能防御软件攻击。
## 目录
* [硬件攻击](#hardware-attacks)
* [软件攻击](#software-attacks)
## 硬件攻击
硬件攻击通常仅在攻击者对 VMK 仅由 TPM 密封的系统具有物理访问权限时才有用。
| 摘要 | 描述 | 已修复 | 公开披露时间 | 发现者 |
| --- | --- | --- | --- | --- |
| TPM 嗅探：bootmgr 与 TPM 明文通信 | Windows Boot Manager 与 TPM 进行明文通信，因此如果在 LPC 总线上使用独立 TPM 芯片（即非 fTPM 或"Pluton"/HSP），可以在该总线上使用逻辑分析仪来转储 VMK。
另请参阅 [Pulse Security 的博客文章](https://pulsesecurity.co.nz/articles/TPM-sniffing)、[LPC 嗅探器 Verilog 代码](https://github.com/denandz/lpc_sniffer_tpm)。 | 无，但固件 TPM 本身不受影响 | [2019 年 1 月](https://web.archive.org/web/20190125001757/https://twitter.com/marcan42/status/1080869868889501696) | marcan | | 硬件调试器：某些系统在启用硬件调试器之前未度量到 PCR7 | [TPG EFI 平台规范（TPM 相关）](https://trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf)（第 6.4 节）包含以下内容：
"如果平台提供可在 UEFI 环境之前使用的固件调试器模式，或者平台提供 UEFI 环境的调试器，则平台应在允许使用调试器之前将 EV_EFI_ACTION 事件扩展到 PCR[7] 中"
某些系统在启用某些硬件调试器（如 Intel DCI）之前未执行此度量。
因此，在此类易受攻击的系统上，可以使用 Secure Boot 绕过（在物理访问条件下，在 Secure Boot 仍然启用的情况下至少有两种方法）或硬件攻击（直接写入 SPI 闪存）来启用硬件调试器；然后在 `bootmgr!FvebUnsealCallback` 内设置断点（例如）即可转储 VMK。另请参阅 [DFRCE 2023 的文章](https://www.sciencedirect.com/science/article/pii/S266628172300015X)。 | 对于易受攻击的系统，无修复。
易受攻击系统的确切列表未知。 | 2023 年 3 月 | 巴西联邦警察 | | fTPM 故障注入：通过故障注入实现代码执行以完全破坏 fTPM 状态 | 如果实现 fTPM 的片上处理器/微控制器存在漏洞，可通过故障注入在启动早期获得代码执行权限，则整个 fTPM 状态可能被破坏，从而导致 VMK 被转储（等）。另请参阅 [研究文章](https://arxiv.org/abs/2304.14717)、[AMD PSP 的载荷等](https://github.com/PSPReverse/ftpm_attack) | IntelME：[2021 年 11 月 / Alder Lake](https://www.theregister.com/2022/08/12/intel_ups_protection_against_chip/)
AMD：未知，无？
其他（ARM64、ARMv7 等）：未知 | 2023 年 4 月 | 柏林工业大学 SecT 的 Hans Niklas Jacob、Christian Werling、Robert Buhren、Jean-Pierre Seifert | | 启动时 IOMMU 禁用：通过闪存转储/重写修改 UEFI 非易失性变量存储可在启动时禁用 IOMMU | 某些 UEFI 固件会根据变量数据在启动时不启用 IOMMU。通过转储闪存、修改相关变量并重写，可在启动时禁用 IOMMU，同时 TPM 非易失性状态仍然有效。此时，攻击者可以在 bootmgr 启动前使用 PCI DMA 覆盖 DMAR ACPI 表，进入安全模式，然后再次使用 PCI DMA 获取 SYSTEM shell。请参阅 [详细分析](https://www.mdsec.co.uk/2026/03/disabling-security-features-in-a-locked-bios/)。
尚不清楚这是哪个组件中的问题；该分析使用的是 Intel 系统，相关代码由 Intel 固件支持包提供。尚不清楚 AMD 对应组件（AGESA/CBS）是否也受影响。 | Intel 固件支持包：未知
AMD AGESA/CBS：未知 | 2026 年 3 月 | MDSec 的 Craig S. Blackie | ## 软件攻击 软件攻击通常是 `bootmgr` 中的漏洞，或其他某个启动应用程序中的漏洞，其中可利用内存中已派生的 BitLocker 密钥对任意卷进行利用。 如果在某个启动应用程序中可以获得代码执行权限，"恶意清理者"攻击者可能安装一个引导工具包（bootkit），该引导工具包本身会在内存中携带已派生的密钥（或仍可派生密钥时）运行，从而攻破使用密码或启动密钥替代或补充 TPM 的系统。 | 摘要 | 描述 | 已修复 | 公开披露时间 | 发现者 | | --- | --- | --- | --- | --- | | 启动环境在创建新密钥表时不清除旧密钥表 | 启动库初始化函数会接收一组标志。
如果设置了第 7 位（bootmgr 至少会如此），则忽略任何现有密钥表并创建新的。
现有密钥表不会被清除，仍保留在内存中。
这使得攻击者可以使用任意 `osdevice` 加载 bootmgr，然后利用 bootmgr 获取代码执行权限，或使用 RS2+ bootmgr（确保仅存在一个 Secure Boot 策略）加载 WinPE 并利用已知易受攻击的驱动程序来查找并转储密钥表。
使用旧版完整性验证可阻止此攻击，因为 BitLocker 分区元数据中的启动应用程序白名单会生效。 | 2022 年 1 月缓解（通过阻止在大多数情况下加载 bootmgr）。
2023 年 3 月随 build 25330 修复（在创建新密钥表之前映射并清除旧密钥表）。
**降级攻击仍可利用此漏洞。** | 2022 年 8 月（与 baton drop 一起）；2022 年 1 月发现。 | Rairii | | 旧版完整性验证关联选项实现错误 | **受影响的为旧版完整性验证（使用易受攻击的 bootmgr 时），Secure Boot 完整性验证完全不受影响**
BitLocker 旧版完整性验证遍历所有启动选项，确保它们存在、确保任何未知选项不存在，或通过哈希确保它们未被更改。
原始实现还尝试遍历关联选项，但使用了错误的偏移量。
这使得可以构造一个包含对 BitLocker 旧版完整性验证不可见的启动选项的 BCD。
许多危险选项，特别是 `debug`，可导致 BitLocker 密钥表被转储。
修复方法是在遍历关联选项时使用正确的偏移量。此漏洞为 CVE-2022-29127。 | 2022 年 5 月 | 2022 年 6 月（在 emfcamp 上，通过 bindiffing 发现） | Microsoft (WDG) 的 Matt Wesemann | | [危险关联](#dangerous-association)：旧版完整性验证关联选项实现错误（第二部分） | **受影响的为旧版完整性验证（使用易受攻击的 bootmgr 时），Secure Boot 完整性验证完全不受影响**
之前漏洞的修复不正确，仅检查了一层关联选项，而使用启动选项的代码会递归处理。
这使得可以构造一个包含对 BitLocker 旧版完整性验证不可见的启动选项的 BCD。
另请参阅 [公开披露](https://haqueers.com/@Rairii/109439636170607042)。
修复方法是像其他代码一样递归处理关联选项。此漏洞为 CVE-2022-22048。 | 2022 年 7 月 | 2022 年 12 月；2022 年 5 月对之前补丁进行 bindiffing 时发现 | Rairii | | [bitpixie](#bitpixie)：PXE 软重启不会从内存中清除已派生的 BitLocker 密钥 | **仅在 UEFI 系统上可利用（传统 BIOS 或 CSM 不可利用）。旧版完整性验证受影响（使用易受攻击的 bootmgr 时），Secure Boot 完整性验证也受影响**
从网络启动时允许 PXE 软重启，仅执行 `BS->LoadImage()` 和 `BS->StartImage()`。
调用 `BS->StartImage` 时，已派生的 BitLocker 密钥仍在内存中。
随后可从内存中转储这些密钥。
此外：BitLocker 密钥在加载启动应用程序的早期就已派生。如果从磁盘加载 PE 失败，则不执行完整性验证，已派生的密钥仍保留在内存中。
此时可执行 PXE 软重启，因此这也绕过了旧版完整性验证。
另请参阅 [公开披露](https://haqueers.com/@Rairii/109817927668949732)。
修复方法是在调用 `bootmgr!PxeSoftReboot` 之前在 `bootmgr!BlNetSoftReboot` 中清除 BitLocker 密钥表。此漏洞为 CVE-2023-21563。 | 2022 年 11 月（build 25236）；2023 年 1 月（向后移植）
在使用 Secure Boot 完整性验证的情况下，**降级攻击仍可利用此漏洞。** | 2023 年 2 月，2022 年 8 月发现 | Rairii | | [按键解密](#push-button-decrypt)：WinRE 重置可在解密过程中被中断，使攻击者获取 shell 以禁用密钥保护器 | **Windows Server 不受影响，因为不支持重置功能。旧版完整性验证和 Secure Boot 完整性验证均受影响（使用易受攻击的 winre 映像时）**
启动到系统的 WinRE 时，会为关联的 osvolume 派生密钥。在执行按键重置（带数据删除）时，这些密钥被允许保留在内存中。
启动"仅删除我的文件"重置将在约 98% 完成时开始解密驱动器。
此时重启将导致重新进入 WinRE，显示错误和一个重启按钮。
重启后，Windows 安装程序会进入升级界面。在此处按 `Shift+F10` 可获取 shell。
此 shell 足以暂停解密并删除所有密钥保护器，然后可使用明文 VMK 解密 FVEK，再结合之前制作的磁盘映像使用。
修复方法是在重置前要求提供 BitLocker 恢复密钥。此漏洞为 CVE-2022-41099。 | 2022 年 11 月（winre 映像需手动修补） | 2023 年 5 月 | 未知 | | [可疑磁盘](https://wack0.github.io/dubiousdisk/)：在启动环境中实现任意代码执行 | 利用此漏洞或其变种可在启动环境中实现任意代码执行，因此可以通过在 bootmgr 中执行任意代码来派生 BitLocker 密钥，或通过在某个其他启动应用程序中执行任意代码来转储 BitLocker 密钥表。
此漏洞及其变种为 CVE-2022-30203、CVE-2023-21560、CVE-2023-28269、CVE-2023-28249、（未知）和 CVE-2024-38065。 | 2022 年 7 月至 2024 年 7 月期间多次修复。**降级攻击仍可利用这些漏洞。** | 2024 年 6 月（公开分析，遗漏了 2024 年 7 月修复的变种）；最初于 2021 年 8 月发现，2022 年 1 月至 3 月期间被利用 | Rairii | | CrashXTS：加密攻击，允许精确破坏 SYSTEM 休眠文件以明文写入 | BitLocker 使用 AES-XTS。通过对加密分区获取多个映像，可以找到 `SYSTEM` 配置单元的偏移量，进而找到 `SYSTEM\ControlSet001\Control\CrashControl` 键的偏移量，并以某种方式破坏该配置单元，使得写入磁盘时用于加密休眠文件的筛选器驱动程序不被加载。因此，可以使系统休眠，再次转储分区，并获得完整的明文（压缩）转储，包括卷密钥。
另请参阅 [公开分析](https://dfir.ru/2025/01/20/cve-2025-21210-aka-crashxts-a-practical-randomization-attack-against-bitlocker/)。
修复方法是当所需的筛选器驱动程序不存在时触发 bugcheck。此漏洞为 CVE-2025-21210。 | 2025 年 1 月 | 2025 年 1 月 | Maxim Suhanov | | 配置单元逃逸：systemdatadevice 元素导致 winload 使用攻击者指定的 SYSTEM 配置单元 | 从 Windows 10（th1）开始，winload 新增了对 `systemdatadevice` 元素的支持。如果存在此元素，winload 将从该设备读取 SYSTEM 配置单元而非 osdevice。
因此，攻击者可以从 WinPE 获取 SYSTEM 配置单元，修改 Setup!CmdLine 为 cmd.exe，并使 winload 在启动 WinRE 时使用此配置单元。
此后启动 WinRE 时，如果已派生密钥，则会打开一个携带 osvolume BitLocker 密钥的 SYSTEM shell；从而实现 BitLocker 绕过。
修复方法是移除从 systemdatadevice 加载 SYSTEM 配置单元的能力。此漏洞为 CVE-2024-20666。 | 2024 年 1 月（winre 映像需手动修补） | 2025 年 2 月；2023 年 3 月发现 | Rairii | | 配置单元逃逸 2：利用 systemdatadevice 元素的替代方法，可通过降级攻击利用 | 配置单元逃逸的修复更新了 winload。
然而，较早的（未修复的）winload 版本**可能**仍可运行以启动其对应的主版本 Windows（并非每个版本在实践中都可行）。
因此，攻击者可以引入旧版 winload，修改 BCD 以从该版本启动，并重复攻击，但必须使用不同的利用方法。
**BCD 中必须设置 `winpe` 元素（否则 BitLocker 加密的 osvolume 中的 SYSTEM 配置单元将被破坏！）**
此处可用的 SYSTEM 配置单元来自相同主版本 Windows 的 `install.wim` 映像（非 WinPE/WinRE）。Win32 子系统将无法完全初始化，但可以在 `ControlSet001\Control\Session Manager!SetupExecute` 中配置 smss，以在内存中携带已派生密钥的情况下实现任意原生子系统代码执行（SYSTEM 权限）。
修复方法是在启用 Secure Boot 时由 bootmgr 清除 `systemdatadevice` 元素，但该修复仅应用于 PCA 2023 签名的 bootmgr_ex，因此**在未启用 KB5025885 缓解措施的情况下，此漏洞仍然存在且未修复。** 此漏洞为 CVE-2025-21213。 | 2025 年 1 月，仅在 PCA2023 签名的 bootmgr_ex 中 | 2025 年 2 月；2024 年 1 月发现（在原始修复之后） | Rairii | | 启动环境加载 ramdisk 时不检查 SDI，而 SDI 包含所用 WIM 的偏移量 | 加载 ramdisk 时，启动环境（及 NT `wimfsf.sys`）从 SDI 文件（如果存在）获取所用 WIM 的偏移量，且不对所使用的 SDI 文件进行验证。因此，可以在恢复序列中使用精心构造的 SDI 文件，以加载携带 osdevice BitLocker 密钥的任意 WinPE WIM。
修复方法是检查计算出的 WIM 偏移量是否等于 WIM 的实际加载偏移量，如果不相等则返回 STATUS_INVALID_IMAGE_FORMAT。此漏洞为 CVE-2025-48804。 | 2025 年 7 月 | 2025 年 8 月（在 Black Hat 上） | Microsoft (MORSE) 的 Alon Leviev 和 Netanel Ben Simon | | [YellowKey](https://github.com/Nightmare-Eclipse/YellowKey) 又名 trans 写入（[镜像](YellowKey-main.zip)，密码：`bitlocker`）：位于一个卷上的文件系统事务文件可以影响另一个卷上的文件 | Germanium 引入了一种新的文件系统事务功能（与 NTFS 事务无关）。此功能的日志位于磁盘上，由 `fstx.dll`（服务堆栈的一部分）解析，在 WinPE 中仅由新的原生可执行文件 `autofstx.exe`（"启动时 FsTx 更新恢复工具" - "此工具在启动时恢复失败的 FsTx 更新。"）加载，smss 因注册表项而运行它。
这些日志包含完整 NT 路径，因此可以影响另一个卷上的文件。
这可以在启动 WinRE 时配合连接的可移动驱动器（NTFS 格式）使用，以删除 ramdisk 上的 `winpeshl.ini`。删除此文件后，如果按住 Ctrl 键，`winpeshl.exe` 将启动一个 SYSTEM shell，内存中携带已派生的 osdevice BitLocker 密钥。
另请参阅 [Will Dormann 的补充分析](https://infosec.exchange/@wdormann/116565129854382214)。此漏洞为 CVE-2026-45585。 | 无 | 2026 年 5 月 | Nightmare-Eclipse | | [内存泄漏](#ram-leak)：启动环境对 ramdisk 创建设备没有限制 | 当配置为创建 ramdisk 时，要加载的文件和加载设备在 BCD 中指定。
启动环境对传入的设备没有检查，因此允许使用 BitLocker 加密的分区，前提是密钥可以被派生。
因此，攻击者可以使用来自 BitLocker 加密分区的任意文件设置 ramdisk，即使已派生的 BitLocker 密钥被清除，文件内容仍将保留在 RAM 中，可在之后转储。
此外，攻击者可以利用此方法确定某个文件是否存在于 BitLocker 加密的 OS 分区上。
有价值的目标包括：休眠文件（包含已派生的 BitLocker 密钥，且经过压缩，应能完全放入 RAM，尤其是在登录屏幕注销后休眠的情况下）、页面文件、SYSTEM 和 SAM 配置单元、任何第三方服务或驱动程序（从 SYSTEM 配置单元中识别）以检查漏洞。 | 无。MSRC 因误解而将其关闭，认为优先级低。 | 2026 年 5 月，最初于 2025 年 3 月发现。 | Rairii | ### 危险关联 易受攻击的系统已安装 2022 年 5 月或 2022 年 6 月的更新，但未安装任何后续更新。 关联选项 GUID 是哈希数据的一部分，因此所使用的设备元素必须标记为未验证。 在 Windows 7 及以下版本中没有可用的元素（尽管在使用自定义非默认设置时仍可能可行）。 在 Windows 8 及以上版本中，`osloader!osdevice` 默认未经验证，因此可以利用。 最简单的利用方法是使用 BCD 原始设备编辑器 [bcdeditmod](https://github.com/Wack0/bcdeditmod)，不过手动编辑 BCD 注册表配置单元也是可行的（自行研究）。 利用步骤包括： * 从目标设备获取 BCD，创建两个设备元素 * 将 `{default}` 中的 osdevice 复制到第一个 * 在 `{default}!osdevice` 中将关联选项 GUID 设置为第一个设备元素 * 在 `{first}!osdevice` 中将关联选项 GUID 设置为第二个设备元素 * 在第二个设备元素中设置任意"危险"选项（如 `debug`） * 使用该 BCD 和相同的 `bootmgfw` 二进制文件启动目标设备 ### bitpixie 此漏洞已存在超过 17 年，已知最早引入该漏洞的版本为 2005 年 10 月的 `6.0.5231.2 (winmain_idx03.051004-2120)`。 在使用 Secure Boot 完整性验证的情况下，降级攻击仍可利用此漏洞。 设置一个 PXE 启动服务器，其中包含易受攻击的 `bootmgfw.efi`（在使用旧版完整性验证的情况下，必须使用目标设备的 `bootmgfw.efi`），并为 EFI 启动正确重命名。 对于 BCD，设置一个默认条目，其中 `device` 为 BitLocker 加密的 osdevice；`path` 为 `"\"`；以及一个恢复序列。 恢复序列应指向单个 `startup` 条目，其中 `device` 为 boot，`path` 指向要运行的 EFI 应用程序（来自 PXE 服务器）；且 `pxesoftreboot` 已启用。 当 Secure Boot 禁用时，该 EFI 应用程序可以是一个扫描物理内存以查找 BitLocker 密钥表进行转储的应用程序。 当 Secure Boot 启用时，该 EFI 应用程序可以使用已知的 Secure Boot 绕过（如果需要，需要物理访问）。 要以这种方式利用 Windows 启动应用程序，需要用 PXE 服务器上的第二个 BCD 替换 BCD。 这意味着在 `bootmgr` 启动期间按箭头键以强制显示启动菜单；然后在此时替换 PXE 服务器上的 BCD。 ### 按键解密 利用步骤包括： * **将 BitLocker 保护的 osvolume 转储为磁盘映像。** 此获取 FVEK 的方法会导致实际数据丢失！ * 使用任何方式启动到 WinRE（如果需要可通过启动修复强制启动，或直接设置 bootsequence BCD 元素等）。 * 开始重置（疑难解答 -> 重置此电脑 -> 删除所有内容）。选择"本地重新安装"更快。确保选择"仅删除我的文件"。 * 选择"保留文件"将要求提供恢复密钥。 * 如果系统的 WinRE 不易受攻击，也会要求提供恢复密钥。 * 当重置达到约 98% 时，强制关闭系统（按住电源按钮 7 秒等）。 * 重新开机，系统应再次启动到 WinRE 并显示错误。确认错误后应会重启。 * 当看到蓝色"正在更新"屏幕时，按 Shift+F10 进入 shell。 * 执行 `manage-bde -pause C:`，然后执行 `manage-bde -protectors -delete C:` * 再次强制关闭系统。 此时，磁盘上的 BitLocker 元数据将包含明文 VMK。 将其转储，并使用该 VMK 解密 FVEK。 解密后的 FVEK 可用于之前制作的磁盘映像来解密分区。 请注意：我仅在非常特定的情况下（仅 TPM 的 BitLocker，无恢复密钥）在 Windows 10 上成功利用了此问题。 然而，[其他人已使用 Windows 11（Nickel）上易受攻击的 WinRE 成功利用了此问题](https://blog.scrt.ch/2023/08/14/cve-2022-41099-analysis-of-a-bitlocker-drive-encryption-bypass/)。 ### 内存泄漏 据我所知，此漏洞自引导管理器存在以来就一直存在——最早可追溯至 2005 年 6 月的 `6.0.5098.0 (winmain_beta1.050628-1740)`，尽管该版本早于 BCD，因此在早期版本中的利用方式会有所不同。相关代码似乎更早之前就已存在（ramdisk 相关代码在 2005 年 4 月的 build 5048 中似乎相同），但 build 5098 是最早存在某种形式 BitLocker 的已转储版本。 要利用此漏洞，需要像 bitpixie 一样设置一个默认条目和一个恢复序列。这是为了在加载文件时为 OS 设备派生密钥。 恢复序列必须有一个额外的设备条目来设置 ramdisk。使用 [bcdeditmod](https://github.com/Wack0/bcdeditmod) 进行设置。在此处使用自定义元素，如 `custom:21100000`。此处使用的设备条目示例如下：`!raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]]` - 你需要将此处 `part2` 块设备替换为目标系统 BCD 中的对应设备。 然后可以使用任何适合你的方法从内存中转储文件。我倾向于通过高级选项菜单使用旧版 winload 加载自签名的 mcupdate，但也有其他选择（例如 PXE 软重启进入第三方操作系统；在 WinPE 中通过使用 bugcheck 或已知易受攻击的驱动程序进行内存转储是可行的，但 winload 会在 NT 内存映射中将该内存区域标记为空闲，因此如果不通过 winload 中的其他设置将该内存标记为坏块等，该区域可能会被覆盖）。 我首选方法的[概念验证实现](ramleak.zip)包含在此仓库中的 `ramleak.zip` 中。请阅读附带的 readme 以获取使用说明。 感谢 Maxim Suhanov，这是受到阅读 CrashXTS 分析并想出其他可能转储 `hiberfil.sys` 的方法的启发。 现在谈谈我对此漏洞和 yellowkey 的个人看法： 这是我第一次在向 MSRC 提交时遇到真正的问题，主要是由于他们对 Secure Boot 的误解。鉴于其他 BitLocker 0day 被公开，我决定现在发布这个，我已经憋了将近一年了，一直在纠结该怎么处理。 与 yellowkey 不同，我不会夸大其词地称之为"后门"，在我看来 yellowkey 并不是后门，相关组件与 WinPE 有关（并非 WinRE 特有），那里主要的"漏洞"是删除 winpeshl.ini 以到达该代码路径，我完全理解为什么 MS 认为在 WinRE+BitLocker 场景下删除它是不可能的。 鉴于从 BitLocker 加密分区加载 ramdisk 实际上是启动环境中的一个功能，尽管我必须使用现有的技巧才能让它实际运作，但如果其他人愿意，他们也可以说这是后门，但我不至于那么极端。启动环境很复杂（而且还在不断增大，最新的 `bootmgfw_ex.efi` 不再适合 2.88MB 的映像——一个时代的终结），由于某些功能之间的交互方式，已经发现了多个漏洞。
另请参阅 [Pulse Security 的博客文章](https://pulsesecurity.co.nz/articles/TPM-sniffing)、[LPC 嗅探器 Verilog 代码](https://github.com/denandz/lpc_sniffer_tpm)。 | 无，但固件 TPM 本身不受影响 | [2019 年 1 月](https://web.archive.org/web/20190125001757/https://twitter.com/marcan42/status/1080869868889501696) | marcan | | 硬件调试器：某些系统在启用硬件调试器之前未度量到 PCR7 | [TPG EFI 平台规范（TPM 相关）](https://trustedcomputinggroup.org/wp-content/uploads/TCG_EFI_Platform_1_22_Final_-v15.pdf)（第 6.4 节）包含以下内容：
"如果平台提供可在 UEFI 环境之前使用的固件调试器模式，或者平台提供 UEFI 环境的调试器，则平台应在允许使用调试器之前将 EV_EFI_ACTION 事件扩展到 PCR[7] 中"
某些系统在启用某些硬件调试器（如 Intel DCI）之前未执行此度量。
因此，在此类易受攻击的系统上，可以使用 Secure Boot 绕过（在物理访问条件下，在 Secure Boot 仍然启用的情况下至少有两种方法）或硬件攻击（直接写入 SPI 闪存）来启用硬件调试器；然后在 `bootmgr!FvebUnsealCallback` 内设置断点（例如）即可转储 VMK。另请参阅 [DFRCE 2023 的文章](https://www.sciencedirect.com/science/article/pii/S266628172300015X)。 | 对于易受攻击的系统，无修复。
易受攻击系统的确切列表未知。 | 2023 年 3 月 | 巴西联邦警察 | | fTPM 故障注入：通过故障注入实现代码执行以完全破坏 fTPM 状态 | 如果实现 fTPM 的片上处理器/微控制器存在漏洞，可通过故障注入在启动早期获得代码执行权限，则整个 fTPM 状态可能被破坏，从而导致 VMK 被转储（等）。另请参阅 [研究文章](https://arxiv.org/abs/2304.14717)、[AMD PSP 的载荷等](https://github.com/PSPReverse/ftpm_attack) | IntelME：[2021 年 11 月 / Alder Lake](https://www.theregister.com/2022/08/12/intel_ups_protection_against_chip/)
AMD：未知，无？
其他（ARM64、ARMv7 等）：未知 | 2023 年 4 月 | 柏林工业大学 SecT 的 Hans Niklas Jacob、Christian Werling、Robert Buhren、Jean-Pierre Seifert | | 启动时 IOMMU 禁用：通过闪存转储/重写修改 UEFI 非易失性变量存储可在启动时禁用 IOMMU | 某些 UEFI 固件会根据变量数据在启动时不启用 IOMMU。通过转储闪存、修改相关变量并重写，可在启动时禁用 IOMMU，同时 TPM 非易失性状态仍然有效。此时，攻击者可以在 bootmgr 启动前使用 PCI DMA 覆盖 DMAR ACPI 表，进入安全模式，然后再次使用 PCI DMA 获取 SYSTEM shell。请参阅 [详细分析](https://www.mdsec.co.uk/2026/03/disabling-security-features-in-a-locked-bios/)。
尚不清楚这是哪个组件中的问题；该分析使用的是 Intel 系统，相关代码由 Intel 固件支持包提供。尚不清楚 AMD 对应组件（AGESA/CBS）是否也受影响。 | Intel 固件支持包：未知
AMD AGESA/CBS：未知 | 2026 年 3 月 | MDSec 的 Craig S. Blackie | ## 软件攻击 软件攻击通常是 `bootmgr` 中的漏洞，或其他某个启动应用程序中的漏洞，其中可利用内存中已派生的 BitLocker 密钥对任意卷进行利用。 如果在某个启动应用程序中可以获得代码执行权限，"恶意清理者"攻击者可能安装一个引导工具包（bootkit），该引导工具包本身会在内存中携带已派生的密钥（或仍可派生密钥时）运行，从而攻破使用密码或启动密钥替代或补充 TPM 的系统。 | 摘要 | 描述 | 已修复 | 公开披露时间 | 发现者 | | --- | --- | --- | --- | --- | | 启动环境在创建新密钥表时不清除旧密钥表 | 启动库初始化函数会接收一组标志。
如果设置了第 7 位（bootmgr 至少会如此），则忽略任何现有密钥表并创建新的。
现有密钥表不会被清除，仍保留在内存中。
这使得攻击者可以使用任意 `osdevice` 加载 bootmgr，然后利用 bootmgr 获取代码执行权限，或使用 RS2+ bootmgr（确保仅存在一个 Secure Boot 策略）加载 WinPE 并利用已知易受攻击的驱动程序来查找并转储密钥表。
使用旧版完整性验证可阻止此攻击，因为 BitLocker 分区元数据中的启动应用程序白名单会生效。 | 2022 年 1 月缓解（通过阻止在大多数情况下加载 bootmgr）。
2023 年 3 月随 build 25330 修复（在创建新密钥表之前映射并清除旧密钥表）。
**降级攻击仍可利用此漏洞。** | 2022 年 8 月（与 baton drop 一起）；2022 年 1 月发现。 | Rairii | | 旧版完整性验证关联选项实现错误 | **受影响的为旧版完整性验证（使用易受攻击的 bootmgr 时），Secure Boot 完整性验证完全不受影响**
BitLocker 旧版完整性验证遍历所有启动选项，确保它们存在、确保任何未知选项不存在，或通过哈希确保它们未被更改。
原始实现还尝试遍历关联选项，但使用了错误的偏移量。
这使得可以构造一个包含对 BitLocker 旧版完整性验证不可见的启动选项的 BCD。
许多危险选项，特别是 `debug`，可导致 BitLocker 密钥表被转储。
修复方法是在遍历关联选项时使用正确的偏移量。此漏洞为 CVE-2022-29127。 | 2022 年 5 月 | 2022 年 6 月（在 emfcamp 上，通过 bindiffing 发现） | Microsoft (WDG) 的 Matt Wesemann | | [危险关联](#dangerous-association)：旧版完整性验证关联选项实现错误（第二部分） | **受影响的为旧版完整性验证（使用易受攻击的 bootmgr 时），Secure Boot 完整性验证完全不受影响**
之前漏洞的修复不正确，仅检查了一层关联选项，而使用启动选项的代码会递归处理。
这使得可以构造一个包含对 BitLocker 旧版完整性验证不可见的启动选项的 BCD。
另请参阅 [公开披露](https://haqueers.com/@Rairii/109439636170607042)。
修复方法是像其他代码一样递归处理关联选项。此漏洞为 CVE-2022-22048。 | 2022 年 7 月 | 2022 年 12 月；2022 年 5 月对之前补丁进行 bindiffing 时发现 | Rairii | | [bitpixie](#bitpixie)：PXE 软重启不会从内存中清除已派生的 BitLocker 密钥 | **仅在 UEFI 系统上可利用（传统 BIOS 或 CSM 不可利用）。旧版完整性验证受影响（使用易受攻击的 bootmgr 时），Secure Boot 完整性验证也受影响**
从网络启动时允许 PXE 软重启，仅执行 `BS->LoadImage()` 和 `BS->StartImage()`。
调用 `BS->StartImage` 时，已派生的 BitLocker 密钥仍在内存中。
随后可从内存中转储这些密钥。
此外：BitLocker 密钥在加载启动应用程序的早期就已派生。如果从磁盘加载 PE 失败，则不执行完整性验证，已派生的密钥仍保留在内存中。
此时可执行 PXE 软重启，因此这也绕过了旧版完整性验证。
另请参阅 [公开披露](https://haqueers.com/@Rairii/109817927668949732)。
修复方法是在调用 `bootmgr!PxeSoftReboot` 之前在 `bootmgr!BlNetSoftReboot` 中清除 BitLocker 密钥表。此漏洞为 CVE-2023-21563。 | 2022 年 11 月（build 25236）；2023 年 1 月（向后移植）
在使用 Secure Boot 完整性验证的情况下，**降级攻击仍可利用此漏洞。** | 2023 年 2 月，2022 年 8 月发现 | Rairii | | [按键解密](#push-button-decrypt)：WinRE 重置可在解密过程中被中断，使攻击者获取 shell 以禁用密钥保护器 | **Windows Server 不受影响，因为不支持重置功能。旧版完整性验证和 Secure Boot 完整性验证均受影响（使用易受攻击的 winre 映像时）**
启动到系统的 WinRE 时，会为关联的 osvolume 派生密钥。在执行按键重置（带数据删除）时，这些密钥被允许保留在内存中。
启动"仅删除我的文件"重置将在约 98% 完成时开始解密驱动器。
此时重启将导致重新进入 WinRE，显示错误和一个重启按钮。
重启后，Windows 安装程序会进入升级界面。在此处按 `Shift+F10` 可获取 shell。
此 shell 足以暂停解密并删除所有密钥保护器，然后可使用明文 VMK 解密 FVEK，再结合之前制作的磁盘映像使用。
修复方法是在重置前要求提供 BitLocker 恢复密钥。此漏洞为 CVE-2022-41099。 | 2022 年 11 月（winre 映像需手动修补） | 2023 年 5 月 | 未知 | | [可疑磁盘](https://wack0.github.io/dubiousdisk/)：在启动环境中实现任意代码执行 | 利用此漏洞或其变种可在启动环境中实现任意代码执行，因此可以通过在 bootmgr 中执行任意代码来派生 BitLocker 密钥，或通过在某个其他启动应用程序中执行任意代码来转储 BitLocker 密钥表。
此漏洞及其变种为 CVE-2022-30203、CVE-2023-21560、CVE-2023-28269、CVE-2023-28249、（未知）和 CVE-2024-38065。 | 2022 年 7 月至 2024 年 7 月期间多次修复。**降级攻击仍可利用这些漏洞。** | 2024 年 6 月（公开分析，遗漏了 2024 年 7 月修复的变种）；最初于 2021 年 8 月发现，2022 年 1 月至 3 月期间被利用 | Rairii | | CrashXTS：加密攻击，允许精确破坏 SYSTEM 休眠文件以明文写入 | BitLocker 使用 AES-XTS。通过对加密分区获取多个映像，可以找到 `SYSTEM` 配置单元的偏移量，进而找到 `SYSTEM\ControlSet001\Control\CrashControl` 键的偏移量，并以某种方式破坏该配置单元，使得写入磁盘时用于加密休眠文件的筛选器驱动程序不被加载。因此，可以使系统休眠，再次转储分区，并获得完整的明文（压缩）转储，包括卷密钥。
另请参阅 [公开分析](https://dfir.ru/2025/01/20/cve-2025-21210-aka-crashxts-a-practical-randomization-attack-against-bitlocker/)。
修复方法是当所需的筛选器驱动程序不存在时触发 bugcheck。此漏洞为 CVE-2025-21210。 | 2025 年 1 月 | 2025 年 1 月 | Maxim Suhanov | | 配置单元逃逸：systemdatadevice 元素导致 winload 使用攻击者指定的 SYSTEM 配置单元 | 从 Windows 10（th1）开始，winload 新增了对 `systemdatadevice` 元素的支持。如果存在此元素，winload 将从该设备读取 SYSTEM 配置单元而非 osdevice。
因此，攻击者可以从 WinPE 获取 SYSTEM 配置单元，修改 Setup!CmdLine 为 cmd.exe，并使 winload 在启动 WinRE 时使用此配置单元。
此后启动 WinRE 时，如果已派生密钥，则会打开一个携带 osvolume BitLocker 密钥的 SYSTEM shell；从而实现 BitLocker 绕过。
修复方法是移除从 systemdatadevice 加载 SYSTEM 配置单元的能力。此漏洞为 CVE-2024-20666。 | 2024 年 1 月（winre 映像需手动修补） | 2025 年 2 月；2023 年 3 月发现 | Rairii | | 配置单元逃逸 2：利用 systemdatadevice 元素的替代方法，可通过降级攻击利用 | 配置单元逃逸的修复更新了 winload。
然而，较早的（未修复的）winload 版本**可能**仍可运行以启动其对应的主版本 Windows（并非每个版本在实践中都可行）。
因此，攻击者可以引入旧版 winload，修改 BCD 以从该版本启动，并重复攻击，但必须使用不同的利用方法。
**BCD 中必须设置 `winpe` 元素（否则 BitLocker 加密的 osvolume 中的 SYSTEM 配置单元将被破坏！）**
此处可用的 SYSTEM 配置单元来自相同主版本 Windows 的 `install.wim` 映像（非 WinPE/WinRE）。Win32 子系统将无法完全初始化，但可以在 `ControlSet001\Control\Session Manager!SetupExecute` 中配置 smss，以在内存中携带已派生密钥的情况下实现任意原生子系统代码执行（SYSTEM 权限）。
修复方法是在启用 Secure Boot 时由 bootmgr 清除 `systemdatadevice` 元素，但该修复仅应用于 PCA 2023 签名的 bootmgr_ex，因此**在未启用 KB5025885 缓解措施的情况下，此漏洞仍然存在且未修复。** 此漏洞为 CVE-2025-21213。 | 2025 年 1 月，仅在 PCA2023 签名的 bootmgr_ex 中 | 2025 年 2 月；2024 年 1 月发现（在原始修复之后） | Rairii | | 启动环境加载 ramdisk 时不检查 SDI，而 SDI 包含所用 WIM 的偏移量 | 加载 ramdisk 时，启动环境（及 NT `wimfsf.sys`）从 SDI 文件（如果存在）获取所用 WIM 的偏移量，且不对所使用的 SDI 文件进行验证。因此，可以在恢复序列中使用精心构造的 SDI 文件，以加载携带 osdevice BitLocker 密钥的任意 WinPE WIM。
修复方法是检查计算出的 WIM 偏移量是否等于 WIM 的实际加载偏移量，如果不相等则返回 STATUS_INVALID_IMAGE_FORMAT。此漏洞为 CVE-2025-48804。 | 2025 年 7 月 | 2025 年 8 月（在 Black Hat 上） | Microsoft (MORSE) 的 Alon Leviev 和 Netanel Ben Simon | | [YellowKey](https://github.com/Nightmare-Eclipse/YellowKey) 又名 trans 写入（[镜像](YellowKey-main.zip)，密码：`bitlocker`）：位于一个卷上的文件系统事务文件可以影响另一个卷上的文件 | Germanium 引入了一种新的文件系统事务功能（与 NTFS 事务无关）。此功能的日志位于磁盘上，由 `fstx.dll`（服务堆栈的一部分）解析，在 WinPE 中仅由新的原生可执行文件 `autofstx.exe`（"启动时 FsTx 更新恢复工具" - "此工具在启动时恢复失败的 FsTx 更新。"）加载，smss 因注册表项而运行它。
这些日志包含完整 NT 路径，因此可以影响另一个卷上的文件。
这可以在启动 WinRE 时配合连接的可移动驱动器（NTFS 格式）使用，以删除 ramdisk 上的 `winpeshl.ini`。删除此文件后，如果按住 Ctrl 键，`winpeshl.exe` 将启动一个 SYSTEM shell，内存中携带已派生的 osdevice BitLocker 密钥。
另请参阅 [Will Dormann 的补充分析](https://infosec.exchange/@wdormann/116565129854382214)。此漏洞为 CVE-2026-45585。 | 无 | 2026 年 5 月 | Nightmare-Eclipse | | [内存泄漏](#ram-leak)：启动环境对 ramdisk 创建设备没有限制 | 当配置为创建 ramdisk 时，要加载的文件和加载设备在 BCD 中指定。
启动环境对传入的设备没有检查，因此允许使用 BitLocker 加密的分区，前提是密钥可以被派生。
因此，攻击者可以使用来自 BitLocker 加密分区的任意文件设置 ramdisk，即使已派生的 BitLocker 密钥被清除，文件内容仍将保留在 RAM 中，可在之后转储。
此外，攻击者可以利用此方法确定某个文件是否存在于 BitLocker 加密的 OS 分区上。
有价值的目标包括：休眠文件（包含已派生的 BitLocker 密钥，且经过压缩，应能完全放入 RAM，尤其是在登录屏幕注销后休眠的情况下）、页面文件、SYSTEM 和 SAM 配置单元、任何第三方服务或驱动程序（从 SYSTEM 配置单元中识别）以检查漏洞。 | 无。MSRC 因误解而将其关闭，认为优先级低。 | 2026 年 5 月，最初于 2025 年 3 月发现。 | Rairii | ### 危险关联 易受攻击的系统已安装 2022 年 5 月或 2022 年 6 月的更新，但未安装任何后续更新。 关联选项 GUID 是哈希数据的一部分，因此所使用的设备元素必须标记为未验证。 在 Windows 7 及以下版本中没有可用的元素（尽管在使用自定义非默认设置时仍可能可行）。 在 Windows 8 及以上版本中，`osloader!osdevice` 默认未经验证，因此可以利用。 最简单的利用方法是使用 BCD 原始设备编辑器 [bcdeditmod](https://github.com/Wack0/bcdeditmod)，不过手动编辑 BCD 注册表配置单元也是可行的（自行研究）。 利用步骤包括： * 从目标设备获取 BCD，创建两个设备元素 * 将 `{default}` 中的 osdevice 复制到第一个 * 在 `{default}!osdevice` 中将关联选项 GUID 设置为第一个设备元素 * 在 `{first}!osdevice` 中将关联选项 GUID 设置为第二个设备元素 * 在第二个设备元素中设置任意"危险"选项（如 `debug`） * 使用该 BCD 和相同的 `bootmgfw` 二进制文件启动目标设备 ### bitpixie 此漏洞已存在超过 17 年，已知最早引入该漏洞的版本为 2005 年 10 月的 `6.0.5231.2 (winmain_idx03.051004-2120)`。 在使用 Secure Boot 完整性验证的情况下，降级攻击仍可利用此漏洞。 设置一个 PXE 启动服务器，其中包含易受攻击的 `bootmgfw.efi`（在使用旧版完整性验证的情况下，必须使用目标设备的 `bootmgfw.efi`），并为 EFI 启动正确重命名。 对于 BCD，设置一个默认条目，其中 `device` 为 BitLocker 加密的 osdevice；`path` 为 `"\"`；以及一个恢复序列。 恢复序列应指向单个 `startup` 条目，其中 `device` 为 boot，`path` 指向要运行的 EFI 应用程序（来自 PXE 服务器）；且 `pxesoftreboot` 已启用。 当 Secure Boot 禁用时，该 EFI 应用程序可以是一个扫描物理内存以查找 BitLocker 密钥表进行转储的应用程序。 当 Secure Boot 启用时，该 EFI 应用程序可以使用已知的 Secure Boot 绕过（如果需要，需要物理访问）。 要以这种方式利用 Windows 启动应用程序，需要用 PXE 服务器上的第二个 BCD 替换 BCD。 这意味着在 `bootmgr` 启动期间按箭头键以强制显示启动菜单；然后在此时替换 PXE 服务器上的 BCD。 ### 按键解密 利用步骤包括： * **将 BitLocker 保护的 osvolume 转储为磁盘映像。** 此获取 FVEK 的方法会导致实际数据丢失！ * 使用任何方式启动到 WinRE（如果需要可通过启动修复强制启动，或直接设置 bootsequence BCD 元素等）。 * 开始重置（疑难解答 -> 重置此电脑 -> 删除所有内容）。选择"本地重新安装"更快。确保选择"仅删除我的文件"。 * 选择"保留文件"将要求提供恢复密钥。 * 如果系统的 WinRE 不易受攻击，也会要求提供恢复密钥。 * 当重置达到约 98% 时，强制关闭系统（按住电源按钮 7 秒等）。 * 重新开机，系统应再次启动到 WinRE 并显示错误。确认错误后应会重启。 * 当看到蓝色"正在更新"屏幕时，按 Shift+F10 进入 shell。 * 执行 `manage-bde -pause C:`，然后执行 `manage-bde -protectors -delete C:` * 再次强制关闭系统。 此时，磁盘上的 BitLocker 元数据将包含明文 VMK。 将其转储，并使用该 VMK 解密 FVEK。 解密后的 FVEK 可用于之前制作的磁盘映像来解密分区。 请注意：我仅在非常特定的情况下（仅 TPM 的 BitLocker，无恢复密钥）在 Windows 10 上成功利用了此问题。 然而，[其他人已使用 Windows 11（Nickel）上易受攻击的 WinRE 成功利用了此问题](https://blog.scrt.ch/2023/08/14/cve-2022-41099-analysis-of-a-bitlocker-drive-encryption-bypass/)。 ### 内存泄漏 据我所知，此漏洞自引导管理器存在以来就一直存在——最早可追溯至 2005 年 6 月的 `6.0.5098.0 (winmain_beta1.050628-1740)`，尽管该版本早于 BCD，因此在早期版本中的利用方式会有所不同。相关代码似乎更早之前就已存在（ramdisk 相关代码在 2005 年 4 月的 build 5048 中似乎相同），但 build 5098 是最早存在某种形式 BitLocker 的已转储版本。 要利用此漏洞，需要像 bitpixie 一样设置一个默认条目和一个恢复序列。这是为了在加载文件时为 OS 设备派生密钥。 恢复序列必须有一个额外的设备条目来设置 ramdisk。使用 [bcdeditmod](https://github.com/Wack0/bcdeditmod) 进行设置。在此处使用自定义元素，如 `custom:21100000`。此处使用的设备条目示例如下：`!raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]]` - 你需要将此处 `part2` 块设备替换为目标系统 BCD 中的对应设备。 然后可以使用任何适合你的方法从内存中转储文件。我倾向于通过高级选项菜单使用旧版 winload 加载自签名的 mcupdate，但也有其他选择（例如 PXE 软重启进入第三方操作系统；在 WinPE 中通过使用 bugcheck 或已知易受攻击的驱动程序进行内存转储是可行的，但 winload 会在 NT 内存映射中将该内存区域标记为空闲，因此如果不通过 winload 中的其他设置将该内存标记为坏块等，该区域可能会被覆盖）。 我首选方法的[概念验证实现](ramleak.zip)包含在此仓库中的 `ramleak.zip` 中。请阅读附带的 readme 以获取使用说明。 感谢 Maxim Suhanov，这是受到阅读 CrashXTS 分析并想出其他可能转储 `hiberfil.sys` 的方法的启发。 现在谈谈我对此漏洞和 yellowkey 的个人看法： 这是我第一次在向 MSRC 提交时遇到真正的问题，主要是由于他们对 Secure Boot 的误解。鉴于其他 BitLocker 0day 被公开，我决定现在发布这个，我已经憋了将近一年了，一直在纠结该怎么处理。 与 yellowkey 不同，我不会夸大其词地称之为"后门"，在我看来 yellowkey 并不是后门，相关组件与 WinPE 有关（并非 WinRE 特有），那里主要的"漏洞"是删除 winpeshl.ini 以到达该代码路径，我完全理解为什么 MS 认为在 WinRE+BitLocker 场景下删除它是不可能的。 鉴于从 BitLocker 加密分区加载 ramdisk 实际上是启动环境中的一个功能，尽管我必须使用现有的技巧才能让它实际运作，但如果其他人愿意，他们也可以说这是后门，但我不至于那么极端。启动环境很复杂（而且还在不断增大，最新的 `bootmgfw_ex.efi` 不再适合 2.88MB 的映像——一个时代的终结），由于某些功能之间的交互方式，已经发现了多个漏洞。
标签：BitLocker, bitlocker攻击, Conpot, firmware TPM, HSP, LPC总线, meg, PCR, PCR验证, Pluton, RuleLab, TPM, TPM嗅探, VMK, Windows BitLocker 漏洞, Windows安全, 信息安全, 加密攻击, 加密破解, 加密磁盘, 加密系统攻击, 固件攻击, 固件漏洞, 子域名枚举, 安全启动, 安全配置, 情报收集, 攻击向量, 攻击技术, 攻击防御, 数字取证, 数据加密标准, 漏洞披露, 漏洞研究, 物理攻击, 硬件安全, 硬件攻击, 硬件调试器, 磁盘加密, 系统安全, 系统安全评估, 系统完整性, 自动化脚本, 虚拟机密钥, 软件攻击