Clients de synchronisation : OneDrive, Google Drive et Dropbox

Un client de synchronisation transforme une opération ordinaire sur un fichier en téléversement : il suffit de copier ou de déplacer un fichier dans un dossier surveillé pour l’envoyer dans le cloud, sans navigateur ni transfert visible. Cette leçon présente les emplacements où OneDrive, Google Drive pour ordinateur et Dropbox conservent les informations de compte, les bases de données de fichiers et les journaux sous Windows, explique pourquoi un fichier situé dans un dossier synchronisé peut être dépourvu de contenu dans l’image et montre comment combiner les éléments de preuve locaux et ceux du fournisseur pour répondre à la question « ce fichier a-t-il été téléversé, quand et depuis quel compte ? ». Les formats des clients sont pour la plupart non documentés et changent d’une version à l’autre ; considérez donc chaque structure de base de données et de journal ci-dessous comme représentative des versions récentes et vérifiez-la sur les éléments de preuve.

OneDrive

OneDrive est intégré à Windows 10 et 11 et s’exécute sous le nom OneDrive.exe dans la session de chaque utilisateur, par défaut depuis %LOCALAPPDATA%\Microsoft\OneDrive\ (les installations par machine utilisent Program Files). Un compte Microsoft personnel se synchronise par défaut avec C:\Users\<user>\OneDrive ; un compte professionnel ou scolaire se synchronise avec C:\Users\<user>\OneDrive - <Organization>, par exemple OneDrive - Contoso. Les bibliothèques SharePoint synchronisées par le même compte professionnel apparaissent dans un dossier portant le nom de l’organisation.

Configuration des comptes dans NTUSER.DAT

Chaque compte connecté possède une clé sous NTUSER.DAT\Software\Microsoft\OneDrive\Accounts\ : Personal pour un compte Microsoft et Business1 (puis Business2, etc.) pour les comptes professionnels ou scolaires. Ces clés contiennent des valeurs telles que UserEmail (l’adresse de connexion) et UserFolder (la racine de synchronisation locale), et la clé du compte personnel contient le cid du compte, un identifiant de 16 chiffres hexadécimaux qui sert également à nommer des fichiers dans le dossier des paramètres. Comme cette clé se trouve dans la ruche propre à l’utilisateur, elle relie une racine de synchronisation et une adresse électronique à un profil Windows. Les dates de dernière écriture de la clé indiquent quand le client a modifié sa configuration pour la dernière fois, et non quand les fichiers ont été synchronisés.

Dossier des paramètres et base de données de synchronisation

%LOCALAPPDATA%\Microsoft\OneDrive\settings\ contient un sous-dossier par type de compte, Personal et Business1. Vous y trouverez de petits fichiers texte, <cid>.ini (les bibliothèques synchronisées et leurs chemins locaux) et global.ini (les paramètres du client), ainsi que la base de données de fichiers du client :

• SyncEngineDatabase.db dans les versions actuelles. Il s’agit d’une base SQLite ; collectez donc également ses fichiers -wal et -shm. Des tables telles que od_ClientFile_Records et od_ClientFolder_Records contiennent une ligne par fichier ou dossier connu du client, avec le nom, un identifiant de ressource, l’identifiant de ressource du dossier parent, la taille, une empreinte du contenu et des horodatages. Pour reconstituer un chemin complet, il faut suivre les identifiants parents jusqu’à la racine.
• <cid>.dat dans les anciennes versions : un fichier binaire non documenté contenant des entrées similaires pour les fichiers et les dossiers. Il peut encore être présent sur des systèmes ayant été mis à niveau.

L’empreinte dépend du type de compte et du service : les comptes professionnels utilisent QuickXorHash de Microsoft, une valeur de 160 bits généralement stockée sous forme de 28 caractères Base64, et les comptes personnels ont utilisé SHA-1. QuickXorHash n’est ni MD5 ni SHA-256 ; pour faire correspondre un fichier de l’image à une ligne de la base de données, vous devez donc calculer son empreinte avec le même algorithme. Des outils tels que OneDriveExplorer reconstituent l’arborescence des dossiers à partir de ces bases de données ; DB Browser for SQLite vous permet d’examiner directement les lignes.

Journaux ODL

%LOCALAPPDATA%\Microsoft\OneDrive\logs\ contient des sous-dossiers tels que Personal, Business1 et Common. Le moteur de synchronisation écrit des journaux binaires ODL (.odl, .odlgz compressés et .odlsent ; l’ensemble des extensions varie selon les versions) qui enregistrent les opérations de synchronisation, notamment les téléversements, téléchargements, renommages et suppressions, avec un horodatage par entrée. Les noms de fichiers et les autres chaînes des journaux sont protégés : les anciennes versions les remplaçaient par des jetons répertoriés dans ObfuscationStringMap.txt, tandis que les versions plus récentes les chiffrent avec une clé conservée dans un fichier general.keystore. Les décodeurs tels que l’analyseur OneDrive ODL de Yogesh Khatri ont besoin de ce fichier provenant de la même installation ; sans lui, vous voyez les opérations, mais pas les noms. Collectez toute l’arborescence logs et vérifiez le fuseau horaire utilisé par l’analyseur dans ses résultats.

