
Decrypting Android Snapchat images - fla
https://github.com/programa-stic/snapchat-decrypt
======
the8472
"Digital files cannot be made uncopyable, any more than water can be made not
wet." \- Schneier on DRM

------
quotemstr
Nothing instills confidence in cryptographic code like the constants "bananas"
and "seems legit...". I'd have hoped that anyone dealing with AES and block
cipher modes would take the task a bit more seriously, even if the whole task
is, in this instance, ultimately futile due to the lack of a trust root.

~~~
cesarb
> Nothing instills confidence in cryptographic code like the constants
> "bananas" and "seems legit...".

And a class called "SlightySecurePreferences". One gets the feeling that the
programmer responsible knew exactly what he was doing, but had been told to do
it anyways.

------
higherpurpose
If Snapchat is serious about its users' private messages, it should be
implementing the Axolotl protocol for end-to-end encryption (what TextSecure
uses, too). But Snapchat _isn 't_ serious about it, as we've seen in several
securiy/privacy scandals involving the company so far, so I'm not going to
hold my breath for this.

[https://whispersystems.org/blog/advanced-
ratcheting/](https://whispersystems.org/blog/advanced-ratcheting/)

Pro tip for future chat app start-ups promising "security" or "privacy" or as
the latest trend goes, "anonymity" for their users. If you can't _really_ hold
your end of the bargain, don't do it! Promise cute emoticons or whatever,
instead. Hopefully there will be some class action lawsuits against companies
like Snapchat, soon. They need to learn their lesson.

~~~
meowface
You don't quite understand. The threat model here is "a Snapchat user
copying/saving a Snapchat image they receive", not TextSecure's threat model
of "a third party observer or man in the middle". Implement whatever protocol
you like, it doesn't matter; a user who roots his own device will be able to
do whatever he likes to data stored on that device.

------
espadrine
> _The key is generated from an MD5 hash using the Android ID concatenated to
> the string 'seems legit...'._

That is a stellar decision. I wonder if there were application-specific
constraints that prevented a more secure option.

~~~
splitbrain
In the end the application needs a key to decrypt the storage. That key has to
be stored somewhere on the device. On a rooted phone there is no place out of
reach, so all they can do is make the storage obscure. Unless the hardware
provides some inaccessible secure thingy there's not much they can do... I
guess even if it did a script like that could access the secure thingy via USB
debug as well.

I don't think the developers are to blame. They did what they could.

The real problem is that snapchat promises something it can not technically
deliver. Once a photo leaves your phone and is delivered to somebody else, you
lost control over that photo.

~~~
pennaMan
No matter how secure they store the photo, at the end the day a simple
screenshot makes it all for nothing. It would be cool if Android had some API
to disable screenshots.

~~~
kuschku
It actually has — Apps can prevent the system from taking screenshots by
telling the DRM hardware chip that they are showing important data. Actually
you can even prevent users from obtaining the data if you encrypt it with a
secure key and store this key in the DRM hardware chip.

Only problem: Someone could still decompile your app, use your API and request
the decryption keys.

------
fidotron
The fundamental problem here is application security in situations of rooted
devices is non-existent. Android lacks mechanisms for apps to tell they're
running as root too (as the root user could disable this) so you can't disable
functioning on rooted devices. (Chrome OS does not have this problem, as the
official builds are signed by a single authority).

Newer Android versions have support for hardware DRM modules which would allow
potential for some sort of nasty workaround (which may involve transcoding any
images into movies), but in the general case for the wider market it's not
going to work yet.

Finally, this is also why the NFC stuff is generally accompanied by another
isolated system, though I seem to recall early versions of that (like in the
Nexus S) proved to be sidesteppable.

~~~
mindslight
> _Android lacks mechanisms for apps to tell they 're running as root too (as
> the root user could disable this) so [apps] can't disable functioning on
> rooted devices_

As the owner of the device (ie the one who should have ultimate control over
it), this is _precisely_ what I want. It would be horribly broken for an
operating system to do anything else!

That we're not only still fighting the battle for _personal computing_ but
additionally having to defend against misguided ideas from people in
supposedly technical communities is ridiculous.

------
alecco
This work was done within the Sadosky Foundation in Argentina under a new
program to research/enhance security for mobile users. World renown
researchers are part of the team. Kudos to them!

------
habosa
Snapchat does not take security seriously. I used the Gibsonsec description of
the SnapChat API to make a Java Snapchat client called JavaSnap
(github.com/hatboysam/JavaSnap). It has been used in many Android apps with
close to 2M combined downloads (from what contribs have told me).

