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

151–160 of 180 posts

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#151

Post by benmmurphy »

trishume wrote: post #147

One thing I'm curious about is what they do to try to stop you from just ripping out the obfuscated token generation library and setting up a harness to run the whole thing in https://www.unicorn-engine.org/ or something. Like presumably they don't compile their whole app with obfuscation and it's just some library that's linked in with some kind of stable-ish API contract with the rest of the app. I wouldn't be surp…

I think someone used this route but ran the real binary on real phones that had been injected with his code that allowed tokens to be generated.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#152

Post by 3eed »

trishume wrote: post #147

One thing I'm curious about is what they do to try to stop you from just ripping out the obfuscated token generation library and setting up a harness to run the whole thing in https://www.unicorn-engine.org/ or something. Like presumably they don't compile their whole app with obfuscation and it's just some library that's linked in with some kind of stable-ish API contract with the rest of the app. I wouldn't be surp…

You could manage to isolate these functions. The problem is that it's much of a hassle to run the whole thing on an emulator because there are way too many real environment dependencies, and even if you go the hackery way and patch all those, you won't know if you're generating one with the correct parameters because you're treating the whole thing as a black box.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#153

Post by 3eed »

ponker wrote: post #150
trishume wrote: post #147

One thing I'm curious about is what they do to try to stop you from just ripping out the obfuscated token generation library and setting up a harness to run the whole thing in https://www.unicorn-engine.org/ or something. Like presumably they don't compile their whole app with obfuscation and it's just some library that's linked in with some kind of stable-ish API contract with the rest of the app. I wouldn't be surp…

Why wouldn’t they obfuscate the whole app?

That'd be a noticeable performance hit I'd say.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#154

Post by alasdair_ »

ffritz wrote: post #90

I was wondering if there are any steps a developer of a small app can take to add such a header and lock down the API so it only answers to said header. This level of obfuscation doesn’t seem doable for smaller shops. Is there something simpler, that is “good enough”?

JWT perhaps?

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#155

Post by xwdv »

Nextgrid wrote: post #97
xwdv wrote: post #50

If you dig very deep, you can also find an offer to come work at Snapchat. Most will never find it.

Those who do have the skill to find it probably have better places to work for than a barely profitable company whose only revenue stream is to push trashy clickbait.

Barely profitable companies regularly pay big salaries for the right people, it’s why they’re barely profitable.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#157

Post by 3eed »

ffritz wrote: post #90

I was wondering if there are any steps a developer of a small app can take to add such a header and lock down the API so it only answers to said header. This level of obfuscation doesn’t seem doable for smaller shops. Is there something simpler, that is “good enough”?

Security is a continuum, how much resource you can put into fending off prying eyes depends on how valuable your assets are and so how many prying eyes are targeting you. But as a start OLLVM is open source and not bad at all.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#158

Post by RNCTX »

snazz wrote: post #133
RNCTX wrote: post #84

Earlier quoted context omitted.

Because Snapchat is ultimately an application designed to trade in porn of amateurs including (and perhaps especially) teenagers. 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.

I think you wildly misunderstand how many people (teenagers included) who use Snapchat for PG-rated things exclusively. The end-to-end encryption (of snaps) and “disappearing” nature makes it work well for anything sensitive, but porn is certainly not the only thing people use it for. Also, any party to a conversation can use the report button to send the unencrypted message to Snap for review. They employ actual con…

Sounds like a bit of lipstick on a billion dollar pig. I'm sure we all remember their early days, their marketing material was straight out of any drunken frat boy's phone.

I mean, pornstars say 90% of pornstars are selling content on Snapchat.

https://www.wired.co.uk/article/premium-snapchat-adult-model...

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#159

Post by jwyatt1995 »

3eed wrote: post #144
jwyatt1995 wrote: post #111

How would one go about understanding the content of this write-up? Even after the first paragraph it begins to go completely over my head.

You need some assembly background, then OWASP's guide[1], has all basics. [1]: https://github.com/OWASP/owasp-mstg

Thank you very much.

Re: Reverse Engineering Snapchat: Obfuscation Techniques

#160

Post by MauranKilom »

imtringued wrote: post #128
underdeserver wrote: post #94

Earlier quoted context omitted.

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.

Most obfuscation techniques are lossy. You lose information such as project structure, names of files, data types, variable names and so on. Decompilation and deobfuscation might give you a shadow of the original source code but the benefits are overstated because the advantages over working directly with assembly code aren't that big. Most of the time is spent finding the dozen relevant functions out of 10000. If yo…

> You lose information such as project structure, names of files, data types, variable names and so on.

You lose half of those by not having debugging symbols and the other half by stripping the binary. This is all lost during compilation already, not due to explicit obfuscation. If you've ever worked with a compiler that is mediocre at generating debug symbols, you'll know it's the compiler doing extra work that provides all these, not obfuscation that removes them.

Post reply on HN