Certificate pinning spoils that, no spoofing of certs with pinning.

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.

Yes that complicates things. But if you can find the cert in the binary's data section, maybe you can patch it with your own.

This probably runs into the same issue mentioned in the article, where the checksums are wrong and you end up in an infinite loop.

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.

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, because nobody knows how the process really works.

In my experience, SafeteyNet bypass on rooted devices has been a solved problem for a long time through Magisk Hide.

Except not all Android devices have Play Services, for example is Snap available in China?

Just don’t do something like only trust a specific CA cert. really-really pin to a leaf.

My guess is the X-Snapchat is a one-time use token that changes on a per-call basis and may even been hashed to the actual data being sent in the API call. For example, if Snapchat is sending a pic that has a MD5 hash of X, the token somehow encodes that or other information so you cannot reuse that token.

I’m confident the security engineering team at Snap has all kinds of white hat teams to prove and probe the security constantly.

According to a old AppSec talk, they used a third-party security company to implement this stuff. They are a customer to a company called ‘Arxan Technologies’ that implements these ‘guards’ in their software. They’re very good at not revealing this, but it came up whilst looking at their private API.

These secret keys are there but heavily obfuscated and is nothing more than white-box cryptography which can be bypassed via emulation.

Worked with Arxan before. They are legit - what is described here is the tip of the iceberg. Haven’t even gotten into in-memory instruction and data encryption. If you’re dumping the binary you’re likely not even seeing all of what is executing at runtime