TotalRecall Reloaded

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.

Come funziona

L'iniezione

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.

Autenticazione

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ì:

1. Inietta in AIXHost.exe (sempre in esecuzione) e corregge DiscardDataAccess in un no-op
2. Attende silenziosamente che l'utente apra Recall e si autentichi normalmente
3. Quando l'utente chiude Recall, Baker.dll tenta di revocare la concessione di accesso ai dati, ma la patch la blocca
4. AIXHost.exe muore e si riavvia. Lo strumento rileva il riavvio e reinietta nel nuovo processo
5. La concessione di autenticazione persiste in aihost.exe (la revoca è stata bloccata). L'estrazione inizia immediatamente
6. Nessun Win+J, nessun prompt Hello, nessuna UI visibile. Fino a 5 tentativi di reiniezione.

--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.

La catena di estrazione

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:

1. 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).

2. 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à.

3. 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ì:

   • Metadati (sincroni): titolo (slot 8), ID del modello dell'app (slot 9), nome dell'app (slot 10), percorso del processo (slot 11), URL (slot 12), dominio (slot 13), URI del file (slot 15), timestamp (slot 7), limiti della finestra (slot 16). Tramite QI a IMemoryEntity2/3: capacità di ripristino, tempo di permanenza nell'app, tempo di permanenza nel web
   • Screenshot (asincrono): (slot 19) restituisce un . in , chiamare per ottenere un bitmap WIC, codificare come PNG tramite

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.

Capacità pre-autenticazione

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.

Utilizzo

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)

| Modalità | Aut. Richiesta | Cosa fa |
|------|:---:|-------------|
| `--launch` | Sì | Simula Win+J, l'utente si autentica, estrazione completa |
| `--stealth` | Passivo | Corregge la revoca dell'autenticazione, attende che l'utente autentichi Recall, estrae silenziosamente |
| `--wait` | Sì | Attende che l'utente apra Recall naturalmente, poi estrae |
| `--preauth` | **No** | Ultimo screenshot + tutte le impostazioni |
| `--search` | No | Ricerca testo OCR senza distinzione tra maiuscole e minuscole nell'ultima estrazione |
| `--destroy` | **No** | `DeleteEvents()`, irreversibile, richiede di digitare DESTROY per confermare |

### Esempio di Output

