Why can we still crack snapchat photos in 12 lines of Ruby? (opens in new tab)

I don't totally see the point to these arguments. The inherent nature of the technology we have means that if they can view it once, they can view it as long and as many times as they want. Anything trying to restrict that is just futile -- look at DRM.

Snapchat has never given that particular illusion of privacy. As the most common and basic example, it has absolutely no way of stopping people from simply taking a screenshot of your image. Snapchat is meant to be used to share throwaway photos without the social expectation that comes from putting it on somewhere like Facebook. Anyone who uses the application learns quickly that someone can potentially store the photo they sent -- in a vast variety of ways.

Forgive my ignorance, but why does SnapChat maintain a local cache beyond the 10-sec limit in the first place? Why don't they delete the photo and overwrite the disk space so that the photo is pretty much unrecoverable? Is it simply that this is too cumbersome to implement? Are there any technical restrictions? I tried Googling the issue and just came across the wave of articles that covered the discovery of the fact that photos were locally recoverable, but I don't seem to have found anything that indicates what motivated this design choice in the first place. Would be great if someone can shed light on this.

PS: I'm not a SnapChat user, so I admit that I might also be overlooking some functionality of the app that necessitates the use of a local cache

This is a bit of a tangent, but I think it get's at the more interesting part of this question.

I ended up following a link to another sec.se thread where the idea of secure program obfuscation was discussed.[0] I feel embarrassed for having missed this but it appears that there exists on a theoretical level a manner of solving snapchat's woes.

The wired article ([0][0]) seems to suggest that it would be impractical at the moment due to resource constraints, however I also haven't had a minute to read the paper ([0][1]) yet as it is quite near morning and I need to get to sleep.

On a related tangent, the thing that sprung to mind about this new technique in obfuscation was the potential for using keyed APIs easily from the browser without having to bother the primary site's servers at all. Clearly very far away from there however.

Also, wouldn't secure obfuscation enable a lot of malware to evade detection by most current av programs?

[0][0]http://www.wired.com/wiredscience/2014/02/cryptography-break... [0][1]http://eprint.iacr.org/2013/631.pdf

I've worked with the unofficial Snapchat API a lot, and I've had the same thoughts. Basically Snapchat used AES ECB encryption with a symmetric key hardcoded into their binary. That's not a good idea, but its also better than nothing. Their api requests are all sent with a generated key parameter that takes 3 steps to make but really boils down to security by obscurity.

Snapchat made these security decisions long before anyone had any interest in "cracking" the app, and now I imagine they are looking for a way to get rid of this legacy code without breaking the millions of installed clients out there. It's an interesting problem and for now I'm having fun hacking on the API. If you're a Java person, check out my JavaSnap library which lets you send and receive Snaps.

I don't fully understand this issue.

I understand that you are never going to be able to stop the intended recipient keeping the image - that's trivial just with a screenshot, and anyone even capable / caring enough to run the linked code is going to defeat any further obfuscation you pile on.

What isn't clear to me from the link is: Is this same encryption the only protection applied to "snaps" that are in-flight? If I run my own wireless access point, can I use this code to decode all messages received by Snapchat users connected to my AP?

As the answers suggest, there's a difference between encrypting everything with the same key, and encrypting between two parties.

Arguably, encrypting all snapchat traffic with the exact same key is almost worthless, and they could just send everything unencrypted. If a snooper knows they're looking at snapchat traffic, decrypting it is trivial.

At least with a key exchange, you have a good chance that only the targeted recipient can view the photo.

it is a bit disappointing that so many developers dive into making things without making some minimum research effort into what others have done before. its a recurring theme... however i'm torn because its nice that useful software can hit the market so quickly.

the usual piracy arguments are fine, and yes information that can be viewed by the intended recipient is necessarily crackable, but i think we owe it to our industry and community to not ignore the past X years of work in this field and implement embarrassingly naive amateur solutions. however it does require knowledge and effort to exploit this - particularly physical or close access to the device - imo no layers of security are not worth much once an attacker has physical access.

SnapChat is not alone - there are much, much worse offenders. That recent memory optimisation article about Firefox was imo considerably more shocking... browsers in general seem to be littered with amateurish crap. Even things like Office have some serious problems (why is this file locked? have you memory mapped it? do you need to actively stream my 1.2MB of excel file? really?) the Visual Studio devs have classically thrown away and rebuilt lots of good work over the last two iterations, whilst damaging the quality of the compiler - despite adding features. if valid code from popular libraries stops building between releases i wonder what regression tests are being done if any...

How would one solve this? One solution seems to be to generate key for each user and store the public keys on the server. If there is need to access the images on the server, encrypt them with a server key and then re-encrypt with the recipients' public key. Are there some problems with this approach (like some functionality of snapchat wouldn't work with this)?

I did not know about the "strings" command. I'm sure that there are plenty of binaries containing secret keys. I would assume that one way to protect against the easy prying ability of strings would be to use an integer array representing chars used to concatinate a string, but that does seem kind of hacky.

Cause we know the encryption key...

Because DRM is an idiot lie.