

Why can we still crack snapchat photos in 12 lines of Ruby? - trippy_biscuits
http://security.stackexchange.com/questions/52584/why-can-we-still-crack-snapchat-photos-in-12-lines-of-ruby

======
Stealth-
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.

~~~
gaius
Actually it does attempt to do that - it requires you keep your finger on the
screen while viewing so you can't perform whatever the screenshot command is.
Which is lame but that's not the point - their selling point is that they _do_
claim the images are transient. I'll wager 90% of their traffic is images
people would not want made public, and some of it will be technically illegal.

~~~
StavrosK
What's the point of that? I just tried it, and I can take a screenshot fine
with one finger on the screen.

~~~
wlesieutre
It used to be that taking a screenshot briefly stopped the touch event, so it
could notify the sender when you took a screenshot.

iOS 7 fixed that bug, but added an official way for apps to detect
screenshots. I would guess snapchat has just hung on to their old interface
out of tradition, since it still works. It just doesn't have anything to do
with screenshots anymore.

~~~
StavrosK
Ah, that makes sense, thank you.

------
kartikkumar
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

~~~
girvo
I wonder if you'd even have block level access to storage to pull that off
through mobile APIs?

~~~
e12e
Well, it runs on Android? And you can compile your own kernel, and install
google apps (or even run it in an emulator, anyway)... so... game over (wrt
access to whatever is written to disc (or ram...))...

------
BWStearns
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...](http://www.wired.com/wiredscience/2014/02/cryptography-
breakthrough/)
[0][1][http://eprint.iacr.org/2013/631.pdf](http://eprint.iacr.org/2013/631.pdf)

~~~
deutronium
While I agree that is amazing, it still wouldn't solve SnapChat's problem.
Because once the image is decrypted and displayed to the user, you can easily
copy it from memory and store it indefinitely.

------
habosa
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.

------
ZoFreX
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?

~~~
habosa
Yes the same encryption is on in-flight snaps. You could absolutely set up
something like that.

~~~
ZoFreX
Well that's just awful.

------
e28eta
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.

------
jheriko
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...

------
rplnt
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)?

~~~
e12e
You could improve (but not solve) the problem of raw access to data. But that
does nothing wrt solving the "problem" of recipients storing a permanent copy
of received snaps -- all they need is a camera.

It's a little like the old (tv series) adage of don't discuss crime in a car
-- it's easy to place a bug in a car, so assume that it's bugged, if you have
reason to fear someone's bugging you. Even if you're using encrypted
phone/voip-chat -- that won't help squat if there's a microphone in the
vicinity that can pick up both ends of the conversation...

------
mrinterweb
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.

------
callesgg
Cause we know the encryption key...

------
davidgerard
Because DRM is an idiot lie.

