How could there have been any doubts that the heavily obfuscated Python could be reverse engineered? Me, and some others, did it quite a while ago. It wasn't a lot of work to find the opcode mapping using frequency analysis and a bit of reasoning (ie, mapping against known libraries).
Anyone remember dropship? <a href="https://en.wikipedia.org/wiki/Dropship_(software)" rel="nofollow">https://en.wikipedia.org/wiki/Dropship_(software)</a> I wonder if they're going to send a takedown request this time too.<p>Oh I see dropship is mentioned in the paper, great :)<p>In any case, interesting that they found some previously unknown security holes this way. This again proves that security through obscurity, at least for client software, doesn't work. When will people learn. You <i>can't</i> hide anything on the client for the user, at least not for long.
<a href="http://neopythonic.blogspot.co.il/2011/06/depth-and-breadth-of-python.html" rel="nofollow">http://neopythonic.blogspot.co.il/2011/06/depth-and-breadth-...</a><p>"The contrast with my visitor the next day couldn't be greater. Through a former colleague I got an introduction to Drew Houston, co-founder and CEO of the vastly successful start-up company Dropbox.<p>Python plays an important role in Dropbox's success: the Dropbox client, which runs on Windows, Mac and Linux (!), is written in Python. This is key to the portability: everything except the UI is cross-platform. (The UI uses a Python-ObjC bridge on Mac, and wxPython on the other platforms.) Performance has never been a problem -- understanding that a small number of critical pieces were written in C, including a custom memory allocator used for a certain type of objects whose pattern of allocation involves allocating 100,000s of them and then releasing all but a few. <i>Before you jump in to open up the Dropbox distro and learn all about how it works, beware that the source code is not included and the bytecode is obfuscated. Drew's no fool. And he laughs at the poor competitors who are using Java.</i>"<p>Sometime after that, Drew poached Guido from Google. I remember this post. :)
I am slightly confused as to why reverse-engineering a client allows you to sidestep two-factor auth. That <i>should</i> be entirely a server-side thing.
I always find reverse engineering things made by people amusing. We could just, you know, ask someone.<p>It's like when a new iPhone comes out and they throw the custom silicon under electron microscopes. It's entertaining, and I'm sure fun for the people doing it, but fighting information wars against ourselves just seems silly.<p>There are large problems humans don't have answers to, but we're busy making things then figuring out how the things we made work. Madness ensues.
Read the paper. They haven't actually found a way to really bypass two-factor authentication and all other security measures. With their findings, you can hijack an account if:<p>- you feel like cracking a 256-bit random value remotely (can't locally bruteforce it), or<p>- you have filesystem access.<p>I'd say both are irrelevant. You can't crack 256-bit values locally, let alone if you have to check the value remotely, and with filesystem access I imagine you can do a whole lot more than just uploading files to someone's Dropbox.<p>Bypassing two-factor authentication with either of the options is possible though, and I can see the issue, but this is by design. I don't think you want to have to enter your credentials (username, password, second factor) every single time you store a file or check for updates.
Link to the presentation of the reverse-engineers: <a href="https://www.usenix.org/sites/default/files/conference/protected-files/kholia_woot13_slides.pdf" rel="nofollow">https://www.usenix.org/sites/default/files/conference/protec...</a>
<a href="http://pastebin.com/gzF4XkBL" rel="nofollow">http://pastebin.com/gzF4XkBL</a><p>Fun find from the source code: There's a module named "gandolf.py" which appears to have something to do with version control.