**`--stealth` (prima esecuzione, in attesa dell'utente):**```
[+] 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 (esecuzione successiva, sessione in cache):``` [+] 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 (nessun Hello richiesto):``` [+] 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

Directory di Output```

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

## Compilazione

**Requisiti:** Visual Studio con strumenti ARM64 C++, Windows 11 ARM64 con Recall abilitato.```
make.bat

Produces totalrecall.exe and totalrecall_payload.dll. Both must be in the same directory when run.

Il modello di fiducia di 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 | +--------------------------------------------------+

La gerarchia delle chiavi: Hello -> NGC ECDH P-384 (con supporto TPM) -> autenticazione reciproca VTL1 -> materiale chiave sigillato nell'enclave -> AES-256-GCM per pagina con nonce casuali e AAD del numero di pagina. Sei strati di derivazione delle chiavi. La crittografia è davvero solida.

Il problema è ciò che accade dopo la decifratura. Il testo in chiaro passa in `AIXHost.exe`, un processo dello stesso utente non protetto e iniettabile. L'enclave non fa distinzione tra `Baker.dll` e codice iniettato. Non può farlo.

---

## Risultati Chiave

### Il confine di fiducia termina troppo presto

Il [blog sull'architettura](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/) di Microsoft afferma che "i processi al di fuori delle VBS Enclave non ricevono mai accesso diretto a snapshot o chiavi di crittografia" e che il design "limita i tentativi di malware latenti di approfittare dell'autenticazione utente per rubare dati."

In pratica, `AIXHost.exe` riceve ogni screenshot decifrato e risultato OCR come un oggetto COM attivo. Non c'è verifica per chiamante all'interno del processo. Nessun controllo "sei Baker.dll?". Se sei nel processo, sei considerato affidabile. Il confine di sicurezza è l'enclave VBS e il PPL, non il processo di rendering. I dati decifrati sono a un solo `CreateRemoteThread` di distanza da qualsiasi applicazione dello stesso utente.

### L'elusione del controllo di accesso di IResponse4

Un divario diretto nell'autorizzazione.

Quando chiami `ContextDataSource.Search()` e ottieni una `IResponse`, il percorso naturale è `IResponse.get_Items()` (slot 9) per ottenere i risultati. Su una sessione fresca, questo restituisce `0x80005473`, un codice di errore personalizzato specifico di Recall. Il server sta deliberatamente rifiutando la chiamata. `IResponse2.ItemsAfterIndex()` restituisce lo stesso errore. Il controllo di accesso funziona.

Ma l'oggetto `IResponse` implementa quattro versioni dell'interfaccia. `IResponse4.get_UnfilledItems()` (slot 9 su un IID diverso) restituisce la stessa raccolta dati sottostante senza alcun controllo di accesso.```
IResponse.get_Items()           -> 0x80005473 (ACCESS DENIED)
IResponse2.ItemsAfterIndex()    -> 0x80005473 (ACCESS DENIED)
IResponse4.get_UnfilledItems()  -> S_OK (all entities returned)

Stessi dati. Versione diversa dell'interfaccia. Nessuna autorizzazione. Il metodo era destinato al caricamento lazy interno nella pipeline di ricerca. La revisione di sicurezza ha individuato get_Items e ItemsAfterIndex, ma ha mancato get_UnfilledItems. Questo è il modello che rende difficile l'ingegneria della sicurezza: il controllo esiste su un percorso di codice (il che significa che qualcuno ha deciso che fosse necessario) ed è assente su un altro.

Da quegli elementi, l'ID contestuale di ciascuna entità porta a ContextEngine2.TryGetEntityForId(), che carica l'entità completa con screenshot, OCR e metadati. L'enclave decifra tutto su richiesta.

L'elusione di DiscardDataAccess

Quando l'utente chiude la finestra di Recall, Baker.dll chiama IDataProtectionManager3::DiscardDataAccess() per revocare esplicitamente la concessione di accesso ai dati in aihost.exe. Questo è il motivo per cui l'autenticazione non persiste dopo la normale sessione di Recall dell'utente: Baker.dll pulisce dopo di sé.

L'elusione: il codice iniettato all'interno di AIXHost.exe può modificare la vtable del proxy COM per sostituire DiscardDataAccess (slot 8) con una funzione no-op. Una chiamata a VirtualProtect, una scrittura di puntatore. Quando l'utente chiude Recall, Baker.dll chiama lo slot modificato, non succede nulla e la concessione rimane attiva in aihost.exe. Qualsiasi istanza successiva di AIXHost.exe eredita silenziosamente la concessione memorizzata nella cache.

In pratica, --stealth distribuisce la patch in AIXHost.exe (che è sempre in esecuzione) e attende. La prossima volta che l'utente apre e chiude Recall normalmente, la pulizia viene soppressa e la concessione di accesso ai dati persiste. Lo strumento rileva l'accesso, gestisce i riavvii del processo AIXHost tramite re-iniezione automatica (riapplicando la patch a ogni nuova istanza) ed estrae tutto silenziosamente. La patch è per processo e per esecuzione: protegge la sessione di estrazione corrente. L'utilizzo successivo di Recall dopo l'uscita dello strumento torna al comportamento normale.

DeleteEvents: Distruzione senza autenticazione

IDataStoreManager::DeleteEvents() cancella l'intera cronologia delle acquisizioni senza Windows Hello. Ghidra ha confermato: il gestore di eliminazione contiene zero chiamate alla funzione gate di autorizzazione. Il controllo di autenticazione non è mai stato collegato al percorso di eliminazione. Un utente malintenzionato che non può leggere i dati può comunque distruggerli. Anti-forense da utente standard.

Estrazione di screenshot pre-autenticazione

RecallPrivacyIndicatorSettings.GetRecentCaptureThumbnail restituisce l'ultimo screenshot di Recall a qualsiasi risoluzione richiesta. Il metodo è destinato al piccolo indicatore di privacy nella barra delle applicazioni. Nessuno ha limitato la risoluzione. Qualsiasi processo dello stesso utente può catturare silenziosamente l'ultima cosa visualizzata sullo schermo, senza Hello.

Conteggio delle acquisizioni pre-autenticazione tramite GetSecureStorageInfo

GetWindowCaptureCount (slot 26) restituisce E_ACCESSDENIED senza Hello. Ma GetSecureStorageInfo (slot 27) restituisce una struttura StorageInfo con esattamente gli stessi dati, senza necessità di autenticazione. La struttura contiene NumberOfItems (conteggio delle acquisizioni) e Size (dimensione totale della memoria crittografata in byte). Un utente malintenzionato può monitorarlo per tracciare l'attività di Recall in tempo reale senza alcuna autenticazione.

Persistenza dello stato di autenticazione

Una volta completato Hello, lo stato di autenticazione viene memorizzato nella cache in aihost.exe (PPL) per l'intera sessione di Windows. L'uccisione e il riavvio di AIXHost.exe non lo cancellano. Un utente malintenzionato può attendere che l'utente apra naturalmente Recall, quindi estrarre silenziosamente i dati ore dopo. Re-estrazione illimitata senza ulteriori richieste, senza finestre visibili, senza che l'utente ne sia a conoscenza.

Cosa acquisisce Recall (e cosa viene estratto)

Recall non solo acquisisce screenshot. Costruisce un profilo comportamentale completo di tutto ciò che fai sul computer. Ogni pochi secondi, acquisisce uno screenshot, esegue OCR e (presumibilmente) classificazione AI su di esso e memorizza il risultato in un database SQLite crittografato.

Tutto quanto segue è confermato da due fonti indipendenti: i metadati WinRT privati (Microsoft.Windows.AI.Platform.winmd, analizzati tramite cppwinrt.exe) e il binario dell'enclave VBS (storage_support.dll, che contiene l'intero schema del database in stringhe di testo semplice).

Dati per acquisizione

Nota: i nomi dei campi di seguito sono confermati dai metadati WinRT e dalle stringhe del binario dell'enclave. Le descrizioni di ciò che contiene ciascun campo sono dedotte dai nomi e dai tipi delle API e non sono state tutte verificate dinamicamente in fase di esecuzione.

Metadati elaborati dall'AI

Nota: stessa avvertenza di cui sopra. I nomi delle classi e degli enum sono elencati dai metadati WinRT e dalle stringhe della DLL dell'enclave; le descrizioni di ciò che ciascuno rappresenta sono dedotte da nomi e contesto e non sono state verificate dinamicamente per ogni voce.

Oltre all'acquisizione grezza, Recall esegue una classificazione AI che produce:

• Riconoscimento di entità nominate (10 tipi): PersonName, Organization, Product, Address, Location, DateTime, Event, Duration, WebUrl, EmailAddress. Ciascuna estratta dal testo OCR con posizione sorgente.
• Classificazione per argomento (23 categorie): Topic, Person, Emoji, App, FileKind, , , , , , , , , , , , , , , , , , . Ciascuna con punteggi di confidenza e bounding box opzionali.

Pipeline di acquisizione

Ogni pochi secondi, il servizio di acquisizione di Recall valuta 12 criteri prima di decidere se acquisire lo screenshot:

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

Se nessuno di questi viene attivato, acquisisce. La struttura di input per acquisizione (dai metadati 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 } } }

### Il database

Il database principale (`ukg.db`) utilizza SQLite SEE con crittografia AES-256-GCM. Schema confermato da `storage_support.dll` (il binario VBS enclave che contiene le istruzioni CREATE TABLE in chiaro):

**Tabelle principali (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

Indice di ricerca semantica (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

In una tipica giornata lavorativa, centinaia di acquisizioni si accumulano. La conservazione predefinita è di 90 giorni con una soglia di archiviazione di 75 GB. Ogni email aperta, ogni documento modificato, ogni sito web visitato, ogni comando del terminale sullo schermo, ogni conversazione di messaggistica visibile. Tutti elaborati con OCR, con estrazione di entità, classificazione per argomento e indicizzazione semantica.

La tua intera vita digitale, indicizzata e ricercabile. Come previsto.

---

## Cosa Microsoft ha fatto bene

L'enclave VBS è solida come una roccia. Il materiale crittografico non lascia mai VTL1. La crittografia AES-256-GCM per pagina con nonce casuali è tecnicamente corretta. La protezione PPL di `aihost.exe` è efficace, il kernel blocca l'iniezione. CFG è completo su ARM64. Le query SQL sono completamente parametrizzate (dieci payload di injection, zero effetti collaterali). Il modello di autenticazione è stateless e privo di race condition (migliaia di sonde, zero bypass). Il problema fondamentale non è la crittografia, l'enclave, l'autenticazione o il PPL. È l'invio di contenuti decrittati a un processo non protetto per il rendering. La porta del caveau è di titanio. Il muro accanto è di cartongesso.

---

## Divulgazione Responsabile

Questa ricerca è stata divulgata responsabilmente al Microsoft Security Response Center (MSRC).

### Timeline

| Data | Evento |
|------|--------|
| 2024-06-07 | Rilasciato l'originale [TotalRecall](https://github.com/xaitax/TotalRecall) (Recall pre-crittografia) |
| 2024-06-13 | Microsoft ritarda il lancio di Recall, annuncia riprogettazione con enclave VBS |
| 2025-04 | Recall viene rilanciato con enclave VBS, crittografia, autenticazione Hello |
| 2026-03-06 | Rapporto MSRC inviato: documentazione completa, codice sorgente, istruzioni di build |
| 2026-03-09 | MSRC apre il Caso 109586, stato: Revisione/Repro |
| 2026-03-27 | MSRC: "il team di ingegneria è attualmente nella fase finale di indagine" |
| 2026-04-03 | MSRC chiude il caso come **Non una Vulnerabilità**: "opera all'interno dell'attuale progetto di sicurezza documentato" |
| 2026-04-09 | Rilascio pubblico di TotalRecall Reloaded |

### Posizione di Microsoft

Dopo la revisione con i loro team di ingegneria, MSRC ha stabilito che "il comportamento osservato opera all'interno dell'attuale progetto di sicurezza documentato di Recall" e che "i pattern di accesso dimostrati sono coerenti con le protezioni previste e i controlli esistenti." Hanno citato il loro [blog sull'architettura](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/), in particolare che l'autorizzazione "limita i tentativi di malware latente di sfruttare l'autenticazione di un utente per rubare dati" e che "i processi esterni alle enclave VBS non ricevono mai direttamente accesso agli snapshot o alle chiavi di crittografia e ricevono solo dati restituiti dall'enclave dopo l'autorizzazione." Il caso è stato chiuso come Non una Vulnerabilità.

Le scoperte relative alla pre-autenticazione documentate qui (distruzione di dati non autenticata, estrazione di screenshot) sono state scoperte durante ricerche successive alla chiusura del caso.

---

## Ambiente Testato

| | Dettagli |
|---|---|
| **Sistema operativo** | Windows 11 25H2 (Build 26300.8155) |
| **Architettura** | ARM64 |
| **AIXHost.exe** | v2126.7602.0.0 |
| **Privilegio** | Utente standard (Integrità media, nessuna elevazione) |

---

## Lavori Precedenti

- [TotalRecall](https://github.com/xaitax/TotalRecall) (giugno 2024), il tool Python originale per Recall pre-crittografia
- [L'analisi di Kevin Beaumont](https://doublepulsar.com/recall-stealing-everything-youve-ever-typed-or-viewed-on-your-own-windows-pc-is-now-possible-da3e12e9465e), la ricerca che ha dato il via a tutto

## Ringraziamenti

Grazie a [Jeff McJunkin](https://x.com/jeffmcjunkin) e [Kevin Beaumont](https://cyberplace.social/@GossiTheDog) per i test e la validazione.

---

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