Windows 11 与 Recall

关键词：Windows 11、Recall、Copilot+ PC、Enhanced Sign-in Security、ESS、Virtualization Based Security、Copilot+ PC 硬件门槛、屏幕快照工件 难度：进阶 前置知识：Windows 取证工件地图、SQLite 查询、事件日志分析

一、概述

Windows 11 带来的取证变化里，最需要重新认识的是 Recall。

它不是普通的活动日志，而是周期性截屏 + 本地 OCR + 向量索引构成的时间线。屏幕上出现过的一切都会留下可搜索的痕迹，包括只在屏幕上停留过几秒的密码、令牌、终端命令、内部后台。

对取证分析者来说，Recall 可能是唯一能重建「用户看到了什么」的工件。传统取证只能证明「打开过什么文件」「访问过什么网站」。Recall 能证明屏幕上的具体内容。在密码泄露、界面取证、内部后台访问这类案件中，这个差别是决定性的。

它同时也是新的证据风险面。一份检材上只要存在 Recall 数据库，其敏感度远高于常规用户工件；设备一旦已解锁，静态加密不再构成保护。取证封装与传递必须按最高敏感级别对待。

这里讲的是 Windows 11 与 Recall 相关的取证要点，常规 Windows 工件见同板块其它篇目。这一块的位置在排期阶段——它能影响你该不该现在就提取证据。

• 上游依赖 Windows 版本与硬件的判定。「这台机器能不能有 Recall 数据」是可以从硬件与固件配置推断的，这决定了它是「优先提取项」还是「直接排除」。判定方法见Windows 取证工件地图。
• 它自己要按顺序做三件事：先读构建号（CurrentBuild / UBR 与区域设置，Recall 的可用性、默认开关、存储路径与留存策略都随构建号、型号与地区变化）；再确认 ESS 状态；最后才按多候选路径检索。
• 下游支撑 三件事。Recall 里的 OCR 文本是时间线的高价值输入；截图用于确认文本上下文与版面；Recall 与 BitLocker 的关系决定了封装要求，见BitLocker 全卷加密取证。
• 它与 Windows Timeline 必须分开——两者不是同一个东西，混淆会导致取错工件或下错结论。

Recall 的处理链路是：周期性屏幕快照 → 本地 AI 处理（OCR + 界面检测）→ 提取文本、窗口标题、应用名、时间戳 → 生成向量嵌入 → 写入本地 SQLite 索引与图像存储。

内容	形态	取证价值
OCR 提取文本	SQLite 索引中的明文	时间线主键，最易检索
应用名与窗口标题	索引字段	定位行为发生的应用上下文
时间戳	索引字段	时间线构建的基础
截图图像	图像文件	确认文本上下文、版面与不可识别内容
候选路径	%LOCALAPPDATA%\Microsoft\Recall\、%LOCALAPPDATA%\CoreAIPlatform.00\UKP\{GUID}\ImageStore\	路径随构建版本与型号变化明显，不同观察来源给出的形态并不一致——必须多候选同时检索
Windows Timeline（不是 Recall）	%LOCALAPPDATA%\Microsoft\Windows\Timeline\，含 ActivitiesCache.db	应用与文档的活动记录缓存，不含屏幕内容

三个判定要点。ESS 依赖的传感器证书在制造阶段烧录，后期加装外接设备无法满足。 Recall 数据的存储路径必须多候选检索。 Recall 与 Windows Timeline 是两个不同工件。

据此能回答的是：用户在某个时段屏幕上出现过什么内容、当时使用的是哪个应用、窗口标题是什么、以及通过语义搜索找到「只停留过几秒的敏感信息」。向量嵌入做到了传统文本日志做不到的事：搜索「昨天看到的关于 Kerberos 的 PDF」，能命中屏幕上写着「Active Directory 票据授予概述」的快照。

回答不了的部分，外加四个必须先写进报告的判断：

• Recall 的可用性、默认开关、存储路径与留存策略都随 Windows 构建号、Copilot+ 型号与地区而变化。 分析时必须先读取检材的 CurrentBuild / UBR 与区域设置；无法确认构建号时，报告中应写明「Recall 实现随版本变化，路径为多候选检索结果」，不针对任何单一构建号做断言。
• 「BitLocker 完全离线加密、Recall 不可读」是错的。 BitLocker 只在设备关机或未解锁状态下保护 Recall 数据；用户一旦登录，卷被解锁，Recall 数据库即可被该用户上下文中的任何进程读取，不需要管理员权限。
• ESS 门槛不是软件开关。 传感器证书在制造阶段烧录，后期加装外接生物识别设备无法满足 ESS 条件——所以「能不能有 Recall 数据」是硬件层面的事实。
• 屏幕内容的语义正确性。 OCR 会出错，截图上的文字与识别结果不一致时以截图为准，且需保留原始图像作为核对依据。
• 「用户看到了」与「用户看到了并理解了」的差别。 Recall 证明屏幕内容出现过，不证明阅读、确认或理解。
• Retina 之外的行为。 Recall 只记屏幕，摄像头、打印、外接设备输出等不在记录范围。

