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

31–40 of 63 posts

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

#31

Post by lliamander »

worewood wrote: post #29
wayne wrote: post #13

This level of API obfuscation reminds me of forever ago when MSN Messenger figured out AOL's AIM API, so MSN Messenger could send AIM messages, which annoyed AOL. AOL would make API changes to break MSN, but MSN would update the client and stay ahead. Eventually to make the API uncloneable, AOL changed their payload to exploit a buffer overrun in their own AIM clients that wouldn't be in the MSN clients. https://nplu…

I think the most important, and this article left it out, is why exactly this makes the API uncloneable - why couldn't MSN just emulate the buffer overflow behavior like it was doing with everything so far? As the article says, the client also responded with some code. What I think was happening: the client was responding with portions of its own executable memory, which could be checked by AOL servers. That way for…

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

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

#32

Post by yasoob »

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

If reading even the first part of this series doesn't help, read this beginner tutorial I recently wrote: https://yasoob.me/posts/reverse-engineering-android-apps-apk... It starts you off with the basics and uses smali.

After that you can explore this tutorial on frida: https://securitygrind.com/bypassing-android-ssl-pinning-with... These two techniques will give you some more basic knowledge of how app reversing is done. :)

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

#33

Post by Roritharr »

spideymans wrote: post #17
wayne wrote: post #13

This level of API obfuscation reminds me of forever ago when MSN Messenger figured out AOL's AIM API, so MSN Messenger could send AIM messages, which annoyed AOL. AOL would make API changes to break MSN, but MSN would update the client and stay ahead. Eventually to make the API uncloneable, AOL changed their payload to exploit a buffer overrun in their own AIM clients that wouldn't be in the MSN clients. https://nplu…

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...

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

#34

Post by ATsch »

lliamander wrote: post #31
worewood wrote: post #29

Earlier quoted context omitted.

I think the most important, and this article left it out, is why exactly this makes the API uncloneable - why couldn't MSN just emulate the buffer overflow behavior like it was doing with everything so far? As the article says, the client also responded with some code. What I think was happening: the client was responding with portions of its own executable memory, which could be checked by AOL servers. That way for…

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.

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

#35

Post by underdeserver »

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.

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

#37

Post by bluesign »

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.

Not the OP, but I can answer I guess. Hardware breakpoints are very limited (number of breakpoints you can put). Usually when you are debugging a decent target, number of breakpoints you use easily reach 50-60.

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

#38

Post by underdeserver »

bluesign wrote: post #37
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.

Not the OP, but I can answer I guess. Hardware breakpoints are very limited (number of breakpoints you can put). Usually when you are debugging a decent target, number of breakpoints you use easily reach 50-60.

No doubt, but it's better than pausing every time. I guess with scripting it isn't really different.

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

#39

Post by saagarjha »

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.

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

#40

Post by taneq »

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.

The TrackIR API does something similar to lock out unauthorised third party client applications.
Post reply on HN