Client di sincronizzazione cloud: OneDrive, Google Drive e Dropbox

Un client di sincronizzazione trasforma una normale operazione sui file in un caricamento: copiare o spostare un file in una cartella monitorata è sufficiente per inviarlo nel cloud, senza browser e senza trasferimenti visibili. Questa lezione illustra dove OneDrive, Google Drive per desktop e Dropbox conservano i dettagli degli account, i database dei file e i log su Windows, perché un file in una cartella di sincronizzazione può essere privo di contenuto nell'immagine e come combinare le evidenze locali e quelle del fornitore per rispondere alla domanda «Questo file è stato caricato, quando e da quale account?». I formati dei client sono perlopiù non documentati e cambiano tra le versioni; pertanto, si considerino tutte le strutture di database e log riportate di seguito come tipiche delle versioni recenti e se ne verifichi la corrispondenza nelle evidenze.

OneDrive

OneDrive è integrato in Windows 10 e 11 e viene eseguito come OneDrive.exe nella sessione di ciascun utente, per impostazione predefinita da %LOCALAPPDATA%\Microsoft\OneDrive\ (le installazioni per computer utilizzano Program Files). Un account Microsoft personale si sincronizza per impostazione predefinita con C:\Users\<user>\OneDrive; un account aziendale o dell'istituto di istruzione si sincronizza con C:\Users\<user>\OneDrive - <Organization>, ad esempio OneDrive - Contoso. Le raccolte SharePoint sincronizzate dallo stesso account aziendale compaiono in una cartella che porta il nome dell'organizzazione.

Configurazione dell'account in NTUSER.DAT

