±Forensic Focus Partners

Become an advertising partner

±Your Account


Forgotten password/username?

Site Members:

New Today: 0 Overall: 36768
New Yesterday: 0 Visitors: 98

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

More Dropbox Forensics

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts

Senior Member

More Dropbox Forensics

Post Posted: Dec 12, 14 20:58

I've used the latest version of Dropbox Decryptor from Magnet Forensics to successfully decrypt the 'filecache'dbx' file used by Dropbox on a case I'm working on. This produced a 'filecache'db' file that I've been able to read using an SQLite program.

In the 'file_journal' table I've matched a filename in the 'local_filename' column to a filename on the suspect hard drive.

I've also matched the file size in the 'local_size' column to the same filename on the suspect hard drive.

Finally I've matched the UNIX numeric time in the 'local_ctime' column with the 'Last Written' time in EnCase for the same filename.

So I can say that a file with the same filename, file size and 'Last Written' date and time existed in both Dropbox and on the suspect's hard drive. It would be nice to match up a hash or at least something else to provide another nail in the coffin.

I have noticed that a lot of files have an equivalent 'com.dropbox.attributes' file associated with them.

For example, '1z.jpg' has a file '1z.jpg·com.dropbox.attributes' with it.

The files are always about 160 bytes in length and EnCase classes them as an alternate data stream. I've looked at 6 random ADS files and the first 4 bytes remain the same for each but other than that it all looks like random data.

Does anyone have any idea whether these files contain anything forensically useful or more specifically, anything that I could tie to the decrypted 'filecache.dbx' file?



Page 1 of 1