
Questo strumento estrae e visualizza i dati dalla funzionalità Recall in Windows 11, offrendo un modo semplice per accedere alle informazioni sugli snapshot delle attività del tuo PC.
Rompere Windows Recall. Ancora.
image
Quando Microsoft ha riprogettato Recall con VBS enclave, crittografia AES-256-GCM, autenticazione Windows Hello e un host Protected Process Light, il messaggio era chiaro: i dati sono chiusi in una cassaforte.
La cassaforte è solida. Il furgone per le consegne no.
AIXHost.exe, il processo che visualizza la timeline di Recall, non ha PPL, AppContainer, né controllo dell'integrità del codice. Qualsiasi processo in esecuzione come utente connesso può iniettarvi codice e chiamare le stesse API COM utilizzate dall'interfaccia utente legittima. Una volta che l'utente si autentica con Windows Hello, gli screenshot decifrati, il testo OCR e i metadati fluiscono attraverso AIXHost.exe come oggetti COM attivi. TotalRecall Reloaded si inserisce all'interno di quel processo ed estrae tutto.
Nessun admin richiesto. Utente standard. Nessun exploit del kernel. Nessun bypass crittografico. Solo chiamate COM.
TotalRecall Reloaded è composto da due file: un injector (totalrecall.exe) e una DLL payload (totalrecall_payload.dll).
L'injector trova AIXHost.exe tramite CreateToolhelp32Snapshot, alloca memoria nel processo target con VirtualAllocEx, scrive il percorso della DLL con WriteProcessMemory e avvia un thread remoto che punta a LoadLibraryW. Classica iniezione DLL. Niente di sofisticato, perché non serve nulla di sofisticato. AIXHost.exe non ha alcuna protezione contro di essa.
Questo funziona con privilegio di utente standard. Nessuna elevazione, nessun SeDebugPrivilege. Il DACL predefinito di Windows consente ai processi dello stesso utente l'accesso completo reciproco. Verificato: il token gira a livello obbligatorio Medium con BUILTIN\Administrators impostato su deny-only.
L'enclave VBS non decifrerà nulla senza Windows Hello. Lo strumento non lo bypassa. Fa sì che l'utente lo faccia, cavalca in silenzio quando l'utente lo fa, o attende che l'utente lo faccia.
--launch simula Win+J tramite keybd_event, la scorciatoia da tastiera che apre la timeline di Recall. L'utente vede un prompt Hello (volto, impronta digitale o PIN), si autentica e l'enclave inizia a servire dati decifrati. Dal punto di vista dell'utente, Recall si è aperto normalmente. Dal nostro, il payload è già all'interno, in attesa.
--stealth è la modalità completamente silenziosa. Funziona così:
AIXHost.exe (sempre in esecuzione) e corregge DiscardDataAccess in un no-opAIXHost.exe muore e si riavvia. Lo strumento rileva il riavvio e reinietta nel nuovo processoaihost.exe (la revoca è stata bloccata). L'estrazione inizia immediatamente--wait è la controparte passiva di --launch. Invece di simulare Win+J, lo strumento rimane inattivo mentre l'utente apre Recall da solo — dalla barra delle applicazioni, da un collegamento o da qualsiasi altro percorso. Quando AIXHost.exe appare e l'utente completa Hello naturalmente, il payload viene iniettato e l'estrazione inizia. Utile su una macchina osservata, o quando la sessione di Recall deve apparire interamente avviata dall'utente senza input sintetico da tastiera.
Una volta all'interno di AIXHost.exe, il payload inizializza un apartment COM con CoInitializeEx(COINIT_APARTMENTTHREADED) e imposta l'inoltro dell'identità proxy con CoSetProxyBlanket(EOAC_DYNAMIC_CLOAKING). Questo è fondamentale. Senza cloaking dinamico, il proxy COM non trasporta l'identità autenticata al server.
L'estrazione segue lo stesso percorso utilizzato dall'interfaccia utente legittima di Recall:
Inizializzazione dell'enclave: DataManager.Load() attiva il caricamento della chiave dell'enclave. DataStoreManager.DecryptDatabase() (slot 37) prepara le viste decifrate. Il payload esegue un polling di DataManager.DataStatus fino a quando restituisce 3 (sbloccato).
Enumerazione delle entità: MemoryEntityStatics.GetLightMemoryItemsBefore() (slot 9) restituisce un vettore di riferimenti leggeri alle entità. Ognuno porta un ID di contesto all'offset +8. Su una macchina tipica, questo restituisce centinaia di entità che coprono giorni o settimane di attività.
Estrazione per entità: Per ogni ID di contesto, il payload carica l'entità completa tramite ContextEngine2.TryGetEntityForId() (slot 6), la srotola attraverso IEntityWrapper (slot 6) e QueryInterface in IMemoryEntity. Da lì:
TryGetBitmapCaptureAsync() (slot 19) restituisce un SoftwareBitmap. QueryInterface in ISoftwareBitmapNative, chiamare GetData(IID_IWICBitmap) per ottenere un bitmap WIC, codificare come PNG tramite IWICBitmapEncoderContextEngine2.TryGetMemoryEntityDetailsForIdAsync() (slot 8) restituisce i dettagli dell'entità. QI in IMemoryEntityDetails per OcrLines (slot 7), IMemoryEntityDetails2 per entità di testo NER (persone, email, indirizzi) e IMemoryEntityDetails4 per descrizioni di attività AIRound di riprova: Baker.dll (la libreria dell'interfaccia utente di Recall) popola la cache di ContextEngine in modo asincrono. Dopo il passaggio iniziale, il payload pompa i messaggi di Windows per 3 secondi (ciclo PeekMessage/DispatchMessage) e riprova eventuali entità che non erano disponibili. Ogni round produce in genere ~12 entità aggiuntive. Fino a 10 round di riprova.
Ogni chiamata è racchiusa in __try/__except perché una singola violazione di accesso su una chiamata proxy COM uccide permanentemente il canale RPC verso aihost.exe. Non c'è recupero. Dovresti riavviare AIXHost.exe. I wrapper SEH intercettano i crash derivanti da tipi di parametri errati e mantengono attiva la sessione.
Diverse operazioni funzionano senza alcuna autenticazione Hello:
Estrazione di screenshot: RecallPrivacyIndicatorSettings (CLSID {42C63551-...}) espone GetRecentCaptureThumbnail(width, height) allo slot 13. Il nome del metodo dice "thumbnail" ma il server non impone un limite di risoluzione. Passando 3840x3840 restituisce il capture Recall più recente a piena risoluzione. Il risultato IRandomAccessStream viene convertito in un IStream tramite CreateStreamOverRandomAccessStream (shcore.dll) e scaricato come BMP.
Distruzione dei dati: IDataStoreManager::DeleteEvents() (slot 12) cancella l'intera cronologia dei capture. Nessun parametro, nessuna autenticazione. L'analisi con Ghidra ha confermato: il gestore di eliminazione all'indirizzo FUN_1802ddd10 contiene zero chiamate alla funzione gate di autorizzazione. Il controllo di autenticazione non è mai stato collegato.
Divulgazione dei metadati: I percorsi di archiviazione (incluso il GUID UKP specifico dell'utente), la dimensione del database, la politica di conservazione, lo stato del capture e l'ID di contesto del capture più recente sono tutti leggibili senza autenticazione tramite IDataStoreManagerStatics e RecallPrivacyIndicatorSettings.