Fichiers à la demande et déplacement des dossiers connus

Avec la fonctionnalité Fichiers à la demande, que les clients actuels activent par défaut, un fichier peut être en ligne uniquement : son nom, sa taille et ses horodatages existent localement, mais son contenu reste dans le cloud jusqu’à son ouverture. NTFS stocke un tel fichier sous la forme d’un point d’analyse doté d’attributs cloud (par exemple FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS, souvent accompagné de FILE_ATTRIBUTE_OFFLINE), et son attribut $DATA ne possède aucun cluster alloué. Un fichier « présent » dans OneDrive - Contoso peut donc ne contenir aucune donnée dans l’image ; signalez-le comme un espace réservé et demandez son contenu au fournisseur. Les fichiers que l’utilisateur marque « Toujours conserver sur cet appareil » sont épinglés et entièrement locaux.

Le déplacement des dossiers connus redirige des dossiers connus tels que Bureau, Documents et Images vers le dossier OneDrive. Vérifiez NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (valeurs Desktop, Personal pour Documents et My Pictures) : si ces valeurs pointent vers OneDrive, chaque fichier enregistré sur le Bureau était susceptible d’être synchronisé.

La corbeille OneDrive, l’historique des versions et les liens de partage se trouvent dans le cloud. Ce sont des données du fournisseur, et non des artefacts du terminal.

Google Drive pour ordinateur

Google Drive pour ordinateur (GoogleDriveFS.exe) conserve ses données dans %LOCALAPPDATA%\Google\DriveFS\. Chaque compte possède un sous-dossier nommé d’après un long identifiant numérique de compte, contenant :

• metadata_sqlite_db (SQLite, sans extension), avec des tables telles que items et item_properties : noms, relations parentales, taille, date de modification et un stable_id qui relie les lignes entre les tables.
• content_cache, un dossier contenant le contenu des fichiers mis en cache, dans des fichiers dépourvus de leurs noms et extensions d’origine. Identifiez-les par leur signature et leur taille, puis faites-les correspondre aux lignes de la base de données.

Des bases de données telles que root_preference_sqlite.db, dans le dossier DriveFS, contiennent les préférences de compte et de montage. Les journaux sont en texte brut : %LOCALAPPDATA%\Google\DriveFS\Logs\drive_fs.txt et les fichiers de rotation drive_fs_<n>.txt, lisibles avec n’importe quel éditeur de texte ou avec grep.

Par défaut, le client diffuse Mon Drive via un lecteur virtuel, généralement G:. Ce lecteur n’est pas un volume NTFS ; les fichiers qu’il contient ne possèdent donc aucune entrée $MFT dans l’image disque ; seuls le contenu mis en cache et la base de données les décrivent. En mode miroir, les fichiers sont également stockés dans un dossier local et se comportent comme des fichiers NTFS ordinaires.

Dropbox

Dropbox stocke le chemin de son dossier de synchronisation dans info.json, situé dans %LOCALAPPDATA%\Dropbox\ ou %APPDATA%\Dropbox\, avec une valeur path pour chaque compte personnel ou professionnel. Les données du client se trouvent dans %LOCALAPPDATA%\Dropbox\instance1\ (avec des instances supplémentaires pour les comptes supplémentaires). Les fichiers portant l’extension .dbx, tels que config.dbx et aggregation.dbx, sont des bases de données SQLite chiffrées dont la clé est protégée par DPAPI (Windows Data Protection API) ; leur déchiffrement nécessite donc les éléments de clé DPAPI de l’utilisateur ou une session active. D’autres fichiers, tels que sync_history.db, ont été lisibles dans certaines versions et chiffrés dans d’autres. Testez chaque fichier avant de vous y fier : un fichier SQLite non chiffré commence à l’offset 0 par la chaîne d’en-tête de 16 octets SQLite format 3 avec son octet nul final (53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00), contrairement à un fichier chiffré.

Le dossier caché .dropbox.cache, situé à la racine de synchronisation, conserve pendant une courte période, généralement quelques jours, des copies des fichiers récemment supprimés ou modifiés. Il peut contenir des données qui n’existent plus nulle part ailleurs sur le disque.

Comparaison des clients

Méthode : le fichier X a-t-il été téléversé, quand et depuis quel compte ?

Aucun artefact ne répond à lui seul à cette question. Construisez la réponse à partir de sources indépendantes :

