When I got this popup while moving a file from a Dropbox folder, I immediately thought Alternate Data Stream:
I ran my filescanner on the file, and found an ADS with name com.dropbox.attributes:
From the Magic HEX value, we can see that the content of the stream (frozen-sea-foam.mp4:com.dropbox.attributes) starts with 0x78 (and the streamsize is 83 bytes). 0x78 hints at zlib deflated data.
If you are not that familiar with magic values, you can use my file-magic tool:
Trying to decompress the ADS with translate.py gives us JSON data {“dropbox_fileid_local”: {“machineid_attr”: {“data”: “aa4xliox7z5n0qewxOlT3Q==”}}}:
The data field looks like BASE64, so let’s try to decode it with base64dump.py:
It decodes with BASE64 to data that looks random. From the names in the JSON data, we can deduce that this is probably a machine ID.
Remark 1: as it could well be my unique machine ID, I altered the value of the ID.
Remark 2: my file-magic.py tool is beta.
Remark 3: if you wonder what the video frozen-sea-foam is, I have it on Instragram.
Didier Stevens 
On unix this data is stored as an extended attribute (xattr). Shows up as @ after the file permissions in “ls -l”.
Comment by Richard — Monday 30 January 2017 @ 15:38
Also compressed Richard?
Comment by Didier Stevens — Monday 30 January 2017 @ 15:40
Yes, looks exactly the same:
$ xattr -l foo.jpg
com.dropbox.attributes:
00000000 78 9C AB 56 4A 29 CA 2F 48 CA AF 88 4F CB CC 49 |x..VJ)./H…O..I|
[truncated]
Comment by Richard — Monday 30 January 2017 @ 16:06
[…] Didier Stevens has identified some information is being stored by Dropbox in Alternate Data Streams and shows how to extract it (however is unable to determine what it is). Quickpost: Dropbox & Alternate Data Streams […]
Pingback by Week 5 – 2017 – This Week In 4n6 — Saturday 4 February 2017 @ 4:25
[…] Quickpost: Dropbox & Alternate Data Streams […]
Pingback by Overview of Content Published In January | Didier Stevens — Tuesday 14 February 2017 @ 0:00
Hi,
I’m doing some research on Dropbox right now and came across this post.
My findings on this value are: Decrypt the filecache.dbx and have a look on the tables file_journal_fileid and deleted_fileids. They contain those values.
The value is different for every indexed file. My guess is that it is used to do some mapping or integrity check between database and real files.
Cheers
Comment by Anonymous — Monday 8 January 2018 @ 13:23