读到这里你应该已经理解：Windows 版本与构建号体系，这是第一个必须做的判断，基础在Windows 取证工件地图；VBS（虚拟化基于安全）、TPM 2.0、安全启动、IOMMU/SMMU 这几个概念的基本含义，否则无法判断 ESS 的前置条件是否满足；SQLite 查询，能读取索引库中的文本与时间字段；以及 BitLocker 的工作前提（它保护的是静态存储，卷解锁后不再提供保护），见BitLocker 全卷加密取证。

还有一条处置纪律不能松：Recall 数据属最高敏感级别，摘录、传递、留存都需按最高敏感标准处理，见合规授权与法律边界。

二、核心原理

2.1 Recall 的工作模型

Recall 随 Windows 11 24H2 在 Copilot+ PC 上提供，其处理链路是：

周期性屏幕快照
    ↓ 本地 AI 处理（OCR 文本识别 + 对象/UI 检测）
    ↓
提取文本 + 窗口标题 + 应用名 + 时间戳
    ↓ 生成向量嵌入（embedding）
    ↓
写入本地 SQLite 索引 + 图像存储

因此它能支持语义搜索：用户搜索「昨天看到的关于 Kerberos 的 PDF」，即使屏幕上的文字是「Active Directory 票据授予概述」，也能通过向量相似度命中。这是它与传统文本日志的本质差异。

对取证的意义是：Recall 数据库中同时存在可读的 OCR 文本与原始截图。文本便于快速检索与时间线构建，截图用于确认文本上下文与版面。

2.2 硬件与系统门槛

Recall 不是所有 Windows 11 设备都能用，门槛相当严格，且这些门槛直接决定检材上是否可能出现 Recall 数据：

条件	说明	版本敏感性
Copilot+ PC 认证硬件	需具备足够算力的 NPU（常见表述为 40+ TOPS）	硬件认证名单随时间变化
Windows 11 24H2 及后续更新	Recall 随 24H2 提供，之后随功能更新与地区分批推送	★ 随构建号与区域变化
VBS（虚拟化基于安全）	ESS 的前置条件，必须可用	随构建号与策略变化
TPM 2.0 + 安全启动	ESS 必需	较稳定
固件满足相应要求	含 IOMMU/SMMU、SDEV ACPI 表等制造侧配置	取决于厂商实现
ESS 支持的生物识别传感器	相机或指纹传感器需在制造时内嵌微软签发证书	取决于厂商实现

★ 版本边界（必须写进报告）：Recall 的可用性、默认开关、存储路径与留存策略都随 Windows 构建号、Copilot+ 型号与地区而变化，微软也在不同版本间调整过实现细节。**本篇给出的是通用工作模型与多候选路径，不针对任何单一构建号断言。**分析时必须先读取检材的 CurrentBuild / UBR 与区域设置，再据此判断适用形态；无法确认构建号时，报告中应写明「Recall 实现随版本变化，路径为多候选检索结果」。

这些不是可绕过的软件开关。

ESS 依赖的传感器证书在制造阶段烧录，后期加装外接生物识别设备无法满足 ESS 条件。

因此「这台机器能不能有 Recall 数据」是可以从硬件与固件配置推断的，这是排期阶段就能做的关键判断。

2.3 ESS 的作用与验证

Enhanced Sign-in Security（ESS）本身是安全特性：它用 VBS 隔离并保护生物识别数据通道，使面部与指纹数据在受信任的硬件路径上处理，抵御欺骗与中间人攻击。

但对取证而言，它的意义在于它是 Recall 的认证前提——Recall 要求系统已配置 Windows Hello 且处于增强签入安全状态。

验证 ESS 状态的方法是查看生物识别日志通道：

Applications and Services Logs
  └─ Microsoft
      └─ Windows
          └─ Biometrics
              └─ Operational

该通道中的特定事件 ID（不同版本 ID 可能不同，以实际系统为准）表明 ESS 是否处于启用并正常工作状态。若查不到相应事件，应先排除「设备或驱动不支持」这一正常情况，而不是直接得出「未启用」。

注册表侧的相关配置位于：

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WinBio

该键下的具体值名与取值含义随系统版本变化，不要在未验证的情况下假设某个 DWORD 的 0/1 极性；以日志通道与实际设置界面为准。

2.4 数据位置

Recall 的数据在用户配置文件内，公开研究中观察到的路径形态包括：

%LOCALAPPDATA%\Microsoft\Recall\
%LOCALAPPDATA%\CoreAIPlatform.00\UKP\{GUID}\
    └─ ImageStore\        （截图图像）

