pencilo's comments

Chad here.

First off I'd like to give props to the gibsonsec.org guys, that is a really high quality protocol breakdown and the attack is neat. I see nothing wrong with going full disclosure after being ignored this long.

The key point is to understand that I, as a protocol reverse engineer/attacker/professional bad dude have access to _everything_ the Snapchat app has. I own the network and the device the app is running on. I can look at every bit of Snapchat's memory space if I want.

I can view all network traffic between the app and the servers. Either by MITMing the app or if the app has cert pinning nothing stops me from peaking at buffers(I did this with Square, it was actually not that painful).

With just that you can see it is not possible to stop me from saving a Snap. I don't even need to make my own API calls, I can simply intercept the traffic of the actual Snapchat client and pull the image out of there. Even if you had a magical way to make sure only the actual app was requesting the Snap it wont help, it is the legit client.

The more important take away though isn't that Snapchat is broken, because that's not super interesting.

What you should take away from Snapchat is that you cannot stop people from calling your remote APIs that your apps are using. All it takes is someone sufficiently bored to go dig through pcaps and decompiled code to map out the API.

So what do you do? Don't trust the damn client. Your service shouldn't be broken just because I am calling your API outside of the bounds of how your application will call them.

This isn't a new idea, but it seems like a lot of people never learned this lesson.

There is an important difference between what Snapchat needs and what game designers need.

First of all, look at what is actually successful for DRM in video games. The only surefire way to make sure someone is actually valid is to force them to authenticate(and get data from your server) to play the game. To do this they'll need to provide credentials(like a CD key) and then they'll get the content[1].

Now look at Snapchat. At no point do we need to fake having valid credentials. We are coming in and presenting valid credentials to Snapchat, my login and password, and it verifies those are correct and begins a sessions.

If you want an analogy to game DRM you need to look toward things like hacked clients in MMOs.

tl;dr Games want to prevent people without valid credentials from playing, we have valid credentials already(our own accounts). [1] This is really simplified and you can find many games, like the new SimCity, that the server interaction is small and simply emulated in the crack.

You're slightly wrong on the app side of things and the keys.

There are in fact two 'secret' keys. One is a fixed SHA256 hash used for their weird request generation and one is the fixed AES-128 key for encrypting snaps. The two have nothing to do with each other besides both being named secret.

Also it was not ctrl+f for secret as much as it is looking at the call sites for calls down into crypto libraries, from there it is simple back tracing to see where the keys came from. Debug symbols are nice but it works just as well if they strip debug symbols and obfuscate.

Hi, one of the authors here. A good chunk of the core is from my python Snapchat API(https://github.com/pencilo/pysnapchat) which lets you do things like download snaps and send snaps.

You are correct that it is impossible for them to stop you from downloading the image and saving it. Images are encrypted on upload but they are encrypted using a fixed key in AES-128 ECB, so it doesn't do any good.

The simple truth with Snapchat is they cannot make it impossible to download and save the images without trusted computing support(which they wont get).