3 ms·
Hey, I'm one of the authors. 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 c
by antics 13y ago
Hey, I'm one of the authors.
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.
- pencilo 13y agoYou'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.
- antics 13y agoMeh, I literally ctrl-F'd and looked for "encrypt". Worked on the first try. You're right about the keys though, I always forget which keys get used for what.