路径随 Windows 构建版本与 Copilot+ 型号变化明显，不同观察来源给出的形态并不一致。实操中不应只按某一个固定路径去搜，而应在用户配置文件下按多个候选路径同时检索，并注意 CoreAIPlatform 这类名称在不同版本中可能不同。

数据内容包括：

内容	形态	取证价值
OCR 提取文本	SQLite 索引中的明文	时间线主键，最易检索
应用名与窗口标题	索引字段	定位行为发生的应用上下文
时间戳	索引字段	时间线构建的基础
截图图像	图像文件	确认文本上下文、版面与不可识别内容

2.5 与 BitLocker 的关系

一个必须明确写入报告的判断：

BitLocker 只在设备关机/未解锁状态下保护 Recall 数据。 用户一旦登录，卷被解锁，Recall 数据库即可被该用户上下文中的任何进程读取——不需要管理员权限。

因此：拿到一台已解锁的 Windows 11 设备，攻击者或取证分析者都能直接访问 Recall 数据；BitLocker 在这个场景下不提供任何额外保护。这与「Recall 数据完全离线加密、不可读」的误解截然相反。

2.6 Windows Timeline：不要与 Recall 混淆

Windows 11 上另有一个较早的功能 Windows Timeline，其工件位于用户配置文件下（如 %LOCALAPPDATA%\Microsoft\Windows\Timeline\），保存的是应用与文档的活动记录缓存（如 ActivitiesCache.db、CachedActivities 目录）。

两者必须区分：

	Windows Timeline	Recall
记录内容	应用/文档活动记录	屏幕快照与 OCR 文本
是否含屏幕内容	否	是
是否需 Copilot+ 硬件	否	是
敏感度	中	高

把 Timeline 的活动记录说成「Recall 记录了屏幕内容」，或反过来把 Recall 数据当作普通活动缓存，都会导致结论与报告中的敏感度评级出错。

三、操作步骤

3.1 先判断是否具备 Recall 可能性

在动手提取前，先做门槛判断，避免无效工作并为报告写明前提：

# 1) 确认系统版本（Recall 随 Windows 11 24H2 提供）
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v DisplayVersion
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentBuild

# 2) 检查 VBS / 内存完整性状态（ESS 前置条件）
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning

# 3) 检查 TPM
Get-Tpm | Select-Object TpmPresent, TpmReady

# 4) 查看生物识别配置与相关注册表键
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WinBio"

3.2 确认 ESS 状态

# 生物识别 Operational 通道：ESS 状态的关键证据
Get-WinEvent -ListLog "Microsoft-Windows-Biometrics/Operational" |
  Select-Object LogName, IsEnabled, RecordCount

Get-WinEvent -Path "Microsoft-Windows-Biometrics/Operational" -MaxEvents 50 |
  Select-Object TimeCreated, Id, @{n='Msg';e={($_.Message -split "`n")[0]}}

注意：若该通道未启用或无事件，先检查设备是否具备 ESS 硬件条件，再下「未启用」的结论。ESS 依赖制造时烧录证书的传感器，普通外接摄像头设备不具备条件。

3.3 定位与提取 Recall 数据

因路径随版本变化，采用多候选路径并行检索：

mmls /work/DigiForensics.dd
fsstat -o 2048 /work/DigiForensics.dd

# 遍历用户配置文件下的候选 Recall 路径
fls -o 2048 -r -p /work/DigiForensics.dd \
  | grep -Ei '/Users/[^/]+/AppData/Local/(Microsoft/Recall|CoreAIPlatform[^/]*)' \
  | grep -E '^r/r' | awk '{print $2}' \
  | while read -r ino; do
      icat -o 2048 /work/DigiForensics.dd "$ino" > "/evidence/recall/$(printf '%s' "${ino%%:*}").bin"
    done

提取后立即：

1. 计算 SHA-256 并记入证据登记表；
2. 按最高敏感级别封装与传递，不要放入普通案件共享目录；
3. 记录提取时的卷解锁状态（决定 BitLocker 是否还提供保护）。

3.4 解析 Recall 索引

数据库为 SQLite，可直接查询：

# 列出数据库文件并确认结构
sqlite3 "file:/evidence/recall/index.db?immutable=1" ".tables"

# 常见表结构随版本变化，先确认列名再写查询
sqlite3 "file:/evidence/recall/index.db?immutable=1" "PRAGMA table_info(activations);"

确认列名后构建时间线，例如（列名以实际检材为准）：

-- 提取含时间戳与应用名的记录
SELECT timestamp, app_name, window_title
FROM activations
ORDER BY timestamp;

-- 检索敏感关键词（按实际列名调整）
SELECT timestamp, app_name, window_title
FROM activations
WHERE lower(window_title) LIKE '%payroll%'
   OR lower(window_title) LIKE '%内部%'
ORDER BY timestamp;

3.5 处理截图

ImageStore 目录中的图像按时间顺序命名，命名规则随版本不同。处理原则：

• 按时间戳与索引记录对齐，把图像归入时