TotalRecall Reloaded

再次攻破 Windows Recall。

image

当微软重新设计 Recall时，加入了 VBS 飞地、AES-256-GCM 加密、Windows Hello 认证以及 Protected Process Light 宿主，其信息很明确：数据被锁在保险库中。

保险库很坚固。但运送数据的卡车并不坚固。

AIXHost.exe，即渲染 Recall 时间线的进程，没有 PPL、没有 AppContainer、没有代码完整性强制。任何以当前登录用户身份运行的进程都可以向它注入代码，并调用与合法 UI 相同的 COM API。一旦用户通过 Windows Hello 认证，解密后的截图、OCR 文本和元数据就会以实时 COM 对象的形式流经 AIXHost.exe。TotalRecall Reloaded 就驻留在该进程内部，提取所有内容。

无需管理员权限。标准用户即可。无需内核漏洞。无需密码学绕过。只需 COM 调用。

工作原理

注入

TotalRecall Reloaded 包含两个文件：一个注入器（totalrecall.exe）和一个 payload DLL（totalrecall_payload.dll）。

注入器通过 CreateToolhelp32Snapshot 找到 AIXHost.exe，使用 VirtualAllocEx 在目标进程中分配内存，通过 WriteProcessMemory 写入 DLL 路径，然后创建一个指向 LoadLibraryW 的远程线程。经典的 DLL 注入。没什么特别的，因为根本不需要什么特别的。AIXHost.exe 对此没有任何防护。

此操作在标准用户权限下即可工作。无需提权，无需 SeDebugPrivilege。Windows 默认的 DACL 允许同一用户进程完全访问彼此。已验证：令牌在中等强制级别运行，BUILTIN\Administrators 设置为仅拒绝。

认证

VBS 飞地不会解密任何未通过 Windows Hello 认证的数据。该工具并未绕过这一点。它让用户自行完成认证，在用户完成认证时静默搭载，或者等待用户完成认证。

--launch 通过 keybd_event 模拟 Win+J（打开 Recall 时间线的键盘快捷键）。用户会看到 Hello 提示（面部、指纹或 PIN），进行认证，然后飞地开始提供解密后的数据。从用户角度看，Recall 只是正常打开了。从我们角度看，payload 早已注入并在等待。

--stealth 是完全静默模式。工作方式如下：

1. 注入到 AIXHost.exe（始终运行）并修补 DiscardDataAccess 使其成为空操作
2. 静默等待用户正常打开 Recall 并完成认证
3. 当用户关闭 Recall 时，Baker.dll 尝试撤销数据访问授权，但该修补阻止了它
4. AIXHost.exe 终止并重新生成。工具检测到重启，重新注入新进程
5. 认证授权在 aihost.exe 中持久存在（撤销被阻止）。提取立即开始
6. 无需 Win+J、无需 Hello 提示、无需可见 UI。最多 5 次重新注入尝试。

--wait 是 --launch 的被动对应模式。工具不模拟 Win+J，而是空闲等待用户自行打开 Recall——通过任务栏、快捷键或其他方式。当 AIXHost.exe 出现且用户自然完成 Hello 认证后，payload 被注入并开始提取。适用于正在被观察的机器，或者需要让 Recall 会话看起来完全由用户发起、没有任何合成键盘输入的情况。

提取链

一旦进入 AIXHost.exe，payload 使用 CoInitializeEx(COINIT_APARTMENTTHREADED) 初始化 COM 单元，并通过 CoSetProxyBlanket(EOAC_DYNAMIC_CLOAKING) 设置代理身份转发。这至关重要。没有动态伪装，COM 代理就不会将已认证的身份传递给服务器。

提取过程遵循与合法 Recall UI 相同的路径：

1. 飞地初始化：DataManager.Load() 触发飞地密钥加载。DataStoreManager.DecryptDatabase()（槽位 37）准备解密后的视图。Payload 轮询 DataManager.DataStatus 直到返回 3（已解锁）。

2. 实体枚举：MemoryEntityStatics.GetLightMemoryItemsBefore()（槽位 9）返回轻量级实体引用的向量。每个引用在偏移量 +8 处携带一个上下文 ID。在典型机器上，这会返回数百个跨越数天或数周活动的实体。

