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

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.

Quick Tip: Meaning of MAC times in different file systems

Every file system handles MAC times slightly differently, however sleuthkit (as well as other forensics software products) use the same acronym/fields no matter which file system you’re analyzing.  Here’s a quick run-down of some popular file systems and what the M, A, C, and B mean:

File System m a c b
Ext2/3 Modified Accessed Attribute modification and/or file content change N/A
FAT File Modified Accessed N/A Created
NTFS File Modified Accessed MFT Modified Created
UFS Modified Accessed Attribute modification and/or file content change N/A
And now, back to your regularly scheduled programming…