What a blast that must be... though the immense amount of [invested|wasted] (take your pick depending on cynicism) effort spent on this game makes me a little sad. All of these brilliant minds just... cosplaying Sisyphus?
And we wonder why such a high % of tech workers have a deep discontent & are desperately searching for meaning.
Here, the goal is to prevent phishers, fraudsters, scammers, spammers, catfish, impersonators, malware spreaders, etc. from running amok in a somewhat unprecedented way by tricking users en masse into thinking they're really receiving photos/videos in real-time, using automated tooling. My understanding is this heavy degree of obfuscation (combined with other anti-tampering tactics) has gone a very long way to mitigate a huge amount of abuse.
From talking to people who've tried to bypass these mechanisms to do unauthorized and potentially risky things (like send things from a custom client in a way that could allow for mass automation), they describe this as an essentially intractable hurdle from their perspective. Of course, it isn't in actuality, but it is for most people when compared to lots of other social media apps, and I expect Snap to change things around not long after OP releases part 2. Cat-and-mouse never ends.
that's an odd position to take. You seem to be ignoring the philosophy behind the cat&mouse game that is RE (and Security Engineering in general). What you call cosplaying Sisyphus is to me one of the most rewarding aspects of Tech. Breaking things especially is fun when somebody has made an effort to lock things down (and maybe even claimed it's "unhackable"). This is an area where you're still paid to solve puzzles and where taking the long-view matters. RE is complex and hard but exactly because of this it's one of the most rewarding things in all of CompSci.
There's no doubt they have skilled security staff, but - as a company overall - they also grew very quickly.
How much of that obfuscation is intentional and how much might just be old code from a few years ago that nobody got around to removing? Before it was passed through obfuscation.
Do you think the same thing of anti-spam teams too? This is pretty much just anti-spam/anti-abuse.
Why not just track usage stats and ban clearly fake/high throughput users?
The issue is pulling images and chats out and potentially saving them, without notification to the sender. If the API was public Snapchat could no longer promise that images are temporary, because an unofficial client could store the images.
They have a vested interest in playing dumb to that fact. They can't really do so if the content escapes out into the wild and shows up in congressional hearings, lawsuits, FBI investigations, DOJ reports, etc.
Also, any party to a conversation can use the report button to send the unencrypted message to Snap for review. They employ actual content moderators as well, who have made reports to federal law enforcement before.
This is a fairly standard debugging technique.
> in-house memmove
You sure they didn't just statically link a libc?
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...
[1]: https://blog.quarkslab.com/deobfuscation-recovering-an-ollvm...
The goal is to get the X-Snapchat token. The most elegant solution is to find the secret in the binary and reverse the algorithm to generate tokens. Wouldn't it be easier to MITM the endpoint; set up a dummy server (which collects tokens) in front of a proxy that spoofs the DNS and TLS certs (may be easier on rooted Android than iOS).
In my last attempt I gave up and went for dumb UI automation, but it would be cool (and worth good money) to exploit the private API.
Cert (or hash of) delivered with app. If server cert doesn't match expected value coded into app, someone is messing with something, terminate connection.
I’m confident the security engineering team at Snap has all kinds of white hat teams to prove and probe the security constantly.
These secret keys are there but heavily obfuscated and is nothing more than white-box cryptography which can be bypassed via emulation.
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.
Their approach is to make a blob of code which collects all kinds of details about its environment (for example, Object.keys(window) ). It then uses a hash/concat of those details (with some random too) to decode data to decide what else to collect, hashes or concatenates those in too. Repeat a few times. Then send the final data blob back to the server.
The server can then run a tiny emulator to run the code with the same seed random to check the results are the same on a whitelist of allowed environments.
Both use some wacky methods for request signing that include encrypted code, obfuscated control flow, hashing the browser environment, ...
Assembly obviously allows for much more powerful obfuscation than Javascript. Webassembly is somewhere inbetween, but a viable path since it is pretty universally supported by now.
Networks requests can be inspected trivially in the browser though, which makes things a lot easier.
Apple have no such system as far as I can know, and if they do, don't share it with 3rd party developers.
They've come a long way since then!
[0] https://en.wikipedia.org/wiki/LA_Hacks
[1] https://medium.com/hacktech-2014/everyones-watching-hacktech...
Your research looks fascinating and sounds similar to what I remember of the hack. Might be the same person we’re talking about. Small world!
3eed, would you be open to adding an RSS feed?
That said, obfuscation is increasingly being used in mobile applications now. Check your banking application or some government applications, you will find obfuscation being used. With mobile applications getting richer and lot of code executing on the client side, makes it compelling case to secure applications by using obfuscation (as a defense-in-depth approach).
Open standards like OWASP MSTG [1] MSTG-RESILIENCE-9 recommend such approach.
Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis.
Most Android developers lack native coding experience, so after failing attempts to protect their applications with the DEX bytecodes obfuscator, they think that recoding parts of the application with the NDK will save them.
However as this article shows, and most here know, they shortly learn that against good attackers, the only benefit from using native code directly is it takes a little longer to decipher what the application does.
So then one turns to solutions like what you are describing.
Yeah like that one app I reversed a while ago that generated the API key in a native library. I was able to get the key by building my own app around their library and calling the function that returns the key. Didn't even have to disassemble the thing.
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 may be creating the token, but it's not obvious what you're supposed to be using the method to sign.
What do they use it for? As far as I could tell, it's so they can verify requests at the edge nodes of their network. When you provide a bad x-snapchat-client-auth, you get a near-instant 403.
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.
- 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.
I remember taking a reverse engineering course in the university where the professor didn't even bother to explain the basics, it was like black magic and left me frustrated, but I still feel amazed when I read blog posts like these.
It's still an ultimately pointless cat and mouse game as long as an attacker can trace the hardware (and with full-platform emulation tools like Corellium, this capability is unlikely to go away soon), but still an amusing one to watch.
Many Asian mobile games run malware DRM like this - https://www.wellbia.com/home/en/pages/xigncode3-for-android/
They are incredibly invasive and insecure, exfiltrate tons of PII (location, private IP, mac, ...) where possible unencrypted to bare IPs in various countries. This company in particular also has a PC-based anticheat rootkit that doesn't prevent cheating and allows the developer to "remote control the user", which is also an advertised feature.
However, the binary level protection is only tangentially anti-screenshot insofar as it also blocks third-party 'scraper' apps. Fundamentally, it's about requiring use of the Snapchat app to access the Snapchat APIs, and as we know from the ongoing saga with other social networks like Twitter, this is ultimately about business control over posts (preventing spam-bots, scheduled clients, and so on) and at the end of the day, ad revenue.
1. Open the Snapchat app for a bit so it is downloaded / cached.
2. Turn on Airplane mode.
3. Screenshot and screen record to your desire.
4. Delete the whole app.
5. Turn off Airplane mode and download the app again.
Edit: another comment mentions that snap chat uses an existing solution, which makes more sense than the expense of developing this sort of obfuscation in-house: https://news.ycombinator.com/item?id=23558784
This is especially important given that Snapchat is widely used to trade amateur underaged pornography.
Remember that obfuscation makes your code run slower. This specific one is part of the reason why the dyld team probably hates you.
a) outbound bots that send messages to users created in bulk messaging millions of users. b) inbound chatbots that answer messages c) when they had snapcash, they didnt want bots generated collecting cash.
spam is a multi million dollar industry.
@3eed i guess it's not considered obfuscation but you gotta pass the correct version # or you won't be able to connect either, old versions are immediately obsolete.
https://www.bloomberg.com/news/articles/2017-07-21/snap-hire...
That sounds particularly devious.
There may be some money in standing up a datacenter that is filled almost exclusively with smartphones.
I once had the chance to work on a project disassembling casino machines, and they had similar protection appropriate for the technology of the time
It’s clever, but man... I have to believe these talented folks were destined for something greater.