Cloud-Synchronisierungsclients: OneDrive, Google Drive und Dropbox

Ein Synchronisierungsclient macht aus einem gewöhnlichen Dateivorgang einen Upload: Eine Datei in einen überwachten Ordner zu kopieren oder zu verschieben, reicht aus, um sie in die Cloud zu übertragen – ohne Browser und ohne sichtbaren Übertragungsvorgang. Diese Lektion behandelt, wo OneDrive, Google Drive for desktop und Dropbox unter Windows Kontodaten, Dateidatenbanken und Protokolle speichern, warum eine Datei in einem Synchronisierungsordner im Abbild möglicherweise keinen Inhalt hat und wie Sie lokale Beweismittel und Beweismittel des Anbieters kombinieren, um die Frage „Wurde diese Datei hochgeladen, wann und über welches Konto?“ zu beantworten. Die Clientformate sind größtenteils undokumentiert und ändern sich zwischen den Versionen. Betrachten Sie daher alle nachfolgend beschriebenen Datenbank- und Protokollstrukturen als typisch für neuere Versionen und überprüfen Sie sie anhand der Beweismittel.

OneDrive

OneDrive ist in Windows 10 und 11 integriert und läuft als OneDrive.exe in der Sitzung des jeweiligen Benutzers, standardmäßig aus %LOCALAPPDATA%\Microsoft\OneDrive\ (computerweite Installationen verwenden Program Files). Ein persönliches Microsoft-Konto synchronisiert standardmäßig mit C:\Users\<user>\OneDrive; ein Geschäfts-, Schul- oder Unikonto synchronisiert mit C:\Users\<user>\OneDrive - <Organization>, beispielsweise OneDrive - Contoso. SharePoint-Bibliotheken, die über dasselbe Geschäftskonto synchronisiert werden, erscheinen unter einem nach der Organisation benannten Ordner.

Kontokonfiguration in NTUSER.DAT

Jedes angemeldete Konto hat einen Schlüssel unter NTUSER.DAT\Software\Microsoft\OneDrive\Accounts\: Personal für ein Microsoft-Konto und Business1 (danach Business2 usw.) für Geschäfts-, Schul- oder Unikonten. Die Schlüssel enthalten Werte wie UserEmail (die Anmeldeadresse) und UserFolder (das lokale Synchronisierungsstammverzeichnis). Der Schlüssel für das persönliche Konto enthält außerdem die cid des Kontos, eine Kennung aus 16 Hexadezimalstellen, die auch zur Benennung von Dateien im Einstellungsordner dient. Da sich der Schlüssel in der eigenen Registrierungsstruktur des Benutzers befindet, verknüpft er ein Synchronisierungsstammverzeichnis und eine E-Mail-Adresse mit einem Windows-Profil. Die Zeitstempel der letzten Änderung des Schlüssels zeigen, wann der Client zuletzt seine Konfiguration geändert hat, nicht wann Dateien synchronisiert wurden.

Einstellungsordner und Synchronisierungsdatenbank

%LOCALAPPDATA%\Microsoft\OneDrive\settings\ enthält je einen Unterordner pro Kontotyp, Personal und Business1. Darin befinden sich kleine Textdateien, <cid>.ini (die synchronisierten Bibliotheken und ihre lokalen Pfade) und global.ini (Clienteinstellungen), sowie die Dateidatenbank des Clients:

• SyncEngineDatabase.db in aktuellen Versionen. Es handelt sich um SQLite; sichern Sie daher auch die zugehörigen Dateien -wal und -shm. Tabellen wie od_ClientFile_Records und od_ClientFolder_Records enthalten je einen Datensatz pro Datei oder Ordner, die bzw. der dem Client bekannt ist, mit dem Namen, einer Ressourcen-ID, der Ressourcen-ID des übergeordneten Ordners, der Größe, einem Inhaltshash und Zeitstempeln. Um einen vollständigen Pfad zu rekonstruieren, müssen Sie den übergeordneten IDs bis zum Stammverzeichnis folgen.
• <cid>.dat in älteren Versionen: eine undokumentierte Binärdatei mit ähnlichen Datei- und Ordnereinträgen. Sie kann auf Systemen, die aktualisiert wurden, weiterhin vorhanden sein.