3. 逐个实体提取：对于每个上下文 ID，payload 通过 ContextEngine2.TryGetEntityForId()（槽位 6）加载完整实体，通过 IEntityWrapper（槽位 6）解包，并 QueryInterface 到 IMemoryEntity。然后：

   • 元数据（同步）：标题（槽位 8）、应用模型 ID（槽位 9）、应用名称（槽位 10）、进程路径（槽位 11）、URL（槽位 12）、域名（槽位 13）、文件 URI（槽位 15）、时间戳（槽位 7）、窗口边界（槽位 16）。通过 QI 到 IMemoryEntity2/3：恢复能力、应用停留时间、网页停留时间
   • 截图（异步）：TryGetBitmapCaptureAsync()（槽位 19）返回 SoftwareBitmap。QueryInterface 到 ，调用 获取 WIC 位图，通过 编码为 PNG

每个调用都包装在 __try/__except 中，因为单个 COM 代理调用中的访问冲突会永久杀死通往 aihost.exe 的 RPC 通道。这是无法恢复的。你必须重启 AIXHost.exe。SEH 包装器捕获因错误参数类型导致的崩溃，并保持会话存活。

预认证能力

几项操作无需任何 Hello 认证即可工作：

截图提取：RecallPrivacyIndicatorSettings（CLSID {42C63551-...}）在槽位 13 暴露了 GetRecentCaptureThumbnail(width, height)。方法名虽说是“缩略图”，但服务器并未强制分辨率上限。传入 3840x3840 会返回最近的 Recall 全分辨率截图。IRandomAccessStream 结果通过 CreateStreamOverRandomAccessStream（shcore.dll）转换为 IStream，并以 BMP 格式转储。

数据销毁：IDataStoreManager::DeleteEvents()（槽位 12）会清除整个捕获历史。无需参数，无需认证。Ghidra 分析确认：FUN_1802ddd10 的删除处理函数中不包含对授权门控函数的调用。认证检查从未被接入。

元数据泄露：存储路径（包括用户特定的 UKP GUID）、数据库大小、保留策略、捕获状态以及最近的捕获上下文 ID，均可通过 IDataStoreManagerStatics 和 RecallPrivacyIndicatorSettings 在无需认证的情况下读取。

使用方法

