Snapchat. It’s a big craze. The point: To send photo’s that self destruct after being viewed. However; there are hacks as well as entire apps which can allow the saving of images without the sender being notified. Awesome. Hardly.
I have spent the last 2 hours finding an efficient way to reverse engineer the protocols and data being passed between the SnapChat client and the SnapChat server, in hope that I’d gain some more knowledge about how snaps are encrypted/transmitted/received by the devices. Unfortunately I have been unable to find a way to read the data in a raw format. I’ve tried both packet sniffing via WireShark, various HTTP Proxies, as well as my own Python creation. Nothing.
So now, I am writing this piece from my perspective, about how the service should work.
The service appears simple. For example; Friend A sends a snap, the server holds this image and sends a push notification to User A’s phone, telling him/her they have an image awaiting collection. User A opens the app on their phone, SnapChat now downloads and caches all the snaps which have been awaiting collection; including Friend A’s snap.
You now have the snaps on your phone. Mods/Plugins like Phantom (iOS) simply save these cached images.
But what about other apps, like “Snap Save”? This is what I would have liked to gone into earlier. It appears the developer of Snap Save has reverse engineered the connection protocols, and mimics within it’s own app. This allows it to save the images straight to the device, instead of restricting the time limit like SnapChat does.
Could SnapChat fix this? Yes. They could.
Why don’t we fix it for them. Here’s how:
- Server generates a random string(), seeded from the current time, therefore it always changes. Let’s set up a time window, to allow these to last for ~2 minutes
- Server encrypts this string using a public key (KeyA). The private key(KeyA) is within the App Bundle.
- Server sends the encrypted string to the client
- Client decrypts the original random string(stringA) and uses the private key (KeyA)
In the mean time, the server has done the following:
- Uses the original stringA
- Uses the secret algorithm to turn StringA into StringC
The server has now received StringB from the client
- Server decrypts the Encrypted StringB using KeyB
- Server should compare it’s own StringC to the client’s StringB
- If StringC is equal to StringB, we should in theory have an authorised client.
- The server should now give the AuthorisedClient an access token with an expiration time or only permissions to view a specific image to limit the damage an unauthorised client could do with it (ie, saving snaps).
It’s complex, and yes, it could most definitely simpler, I am sure there are more efficient ways (lol lots of server resources) to do this, however, I have never implemented such a system, nor have I began to research this topic. This is simply how I would jump in and solve the problem.
And a quick note, this does not solve issues of plugins such as Phantom, as they hook into the SnapChat app itself.