Der Hash hängt vom Kontotyp und vom Dienst ab: Geschäftskonten verwenden Microsofts QuickXorHash, einen 160-Bit-Wert, der üblicherweise als 28 Base64-Zeichen gespeichert wird; persönliche Konten haben SHA-1 verwendet. QuickXorHash ist weder MD5 noch SHA-256. Um eine Datei im Abbild einem Datenbankdatensatz zuzuordnen, müssen Sie daher denselben Algorithmus auf die Datei anwenden. Werkzeuge wie OneDriveExplorer rekonstruieren den Ordnerbaum aus diesen Datenbanken; mit DB Browser for SQLite können Sie die Datensätze direkt untersuchen.

ODL-Protokolle

%LOCALAPPDATA%\Microsoft\OneDrive\logs\ enthält Unterordner wie Personal, Business1 und Common. Die Synchronisierungsengine schreibt binäre ODL-Protokolle (.odl, komprimierte .odlgz und .odlsent; die verwendeten Erweiterungen variieren zwischen den Versionen), die Synchronisierungsvorgänge einschließlich Uploads, Downloads, Umbenennungen und Löschungen mit einem Zeitstempel pro Eintrag aufzeichnen. Dateinamen und andere Zeichenfolgen in den Protokollen sind geschützt: Ältere Versionen ersetzten sie durch Tokens, die in ObfuscationStringMap.txt aufgeführt sind; neuere Versionen verschlüsseln sie mit einem Schlüssel, der in einer Datei namens general.keystore gespeichert ist. Decoder wie der OneDrive ODL parser von Yogesh Khatri benötigen diese Datei aus derselben Installation; ohne sie sehen Sie Vorgänge, aber keine Namen. Sichern Sie den gesamten Verzeichnisbaum logs und prüfen Sie, welche Zeitzone der Parser für seine Ausgabe verwendet.

Dateien bei Bedarf und Known Folder Move

Mit Dateien bei Bedarf, einer Funktion, die aktuelle Clients standardmäßig aktivieren, kann eine Datei nur online verfügbar sein: Name, Größe und Zeitstempel sind lokal vorhanden, der Inhalt bleibt jedoch bis zum Öffnen in der Cloud. NTFS speichert eine solche Datei als Analysepunkt mit Cloudattributen (beispielsweise FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS, häufig zusammen mit FILE_ATTRIBUTE_OFFLINE), und ihr $DATA-Attribut hat keine zugewiesenen Cluster. Eine Datei, die in OneDrive - Contoso „vorhanden“ ist, kann daher im Abbild ohne Inhalt sein. Dokumentieren Sie sie als Platzhalter und fordern Sie den Inhalt beim Anbieter an. Dateien, die der Benutzer mit „Immer auf diesem Gerät behalten“ kennzeichnet, sind angeheftet und vollständig lokal vorhanden.

Known Folder Move leitet bekannte Ordner wie Desktop, Dokumente und Bilder in den OneDrive-Ordner um. Prüfen Sie NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (Werte Desktop, Personal für Dokumente und My Pictures): Wenn sie auf OneDrive verweisen, kam jede auf dem Desktop gespeicherte Datei für eine Synchronisierung infrage.

Der OneDrive-Papierkorb, der Versionsverlauf und Freigabelinks befinden sich in der Cloud. Sie sind Anbieterdaten, keine Endpunktartefakte.

Google Drive for desktop

Google Drive for desktop (GoogleDriveFS.exe) speichert seine Daten unter %LOCALAPPDATA%\Google\DriveFS\. Jedes Konto hat einen Unterordner, der nach einer langen numerischen Konto-ID benannt ist und Folgendes enthält:

• metadata_sqlite_db (SQLite, ohne Erweiterung) mit Tabellen wie items und item_properties: Namen, Beziehungen zu übergeordneten Elementen, Größe, Änderungszeit und eine stable_id, die Datensätze tabellenübergreifend verknüpft.
• content_cache, ein Ordner mit zwischengespeicherten Dateiinhalten in Dateien ohne ihre ursprünglichen Namen oder Erweiterungen. Identifizieren Sie sie anhand von Signatur und Größe und ordnen Sie sie anschließend Datenbankdatensätzen zu.

Datenbanken wie root_preference_sqlite.db im Ordner DriveFS enthalten Konto- und Einbindungseinstellungen. Protokolle liegen als Klartext vor: %LOCALAPPDATA%\Google\DriveFS\Logs\drive_fs.txt und rotierte Dateien namens drive_fs_<n>.txt, die mit jedem Texteditor oder grep lesbar sind.