image``` totalrecall.exe --launch Open Recall, trigger Hello, extract everything totalrecall.exe --stealth Silent extraction (patches auth revocation, waits) totalrecall.exe --wait Wait for user to manually open Recall totalrecall.exe --preauth Grab latest screenshot + settings (no Hello) totalrecall.exe --search "password" Search OCR text in latest extraction totalrecall.exe --destroy Wipe all Recall data (confirmation required, no Hello)

| 模式 | 需要身份验证 | 功能说明 |
|------|:---:|-------------|
| `--launch` | 需要 | 模拟 Win+J，用户认证后，完整提取 |
| `--stealth` | 被动 | 修补认证撤销，等待用户认证 Recall，静默提取 |
| `--wait` | 需要 | 等待用户自然打开 Recall，然后提取 |
| `--preauth` | **否** | 最新截图 + 所有设置 |
| `--search` | 否 | 最新提取中的不区分大小写 OCR 文本搜索 |
| `--destroy` | **否** | `DeleteEvents()`，不可逆，需输入 DESTROY 确认 |

### 输出示例

**`--stealth`（首次运行，等待用户）：**```
[+] Target: AIXHost.exe  PID 8648 (stealth mode)
[*] Patching auth revocation...
[+] Waiting for Recall session...
[+] Recall session detected
[*] Waiting for user to close Recall...
[*] Recall closed, waiting for AIXHost to respawn...
[+] Extracting from AIXHost PID 26208
[+] Payload active
[*] Extracting
[##############################] 384/384 entities

EXTRACTION COMPLETE  6 min 51 sec
Screenshots       192   328.8 MB
OCR Text          184   535.2 KB
Metadata (CSV)    384    97.4 KB

--stealth（后续运行，缓存会话）：``` [+] Target: AIXHost.exe PID 27532 (stealth mode) [] Patching auth revocation... [+] Waiting for Recall session... [+] Cached session found, extracting... [] Extracting [##############################] 398/398 entities

**`--launch`:**```
[+] Target: AIXHost.exe  PID 14636  Memory 60 MB
[*] Triggering Recall via Win+J...
[*] Waiting for Hello authentication authenticating
[+] Recall ready  PID 14636  Memory 242 MB
[*] Extracting
[##############################] 212/212 entities

EXTRACTION COMPLETE  3 min 59 sec
Screenshots       104   184.0 MB

--preauth（不需要 Hello）：``` [+] Target: AIXHost.exe PID 27532 (pre-auth mode) [*] Injecting payload (pre-auth only)... [+] Payload active

PRE-AUTH EXTRACTION COMPLETE 0 min 1 sec

Screenshot 4K (3840x2464) 36.1 MB

Settings Storage Path C:\Users<user>\AppData\Local\CoreAIPlatform.00\UKP{...} Storage Size 178.3 MB Capture Count 0 Retention Days 90

**`--search`:**```
Searching for: "password"
In: extraction_20260406_152736

[1] === [12] ctxId=90443 Settings | Chrome ===
     Saved passwords and passkeys
[2] === [47] ctxId=91201 inbox | Thunderbird ===
     Your temporary password has been reset

输出目录```

extraction_20260404_143052/ screenshots/ Full-resolution decrypted PNGs screenshots/*.txt Per-image OCR text thumbnails/ Thumbnail PNGs (fallback when full screenshot unavailable) ocr_text.txt Combined OCR text for all captures recall_data.csv Structured metadata settings.txt Storage path, size, retention, capture state latest_capture_4k.bmp Pre-auth screenshot of most recent capture extraction.log Detailed extraction log with timing

## 构建

**要求：** 安装了ARM64 C++工具的Visual Studio，启用了Recall功能的Windows 11 ARM64。```
make.bat

生成 totalrecall.exe 和 totalrecall_payload.dll。运行两者时必须位于同一目录下。

Recall 的信任模型```

VTL1 (Secure World) +--------------------------------------------------+ | VBS Enclave: AES-256-GCM, sealed keys | | snapshot_support.dll / storage_support.dll | | Keys never leave here. Crypto is sound. | +--------------------------------------------------+ ^ CallEnclave | VTL0 (Normal World) +--------------------------------------------------+ | aihost.exe (PPL, Signer=5) | | +-- Microsoft.Windows.AI.Platform.dll (6.9 MB) | | 44 methods on IDataStoreManager alone | | Enclave bridge. Protected. Can't touch it. | | | | AIXHost.exe (NO PROTECTION) | | +-- Baker.dll: OCR, NER, AI classification | | +-- Receives decrypted data for rendering | | +-- CreateRemoteThread = game over | +--------------------------------------------------+

密钥层次结构：Hello → NGC ECDH P-384（TPM 支撑）→ VTL1 相互认证 → 飞地密封密钥材料 → 每页 AES-256-GCM（随机 nonce 和页码 AAD）。六层密钥派生。密码学设计确实扎实。

问题出在解密之后。明文会流入 `AIXHost.exe`——一个不受保护、可注入、同用户进程。飞地无法区分 `Baker.dll` 与注入的代码。它做不到。

---

## 关键发现

### 信任边界过早结束

微软的[架构博客](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/)指出“VBS 飞地之外的进程永远不会直接获得快照或加密密钥的访问权限”，并且设计“限制了潜伏的恶意软件试图借助用户身份验证来窃取数据的行为”。

实际上，`AIXHost.exe` 会将每张解密后的截图和 OCR 结果作为活动 COM 对象接收。进程内部没有按调用者进行的验证。没有“你是 Baker.dll 吗？”的检查。只要你在进程内，你就被信任。安全边界是 VBS 飞地和 PPL，而不是渲染进程。解密后的数据距离任何同用户应用程序只需一次 `CreateRemoteThread`。

### IResponse4 访问控制绕过

一个直接的授权漏洞。

当你调用 `ContextDataSource.Search()` 并返回一个 `IResponse` 时，自然路径是通过 `IResponse.get_Items()`（槽位 9）获取结果。在全新会话中，这会返回 `0x80005473`，一个 Recall 特有的自定义错误代码。服务器在有意拒绝调用。`IResponse2.ItemsAfterIndex()` 返回同样的错误。访问控制正在生效。

但 `IResponse` 对象实现了四个接口版本。`IResponse4.get_UnfilledItems()`（不同 IID 上的槽位 9）在不进行任何访问检查的情况下返回相同的基础数据集合。```
IResponse.get_Items()           -> 0x80005473 (ACCESS DENIED)
IResponse2.ItemsAfterIndex()    -> 0x80005473 (ACCESS DENIED)
IResponse4.get_UnfilledItems()  -> S_OK (all entities returned)

相同的数据。不同的接口版本。无授权。该方法原本用于搜索管道中的内部懒加载。安全审查发现了 get_Items 和 ItemsAfterIndex，但漏掉了 get_UnfilledItems。这就是安全工程困难的原因：检查存在于一个代码路径上（这意味着有人认为它是必需的），而在另一个路径上缺失。

根据这些条目，每个实体的上下文 ID 会引导至 ContextEngine2.TryGetEntityForId()，该函数加载包含截图、OCR 和元数据的完整实体。飞地按请求解密所有内容。

DiscardDataAccess 绕过

当用户关闭 Recall 窗口时，Baker.dll 调用 IDataProtectionManager3::DiscardDataAccess() 以明确撤销 aihost.exe 中的数据访问授权。这就是为什么在用户正常使用 Recall 会话后，授权不会持久化：Baker.dll 会清理自身。

绕过方式：注入到 AIXHost.exe 中的代码可以修补 COM 代理虚函数表，将 DiscardDataAccess（槽位 8）替换为一个无操作函数。一次 VirtualProtect 调用，一次指针写入。当用户关闭 Recall 时，Baker.dll 调用修补后的槽位，什么也不发生，授权在 aihost.exe 中保持激活。任何后续的 AIXHost.exe 实例都会静默继承缓存的授权。

在实践中，--stealth 将补丁部署到 AIXHost.exe（它始终在运行）并等待。下次用户正常打开并关闭 Recall 时，清理被抑制，数据访问授权得以持久化。该工具检测访问，通过自动重新注入（为每个新实例重新修补）处理 AIXHost 进程重启，并静默提取所有内容。补丁是每个进程和每次运行的：它保护当前的提取会话。工具退出后，后续的 Recall 使用恢复正常行为。

DeleteEvents：无需授权的破坏

IDataStoreManager::DeleteEvents() 无需 Windows Hello 即可清除整个捕获历史。Ghidra 确认：删除处理程序中没有调用授权门函数。授权检查从未被接入删除路径。即使无法读取数据的攻击者也能破坏它。标准用户的反取证手段。

预认证截图提取

RecallPrivacyIndicatorSettings.GetRecentCaptureThumbnail 返回任意分辨率的最近 Recall 截图。该方法旨在用于任务栏中的小隐私指示器。没有人限制分辨率。任何同一用户进程都可以静默抓取屏幕上最后显示的内容，无需 Hello。

通过 GetSecureStorageInfo 的预认证捕获计数

GetWindowCaptureCount（槽位 26）在没有 Hello 的情况下返回 E_ACCESSDENIED。但 GetSecureStorageInfo（槽位 27）返回一个 StorageInfo 结构体，其中包含完全相同的数据，无需认证。该结构体包含 NumberOfItems（捕获计数）和 Size（加密存储总字节数）。攻击者可以实时监控此信息以跟踪 Recall 活动，无需任何认证。

认证状态持久化

一旦完成 Hello，认证状态会在整个 Windows 会话中缓存在 aihost.exe（PPL）中。杀死并重启 AIXHost.exe 不会清除它。攻击者可以等待用户自然打开 Recall，然后在数小时后静默提取数据。无限次重新提取，无需额外提示、无需可见窗口、无需用户感知。

Recall 捕获的内容（以及提取的内容）

Recall 不仅仅截取屏幕截图。它构建了你计算机上所有操作的全面行为画像。每隔几秒，它捕获一张截图，对其运行 OCR 和（据称）AI 分类，并将结果存储在加密的 SQLite 数据库中。

以下所有内容均来自两个独立来源：私有 WinRT 元数据（Microsoft.Windows.AI.Platform.winmd，通过 cppwinrt.exe 解析）和 VBS 飞地二进制文件（storage_support.dll，其中包含以纯文本字符串形式呈现的完整数据库模式）。

每次捕获的数据

注意：下面的字段名称已从 WinRT 元数据和飞地二进制字符串中确认。每个字段内容的描述是根据 API 名称和类型推断的，并未全部在运行时动态验证。

AI 处理后的元数据

注意：与上面相同。类名和枚举名称从 WinRT 元数据和飞地 DLL 字符串中枚举；每个代表的内容描述是根据名称和上下文推断的，并未对每个条目进行动态验证。

除了原始捕获内容，Recall 还运行 AI 分类，生成：

• 命名实体识别（10 种类型）：PersonName、Organization、Product、Address、Location、DateTime、Event、Duration、WebUrl、EmailAddress。每个都从 OCR 文本中提取，并带有源位置。
• 主题分类（23 个类别）：Topic、Person、Emoji、App、FileKind、、、、、、、、、、、、、、、、、、。每个都带有置信度分数和可选的边界框。

捕获管道

每隔几秒，Recall 的捕获服务会评估 12 条策略，然后决定是否截取屏幕截图：

GameModeActive、BatterySaverActive、UserActivityIdle、UserPresenceIdle、StorageLow、PrivateWindow、BlockedByContentProtection、BlockedAppId、BlockedExecutable、BlockedURL、BlockedContentFilePath、BitLockerDisabled

如果这些都没有触发，则进行捕获。每次捕获的输入结构（来自 WinRT 元数据）：``` WindowData { WindowId, Foreground, Title, Bounds, Minimized, PrivateState, InputScopePrivacy AppData { AppUserModelId, ProcessPath, IconUri, AppName, TileId RemoteClient, IsBrowserWindow } RestoreData { WebUrl, FilePath, ActivationUri, ActivityId, WebIconUri FileObjectId, VolumeId // NTFS persistent file identifiers SensitivityLabelData { State, Labels } } }

### 数据库

主数据库（`ukg.db`）使用带有 AES-256-GCM 加密的 SQLite SEE。从 `storage_support.dll`（包含明文 CREATE TABLE 语句的 VBS 飞地二进制文件）确认了数据库模式：

**核心表（17 个）：**```
WindowCapture              Id, Name, ImageToken, IsForeground, WindowId, WindowBounds,
                           WindowTitle, Properties, IsProcessed, Retry, ActivationUri,
                           ActivityId, FallbackUri, TimeStamp, DwellTime
WindowCaptureAppRelation   WindowCaptureId, AppId, IsBackground
WindowCaptureWebRelation   WindowCaptureId, WebId, IsBackground
WindowCaptureFileRelation  WindowCaptureId, FileId
WindowCaptureTopicRelation WindowCaptureId, TopicId, Score (float)
WindowCaptureTextIndex     FTS5 virtual table (WindowCaptureId, WindowTitle, OcrText)
App                        Id, WindowsAppId, IconUri, Name, Path, TileId, Properties
Web                        Id, Domain, Uri, IconUri, Properties
File                       Id, Path, Name, Extension, Kind, Type, ObjectId, VolumeId
Topic                      Id, Title, Properties
ScreenRegion               Id, WindowCaptureId, RegionKind, OcrText, Bounds
AppDwellTime               Id, WindowsAppId, HourOfDay, DayOfWeek, HourStartTimestamp, DwellTime
WebDomainDwellTime         Domain, HourOfDay, DayOfWeek, HourStartTimestamp, DwellTime
SearchHistory              SessionId, CorrelationId, TimeStamp, Kind, Text, Language
SearchFeedback             SessionId, CorrelationId, TimeStamp, Kind, Text, Language,
                           ItemChosenEventId, FeedbackType
IdTable                    NextId
_MigrationMetadata         Id, Version

语义搜索索引（SemanticTextStore.sidb / SemanticImageStore.sidb）：``` si_items Core embedding storage si_embedding_metadata Embedding type and source mapping si_diskann_graph DiskANN approximate nearest neighbor graph si_diskann_references Graph edge references si_diskann_config Index configuration si_diskann_info Index statistics si_application_values Application-level settings

在一个典型的工作日里，数百次的屏幕截图不断累积。默认保留期为90天，存储阈值为75 GB。每一封打开的邮件、每一个编辑的文档、每一个访问的网站、每一条屏幕上的终端命令、每一段可见的聊天内容——全部经过OCR处理、实体提取、主题分类和语义索引。

你的整个数字生活，已被索引并可搜索。正如设计所愿。

---

## 微软做对的部分

VBS 飞地坚如磐石。密钥材料从未离开 VTL1。每页使用随机 nonce 的 AES-256-GCM 在教科书级别上是正确的。`aihost.exe` 的 PPL 保护是有效的，内核阻止了注入。CFG 在 ARM64 上全面覆盖。SQL 查询完全参数化（十个注入载荷，零副作用）。身份验证模型是无状态且无竞争条件的（数千次探测，零绕过）。

根本问题并不在于加密、飞地、身份验证或 PPL。而在于将解密后的内容发送到一个不受保护的处理进程进行渲染。保险库门是钛合金的，但旁边的墙壁是干墙。

---

## 负责任的披露

本研究成果已负责任地向微软安全响应中心 (MSRC) 披露。

### 时间线

| 日期       | 事件                                                                                      |
|------------|-------------------------------------------------------------------------------------------|
| 2024-06-07 | 原始 [TotalRecall](https://github.com/xaitax/TotalRecall) 发布（加密前的 Recall）          |
| 2024-06-13 | 微软推迟 Recall 发布，宣布重新设计，采用 VBS 飞地                                        |
| 2025-04    | Recall 重新发布，包含 VBS 飞地、加密、Hello 认证                                         |
| 2026-03-06 | 向 MSRC 提交报告：完整文档、源代码、构建说明                                               |
| 2026-03-09 | MSRC 开启案例 109586，状态：审查 / 复现                                                  |
| 2026-03-27 | MSRC：“工程团队目前处于调查的最后阶段”                                                    |
| 2026-04-03 | MSRC 结案，判定为 **非漏洞**：“行为在当前已记录的 security design 范围内运行”              |
| 2026-04-09 | TotalRecall Reloaded 公开发布                                                             |

### 微软的立场

经过与工程团队的审查，MSRC 确定“所观察到的行为在当前已记录的 Recall security design 范围内运行”，并且“所展示的访问模式与预期的保护及现有控制措施一致。”他们引用了自己的[架构博客](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/)，特别指出授权“限制了潜伏的恶意软件试图借用户身份验证之机窃取数据的行为”，并且“VBS 飞地之外的进程从不直接获得对截图或加密密钥的访问权限，只有在授权后接收从飞地返回的数据。”

该案例以“非漏洞”结案。

本文档中记录的身份验证前发现（未认证的数据销毁、截图提取）是在案例结案后的后续研究中发现的。

---

## 测试环境

|               | 详情                                   |
|---------------|----------------------------------------|
| **操作系统**   | Windows 11 25H2 (Build 26300.8155)     |
| **架构**       | ARM64                                  |
| **AIXHost.exe** | v2126.7602.0.0                         |
| **权限**       | 标准用户（中等完整性，未提权）          |

---

## 先前工作

- [TotalRecall](https://github.com/xaitax/TotalRecall)（2024年6月），用于加密前 Recall 的原始 Python 工具
- [Kevin Beaumont 的分析](https://doublepulsar.com/recall-stealing-everything-youve-ever-typed-or-viewed-on-your-own-windows-pc-is-now-possible-da3e12e9465e)，一切由此开始的研究

## 致谢

感谢 [Jeff McJunkin](https://x.com/jeffmcjunkin) 和 [Kevin Beaumont](https://cyberplace.social/@GossiTheDog) 的测试与验证。

---

**Alexander Hagenah ([@xaitax](https://x.com/xaitax))**