Brush up on Dropbox DBX decryption

Few weeks ago I was contacted about how to decrypt Windows Dropbox DBX files and the same topic appeared on SANS DFIR mailing list too. So I decided to create an Open Source toolkit and this post to brush up on the DBX files create by the Dropbox client on a Windows machine.

The Windows Dropbox client keeps its own files - user info, configuration, 'my dropbox' files sync status and even more - inside the user profile: on the Windows 7 and Windows 10 machines I used for test they reside in '\Users\%USERNAME%\AppData\Local\Dropbox\' and sub folders. Among them there are files with .DBX extension, which are the target of this post. When you take a raw look at them, you see garbage, noise... encryption is in place.

Without too much suspence, this is well-known. Nicolas Ruff and Florian Ledoux had a talk at hack.lu 2012 on the topic, “A critical analysis of Dropbox software security” (here). They discovered that the encryption key used for DBX files is kept in the registry and it's protected using DPAPI: I suggest everybody to read all the slides, since they cover much more than Windows Dropbox DBX files. When doing my DPAPI research ("From mimikatz to DPAPI" SANS@Night Milan 2014,  "give me the password and I'll rule the world" SANS Prague 2014) I used their findings to code the dropbox probe for dpapick, to get post-mortem the Dropbox User key.

The core question now becomes: is the same schema still used for Dropbox Encryption? Short answer, yes: almost nothing changed since 2012. Assumed you read their analysis, to make the DBX decryption process easier I created a GitHub project called decwindbx which provides the Open Source toolkit I will show in action in the next lines [https://github.com/dfirfpi/decwindbx].

Quick review.

• DBX files are sqlite files encrypted using the SQLite Encryption Extension (SEE) for SQLite.

• Not every DBX file is an encrypted sqlite: some are simple... sqlite files, some are base64 files etc. As DFIR guys, we should not trust extensions, should we? Take a raw look at files before trying to decrypt them.

• There are two registry keys (values) which contain the Dropbox users keys, not just one.

• Those two registry keys are DPAPI blobs, so you'll need the user's login password (or its SHA1, see "Happy DPAPI!") to allow their decryption.

• The registry values containing the DPAPI blobs have data before (version, length) and after (HMAC) them.

• The DBX security is solely based on DPAPI security (strong, by the way).

• The DPAPI blobs use a fixed entropy (a secret), d114a55212655f74bd772e37e64aee9b.

• When decrypted, the registry DPAPI blobs will provide the so called User Keys: they will not decrypt the DBX files.

• The DBX decryptions keys are derived from User Keys using PBKDF2 with 1066 iterations and a fixed salt, 0D638C092E8B82FC452883F95F355B8E.

• From 'HKCU:\SOFTWARE\Dropbox\ks\Client' you'll derive the DBX decryption key for DBX files which reside in  '\Users\%USERNAME%\AppData\Local\Dropbox\instance_db'.

• From 'HKCU:\SOFTWARE\Dropbox\ks1\Client' you'll derive the DBX decryption key for DBX files which reside in  '\Users\%USERNAME%\AppData\Local\Dropbox\instance1' and, usually, for root DBX files.

Getting DBX decryption keys.

Live. If for any reason (e.g. testing) you are on the live machine, you have two scripts to get the DBX decryption keys: the Powershell script dbx-key-win-live.ps1 and the Python dbx-key-win-live.py. They both do not require any parameter, just launch them and get the results.

ascell#> @powershell -ExecutionPolicy Bypass ".\dbx-key-win-live.ps1"

ascell#> py -2 dbx-key-win-live.py

ascell#> py -3 dbx-key-win-live.py

I modified the original Ruff's Python script dbx-keygen-windows.py (here) to work on both ks and ks1 registry keys and to run using Python2 or Python3. Take into account that the py script has two prerequisites, pbkdf2 and pypiwin32. It's far easier to use the PowerShell  dbx-key-win-live.ps1, which should run as is on Windows, starting from Vista up to Windows 10.

Post-mortem. To grab the same information post-mortem, I refactored my Python script dbx-key-win-dpapi.py which needs dpapick: you need to have dpapick installed or put it in PYTHONPATH, assuming you have installed its requirements.

ascell#> py -2 dbx-key-win-dpapi.py --sid=<sid> --masterkey=<directory> --ntuser=<ntuser.dat> 

--password=<the_password>

As already pointed out, you can use the user login sha1 password or the proper unlocked Master Key. Note that dpapick needs Python2 (even if it's quite easy to port it) since the crypto library M2Crypto will not work out of the box on Python3, especially on Windows.

Decrypting DBX files.

Now we got the decryption keys we can move forward by decrypting the DBX files: remember to choose the proper 'ks' key, depending on the DBX folder location. I provided Windows and Linux static binaries, both 32 and 64 bits: sqlite-dbx-win32.exe, sqlite-dbx-win64.exe, sqlite-dbx-tux32, sqlite-dbx-tux64. The suggested approach is the following:

ascell#> sqlite-dbx-win64.exe -key <dbx_key> config.dbx ".backup config.db"

The resulting config.db will be the normal (not encrypted) sqlite file that you can handle as usual. The reason to run the sqlite tool batch is due to the old sqlite source code used: you can try the sqlite shell, but most likely you'll get some issues. If, for any reason, you don't trust the cross compiled binaries I provided on GitHub, you can easily compile them by yourself using the source code inside the sqlite3dbx directory.

Conclusions.

I truly like Open Source Researches integration, which can allow us to achieve great results: every step is known, every step can be reviewed and analyzed. Here I guess we had a good example. Commercial tools often use such open researches or even the code, without giving the proper acknowledgements or even without saying just a "thanks": bad, but that's it. Coming back to Dropbox, DBX decryption is just a starting point: you have the data, now you need to analyze it... Given the level of details inside all those databases, I think there is more to be done... For example, correlating what Didier Stevens recently found out looking at Dropbox ADS files (here) with the information from the decrypted DBX...