Forensic artifacts: Dropbox

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

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…

Comments

The ctime and mtime which are the created time and modified time are stated with a buffer added to it. Eg: Instead of 23:50:13 as ctime, the unix value corresponds to 22:50:13 in Dropbox version 2.0.5 ‘s filecache database