Standardmäßig streamt der Client „Meine Ablage“ über ein virtuelles Laufwerk, üblicherweise G:. Dieses Laufwerk ist kein NTFS-Volume; daher haben Dateien darauf keine $MFT-Einträge im Datenträgerabbild. Nur zwischengespeicherte Inhalte und die Datenbank beschreiben sie. Im Spiegelungsmodus werden Dateien zusätzlich in einem lokalen Ordner gespeichert und verhalten sich wie gewöhnliche NTFS-Dateien.

Dropbox

Dropbox speichert den Pfad seines Synchronisierungsordners in info.json, zu finden unter %LOCALAPPDATA%\Dropbox\ oder %APPDATA%\Dropbox\, mit einem path-Wert für jedes persönliche oder geschäftliche Konto. Die Clientdaten befinden sich unter %LOCALAPPDATA%\Dropbox\instance1\ (weitere Instanzen für weitere Konten). Dateien mit der Erweiterung .dbx, beispielsweise config.dbx und aggregation.dbx, sind verschlüsselte SQLite-Datenbanken, deren Schlüssel durch DPAPI (Windows Data Protection API) geschützt ist. Ihre Entschlüsselung erfordert daher das DPAPI-Schlüsselmaterial des Benutzers oder eine laufende Sitzung. Andere Dateien wie sync_history.db waren in einigen Versionen lesbar und in anderen verschlüsselt. Prüfen Sie jede Datei, bevor Sie sich darauf stützen: Eine unverschlüsselte SQLite-Datei beginnt an Offset 0 mit der 16-Byte-Zeichenfolge SQLite format 3 einschließlich eines abschließenden Nullbytes; eine verschlüsselte Datei nicht.

Der versteckte Ordner .dropbox.cache im Synchronisierungsstammverzeichnis bewahrt Kopien kürzlich gelöschter oder geänderter Dateien für einen kurzen Zeitraum auf, typischerweise einige Tage. Er kann Inhalte enthalten, die an keiner anderen Stelle auf dem Datenträger mehr vorhanden sind.

Vergleich der Clients

Methode: Wurde Datei X hochgeladen, wann und über welches Konto?

Kein einzelnes Artefakt beantwortet diese Frage. Erarbeiten Sie die Antwort aus unabhängigen Quellen:

1. Dateisystem. Suchen Sie die Datei im Synchronisierungsordner. Ihre $SI-Erstellungszeit hält fest, wann die Datei erstellt wurde, und bleibt bei einem Verschieben erhalten. Ein Verschieben oder Umbenennen in den Ordner erscheint in $J als Datensätze vom Typ RENAME_OLD_NAME und RENAME_NEW_NAME; eine Kopie erscheint als dort neu erstellte Datei (Lektion 1.4).
2. Clientdatenbank. Suchen Sie den Datensatz mit demselben Namen, übergeordneten Ordner und derselben Größe. Ein Datenbankdatensatz bedeutet, dass der Client die Datei kannte; ein übereinstimmender Hash verknüpft ihn mit dem Inhalt.
3. Clientprotokoll. Suchen Sie den Upload-Eintrag und dessen Abschlusszeit.
4. SRUM. Prüfen Sie die von OneDrive.exe, GoogleDriveFS.exe oder Dropbox.exe gesendeten Bytes im Intervall, das den Upload umfasst (Lektion 2.8).
5. Konto. Verknüpfen Sie das Synchronisierungsstammverzeichnis über die Registrierung, info.json oder den DriveFS-Kontoordner mit dem Konto.
6. Anbieter. Soweit verfügbar, bestätigt das vereinheitlichte Überwachungsprotokoll von Microsoft 365 (Vorgänge wie FileUploaded und FileSyncUploadedFull) oder das Drive-Überwachungsprotokoll von Google Workspace den Upload, das Konto und die IP-Adresse des Clients.

Triage-Sicherungen müssen die oben genannten Einstellungs- und Protokollordner enthalten. Eine Sicherung, die nur Registrierungsstrukturen und Ereignisprotokolle umfasst, kann diese Frage nicht beantworten.

Durchgerechnetes Beispiel

Benutzer ana kopiert q3-files.7z vom USB-Laufwerk E:\ (das in Lektion 3.4 erstellte Archiv) nach C:\Users\ana\OneDrive - Contoso\Shared\. Die Beweismittel:

