I got a bit waylaid with how Dropbox performs host-level authentication while I was researching and documenting forensic artifacts that Dropbox leaves lying around, but finally have gotten the chance to come back around to finish my research/documentation. Here’s a summary of my observations:
- Dropbox binaries are installed into %AppData%\Dropbox\bin instead of the standard %PROGRAMFILES%. During the install, a number of registry keys were added (13), although they contained no forensically useful data.
- The Dropbox configuration and state is stored in SQLite files found in %AppData%\Dropbox
- config.db: contains baseline configuration settings that the Dropbox client references in order to run in a table named config. Records of interest include:
- host_id: the authentication hash used by the Dropbox client to authenticate into the Dropbox “cloud.” This hash is assigned upon initial install/authentication and does not change unless revoked from the Dropbox web interface.
- email: account holder’s email address. Can be changed to any value without consequence – set at install/authentication.
- dropbox_path: actual path to the user’s Dropbox on the local system.
- recently_changed3: lists the path/filename for the five most recently changed files- this includes files removed/deleted from the Dropbox. This is probably the only truly useful forensic artifact produced by Dropbox (other than the usual filesystem related artifacts). The BLOB for this record is text-based and is consistently formatted:
- text begins with “lp1”, ends with “a.”
- entries are in order of most recent to least recent and each entry the filename/path is followed by “I00” and “tp#” (replace # with the order that the file is in + 1, i.e. first entry is followed by “tp2”), separate by line breaks.
- if the file has been removed/deleted from the Dropbox, the “I00” text is removed and a “N” is placed in front of the “tp#”. So, an example of a removed/deleted file is would be:(V41725479:/new file.txt
Ntp2
- root_ns: appears to be used throughout the Dropbox DBs to reference the base Dropbox path/location.
- filecache.db: contains a number of tables, but the primary focus is to describe all files actively in the Dropbox (deleted/removed files are removed from this table upon deletion/removal). Tables and records of interest:
- file_journal: includes the filename, path, size (in Bytes), mtime (file modified time, in Unix/POSIX format), ctime (file created time, in Unix/POSIX format), local_dir (flag indicating whether the entry is a directory), and more (mainly unpopulated).
- block_ref: maps file IDs (fj_id) to file hashes (hash_id) found in the block_cache table.
- block_cache: hash id (id) and hash. Hash is of an unknown format and did not match up with anything I could generate using standard tools.
- mount_table: appears to list folders that are shared with other Dropbox users.
- host.db: actually not a SQLite database but contains what looks to be a hash of some sort (possibly SHA-1?) and the dropbox path (dropbox_path in config.db) encoded in base-64. The entire file may be encoded in base-64 (basing this on a few Dropbox forum postings I read), but the first part of the file does not decode into anything human readable or match any other fields that I observed in the other DBs.
- sigstore.db: stores hash values which correspond to the values found in the block_cache table in filecache.db.
- unlink.db: appears to be a binary file and is not a SQLite database. Format and purpose is unknown.
- config.db: contains baseline configuration settings that the Dropbox client references in order to run in a table named config. Records of interest include:
Honestly, short of the recently_changed3 record in the config database, there really isn’t a significant number of useful forensic artifacts generated by Dropbox. Given Dropbox writes to the local filesystem, your standard filesystem analysis steps will encompass files stored/synced into a subject’s Dropbox; but perhaps, under certain circumstances, the recently_changed3 record and/or the Dropbox ctime/mtime entries for files could come in handy…
Happy Forensicating.