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 SoftwareBitmap zurück. QueryInterface zu ISoftwareBitmapNative, Aufruf von GetData(IID_IWICBitmap), um eine WIC-Bitmap zu erhalten, Kodierung als PNG über 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.
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.