Live data from Hacker News

Reverse Engineering Snapchat: Obfuscation Techniques

hot3eed.github.io

31–40 of 180 posts

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#31
post #23

Philosophically I never gave much thought to securing app client code. Why not just track usage stats and ban clearly fake/high throughput users?

Because not so clearly fake users still make it through. The server side is also fairly quick on the trigger if you accidentally send anything that doesn't make sense, you're kicked off to "re-verification land"

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#32
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…

I can't help but wonder if it's more of a "a little from Column A, a little from Column B" scenario. 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.

The vast majority of these obfuscations (maybe except for the scratch arguments one) are done as LLVM passes, so it's done post-code writing, writing code like this would be unreadable and unmaintainable.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#34
post #4
post #2

Things were definitely much simpler a couple years ago.

I'm actually a bit surprised it's taken as long as it has for mobile obfuscation to catch up. Both on the Android bytecode and the iOS native code side there are obvious PC analogs in the form of .NET obfuscators for MSIL and packers and game DRM for native code. Of course, the Obj-C runtime throws a little wrench into things on iOS, making it a bit of a hybrid - but the approaches are still similar. It's still an ul…

I've seen this for _years_ already - it might also be because of a bit of an app usage difference, where the people that typically do these writeups or browse HN don't install the shitware on the app stores that do these things, except for rare common cases like large communications platforms (Snap)

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.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#35
This is some pretty heavy-duty obfuscation. What is the business case for this amount of work towards preventing reverse-engineering? Decent rate limiting should be much more effective than making such a herculean effort to obfuscate one's API.

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

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#36
post #12
post #6

Snapchat is notoriously difficult to automate/spam. 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 an…

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.

[deleted]

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#37
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…

[deleted]

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#38
post #36
post #12

Earlier quoted context omitted.

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.

[deleted]

[deleted]

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#39
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…

> 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

Do you think the same thing of anti-spam teams too? This is pretty much just anti-spam/anti-abuse.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#40
post #16

How many of these tricks are off the shelf techniques? Seems like a tremendous effort.

OP here. About half are off the shelf. Joint functions, the breakpoint infinite loop, in-house memmove, the overflowing thing, those I haven’t read about anywhere before.

For the overflow, Jagex with RuneScape did it in Java. They also did stupid Object arrays 7 or so levels deep, doing casts on casts in between. The bytecode itself made the actual runtime slow to a crawl (anywhere from 5 to 10x slowdown.) This was circa 2014.
Post reply on HN