It was too easy. This is why things like 'The Snappening' happen (note: I
never did anything evil like that, but it would not have been hard).

~~~
meowface
1\. "The Snappening" was due to a breach of a third party service with no
actual ties to Snapchat. This is like saying Bitcoin is insecure because of
Mt. Gox's breach(es).

2\. Most apps have documented or undocumented APIs. Writing a client to
consume them does not indicate insecurity. It's only a security issue if the
undocumented API exposes something that the company did not actually intend to
expose (which, to be fair, is fairly common).

I have serious doubts about Snapchat's security due to the username <-> phone
number leak discovered by GibsonSec, but the other things you listed say
nothing of their security posture.

------
mukyu
I don't understand why it says the IVs are _unnecessarily_ stored as without
them you could not decrypt the first block for each image properly.

~~~
MichaelGG
Maybe the unnecessary part refers to keeping the IVs in the "secure" bananas
file, instead of as unencrypted metadata in the DB? IVs aren't a secret.

------
jszymborski
I don't know much about the Android environment, and I get that regardless
you're storing keys in a hostile environment, but would using the Android
KeyChain to store the passwords instead work?

[https://developer.android.com/reference/android/security/Key...](https://developer.android.com/reference/android/security/KeyChain.html)

~~~
tokenizerrr
Only available since ICS and can still be cracked open when the phone is
rooted.

------
jaimex3
This is nothing, you can intercept the snap with wireshark and MITM:

[https://www.youtube.com/watch?v=CuW-
Rz65zLs](https://www.youtube.com/watch?v=CuW-Rz65zLs)

~~~
steakejjs
You can do this for any app.... not just snapchat.

He sets his computer as a proxy between snapchat-app and snappchat-server.
When I did this, Snapchat was certificate pinned to their server (it's been
over a year though..so correct me if Im wrong).

This isn't an attack other people on the network can perform on you.

------
wellboy
How a company with $163M in funding is not able to put just a normal
encryption into their app or hire someone who knows about encryption is out of
my comprehension.

We implemented a standard Blowfish encryption in university at a small project
on the side and it was better than that.

I'm by no means a cryptography expert, but you don't store keys on the device,
they are generated dynamically. Storing them in a directory that seems like an
unimportant directory is the most amateur mistake of trying to increase
security, as it adds zero security.

~~~
Erwin
Enlightens on then on how you would solve the issue. You have a program, and
the program is storing data and the "attacker" (here really the user himself)
wants to bypass the policies enforced by the application. The attacker has
access to both the binary of the app and the data.

What would you encrypt the data with that the user himself cannot also access?
Without a secure encryption hardware module, there's little you can do except
add additional layers of obscurity.

You could encrypt all the data with a key derived off the user's password, and
require the user to re-enter the key if the app stops. That too could be
broken.

You could store the images in some odd obfuscated format that only the app can
understand. That too could be broken after some time.

You could never store any images on disk at all and fetch them only when
requested. Then you have the third-party services imitating the app.

~~~
wellboy
I'm not sure as no system is 100% secure. It's only a matter of how high you
want to set the bar, but this bar is very low imho.

------
dpweb
Lemme get this straight.. The password is hardcoded into Java code, so by
decompiling it you can get that pw and break it? So essentially simple
decompilation was all that was needed? That's weak.

What would have been some better alternatives to keep the encrypted files safe
on the phone? Couldn't they have it call the server for a dynamic (safe) key?

------
ExpiredLink
The end of Snapchat?

I cannot understand people who confide their privacy to companies like Apple
and Snapchat. Of course their photos will be 'leaked'. It's just a matter of
time.

~~~
tjbiddle
Not really. Most people couldn't care less about the 10 second thing. They use
Snapchat just as a means of sending a quick photo. It's just _more fun_ than
texting. I know very few people who actually care about the privacy aspect of
it.

~~~
ExpiredLink
> * Most people couldn't care less about the 10 second thing.*

Really? That's Snapchat's unique selling proposition!

~~~
meowface
It is technologically impossible to prevent Snapchat users from saving or
copying images they receive from other Snapchat users. Replace "Snapchat" with
any other app here and the same principle applies.

Their proposition is not that this is impossible, but rather that it is not
easy for a typical end user to see past images. This enables a form of
ephemeral communication; it was never intended as a security feature, simply a
communication feature.

