Researchers Reverse-Engineer Dropbox, Cracking Heavily Obfuscated Python App

rjmarvin writes "Two developers were able to successfully reverse-engineer Dropbox to intercept SSL traffic, bypass two-factor authentication and create open-source clients. They presented their paper, 'Looking inside the (Drop) box' (PDF) at USENIX 2013, explaining step-by-step how they were able to succeed where others failed in reverse-engineering a heavily obfuscated application written in Python. They also claimed the generic techniques they used could be applied to reverse-engineer other Frozen python applications: OpenStack, NASA, and a host of Google apps, just to name a few..."

Re:Python? Really?

[epyT-R]

even then, all it takes is someone versed in the assembly language of the platform your application runs on, a copy of IDA pro or something similar, and a few hours of his time. I know this is a bit of a lost art in today's world of python and javascript, but it's still valid.

Re:Obfuscated python code?

[You're All Wrong]

Reading the paper, googling for the debug hash, lead to this from 2012 which covers a lot of the same ground:

http://archive.hack.lu/2012/Dropbox%20security.pptx
"A critical analysis of Dropbox software security", Florian LEDOUX

Re:Python? Really?

[You're All Wrong]

I hope your sarcasm is understood, it's a dangerous technique to use on the internet.

However, there's an interesting twist to the pcode vs. native code dichotomy, from reverse engineering standpoint, as anyone who's well versed in the brain-mangling line noise that calls itself the IOCCC will know. One of the best obfuscations is to embed an interpreter into your code, and then do all the hard work in the bytecode.

Re:Well, there goes Eve Online

[marcansoft]

EVE doesn't use IronPython. It uses Stackless Python. And yes, it is possible to decompile the code, and it has been done in the past.

http://evesupernerf.blogspot.co.uk/2012/05/decompiling-eve-client.html [blogspot.co.uk]
https://github.com/wibiti/evedec/blob/master/evedec.py [github.com]

Re:Python? Really?

[davester666]

Been there. Done that.

I believe it was EA that was doing that way back as part of their DRM for their Commodore 64 disk-based games. It would load the interpreter and a script, then execute the script [drawing it's fancy startup screens, checking for various bad sectors on their disk, over-writing parts of the script and interpreter, loading the game from various parts of the disk].

Re:Waste of resources

[smash]

Because if you can raise the bar in terms of effort required to be equal to, or more than just writing your own damn product, then you'll get less people freeloading off your development.

Re:Python? Really?

[buchner.johannes]

Use a non-compiled language, get what you deserve...

Python is compiled, if you distribute *.pyc files only.

Re:Insecure by design

[Anonymous Coward]

http://en.wikipedia.org/wiki/Cryptographic_nonce

It is a crypto term.

Re:Wow, amazing.

[Anonymous Coward]

Andrew Tridgell was accused of "hacking" BitKeeper because he telnetted in and typed "HELP".

Trusting trust is busted

[tepples]

The "trusting trust" attack that you linked already has countermeasures. One by David A. Wheeler, called diverse double compiling [dwheeler.com], involves bootstrapping the compiler using several independently developed compilers for the same language and seeing whether they ultimately produce the same binary. Of course, these countermeasures are no help for a proprietary language such as the Pascal variant used by Delphi.

ecryptfs+Dropbox is a nice solution

[Orp]

I've always assumed that data on Dropbox wasn't very secure, which is why I was happy to find that ecryptfs works well with dropbox across multiple machines (assuming they are all running Linux). To wit:

chinook: ~orp df /home/orp/e
Filesystem          1K-blocks      Used Available Use% Mounted on
/home/orp/Dropbox/e 491451392 129077764 361240528  27% /home/orp/e
chinook: ~orp ls Dropbox/e
./
../
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkw6-7kc4NR3-58yIKIxSsrgk--
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkw9VkRKmwOO95LV0W1qwwNHk--/
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwKsqUWInaV2aVwzvhw6CcW---
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwOggoYf2PUQpQQmgJLHwIaU--/
ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwQEdvushvgMYZ2uRpeRJ9EU--
[etc]

This works with the same partition mounted across multiple machines. Save a file to /home/orp/e, and it "magically" appears in its unencrypted form (name, content) on any other machine that was updated on Dropbox that has the encrypted partition mounted the same way. All dropbox ever sees is the encrypted stuff.

The main disadvantage to this approach is that if you are trying to access files on a non-linux machine you are hosed; Lastpass and other password managers that have file encryption functionality can give you cross-platform encryption but not with the nice filesystem access that Dropbox provides.