91–100 of 180 posts
This is brilliant work, I'm hoping in part II we get to see it working against the API. I reverse engineered this in a production environment. It took approximately 7 months to build a scalable solution. The investigation on how to create the x-snapchat-client-auth token is brilliant. One day I hope to do a talk on what my old team did to circumvent it. There's a painful gotcha on the homestretch for this token: You…
Snapchat acquired Obfuscator-LLVM and the people behind it in 2017, which was actually partially open source for a period of time. It is a compiler backend for LLVM that obfuscates your code for you. You can read a bit about some of the techniques used on their old wiki:
https://github.com/obfuscator-llvm/obfuscator/wiki/Features (outdated)
https://www.bloomberg.com/news/articles/2017-07-21/snap-hire...
Earlier quoted context omitted.
No, they don't. You can provide them with symbol files for your application so they can symbolicate crashes on your behalf, but this isn't required. (Interestingly, there are teams at Apple that reverse engineer applications for compatibility reasons, and the occasional "someone got an obfuscated binary past app review and we need to know what it does".)
Huh, thanks. I thought they reviewed the source of all apps to make sure they aren't doing anything naughty.
I’m surprised that no one has mentioned how this is actually accomplished. The answer is: largely automatically, at the compiler level. Snapchat acquired Obfuscator-LLVM and the people behind it in 2017, which was actually partially open source for a period of time. It is a compiler backend for LLVM that obfuscates your code for you. You can read a bit about some of the techniques used on their old wiki: https://gith…
Well at this point, you might as well run the binary in a Mach-O ARM emulator since Snap has seriously cranked up the reversing difficulty to level 10,000. I suggest anyone looking at this would need to use Corellium such that Snap has made it hard for almost anyone to get their private API.
Your only hope for emulating the whole thing would be Corellium, really. Too many real-device-dependencies.
- Request Path - Timestamp - Snapchat Binary Size - Bit Flags for various hack checks such as jailbreak, checks for various tweaks, etc. - Device Type - iOS Version - A pair of counters, I believe these were being used to detect real devices being used as signature proxies. - A unique device ID generated at startup
I can't remember which one of the tokens this was for. There is a X-Snapchat-Client-Token used at login if I remember correctly and X-Snapchat-Client-Auth-Token which is used for every request.
I never ended up using it for anything but it was a lot of fun getting token generation working through emulation. I'm not sure if I was actually able to bypass all their checks or if it would have been detected had I actually tried to deploy it for something in production.
Earlier quoted context omitted.
You could patch Android and run it in an emulator. Or patch Snap not to care. Not super familiar, but there should be a way. Client side security can only do so much.
You can't patch Snap to not care because the safetynet process is (roughly) like that: The App asks the Play libraries whether the phone is okay. This is verified (in part) on the Google servers, so the Snap servers can ask Google whether a call came from a non-tampered phone. The client can't do anything about it, except tricking google into believing the phone is not tampered with. Which is notoriously hard, becaus…
If you dig very deep, you can also find an offer to come work at Snapchat. Most will never find it.
Earlier quoted context omitted.
Assuming this is for Android, the APK would no longer be signed and would cause all login attempts to fail. Have a read about "SafetyNet Attestion API" for Android.
You could patch Android and run it in an emulator. Or patch Snap not to care. Not super familiar, but there should be a way. Client side security can only do so much.
I’m surprised that no one has mentioned how this is actually accomplished. The answer is: largely automatically, at the compiler level. Snapchat acquired Obfuscator-LLVM and the people behind it in 2017, which was actually partially open source for a period of time. It is a compiler backend for LLVM that obfuscates your code for you. You can read a bit about some of the techniques used on their old wiki: https://gith…
Funny thing about things like that is that you can likely write tools to automatically deobfuscate, if you know the mechanisms. Of course, this takes time and effort, and is beyond most spammers' capabilities.
I'm curious, can anyone recommend any techniques (or companies providing solutions) for attempting something similar with javascript in a browser calling an API? Obviously it's much more difficult to obfuscate an algorithm for generating a client token in JS than it would be in assembly, but I'm just curious if anyone has tried any form of "lock down my API so it's only callable from the web front end I provide" obfu…
Generate secret tokens that the server can validate using some heavily obfuscated process. Compile the JS to WASM.
If you can use HTTP3 or WebSockets that's a bonus, because you can create a custom protocol that does some secret handshake before sending the goods.