Plausibilitätsprüfungen. Der Upload wurde 14:01:41 − 14:01:03 = 38 Sekunden nach dem Eintreffen der Datei im Ordner abgeschlossen. 64.108.233 Bytes × 8 / 38 s = 13,5 Mbit/s, eine plausible Uploadrate. 64.108.233 / 1.048.576 = 61,1 MiB. Die laut SRUM gesendeten Bytes übersteigen die Dateigröße um 64.812.544 − 64.108.233 = 704.311 Bytes (etwa 1,1 %). Das passt zu Protokoll-Overhead und weiterem Synchronisierungsverkehr im selben Intervall; SRUM kann nicht belegen, dass diese Bytes zu dieser Datei gehörten. Falls die Datei noch lokal vorhanden ist, berechnen Sie ihren QuickXorHash und vergleichen Sie ihn mit dem Datenbankwert.

Aussage. „Um 2026-03-14T14:01:03Z wurde die Datei q3-files.7z (64.108.233 Bytes) vom USB-Laufwerk E:\ nach C:\Users\ana\OneDrive - Contoso\Shared\ kopiert, in den Synchronisierungsordner des Geschäftskontos ana@contoso.com, das im Profil des Benutzers ana konfiguriert ist. Die OneDrive-Clientdatenbank führt die Datei in diesem Ordner mit derselben Größe auf, und das Clientprotokoll verzeichnet ihren Upload um 2026-03-14T14:01:41Z als abgeschlossen. SRUM verzeichnet 64.812.544 von OneDrive.exe gesendete Bytes im Intervall 13:31:09Z–14:31:09Z, was mit dem Upload vereinbar ist. Das vereinheitlichte Überwachungsprotokoll von Microsoft 365 für den Contoso-Mandanten sollte angefordert werden, um den Upload serverseitig zu bestätigen.“ Die Aussage legt nicht fest, wer an der Tastatur saß, und behauptet nicht, dass die Datei für jemanden freigegeben wurde.

Prüfungsschwerpunkt: Rechnen Sie mit einer Aufgabe in Teil B, in der Sie anhand der ausgewerteten ODL-Protokolle und der SyncEngineDatabase.db beantworten sollen, welche Datei über OneDrive hochgeladen wurde und wann. Das Konto entnehmen Sie dabei Accounts\Business1 oder Accounts\Personal. Kennen Sie die Einstellungs- und Protokollpfade und wissen Sie, dass ODL-Zeichenfolgen ObfuscationStringMap.txt oder general.keystore benötigen und dass ein nur online verfügbarer Platzhalter im Abbild keinen Inhalt hat. Seien Sie darauf vorbereitet, den Zeitpunkt, zu dem eine Datei im Synchronisierungsordner eintraf ($J), von ihrer Erstellungszeit ($SI) und ihrer Uploadzeit (Protokoll) zu unterscheiden.

Kernpunkte

• OneDrive-Konten befinden sich unter NTUSER.DAT\Software\Microsoft\OneDrive\Accounts\Personal und Business1, mit Werten wie UserEmail und UserFolder.
• settings\<account>\SyncEngineDatabase.db (SQLite in aktuellen Versionen, <cid>.dat in älteren) führt Dateien mit übergeordneten IDs, Größen und Hashes auf; logs\<account>\*.odl zeichnet Uploads, Downloads und Löschungen auf.
• ODL-Zeichenfolgen sind verschleiert oder verschlüsselt; zur Dekodierung wird ObfuscationStringMap.txt oder general.keystore vom selben System benötigt. Sichern Sie daher den gesamten Protokollverzeichnisbaum.
• Platzhalter von Dateien bei Bedarf sind Analysepunkte mit Cloudattributen und ohne lokalen Inhalt; das gestreamte Laufwerk G: von Google Drive hat überhaupt keine MFT-Einträge.
• Dropbox-Datenbanken mit der Erweiterung .dbx sind DPAPI-geschützt und verschlüsselt; info.json liefert den Synchronisierungspfad, und .dropbox.cache kann kürzlich gelöschte Dateien enthalten.
• Belegen Sie einen Upload durch die gemeinsame Auswertung von Dateisystem, Clientdatenbank, Clientprotokoll und SRUM und fordern Sie Überwachungsprotokolle des Anbieters zur serverseitigen Bestätigung an.