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.
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 MSN to emulate that behavior, it would need to have the AIM client's executable code inside itself, which would be an easy win in a copyright lawsuit.
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, I don't think I could understand what you've done well enough to use these techniques on that app. Except maybe the breakpointing within `fuck_debug`, that was pretty slick and easy to follow.
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.
Obviously not the OP but I think that a longform version of this would be an entire book/college level course. I wish I could learn how to reverse state of the art obfuscation in a single, long post but that's just not how it works.
I found it fairly reasonable, although you'd have to have a general idea of the subject beforehand. I read it as a being aimed at reverse engineers who are looking for some general techniques to bypass common anti-debugging/obfuscation features rather than "how to reverse engineer apps 101".
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)?
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].
As someone who wrote similar obfuscators (manually) back in 2003-2006 to protect a few indie games distributed on PocketPC (ARM7/WinCE) I found it quite conforting to see that the techniques are still similar.
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.
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.
I came across Arybo while working on the binary but I can't remember why I didn't use it, this is vague memory now. Anyway it does the job in one go, I added an edit.
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?
I'm not sure what you're asking. Obfsucating means making the code unreadable/unintelligible. Think minimfy js on steroids. Debofuscating just means undoing the obfuscation.
Maybe you don't understand Latin root words as prefixes and suffixes, in which case I highly recommend doing a bit of research into it. It really makes the English language more understandable when you can parse words based on their roots rather than on rote memorization.
wayne|5 years ago
https://nplusonemag.com/issue-19/essays/chat-wars/
worewood|5 years ago
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 MSN to emulate that behavior, it would need to have the AIM client's executable code inside itself, which would be an easy win in a copyright lawsuit.
spideymans|5 years ago
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/
saltedonion|5 years ago
foobar_|5 years ago
hackernewsn00b|5 years ago
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, I don't think I could understand what you've done well enough to use these techniques on that app. Except maybe the breakpointing within `fuck_debug`, that was pretty slick and easy to follow.
yasoob|5 years ago
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. :)
3eed|5 years ago
drudu|5 years ago
saagarjha|5 years ago
jonas21|5 years ago
https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.ht...
masteruvpuppetz|5 years ago
zimmerfrei|5 years ago
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)?
3eed|5 years ago
[1]: https://developer.apple.com/support/app-store/ [2]: https://magiskmanager.com/
zemnmez|5 years ago
whs|5 years ago
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.
stephc_int13|5 years ago
I wonder about something, how long did it take?
underdeserver|5 years ago
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.
saagarjha|5 years ago
bluesign|5 years ago
dang|5 years ago
sintax|5 years ago
[1] https://github.com/quarkslab/arybo
3eed|5 years ago
coolspot|5 years ago
bluesign|5 years ago
So usually there is nothing to patch.
saagarjha|5 years ago
3eed|5 years ago
Method5440|5 years ago
Prediction: Just me.
By the way, love both articles. Thanks for taking the time to share.
raverbashing|5 years ago
sarabande|5 years ago
drfuchs|5 years ago
[deleted]
gruez|5 years ago
saagarjha|5 years ago
mbrevda1|5 years ago
Google234|5 years ago
craftinator|5 years ago