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.

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.