If the project doesn't actually contain copyrighted code from SnapChat (and it doesn't seem to) then a DMCA takedown notice would be illegitimate and fraudulent.
Not that that would prevent SnapChat from making one, and GitHub from following along with it. GitHub has a trend of taking down repositories lately...
It's not like they have much choice -- they're bound under the DMCA to do so. In fact, GitHub's probably one of the best companies about this sort of thing with their full transparency.
From a casual glance over the list of cases brought under CFAA[1], that would be completely unheard of, and seems contrary to the spirit of that law. If I'm reading correctly, it hasn't ever been used to punish someone who wrote software, only people who have used software to allegedly exploit servers. Therefore the users of this tool would be at risk, not the author.
Excuse me but did you read the README? The author clearly admits to using it:
"Since Snapchat imposes few restrictions on what data can be uploaded (i.e., not just images), I've taken to using it as a system to send files to myself and others."
What types of files might one actually want to upload to their servers? This falls into the "cool" category for me more than making me want to try it (especially since you can't delete files you upload...)
Hey, I'm one of the authors. In fact you can delete a file. Just "view" it in the app and it gets deleted. What you can't do is delete it from the command line!
As for your "is this useful" question, I use it to send files to myself, my friends, and other computers, since it's a bit like asynchronous SCP. But of course YMMV.
Thanks for the reply, and I can see that just a few minutes ago you clarified the wording in the readme, which was my next suggestion. Definitely a cool tool, I'll definitely try it out now that I know "viewing" it deletes the file still (makes perfect sense). I figured it'd be good for temporary file storing & sending, just was a bit worried about leaving permanent copies on their servers.
When I saw it on HN frontpage, I freaked out and started adding more customization and features. :)
As we speak I'm writing the feature that will allow you to use a config file ('~/.snapchat_fs') to configure, e.g., the encryption protocol used, which would make storing features more secure for you, the user, in the event Snapchat starts snooping through stuff you've uploaded.
I don't read PHP, but you're right that we're not the first to get through the API. We might be among the first to misappropriate the service for use of storing and managing arbitrary files, though.
FWIW, we did do this from scratch. I have no idea if this library has the same secret keys and stuff, but after we finished we went back and looked at other amateur audits and found the API to be basically unchanged in form between them, meaning that if they changed the API, it differed only in the specifics of the keys used, and not in say the protocol for handing server tokens and request tokens out. (I still don't know if the keys are the same between that library and our core, for example.)
This seems like kind of a crummy thing to do to snapchat, but I like the idea.
I wonder if that could be successful, like a file swapping service built on the same premise of one time only. Charge a nickel a shot or something. I have no idea why that's useful, but for some reason I think it's cool. Maybe just because it's set and forget and you don't have to worry about cleaning up later.
I can see that working. I had this camgirl as a friend on Snapchat and must have clicked her story update about 200 times fapping to it. I bet Snapchat has thought of this too, just looking at data like mine xD
I presuming without searching that someone has produced a SnapChat-like application that just doesn't delete photos and lets you look at them as long as you like? That seems like a pretty reasonable thing to do and basically impossible for SnapChat to stop.
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).
Poor name for the package: sfs is already a filesystem type used in the embedded/musical-instrument industry (primary Yamaha). A better name would be scfs, imho.
* Use MITMProxy to execute a man-in-the-middle attack, which lets you see all the packets in plaintext. It's a command line app which prettifies the packets in a readable way.
* From the packets we can get a lot of info, like where the packets are going, what data the fields contain, etc.
* We can also intercept the packages and mess with the fields to see what breaks when we change things.
* From here we use smali to decompile the Android DPK. Since debugging symbols are left in, this leaves a lot of info for us to look at.
* We ctrl-F for words like "encrypt" and "secret". This leads us right to the call to util android encrypt which is encrypting the images. The argument is a hard-coded secret string that turns out to be used everywhere.
* Looking through the source where that key is used we see that it's also used to generate request tokens, which validate that a request to the API is valid.
* And so on. Eventually with some more poking around we end up with the library here.
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.
28 comments
[ 2.6 ms ] story [ 61.9 ms ] thread[1] http://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act#No...
1. FUSE Python: http://sourceforge.net/apps/mediawiki/fuse/?title=FUSE_Pytho...
or
2. pyfilesystem https://code.google.com/p/pyfilesystem/
I've seen FUSE Python used in some different projects on github, and it seems to work pretty well. I'd not heard of pyfilesystem until recently.
As for your "is this useful" question, I use it to send files to myself, my friends, and other computers, since it's a bit like asynchronous SCP. But of course YMMV.
As we speak I'm writing the feature that will allow you to use a config file ('~/.snapchat_fs') to configure, e.g., the encryption protocol used, which would make storing features more secure for you, the user, in the event Snapchat starts snooping through stuff you've uploaded.
I don't read PHP, but you're right that we're not the first to get through the API. We might be among the first to misappropriate the service for use of storing and managing arbitrary files, though.
FWIW, we did do this from scratch. I have no idea if this library has the same secret keys and stuff, but after we finished we went back and looked at other amateur audits and found the API to be basically unchanged in form between them, meaning that if they changed the API, it differed only in the specifics of the keys used, and not in say the protocol for handing server tokens and request tokens out. (I still don't know if the keys are the same between that library and our core, for example.)
I wonder if that could be successful, like a file swapping service built on the same premise of one time only. Charge a nickel a shot or something. I have no idea why that's useful, but for some reason I think it's cool. Maybe just because it's set and forget and you don't have to worry about cleaning up later.
Does anything easy to use do that already?
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).
Our process was:
* Use MITMProxy to execute a man-in-the-middle attack, which lets you see all the packets in plaintext. It's a command line app which prettifies the packets in a readable way.
* From the packets we can get a lot of info, like where the packets are going, what data the fields contain, etc.
* We can also intercept the packages and mess with the fields to see what breaks when we change things.
* From here we use smali to decompile the Android DPK. Since debugging symbols are left in, this leaves a lot of info for us to look at.
* We ctrl-F for words like "encrypt" and "secret". This leads us right to the call to util android encrypt which is encrypting the images. The argument is a hard-coded secret string that turns out to be used everywhere.
* Looking through the source where that key is used we see that it's also used to generate request tokens, which validate that a request to the API is valid.
* And so on. Eventually with some more poking around we end up with the library here.
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.
You're right about the keys though, I always forget which keys get used for what.