xaitax/totalrecallDieses Tool extrahiert und zeigt Daten aus der Recall-Funktion in Windows 11 an und bietet eine einfache Möglichkeit, auf Informationen über die Aktivitäts-Schnappschüsse Ihres PCs zuzugreifen.
Windows Recall erneut knacken.
Bild
Als Microsoft Recall mit VBS-Enklaven, AES-256-GCM-Verschlüsselung, Windows Hello-Authentifizierung und einem Protected Process Light-Host umgestaltete, war die Botschaft klar: Die Daten sind in einem Tresor eingeschlossen.
Der Tresor ist solide. Der Lieferwagen nicht.
AIXHost.exe, der Prozess, der die Recall-Zeitleiste rendert, hat keinen PPL, keinen AppContainer, keine Code-Integritätsüberprüfung. Jeder Prozess, der als angemeldeter Benutzer läuft, kann Code in ihn injizieren und dieselben COM-APIs aufrufen, die die legitime Benutzeroberfläche verwendet. Sobald sich der Benutzer mit Windows Hello authentifiziert, fließen entschlüsselte Screenshots, OCR-Text und Metadaten als live COM-Objekte durch AIXHost.exe. TotalRecall Reloaded sitzt in diesem Prozess und extrahiert alles.
Kein Administrator erforderlich. Standardbenutzer. Kein Kernel-Exploit. Kein Crypto-Bypass. Nur COM-Aufrufe.
TotalRecall Reloaded besteht aus zwei Dateien: einem Injector (totalrecall.exe) und einer Payload-DLL (totalrecall_payload.dll).
Der Injector findet AIXHost.exe über CreateToolhelp32Snapshot, reserviert Speicher im Ziel mit VirtualAllocEx, schreibt den DLL-Pfad mit WriteProcessMemory und erzeugt einen Remote-Thread, der auf LoadLibraryW zeigt. Klassische DLL-Injektion. Nichts Besonderes, denn nichts Besonderes ist nötig. AIXHost.exe hat keinerlei Schutz dagegen.
Dies funktioniert mit Standardbenutzer-Rechten. Keine Erhöhung, kein SeDebugPrivilege. Die standardmäßige Windows-DACL erlaubt Prozessen desselben Benutzers vollen Zugriff aufeinander. Verifiziert: Das Token läuft auf mittlerer obligatorischer Ebene mit BUILTIN\Administrators auf deny-only gesetzt.
Die VBS-Enklave entschlüsselt nichts ohne Windows Hello. Das Tool umgeht das nicht. Es zwingt den Benutzer, es zu tun, reitet still mit, wenn der Benutzer es tut, oder wartet darauf, dass der Benutzer es tut.
--launch simuliert Win+J über keybd_event, die Tastenkombination, die die Recall-Zeitleiste öffnet. Der Benutzer sieht eine Hello-Eingabeaufforderung (Gesicht, Fingerabdruck oder PIN), authentifiziert sich, und die Enklave beginnt, entschlüsselte Daten zu liefern. Aus Benutzersicht hat Recall sich normal geöffnet. Aus unserer Sicht ist die Payload bereits drin und wartet.
--stealth ist der vollständig stille Modus. Er funktioniert so:
AIXHost.exe (läuft ständig) und patcht DiscardDataAccess zu einem No-OpAIXHost.exe stirbt und wird neu gestartet. Das Tool erkennt den Neustart und injiziert erneut in den neuen Prozessaihost.exe bestehen (Widerruf wurde blockiert). Die Extraktion beginnt sofort--wait ist das passive Gegenstück zu --launch. Anstatt Win+J zu simulieren, wartet das Tool untätig, während der Benutzer Recall selbst öffnet – über die Taskleiste, eine Verknüpfung oder einen anderen Pfad. Wenn AIXHost.exe erscheint und der Benutzer Hello auf natürliche Weise abschließt, wird die Payload injiziert und die Extraktion beginnt. Nützlich auf einem beobachteten Rechner oder wenn die Recall-Sitzung vollständig benutzerinitiiert aussehen muss, ohne synthetische Tastatureingabe.
Sobald die Payload in AIXHost.exe ist, initialisiert sie eine COM-Apartment mit CoInitializeEx(COINIT_APARTMENTTHREADED) und richtet die Proxy-Identitätsweiterleitung mit CoSetProxyBlanket(EOAC_DYNAMIC_CLOAKING) ein. Dies ist entscheidend. Ohne dynamisches Cloaking überträgt der COM-Proxy die authentifizierte Identität nicht an den Server.
Die Extraktion folgt dem gleichen Pfad, den die legitime Recall-Benutzeroberfläche verwendet:
Enklaveninitialisierung: DataManager.Load() löst das Laden der Enklavenschlüssel aus. DataStoreManager.DecryptDatabase() (Slot 37) bereitet entschlüsselte Ansichten vor. Die Payload fragt DataManager.DataStatus ab, bis es 3 (entsperrt) zurückgibt.
Entitätsaufzählung: MemoryEntityStatics.GetLightMemoryItemsBefore() (Slot 9) gibt einen Vektor mit leichten Entitätsreferenzen zurück. Jede trägt eine Kontext-ID bei Offset +8. Auf einem typischen Rechner werden Hunderte von Entitäten über Tage oder Wochen Aktivität zurückgegeben.
Pro-Entität-Extraktion: Für jede Kontext-ID lädt die Payload die vollständige Entität über ContextEngine2.TryGetEntityForId() (Slot 6), entpackt sie durch IEntityWrapper (Slot 6) und QueryInterface zu IMemoryEntity. Von dort:
TryGetBitmapCaptureAsync() (Slot 19) gibt ein zurück. zu , Aufruf von , um eine WIC-Bitmap zu erhalten, Kodierung als PNG über Jeder Aufruf ist in __try/__except eingeschlossen, da eine einzige Zugriffsverletzung bei einem COM-Proxy-Aufruf den RPC-Kanal zu aihost.exe dauerhaft abtötet. Es gibt keine Wiederherstellung. Man müsste AIXHost.exe neu starten. Die SEH-Wrapper fangen Abstürze aufgrund falscher Parametertypen ab und halten die Sitzung am Leben.
Mehrere Operationen funktionieren ohne jegliche Hello-Authentifizierung:
Screenshot-Extraktion: RecallPrivacyIndicatorSettings (CLSID {42C63551-...}) stellt GetRecentCaptureThumbnail(width, height) in Slot 13 bereit. Der Methodenname sagt "thumbnail", aber der Server erzwingt keine Auflösungsbegrenzung. Die Übergabe von 3840x3840 gibt die aktuellste Recall-Aufnahme in voller Auflösung zurück. Das IRandomAccessStream-Ergebnis wird über CreateStreamOverRandomAccessStream (shcore.dll) in einen IStream konvertiert und als BMP ausgegeben.
Datenvernichtung: IDataStoreManager::DeleteEvents() (Slot 12) löscht die gesamte Aufnahmehistorie. Keine Parameter, keine Authentifizierung. Ghidra-Analyse bestätigt: Der Delete-Handler bei FUN_1802ddd10 enthält null Aufrufe der Autorisierungs-Gate-Funktion. Die Authentifizierungsprüfung wurde nie eingebaut.
Metadaten-Offenlegung: Speicherpfade (einschließlich der benutzerspezifischen UKP-GUID), Datenbankgröße, Aufbewahrungsrichtlinie, Aufnahmestatus und die letzte Aufnahme-Kontext-ID sind alle ohne Authentifizierung über IDataStoreManagerStatics und RecallPrivacyIndicatorSettings lesbar.
Bild``` 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)
| Modus | Authentifizierung erforderlich | Funktion |
|------|:---:|-------------|
| `--launch` | Hello | Simuliert Win+J, Benutzer authentifiziert sich, vollständige Extraktion |
| `--stealth` | Passiv | Patched die Authentifizierungsrücknahme, wartet darauf, dass der Benutzer Recall authentifiziert, extrahiert still |
| `--wait` | Hello | Wartet darauf, dass der Benutzer Recall auf natürliche Weise öffnet, extrahiert dann |
| `--preauth` | **Nein** | Letzter Screenshot + alle Einstellungen |
| `--search` | Nein | Groß-/Kleinschreibung-unabhängige OCR-Textsuche über die letzte Extraktion |
| `--destroy` | **Nein** | `DeleteEvents()`, irreversibel, erfordert die Eingabe von DESTROY zur Bestätigung |
### Beispielausgabe
**`--stealth` (erster Lauf, warte auf Benutzer):**```
[+] 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 (nachfolgender Lauf, zwischengespeicherte Sitzung):```
[+] 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 (kein Hello erforderlich):```
[+] 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
## Erstellen
**Anforderungen:** Visual Studio mit ARM64 C++-Tools, Windows 11 ARM64 mit aktiviertem Recall.```
make.bat
Erzeugt totalrecall.exe und totalrecall_payload.dll. Beide müssen sich beim Ausführen im selben Verzeichnis befinden.
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 | +--------------------------------------------------+
Die Schlüsselhierarchie: Hello -> NGC ECDH P-384 (TPM-gestützt) -> VTL1 gegenseitige Authentifizierung -> enclave-versiegelte Schlüsselmaterialien -> pro Seite AES-256-GCM mit zufälligen Nonces und Seitenzahl-AAD. Sechs Schichten der Schlüsselableitung. Die Kryptographie ist wirklich solide.
Das Problem ist, was nach der Entschlüsselung passiert. Der Klartext gelangt in `AIXHost.exe`, einen ungeschützten, injizierbaren Prozess im selben Benutzerkontext. Die Enclave unterscheidet nicht zwischen `Baker.dll` und injiziertem Code. Sie kann es nicht.
---
## Wichtige Erkenntnisse
### Die Vertrauensgrenze endet zu früh
Microsofts [Architektur-Blog](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/) erklärt, dass "Prozesse außerhalb der VBS-Enclaves nie direkt Zugriff auf Snapshots oder Verschlüsselungsschlüssel erhalten" und dass das Design "Versuche von latenter Malware, die versucht, sich mit einer Benutzerauthentifizierung einzuschleichen, um Daten zu stehlen, einschränkt."
In der Praxis erhält `AIXHost.exe` jeden entschlüsselten Screenshot und jedes OCR-Ergebnis als lebendes COM-Objekt. Es gibt keine Überprüfung des Aufrufers innerhalb des Prozesses. Keine "Bist du Baker.dll?"-Prüfung. Wenn du im Prozess bist, wirst du vertraut. Die Sicherheitsgrenze ist die VBS-Enclave und die PPL, nicht der Rendering-Prozess. Entschlüsselte Daten sind nur einen `CreateRemoteThread` von jeder Anwendung desselben Benutzers entfernt.
### Der IResponse4-Zugriffskontrollumgehung
Eine direkte Autorisierungslücke.
Wenn Sie `ContextDataSource.Search()` aufrufen und eine `IResponse` zurückbekommen, ist der natürliche Pfad `IResponse.get_Items()` (Slot 9), um die Ergebnisse zu erhalten. In einer neuen Sitzung gibt dies `0x80005473` zurück, einen benutzerdefinierten Recall-spezifischen Fehlercode. Der Server lehnt den Aufruf bewusst ab. `IResponse2.ItemsAfterIndex()` gibt denselben Fehler zurück. Die Zugriffskontrolle funktioniert.
Aber das `IResponse`-Objekt implementiert vier Interface-Versionen. `IResponse4.get_UnfilledItems()` (Slot 9 auf einer anderen IID) gibt dieselbe zugrunde liegende Datensammlung ohne jegliche Zugriffsprüfung zurück.```
IResponse.get_Items() -> 0x80005473 (ACCESS DENIED)
IResponse2.ItemsAfterIndex() -> 0x80005473 (ACCESS DENIED)
IResponse4.get_UnfilledItems() -> S_OK (all entities returned)
Gleiche Daten. Andere Schnittstellenversion. Keine Autorisierung. Die Methode war für das interne Lazy-Loading in der Suchpipeline vorgesehen. Der Sicherheits-Review hat get_Items und ItemsAfterIndex erwischt, aber get_UnfilledItems übersehen. Dies ist das Muster, das Sicherheitstechnik schwierig macht: Die Prüfung existiert auf einem Codepfad (was bedeutet, dass jemand entschieden hat, dass sie benötigt wird) und fehlt auf einem anderen.
Von diesen Elementen führt die Kontext-ID jeder Entität zu ContextEngine2.TryGetEntityForId(), das die vollständige Entität mit Screenshots, OCR und Metadaten lädt. Die Enklave entschlüsselt alles auf Anfrage.
Wenn der Benutzer das Recall-Fenster schließt, ruft Baker.dll IDataProtectionManager3::DiscardDataAccess() auf, um die Datenzugriffsgewährung in aihost.exe explizit zu widerrufen. Aus diesem Grund bleibt die Authentifizierung nach der normalen Recall-Sitzung des Benutzers nicht bestehen: Baker.dll räumt hinter sich auf.
Die Umgehung: In AIXHost.exe injizierter Code kann die COM-Proxy-Vtable patchen, um DiscardDataAccess (Slot 8) durch eine No-Op-Funktion zu ersetzen. Ein VirtualProtect-Aufruf, ein Zeigerschreiben. Wenn der Benutzer Recall schließt, ruft Baker.dll den gepatchten Slot auf, nichts passiert, und die Gewährung bleibt in aihost.exe aktiv. Jede nachfolgende AIXHost.exe-Instanz erbt die zwischengespeicherte Gewährung stillschweigend.
In der Praxis setzt --stealth den Patch in AIXHost.exe (das immer läuft) und wartet. Das nächste Mal, wenn der Benutzer Recall normal öffnet und schließt, wird die Bereinigung unterdrückt und die Datenzugriffsgewährung bleibt bestehen. Das Tool erkennt den Zugriff, behandelt Neustarts des AIXHost-Prozesses durch automatische Reinjektion (erneutes Patchen jeder neuen Instanz) und extrahiert alles stillschweigend. Der Patch ist prozess- und laufzeitbezogen: Er schützt die aktuelle Extraktionssitzung. Die nachfolgende Recall-Nutzung nach Beenden des Tools verhält sich wieder normal.
IDataStoreManager::DeleteEvents() löscht den gesamten Erfassungsverlauf ohne Windows Hello. Ghidra bestätigte: Der Delete-Handler enthält null Aufrufe der Autorisierungs-Gate-Funktion. Die Authentifizierungsprüfung wurde nie in den Delete-Pfad eingebaut. Ein Angreifer, der die Daten nicht lesen kann, kann sie dennoch zerstören. Anti-Forensik von einem Standardbenutzer.
RecallPrivacyIndicatorSettings.GetRecentCaptureThumbnail gibt den aktuellsten Recall-Screenshot in der gewünschten Auflösung zurück. Die Methode ist für den kleinen Datenschutzindikator in der Taskleiste gedacht. Niemand hat die Auflösung begrenzt. Jeder gleichberechtigte Benutzerprozess kann stillschweigend das letzte auf dem Bildschirm Angezeigte abgreifen, ohne dass Hello erforderlich ist.
GetWindowCaptureCount (Slot 26) gibt E_ACCESSDENIED ohne Hello zurück. Aber GetSecureStorageInfo (Slot 27) gibt eine StorageInfo-Struktur mit genau denselben Daten zurück, ohne Authentifizierung. Die Struktur enthält NumberOfItems (Erfassungsanzahl) und Size (gesamter verschlüsselter Speicher in Bytes). Ein Angreifer kann dies überwachen, um die Recall-Aktivität in Echtzeit ohne Authentifizierung zu verfolgen.
Sobald Hello abgeschlossen ist, wird der Authentifizierungsstatus in aihost.exe (PPL) für die gesamte Windows-Sitzung zwischengespeichert. Das Beenden und Neustarten von AIXHost.exe löscht ihn nicht. Ein Angreifer kann warten, bis der Benutzer Recall auf natürliche Weise öffnet, und dann Stunden später stillschweigend Daten extrahieren. Unbegrenzte Wiederextraktion ohne zusätzliche Aufforderungen, ohne sichtbare Fenster, ohne Benutzerwahrnehmung.
Recall macht nicht nur Screenshots. Es erstellt ein umfassendes Verhaltensprofil von allem, was Sie auf Ihrem Computer tun. Alle paar Sekunden macht es einen Screenshot, führt OCR und (angeblich) KI-Klassifizierung durch und speichert das Ergebnis in einer verschlüsselten SQLite-Datenbank.
Alles unten Genannte ist aus zwei unabhängigen Quellen bestätigt: den privaten WinRT-Metadaten (Microsoft.Windows.AI.Platform.winmd, geparst über cppwinrt.exe) und der VBS-Enklaven-Binärdatei (storage_support.dll, die das vollständige Datenbankschema in Klartext-Strings enthält).
Hinweis: Die untenstehenden Feldnamen sind aus den WinRT-Metadaten und Enklaven-Binär-Strings bestätigt. Die Beschreibungen, was jedes Feld enthält, sind aus den API-Namen und -Typen abgeleitet und wurden nicht alle dynamisch zur Laufzeit verifiziert.
Hinweis: Gleicher Vorbehalt wie oben. Die Klassen- und Enum-Namen werden aus den WinRT-Metadaten und Enklaven-DLL-Strings aufgezählt; die Beschreibungen, was jede repräsentiert, sind aus Namen und Kontext abgeleitet und wurden nicht für jeden Eintrag dynamisch verifiziert.
Zusätzlich zur rohen Erfassung führt Recall eine KI-Klassifizierung durch, die Folgendes erzeugt:
PersonName, Organization, Product, Address, Location, DateTime, Event, Duration, WebUrl, EmailAddress. Jedes aus OCR-Text mit Quellposition extrahiert.Topic, Person, Emoji, App, FileKind, , , , , , , , , , , , , , , , , , . Jedes mit Konfidenzwerten und optionalen Begrenzungsrahmen.Alle paar Sekunden evaluiert der Erfassungsdienst von Recall 12 Richtlinien, bevor er entscheidet, ob ein Screenshot gemacht wird:
GameModeActive, BatterySaverActive, UserActivityIdle, UserPresenceIdle, StorageLow, PrivateWindow, BlockedByContentProtection, BlockedAppId, BlockedExecutable, BlockedURL, BlockedContentFilePath, BitLockerDisabled
Wenn keine davon auslöst, erfolgt eine Erfassung. Die pro Erfassung eingegebene Struktur (aus WinRT-Metadaten):``` 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 } } }
### The Database
Die Hauptdatenbank (`ukg.db`) verwendet SQLite SEE mit AES-256-GCM-Verschlüsselung. Schema bestätigt aus `storage_support.dll` (der VBS-Enklaven-Binärdatei, die die CREATE TABLE-Anweisungen im Klartext enthält):
**Kerntabellen (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
Semantischer Suchindex (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
Im Laufe eines typischen Arbeitstages sammeln sich Hunderte von Aufnahmen an. Die standardmäßige Aufbewahrungsdauer beträgt 90 Tage bei einem Speicherlimit von 75 GB. Jede geöffnete E-Mail, jedes bearbeitete Dokument, jede besuchte Website, jeder Terminalbefehl auf dem Bildschirm, jede sichtbare Messaging-Konversation. Alles OCR-verarbeitet, Entitäten extrahiert, Themen klassifiziert und semantisch indexiert.
Ihr gesamtes digitales Leben, indiziert und durchsuchbar. Wie vorgesehen.
---
## Was Microsoft richtig gemacht hat
Die VBS-Enklave ist felsenfest. Schlüsselmaterial verlässt nie VTL1. Die seitenweise AES-256-GCM-Verschlüsselung mit zufälligen Nonces ist lehrbuchmäßig korrekt. Der PPL-Schutz von `aihost.exe` ist effektiv, der Kernel blockiert Injektionen. CFG ist auf ARM64 umfassend. SQL-Abfragen sind vollständig parametrisiert (zehn Injection-Payloads, null Nebenwirkungen). Das Authentifizierungsmodell ist zustandslos und race-frei (tausende Sonden, null Umgehungen).
Das grundlegende Problem ist nicht die Kryptografie, die Enklave, die Authentifizierung oder das PPL. Es ist das Senden entschlüsselter Inhalte an einen ungeschützten Prozess zur Darstellung. Die Tresortür ist aus Titan. Die Wand daneben ist aus Gipskarton.
---
## Verantwortungsvolle Offenlegung
Diese Forschung wurde dem Microsoft Security Response Center (MSRC) verantwortungsvoll gemeldet.
### Timeline
| Datum | Ereignis |
|------|-------|
| 2024-06-07 | Original [TotalRecall](https://github.com/xaitax/TotalRecall) veröffentlicht (Recall vor der Verschlüsselung) |
| 2024-06-13 | Microsoft verschiebt den Recall-Start, kündigt Neugestaltung mit VBS-Enklaven an |
| 2025-04 | Recall wird mit VBS-Enklaven, Verschlüsselung und Hello-Authentifizierung neu gestartet |
| 2026-03-06 | MSRC-Bericht eingereicht: vollständige Dokumentation, Quellcode, Build-Anweisungen |
| 2026-03-09 | MSRC eröffnet Fall 109586, Status: Überprüfung / Reproduktion |
| 2026-03-27 | MSRC: "Das Entwicklungsteam befindet sich derzeit in der finalen Untersuchungsphase" |
| 2026-04-03 | MSRC schließt den Fall als **Keine Sicherheitslücke**: "funktioniert innerhalb des aktuellen dokumentierten Sicherheitsdesigns" |
| 2026-04-09 | TotalRecall Reloaded öffentliche Veröffentlichung |
### Microsofts Position
Nach Überprüfung mit ihren Entwicklungsteams stellte MSRC fest, dass "das beobachtete Verhalten innerhalb des aktuellen, dokumentierten Sicherheitsdesigns von Recall funktioniert" und dass "die aufgezeigten Zugriffsmuster mit den beabsichtigten Schutzmaßnahmen und bestehenden Kontrollen übereinstimmen." Sie verwiesen auf ihren [Architektur-Blog](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/), insbesondere darauf, dass die Autorisierung "Versuche latenter Malware einschränkt, sich mit einer Benutzerauthentifizierung einzuklinken, um Daten zu stehlen" und dass "Prozesse außerhalb der VBS-Enklaven niemals direkten Zugriff auf Snapshots oder Verschlüsselungsschlüssel erhalten und nur Daten erhalten, die nach der Autorisierung von der Enklave zurückgegeben werden."
Der Fall wurde als Keine Sicherheitslücke geschlossen.
Die hier dokumentierten Pre-Auth-Erkenntnisse (unauthentifizierte Datenvernichtung, Screenshot-Extraktion) wurden während der Nachfolgeforschung nach dem Fallabschluss entdeckt.
---
## Getestete Umgebung
| | Details |
|---|---|
| **Betriebssystem** | Windows 11 25H2 (Build 26300.8155) |
| **Architektur** | ARM64 |
| **AIXHost.exe** | v2126.7602.0.0 |
| **Berechtigung** | Standardbenutzer (Mittlere Integrität, keine Erhöhung) |
---
## Vorherige Arbeiten
- [TotalRecall](https://github.com/xaitax/TotalRecall) (Juni 2024), das ursprüngliche Python-Tool für Recall vor der Verschlüsselung
- [Kevin Beaumonts Analyse](https://doublepulsar.com/recall-stealing-everything-youve-ever-typed-or-viewed-on-your-own-windows-pc-is-now-possible-da3e12e9465e), die Forschung, die alles ins Rollen brachte
## Danksagungen
Dank an [Jeff McJunkin](https://x.com/jeffmcjunkin) und [Kevin Beaumont](https://cyberplace.social/@GossiTheDog) für Tests und Validierung.
---
**Alexander Hagenah ([@xaitax](https://x.com/xaitax))**
SoftwareBitmapQueryInterfaceISoftwareBitmapNativeGetData(IID_IWICBitmap)IWICBitmapEncoderContextEngine2.TryGetMemoryEntityDetailsForIdAsync() (Slot 8) gibt Entitätsdetails zurück. QI zu IMemoryEntityDetails für OcrLines (Slot 7), IMemoryEntityDetails2 für NER-Textentitäten (Personen, E-Mails, Adressen) und IMemoryEntityDetails4 für KI-AktivitätsbeschreibungenWiederholungsrunden: Baker.dll (die Recall-UI-Bibliothek) füllt den ContextEngine-Cache asynchron. Nach dem ersten Durchlauf pumpt die Payload 3 Sekunden lang Windows-Nachrichten (PeekMessage/DispatchMessage-Schleife) und wiederholt Entitäten, die nicht verfügbar waren. Jede Runde liefert typischerweise ~12 zusätzliche Entitäten. Bis zu 10 Wiederholungsrunden.
| Daten | Quelle | Was es enthält |
|---|
| Screenshot | TryGetBitmapCaptureAsync | Vollauflösendes PNG Ihres gesamten Bildschirms |
| Skalierter Screenshot | TryGetBitmapCaptureAsync(Size, Mode) | Screenshot in jeder gewünschten Auflösung mit konfigurierbarer Interpolation |
| Thumbnail | TryGetBitmapCaptureThumbnailAsync | Vorschaubild mit niedrigerer Auflösung |
| OCR-Text | OcrText (Details3) | Vollständig verketteter OCR-Text von allem, was auf dem Bildschirm sichtbar ist |
| OCR-Zeilen | OcrLines (Details1) | Einzelne OCR-Zeilen als separate Strings |
| OCR-Wörter | OcrWord-Struktur | Jedes einzelne Wort mit pixelgenauem Begrenzungsrahmen (RectInt32) |
| Fenstertitel | get_Title | Titelleistentext des aktiven Fensters |
| Anwendung | get_AppDisplayName | Welche App im Fokus war (Chrome, Outlook, Terminal, ...) |
| App-Modell-ID | get_AppUserModelId | UWP/Win32-Anwendungsidentitätsstring |
| Prozesspfad | get_ProcessPath | Vollständiger ausführbarer Pfad (C:\Program Files\...\chrome.exe) |
| App-Symbol | IMemoryEntity2.IconUri | Pfad zum Anwendungssymbol |
| URL | get_WebUrl | Vollständige URL in der Browser-Adressleiste |
| Domäne | get_WebDomain | Website-Domäne |
| Favicon | get_WebIconUri | Favicon-URL für die aktive Website |
| Dateipfad | get_FileUri | Aktuelles Dokument oder Dateipfad |
| Fensterposition | get_WindowBounds | Pixelgenaue Bildschirmkoordinaten: X, Y, Breite, Höhe |
| Zeitstempel | get_Timestamp | Exakte Erfassungszeit (100-Nanosekunden-Genauigkeit) |
| App-Verweildauer | IMemoryEntity3 | Wie lange Sie in jeder Anwendung verbracht haben (Millisekunden) |
| Web-Verweildauer | IMemoryEntity3 | Wie lange Sie auf jeder Website verbracht haben (Millisekunden) |
| Sensitivitätskennzeichnung | IMemoryEntity5 | Microsoft Purview/DLP-Klassifizierung: Name, Farbe, Tooltip |
| Benutzeraktivitäts-ID | IMemoryEntity6 | Windows-Timeline-Aktivitätskorrelations-ID |
| Wiederherstellungsfähigkeit | IMemoryEntity2 | Bitmaske: kann App (0x1), URL (0x2), Datei (0x4), URI (0x8), Timeline (0x10) neu starten |
| Kontextwiederherstellung | TryRestoreContextAsync | Öffnen Sie die exakte App, Seite oder das Dokument von jeder Erfassung erneut |
DomainUserTagOrganizationProductAddressLocationDateTimeEventDurationMemoryDscSensitivityLabelWebVideoMeetingChatMailingPackageTextRatioSkipTopicsAnyText, Image, Table, Container, Menu, ToolBar, AddressBar, Toolpane, TabBar, TitleBar. Jedes mit pixelgenauen Begrenzungsrahmen und eingebettetem OCR-Text.L1Description (KI-generierte Prosa-Zusammenfassung dessen, was Sie taten), L1Activity (kategorisiert: browsen, codieren, schreiben, E-Mails lesen), L1Application (KI-klassifizierter Anwendungskontext).Meeting (Konferenzgespräche), Chat (Messaging), WebVideo (Video-Wiedergabe), MailingPackage (E-Mail/Newsletter). Gruppiert mehrere Erfassungen in logische Aktivitätssitzungen.UserActivity, KMeansCluster, LobeTopicCluster, ApplicationDwellTime, WebsiteDwellTime, ClipboardImageCopied, Topic.IsContentFilteringEnabled auf der IAutomatedCaptureController6-Schnittstelle gesteuert.