Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse Engineering Snapchat: Obfuscation Techniques

hot3eed.github.io

Post reply on HN
Print view View original

71–80 of 180 posts

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#71

Post by looperhacks »

IAmLiterallyAB wrote: post #64
brendonjohn wrote: post #62

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.

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.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#72

Post by grecy »

saagarjha wrote: post #68
grecy wrote: post #65

Will Apple approve an app with this level of Obfuscation in it's source? I thought they had to have the source itself?

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.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#73

Post by SXX »

surround wrote: post #42

There are already alternative front-ends for YouTube, Facebook, and Reddit. I’d love to see one for Snapchat and Instagram, although it looks like one for Snapchat would be incredibly difficult.

Most usable alternative front-ends for such services are usually just parse web API or even plain html in case of YouTube. Snapchat don't have any web app so parsing it is tricky and Instagram provide only limited set of features on the web.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#75

Post by theincredulousk »

just-ok wrote: post #27

This is an awesome write-up; I’m shocked at the level of effort that went into Snap’s obfuscation process. It implies that are entire teams of engineers out there whose sole job it is to play cat&mouse with reverse engineers and nothing more. Another comment mentioned that this effort is outsourced, so not only are there teams, but entire companies dedicated to this! What a blast that must be... though the immense am…

There are commercial products that largely automate these techniques through metadata. See Arxan.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#76

Post by pjmlp »

jor-el wrote: post #52

Some I see are surprised to see the level of obfuscation used in the application. Many pointed, many ingredients for the obfuscation used in the app are off-the-shelf and few of them can be said to be well known in the industry, but still there is a cost in integrating them into a product. Obfuscation is notorious in breaking things which should work normally (normal compilation process) and as a own goal making it h…

I think that it is due to the copy cats that keep stealing apps and repacking them.

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.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#77

Post by theincredulousk »

rvz wrote: post #24
wallflower wrote: post #13

Earlier quoted context omitted.

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 secu…

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 bypass…

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

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#78

Post by pjmlp »

looperhacks wrote: post #71
IAmLiterallyAB wrote: post #64

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…

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

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#79

Post by pjmlp »

akersten wrote: post #9

Wow, that seems really messy. If you're just after the API key or whatever, wouldn't reversing the Android app be simpler? As far as I know, you can't do all these low-level tricks on the Java platform.

Not only does Android use obfuscators as part of the build process, most applications make use of native code for their secure modules.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#80

Post by theincredulousk »

jayd16 wrote: post #43
qvrjuec wrote: post #25

Earlier quoted context omitted.

Because the users who were less clearly fake would still degrade the experience of the rest of the users. To use an analogy, consider currency counterfeiting. The government doesn't just look to see who is spending lots of cash without a job because it's a much harder problem than making the bills extremely difficult for the layman to forge. Same principle here - making the token extremely difficult to forge is the e…

I'm not sure this analogy tracks very well. The government doesn't bother heightening the quality of one dollar bills, either. The government doesn't have information about every transaction, a web API does.

These techniques are largely automated through metadata during a build process. It takes effort to setup, but not nearly as much effort as you think. The effect is asymmetrical- what takes you 1 hour to do costs a reverser 100. At least as time efficient as implementing backend detection algorithms.
Post reply on HN