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

Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

hot3eed.github.io

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#41

Post by zimmerfrei »

Both iOS and recent Androids have by now a form of app attestation: the server can tell if the caller is the legitimate app or not (with good enough confidence - as everything, it's not unbreakable).

Doesn't that make obfuscation kind of pointless? Even if your knock-off app knows everything about the API of the original service, it won't be able to use it because it is not the genuine app or maybe it is but it is not running in a real iOS/Android device.

Or maybe this is only meant to include non-Android certified phones (= China)?

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#42

Post by sanqui »

ATsch wrote: post #34
lliamander wrote: post #31

Earlier quoted context omitted.

Why not just send copy written code as part of the payload?

Especially trademark violations are very effective for this. For example the original GameBoy used it as DRM. The cartridge had to contain a Nintendo(R) logo which was displayed on boot to work, a legal deterrent for publishing unlicensed games that still works to this day.

Except that the use of copyrighted and trademarked data for means of enabling interoperability has been ruled fair use in the Sega v. Accolade[1] case. So I believe Nintendo's use of the logo in this way is not much more than snake oil.

[1] https://en.wikipedia.org/wiki/Sega_v._Accolade

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#43

Post by zemnmez »

zimmerfrei wrote: post #41

Both iOS and recent Androids have by now a form of app attestation: the server can tell if the caller is the legitimate app or not (with good enough confidence - as everything, it's not unbreakable). Doesn't that make obfuscation kind of pointless? Even if your knock-off app knows everything about the API of the original service, it won't be able to use it because it is not the genuine app or maybe it is but it is no…

seems like something having a rooted os would fix pretty quickly

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#44

Post by piva00 »

Roritharr wrote: post #33
spideymans wrote: post #17

Earlier quoted context omitted.

Interesting time that was. I don't believe that any of these internet giants would ship a feature that is effectively a hack, in this day and age. HTC and Palm also engaged in the back-and-forth, when Palm attempted to get their OS to sync with iTunes. https://www.wired.com/2009/10/palm-pre-itunes/

You will be scared to find out that a lot of Fintech has webscraping as an accepted part of their stack...

Yup, not only as accepted part of their stack but also offered as a product that sometimes users need to input their bank details in 3rd party applications from some fintechs.

If you look under the hood there is a lot of grey areas being exploited by fintech, all around...

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#45

Post by 3eed »

hackernewsn00b wrote: post #10

Hey OP, since you're here: I find this pretty hard to follow. Would you be open to writing a longform version of this aimed at the tutorial level? Reading between the lines, I would guess you're trying to demonstrate that you really know what you're doing. Maybe as a proof of concept for possible employment opportunities. If so, that's great! Good luck. But if I were interested in reverse engineering some other app,…

It's true, these posts are for intermediate and upper reverse engineers. It would really take a book to explain it from the ground up it like someone here mentioned. I suggest getting some background in assembly, then reading the OWASP guide (link in my previous HN post), and persistence.

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#46

Post by 3eed »

zimmerfrei wrote: post #41

Both iOS and recent Androids have by now a form of app attestation: the server can tell if the caller is the legitimate app or not (with good enough confidence - as everything, it's not unbreakable). Doesn't that make obfuscation kind of pointless? Even if your knock-off app knows everything about the API of the original service, it won't be able to use it because it is not the genuine app or maybe it is but it is no…

DeviceCheck on iOS support iOS 11 and up. Which would cut off 7% of users[1], a bit extreme. But when the time comes when you don't have to cut off anyone, it'll be very interesting to see what'll happen on iOS. Someone will bypass it? Death of reverse engineering? Who knows. On Android, an HN user mentioned in the previous post that it's a solved problem[2].

[1]: https://developer.apple.com/support/app-store/ [2]: https://magiskmanager.com/

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#47

Post by 3eed »

saagarjha wrote: post #39
underdeserver wrote: post #35

For fuckup_debugging, can't you use hardware breakpoints instead? Also, why not patch the binary? I think iteratively patching out protections (in a repeatable, versioned way) would be my approach. It is then applicable to other binaries as well.

Hardware breakpoints are a little complicated on iOS. And patching the binary would of course only work if no other code verified the validity of the page you touched.

Are hardware breakpoints even possible on iOS? And correct, you can't patch the binary because there many anti-tampering measures, you could probably bypass those, but that's going a different route.

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#48

Post by whs »

zimmerfrei wrote: post #41

Both iOS and recent Androids have by now a form of app attestation: the server can tell if the caller is the legitimate app or not (with good enough confidence - as everything, it's not unbreakable). Doesn't that make obfuscation kind of pointless? Even if your knock-off app knows everything about the API of the original service, it won't be able to use it because it is not the genuine app or maybe it is but it is no…

I tried adding safetynet attestation on launch for all Android clients and ran into rate limit pretty fast. (iirc it's about 10k/hr)

Devicecheck have no such problem though, but it doesn't really feel designed for the use case - you need to implement an anti replay system yourself.

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#49

Post by 3eed »

saagarjha wrote: post #16

I’m surprised that Snapchat doesn’t check for the mere presence of a debugger and instead tries to look for breakpoints. Or perhaps you’ve already found and patched those checks out?

It does check for a debugger. But that would be through sysctl, or the csops sys call, which would be trivial to patch and a single point of failure.

Re: Reverse Engineering Snapchat (Part II): Debofuscating the Undeobfuscatable

#50

Post by sneak »

djhaskin987 wrote: post #23
xmprt wrote: post #22

Earlier quoted context omitted.

Is there legal precedent for copyrighting APIs?

That's actually the central issue behind the Supreme Court case battle between Oracle and Google right now: whether or not you can copyright apis

This thread is about web or network service APIs, which, thanks to the CFAA, have broad leeway to dictate what client software you are legally allowed to use to speak to it. It's a grey area and some real bullshit, IMO.

You are talking about programmatic APIs, which is a horse of a different color: a copyright issue, which is still being figured out.

It's annoying that we overload the same term for both things.

Post reply on HN