Ogni account con cui è stato effettuato l'accesso dispone di una chiave in NTUSER.DAT\Software\Microsoft\OneDrive\Accounts\: Personal per un account Microsoft e Business1 (poi Business2 e così via) per gli account aziendali o dell'istituto di istruzione. Le chiavi contengono valori quali UserEmail (l'indirizzo di accesso) e UserFolder (la cartella radice di sincronizzazione locale), e la chiave personale contiene il cid dell'account, un identificatore di 16 cifre esadecimali che viene utilizzato anche per denominare i file nella cartella delle impostazioni. Poiché la chiave si trova nell'hive dell'utente stesso, associa una cartella radice di sincronizzazione e un indirizzo e-mail a un profilo Windows. I tempi di ultima scrittura della chiave indicano quando il client ha modificato per l'ultima volta la propria configurazione, non quando sono stati sincronizzati i file.

Cartella delle impostazioni e database di sincronizzazione

%LOCALAPPDATA%\Microsoft\OneDrive\settings\ contiene una sottocartella per ciascun tipo di account, Personal e Business1. Al suo interno si trovano piccoli file di testo, <cid>.ini (le raccolte sincronizzate e i relativi percorsi locali) e global.ini (le impostazioni del client), oltre al database dei file del client:

• SyncEngineDatabase.db nelle versioni attuali. È un database SQLite, quindi occorre acquisire anche i relativi file -wal e -shm. Tabelle come od_ClientFile_Records e od_ClientFolder_Records contengono una riga per ogni file o cartella noto al client, con il nome, un ID risorsa, l'ID risorsa della cartella padre, la dimensione, un hash del contenuto e i timestamp. Per ricostruire un percorso completo è necessario seguire gli ID delle cartelle padre fino alla radice.
• <cid>.dat nelle versioni precedenti: un file binario non documentato con voci analoghe per file e cartelle. Può essere ancora presente sui sistemi che sono stati aggiornati.

L'hash dipende dal tipo di account e dal servizio: gli account aziendali utilizzano QuickXorHash di Microsoft, un valore a 160-bit solitamente memorizzato come 28 caratteri Base64, mentre gli account personali hanno utilizzato SHA-1. QuickXorHash non è MD5 né SHA-256; pertanto, per confrontare un file nell'immagine con una riga del database è necessario calcolare lo stesso algoritmo sul file. Strumenti come OneDriveExplorer ricostruiscono l'albero delle cartelle a partire da questi database; DB Browser for SQLite consente di esaminare direttamente le righe.

Log ODL

%LOCALAPPDATA%\Microsoft\OneDrive\logs\ contiene sottocartelle quali Personal, Business1 e Common. Il motore di sincronizzazione scrive log binari ODL (.odl, .odlgz compressi e .odlsent; l'insieme delle estensioni varia tra le versioni) che registrano le operazioni di sincronizzazione, inclusi caricamenti, download, ridenominazioni ed eliminazioni, con un timestamp per ciascuna voce. I nomi dei file e le altre stringhe nei log sono protetti: le versioni precedenti li sostituivano con token elencati in ObfuscationStringMap.txt, mentre le versioni più recenti li cifrano con una chiave conservata in un file general.keystore. I decodificatori, come il parser ODL di OneDrive di Yogesh Khatri, richiedono tale file proveniente dalla stessa installazione; senza di esso sono visibili le operazioni, ma non i nomi. Acquisire l'intero albero logs e verificare quale fuso orario utilizza il parser per il proprio output.

File su richiesta e Known Folder Move

Con File su richiesta, che i client attuali attivano per impostazione predefinita, un file può essere solo online: il nome, la dimensione e i timestamp esistono localmente, ma il contenuto rimane nel cloud finché il file non viene aperto. NTFS memorizza un file di questo tipo come reparse point con attributi cloud (ad esempio FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS, spesso con FILE_ATTRIBUTE_OFFLINE) e il suo $DATA non ha cluster allocati. Un file «presente» in OneDrive - Contoso può quindi essere privo di contenuto nell'immagine; occorre segnalarlo come segnaposto e richiederne il contenuto al fornitore. I file che l'utente contrassegna con «Conserva sempre su questo dispositivo» sono mantenuti disponibili e interamente locali.

Known Folder Move reindirizza cartelle note come Desktop, Documenti e Immagini nella cartella OneDrive. Controllare NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (valori Desktop, Personal per Documenti e My Pictures): se puntano a OneDrive, ogni file salvato sul desktop era un candidato alla sincronizzazione.

Il cestino, la cronologia delle versioni e i link di condivisione di OneDrive risiedono nel cloud. Si tratta di dati del fornitore, non di artefatti dell'endpoint.

Google Drive per desktop

Google Drive per desktop (GoogleDriveFS.exe) conserva i propri dati in %LOCALAPPDATA%\Google\DriveFS\. Ogni account dispone di una sottocartella denominata con un lungo ID account numerico, contenente:

• metadata_sqlite_db (SQLite, senza estensione) con tabelle quali items e item_properties: nomi, relazioni con gli elementi padre, dimensione, ora di modifica e uno stable_id che collega le righe tra le tabelle.
• content_cache, una cartella di contenuti dei file memorizzati nella cache, in file privi dei nomi o delle estensioni originali. Identificarli in base alla firma e alla dimensione, quindi associarli alle righe del database.

Database come root_preference_sqlite.db nella cartella DriveFS contengono le preferenze degli account e di montaggio. I log sono in testo semplice: %LOCALAPPDATA%\Google\DriveFS\Logs\drive_fs.txt e file a rotazione drive_fs_<n>.txt, leggibili con qualsiasi editor di testo o grep.

Per impostazione predefinita, il client trasmette in streaming Il mio Drive tramite un'unità virtuale, solitamente G:. Tale unità non è un volume NTFS, quindi i file al suo interno non hanno voci $MFT nell'immagine del disco; soltanto il contenuto nella cache e il database li descrivono. In modalità mirroring, i file vengono memorizzati anche in una cartella locale e si comportano come normali file NTFS.

Dropbox

Dropbox memorizza il percorso della propria cartella di sincronizzazione in info.json, che si trova in %LOCALAPPDATA%\Dropbox\ o %APPDATA%\Dropbox\, con un valore path per ciascun account personale o aziendale. I dati del client si trovano in %LOCALAPPDATA%\Dropbox\instance1\ (con ulteriori istanze per ulteriori account). I file con estensione .dbx, come config.dbx e aggregation.dbx, sono database SQLite cifrati la cui chiave è protetta da DPAPI (Windows Data Protection API); per decifrarli è quindi necessario il materiale delle chiavi DPAPI dell'utente oppure una sessione attiva. Altri file, come sync_history.db, sono risultati leggibili in alcune versioni e cifrati in altre. Verificare ogni file prima di farvi affidamento: un file SQLite non cifrato inizia all'offset 0 con la stringa di intestazione di 16 byte SQLite format 3 più un byte nullo di terminazione (53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00), mentre un file cifrato no.

La cartella nascosta .dropbox.cache nella cartella radice di sincronizzazione conserva per un breve periodo, in genere alcuni giorni, copie dei file eliminati o modificati di recente. Può contenere dati che non esistono più in nessun'altra posizione sul disco.

Confronto tra i client

Metodo: il file X è stato caricato, quando e da quale account?

Nessun singolo artefatto risponde alla domanda. Costruire la risposta a partire da fonti indipendenti:

1. File system. Individuare il file nella cartella di sincronizzazione. Il suo tempo di creazione $SI registra quando il file è stato creato e viene mantenuto in caso di spostamento; uno spostamento o una ridenominazione nella cartella compare in $J sotto forma di record RENAME_OLD_NAME e RENAME_NEW_NAME, mentre una copia compare come un nuovo file creato in quella posizione (lezione 1.4).
2. Database del client. Individuare la riga con lo stesso nome, la stessa cartella padre e la stessa dimensione. Una riga del database indica che il client era a conoscenza del file; un hash corrispondente la collega al contenuto.
3. Log del client. Individuare la voce di caricamento e il relativo orario di completamento.
4. SRUM. Controllare i byte inviati da OneDrive.exe, GoogleDriveFS.exe o Dropbox.exe nell'intervallo che comprende il caricamento (lezione 2.8).
5. Account. Associare la cartella radice di sincronizzazione all'account tramite il registro, info.json o la cartella dell'account DriveFS.
6. Fornitore. Ove disponibile, il log di audit unificato di Microsoft 365 (operazioni quali FileUploaded e FileSyncUploadedFull) o il log di audit di Drive di Google Workspace conferma il caricamento, l'account e l'indirizzo IP del client.

Le acquisizioni di triage devono includere le cartelle delle impostazioni e dei log sopra indicate. Un'acquisizione che preleva soltanto gli hive del registro e i log eventi non può rispondere a questa domanda.

Esempio svolto

L'utente ana copia q3-files.7z da E:\Clients\ sull'unità USB (l'archivio creato nella lezione 3.4) in C:\Users\ana\OneDrive - Contoso\Shared\. Le evidenze:

Verifiche. Il caricamento è stato completato 14:01:41 − 14:01:03 = 38 secondi dopo l'ingresso del file nella cartella. 64.108.233 byte × 8 / 38 s = 13,5 Mbit/s, una velocità di caricamento plausibile. 64.108.233 / 1.048.576 = 61,1 MiB. I byte inviati registrati da SRUM superano la dimensione del file di 64.812.544 − 64.108.233 = 704.311 byte (circa l'1,1%), un valore compatibile con l'overhead del protocollo e altro traffico di sincronizzazione nello stesso intervallo; SRUM non può dimostrare che i byte corrispondessero a questo file. Se il file è ancora locale, calcolarne il QuickXorHash e confrontarlo con il valore del database.

Dichiarazione. «Alle 2026-03-14T14:01:03Z il file q3-files.7z (64.108.233 byte) è stato copiato dall'unità USB E:\ in C:\Users\ana\OneDrive - Contoso\Shared\, la cartella di sincronizzazione dell'account aziendale ana@contoso.com configurato nel profilo dell'utente ana. Il database del client OneDrive elenca il file in tale cartella con la stessa dimensione e il log del client ne registra il caricamento come completato alle 2026-03-14T14:01:41Z. SRUM registra 64.812.544 byte inviati da OneDrive.exe nell'intervallo 13:31:09Z–14:31:09Z, un dato coerente con il caricamento. Per confermare il caricamento lato server, occorre richiedere il log di audit unificato di Microsoft 365 per il tenant Contoso». La dichiarazione non indica chi fosse alla tastiera e non afferma che il file sia stato condiviso con qualcuno.

Focus sull'esame: Sono previste domande su quale file sia stato caricato tramite OneDrive e quando, con deduzioni basate sulle voci dei log ODL e sulle righe di SyncEngineDatabase.db, ricavando l'account da Accounts\Business1 o Accounts\Personal. Occorre conoscere i percorsi delle impostazioni e dei log, sapere che le stringhe ODL richiedono ObfuscationStringMap.txt o general.keystore e che un segnaposto solo online non ha contenuto nell'immagine. È necessario saper distinguere l'orario di arrivo di un file nella cartella di sincronizzazione ($J) dal suo tempo di creazione ($SI) e dal suo orario di caricamento (log).

Punti chiave

• Gli account OneDrive si trovano in NTUSER.DAT\Software\Microsoft\OneDrive\Accounts\Personal e Business1, con valori quali UserEmail e UserFolder.
• settings\<account>\SyncEngineDatabase.db (SQLite nelle versioni attuali, <cid>.dat in quelle precedenti) elenca i file con gli ID delle cartelle padre, le dimensioni e gli hash; logs\<account>\*.odl registra caricamenti, download ed eliminazioni.
• Le stringhe ODL sono offuscate o cifrate; la decodifica richiede ObfuscationStringMap.txt o general.keystore dello stesso sistema, quindi occorre acquisire l'intero albero dei log.
• I segnaposto di File su richiesta sono reparse point con attributi cloud e senza contenuto locale; l'unità G: in streaming di Google Drive non ha alcuna voce MFT.
• I database .dbx di Dropbox sono cifrati e protetti da DPAPI; info.json fornisce il percorso di sincronizzazione e .dropbox.cache può contenere file eliminati di recente.
• Dimostrare un caricamento utilizzando congiuntamente file system, database del client, log del client e SRUM, e richiedere i log di audit del fornitore per la conferma lato server.