一、概述
BitLocker 是 Windows 内置的全卷加密方案，位置在卷层之下的透明加密层：NTFS/FAT/exFAT 照常读写，扇区落盘前被加密、读出后被解密。
这个架构直接定下两条基本事实。
一，不解锁就拿不到任何数据。文件、注册表 hive、事件日志、页面文件、卷影副本全在加密层之上——密钥不对就是一整块随机字节。
恢复密码、启动密钥和组织侧备份是需要核查的恢复材料，但不能假定它们一定存在于本地检材中。恢复信息是否自动备份取决于设备配置与组织策略。参见 Microsoft：BitLocker 恢复流程。
先核实卷状态和保护器配置，再评估可用恢复材料。关键字搜索只是查找途径之一；是否能解锁，应以候选材料的验证结果为准。
本篇处理的证据形态：
| 证据 |
位置 |
判据 |
| FVE metadata |
卷末尾，典型 0x80000（512 KB），三份副本，块头 8 字节 ASCII -FVE-FS- |
唯一的权威判据 |
| BitLocker 卷标识符 |
FVE metadata 内部（加密区） |
4967d63b-…3d001（Vista/7/8/10）等三个变体。不解密读不到，只能作解锁后交叉验证 |
| 分区类型 GUID |
分区表 |
{ebd0a0a2-…} 是 Basic Data Partition，几乎每个 Windows 分区都是它——加密前后不变，不能用于识别（见 2.3） |
| 恢复密码 |
视用户选择，可能在 .txt、U 盘、AD 域控属性、纸质归档 |
48 位数字 = 8 组 6 位、组间连字符，误判率极低 |
| 启动密钥 |
U 盘或 Documents\ 下的 StartupKey-<GUID>.cer |
注册表 StartUpKey 值里的 GUID 与文件名是同一个值，构成强关联 |
| SYSTEM hive |
/Windows/System32/config/SYSTEM |
HKLM\SYSTEM\CurrentControlSet\Control\BitLocker 下的保护器配置 |
| 内核中的 FVEK |
内存镜像里 fvevol.sys 维护的 FVE context |
恢复密钥在内存里不是 ASCII 文本，搜索无效 |
识别卷时，应结合 FVE metadata 与解析工具的结果。
「分区显示为未知类型」是工具的文案问题，不是盘的状态；-FVE-FS- 标识才是权威判据。用错判据会让整份分析建立在错误前提上——按明文去解析一块 BitLocker 卷，结果是"一无所获"，而这恰恰是最容易被误读为"该机无加密、无敏感数据"的情形。
本篇的四条路径按成本从低到高排列，这个顺序本身就是方法论：
| 路径 |
做什么 |
成本 |
什么时候选它 |
| 1 |
关键字搜索恢复密码 |
一次全盘搜索 |
默认首选——明文留存，误判率极低 |
| 2 |
搜启动密钥 |
一次搜索 + 一次注册表读取 |
路径 1 无果时；GUID 双向印证，几乎不误报 |
| 3 |
读注册表取保护器信息 |
一次 hive 提取 |
无论用哪条路都应该先做——它决定你该攻哪个方向 |
| 4 |
内存取证 |
需已有内存镜像 |
已解锁的 FVEK 在内存里不是 ASCII，别指望搜关键字 |
| — |
拆机 / 重置 TPM |
不可逆 |
最后手段，且必须预先获得授权 |
三件必须提前想清楚的事：
第一，"转换中"是一个独立状态。BitLocker 有未加密 / 转换中 / 已加密三态，转换是有时间跨度的过程——开始之前写入的数据保持明文。
同一台机器上可能同时存在明文区与密文区，而"已加密"这个笼统说法会把它完全掩盖。
第二，逐卷判断，不能以偏概全。一次初始化会同时保护系统卷、数据卷与恢复分区，而每个卷的 FVEK 独立、保护器组合可能不同。解锁 C: 对 D: 没有任何影响。
报告里写一句"BitLocker 已解密"就可能掩盖一个完全没取到的数据卷。
第三，解锁成功必须以"能读出内容"为准，不是命令返回 0。
这一条决定了你的结论是"已解密"还是"候选密钥"。
在取证流程中的位置：本篇是分析环节的前置关卡。上游依赖是镜像制作与证据格式与转换——BitLocker 卷在 E01 里表现为一段无法识别的字节流，你可能需要先把它切出来；注册表取证提供 SYSTEM hive 的离线提取。卷解锁之后，本篇的工作就交棒给下游：文件系统解析交给NTFS 结构与 MFT 解析与NTFS 数据流与隐藏数据（恢复密钥本身有时就被藏在 ADS 里），事件日志交给事件日志深度分析。若案件涉及加密应用数据，解开后还会撞上浏览器密码库与 Token 解密与远程工具凭据解密。
该卷是否启用了 BitLocker、处于"未加密/转换中/已加密"哪一态、启用了哪几类保护器、启动密钥 GUID 是什么、是否在盘上找到恢复密码或启动密钥、哪些卷已成功解锁并验证。
未发现恢复材料时，应注明已检索的位置、账户和时间范围。这个结果不能直接证明数据永久无法恢复，也不能作为恢复材料一定存在的依据。
同样不能回答的还有一次初始化保护了哪些卷（每个卷的 FVEK 独立、保护器组合可能不同，解锁 C: 对 D: 没有影响），以及TPM 密封在 PCR 状态无法复现时的解封——这条路技术上存在，但本篇明确不建议作为首选。
拆机与重置 TPM 属于不可逆的现场破坏，在委托书中预先写明条件，比事后补授权稳妥得多。
读者前提：你需要先能识别分区表与卷边界（NTFS 结构与 MFT 解析）、能离线提取并查询注册表 hive（注册表取证）、并理解"只读挂载 + 副本操作"的工作纪律（只读挂载与安全接入）。如果你还没确认委托方是否允许拆机，本篇第三章的路径 4 请先跳过。 内存侧的补充路径见内存取证总览与内存中的凭据与密钥。
二、核心原理
2.1 两级密钥体系
| 组件 |
全称 |
作用 |
存放 |
| FVEK |
Full Volume Encryption Key |
实际加密扇区数据 |
加密后存于卷上 FVE metadata |
| VMK |
Volume Master Key |
解锁 FVEK 的主密钥 |
加密后存于卷上 FVE metadata |
| ** protector** |
保护器 / 外部密钥 |
包裹 VMK 的材料 |
见下表 |
关键设计：卷上 FVE metadata 中保存的是被外部密钥包裹的 VMK。
所以破解 BitLocker 等价于"找到任意一个可用 protector"。
2.2 五类保护器与取证价值
| 保护器类型 |
存储位置 |
取证价值 |
备注 |
| TPM 密封 |
TPM 芯片内，绑定 PCR 值 |
★★★★ |
需复现 PCR 状态，拆机有风险 |
| TPM + PIN |
同上，额外需 PIN |
★★★ |
知道 PIN 才有用 |
| 启动密钥（Startup Key） |
U 盘上的 .cer 文件 |
★★★★★ |
明文文件，搜关键字即可 |
| 恢复密码 |
文件 / 打印 / AD 属性 |
★★★★★ |
明文，48 位数字，搜关键字即可 |
| 自动解锁（Auto-unlock） |
系统内，已解锁数据卷 |
★★★ |
需原机在线或已解锁状态 |
实战结论：优先攻"启动密钥"和"恢复密码"——它们是明文落盘的，搜索成本极低。
TPM 密封最麻烦，需要复现 PCR（Platform Configuration Register）状态，例如把机器关机、拔掉某些设备再开机。
FVE metadata 位于卷的末尾（最后若干扇区），典型大小 0x80000（512 KB）。卷上共有三份副本，解析器按从后向前的顺序依次尝试解密——这与文件系统无关，正是"文件系统和数据都无法读取"的原因：解析器读到的是密文。
权威判据是卷尾那个 8 字节 ASCII 签名：
-FVE-FS-
它出现在 FVE metadata 块头的起始位置（metadata block header 为 64 字节，前 8 字节即签名），三份副本各有一个。
「三份副本」与「在卷尾」的准确机制（libbde 格式规范）：FVE metadata 块头的偏移 32/40/48 三个 8 字节字段，
存的就是三份副本相对卷起点的偏移量。所以「在卷尾」是通常的落位，不是硬规则——
可靠的做法是解析块头读那三个偏移，而不是假定它一定在最后一个扇区。
落位偏前的情况在加密卷初始化时数据区尚未写满、或卷被扩容时会出现。
另外块头有两个版本：Vista 用的是版本 1（偏移 56 是 MFT 镜像簇号），Windows 7 及以后是版本 2
（偏移 16 是加密卷大小、偏移 56 是卷头扇区数）。两个版本的偏移字段位置一致，所以读取三份副本偏移的逻辑通用。
另外注意块头版本 2 在部分解密状态下，偏移 12/14 会出现 0x0005 / 0x0001 这类不同取值。
见到这两个值说明卷处于保护暂停（Protection Off / Clear Key）状态——数据在盘上是 AES 加密的，
但解密所需的密钥材料以明文存在 metadata 里。这与「没加密」是两回事，报告里要区分。
关于分区类型 GUID：这里有一个流传很广的错误。 常见说法是「用分区类型 GUID 识别 BitLocker 卷」，并给出：
{ebd0a0a2-b9e5-4433-87c0-68b6b72699c7}
这个 GUID 是 Microsoft 的 Basic Data Partition（基本数据分区），几乎每一个 Windows 数据分区都是它——它不标识 BitLocker。 加密前后分区类型 GUID 通常不变，所以它对"是否加密"这个问题零信息量。
BitLocker 真正使用的标识是卷标识符（volume identifier），与分区类型无关：
4967d63b-2e29-4ad8-8399-f6a339e3d001 BitLocker Vista / 7 / 8 / 10
4967d63b-2e29-4ad8-8399-f6a339e3d01 BitLocker To Go
92a84d3b-dd80-4d0e-9e4e-b1e3284eaed8 BitLocker Used Disk Space Only
这三个值位于 FVE metadata 内部（加密区），因此在不解密的前提下根本读不到——它们只能作为解锁成功后的交叉验证，不能作为识别判据。
所以识别阶段的唯一可靠判据就是 -FVE-FS-。
用 fdisk -l / FTK Imager 打开时若显示为未知文件系统类型、且分区大小与内容明显不匹配，通常就是 BitLocker——
但这只算旁证，正式结论必须落到卷尾那个签名上。
2.4 恢复密码的格式
恢复密码是 48 位十进制数字，Windows 显示为 8 组、每组 6 位、组间以连字符分隔：
123456-123456-123456-123456-123456-123456-123456-123456
这个模式在原始镜像中误判率极低——"6 位数字 + 连字符" 连续重复 8 次，是极强的特征信号。
成本最低、命中率最高的一条路径，就是它。
存放位置取决于用户选择：
| 用户选择 |
电子痕迹 |
取证方法 |
| 另存为文件 |
.txt 明文 ASCII |
关键字搜索（首选） |
| 打印 |
无 |
物理勘验 |
| 保存到 USB |
.txt 明文 |
关键字搜索 |
| 注册到 AD 域 |
域控属性 msFVE-RecoveryInformation |
需域权限 |
| 保存到 Microsoft 账户 |
云端 |
需云取证权限 |
| 记忆 |
无 |
字典爆破（48 位数字不可行） |
重要：TXT 文件即便被删除，只要数据区未被覆盖，明文仍可通过关键字搜索还原。取证中务必在"未分配空间"和 $MFT 之外的空闲区做全盘搜索。
三、操作步骤
路径 1：关键字搜索恢复密钥（首选，成本最低）
第 1 步：确定搜索目标
若已有恢复密钥文件，取其中任意 13 字符以上的连续片段作为关键字。若没有，则用正则模式搜。
# 提取 BitLocker 分区镜像（假设已从全盘镜像切出）
fdisk -l DigiForensics.dd # 确认分区类型与偏移
第 2 步：命令行搜索
# 方式 A：strings 过滤（快，适合分区数据量不大）
strings -n 40 DigiForensics.dd | grep -E '^([0-9]{6}-){7}[0-9]{6}'
# 方式 B：直接二进制搜索（慢但更彻底，能命中非对齐位置）
grep -aobE '([0-9]{6}-){7}[0-9]{6}' DigiForensics.dd | head
# 方式 C：大镜像推荐用 foremost 或 bulk_extractor 的自定义签名
第 3 步：在 X-Ways / FTK Imager 中定义自定义关键字（实战最常用）
X-Ways 的自定义关键字语法（tools\keywords 目录下的 .kw 文件）：
[KEYWORDS]
KEYWORD=123456-1234 ; 截取真实密钥的连续 13 字符
ALIAS=BitLocker Recovery Key
COMMENT=BitLocker 48-digit recovery password
FTK Imager 的自定义关键字格式：
123456-1234
技巧：从真实密钥中截取 13–20 字符片段。
片段越长，误报越少；若多个片段均落在同一偏移区域，置信度极高。
第 4 步：验证
找到密钥后，必须实际解锁验证——不要只凭"格式匹配"就下结论：
# 在 Windows 上解锁（假设目标卷挂载为 D:）
manage-bde -unlock D: -RecoveryPassword 123456-123456-123456-123456-123456-123456-123456-123456
⚠️ 注意：命令中带连字符的格式是标准用法（111111-222222-...），48 位纯数字形式也接受但更易出错。推荐先用交互式 manage-bde -unlock D: -Password（会在终端内提