1. Système de fichiers. Repérez le fichier dans le dossier de synchronisation. Son horodatage de création $SI indique quand le fichier a été créé et subsiste après un déplacement ; un déplacement ou un renommage vers le dossier apparaît dans $J sous forme d’enregistrements RENAME_OLD_NAME et RENAME_NEW_NAME, tandis qu’une copie apparaît comme un nouveau fichier créé à cet emplacement (leçon 1.4).
2. Base de données du client. Repérez la ligne présentant le même nom, le même dossier parent et la même taille. Une ligne dans la base de données signifie que le client connaissait le fichier ; une empreinte correspondante la relie au contenu.
3. Journal du client. Repérez l’entrée de téléversement et son heure de fin.
4. SRUM. Vérifiez les octets envoyés par OneDrive.exe, GoogleDriveFS.exe ou Dropbox.exe dans l’intervalle contenant le téléversement (leçon 2.8).
5. Compte. Reliez la racine de synchronisation au compte à l’aide du Registre, de info.json ou du dossier de compte DriveFS.
6. Fournisseur. Lorsqu’il est disponible, le journal d’audit unifié Microsoft 365 (opérations telles que FileUploaded et FileSyncUploadedFull) ou le journal d’audit Drive de Google Workspace confirme le téléversement, le compte et l’adresse IP du client.

Les collectes de triage doivent inclure les dossiers de paramètres et de journaux mentionnés ci-dessus. Une collecte qui ne prend que les ruches du Registre et les journaux d’événements ne permet pas de répondre à cette question.

Exemple détaillé

L’utilisateur ana copie q3-files.7z depuis E:\Clients\ sur le support USB (l’archive créée dans la leçon 3.4) vers C:\Users\ana\OneDrive - Contoso\Shared\. Les éléments de preuve :

Vérifications. Le téléversement s’est terminé 14:01:41 − 14:01:03 = 38 secondes après l’arrivée du fichier dans le dossier. 64 108 233 octets × 8 / 38 s = 13,5 Mbit/s, un débit de téléversement plausible. 64 108 233 / 1 048 576 = 61,1 MiB. Le nombre d’octets envoyés selon SRUM dépasse la taille du fichier de 64 812 544 − 64 108 233 = 704 311 octets (environ 1,1 %), ce qui est compatible avec la surcharge du protocole et les autres échanges de synchronisation dans le même intervalle ; SRUM ne permet pas de démontrer que ces octets correspondaient à ce fichier. Si le fichier est toujours présent localement, calculez son empreinte QuickXorHash et comparez-la à la valeur de la base de données.

Constat. « À 2026-03-14T14:01:03Z, le fichier q3-files.7z (64 108 233 octets) a été copié depuis le support USB E:\ vers C:\Users\ana\OneDrive - Contoso\Shared\, le dossier de synchronisation du compte professionnel ana@contoso.com configuré dans le profil de l’utilisateur ana. La base de données du client OneDrive répertorie le fichier dans ce dossier avec la même taille, et le journal du client enregistre la fin de son téléversement à 2026-03-14T14:01:41Z. SRUM enregistre 64 812 544 octets envoyés par OneDrive.exe dans l’intervalle 13:31:09Z–14:31:09Z, ce qui est cohérent avec le téléversement. Le journal d’audit unifié Microsoft 365 du tenant Contoso devrait être demandé afin de confirmer le téléversement côté serveur. » Ce constat ne précise pas qui était au clavier et n’affirme pas que le fichier a été partagé avec qui que ce soit.

Points clés pour l’examen : Attendez-vous à des questions visant à déterminer quel fichier a été téléversé via OneDrive et à quel moment, en vous appuyant sur les entrées des journaux ODL et les lignes de SyncEngineDatabase.db, le compte étant identifié à partir de Accounts\Business1 ou de Accounts\Personal. Connaissez les chemins des paramètres et des journaux, sachez que les chaînes ODL nécessitent ObfuscationStringMap.txt ou general.keystore, et qu’un espace réservé en ligne uniquement n’a aucun contenu dans l’image. Soyez prêt à distinguer l’heure d’arrivée d’un fichier dans le dossier de synchronisation ($J) de son heure de création ($SI) et de son heure de téléversement (journal).

Points essentiels

• Les comptes OneDrive se trouvent dans NTUSER.DAT\Software\Microsoft\OneDrive\Accounts\Personal et Business1, avec des valeurs telles que UserEmail et UserFolder.
• settings\<account>\SyncEngineDatabase.db (SQLite dans les versions actuelles, <cid>.dat dans les anciennes) répertorie les fichiers avec leurs identifiants parents, leurs tailles et leurs empreintes ; logs\<account>\*.odl enregistre les téléversements, les téléchargements et les suppressions.
• Les chaînes ODL sont obscurcies ou chiffrées ; leur décodage nécessite ObfuscationStringMap.txt ou general.keystore provenant du même système ; collectez donc toute l’arborescence des journaux.
• Les espaces réservés de la fonctionnalité Fichiers à la demande sont des points d’analyse dotés d’attributs cloud et dépourvus de contenu local ; le lecteur G: diffusé de Google Drive ne possède aucune entrée MFT.
• Les bases de données .dbx de Dropbox sont chiffrées et protégées par DPAPI ; info.json fournit le chemin de synchronisation et .dropbox.cache peut contenir des fichiers récemment supprimés.
• Démontrez un téléversement en combinant le système de fichiers, la base de données du client, le journal du client et SRUM, et demandez les journaux d’audit du fournisseur pour obtenir une confirmation côté serveur.