3eed

This is incredibly helpful, kudos to everyone who worked on this.

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.

That guy gets it

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.

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.

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/

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.

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.

Why not ;)

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

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.

You need some assembly background, then OWASP's guide[1], has all basics.

[1]: https://github.com/OWASP/owasp-mstg

"Evan Spiegel Hates this Trick!"

Couldn't agree more.

Hmm, I wonder how deep one should look. Why don't you shoot me an email at hot3eed at gmail? I'd appreciate it a lot!

Sure! I'll consider doing this before the next post

Definitely not true.

Not all of it, really ;)

All these are great programs, but none of them can understand that level of obfuscation so far. As stated in the post, both Ghidra and IDA interpret the very first block in any of the obfuscated functions, which ends with an indirect branch, as a complete function in and of its own. Because this is the usual case, indirect branches AKA tail calls terminate a function to start another, all with the same stack frame.

EDIT: also keep in mind the CFG isn't flattened here.

I'm gonna write about this in pt. 2. Basically you can use symbolic execution to recover the CFG[1] (using something like miasm), you can eliminate dead code, restore dynamic lib calls with an emulation, and whatever else. But the point is that it would take an incredible amount of work and co-operation between tools, and then you wouldn't have even begun understanding anything about the binary, which is a whole another story. Now there's a kind of a little shortcut to all of this, which when combined with a couple of tools, you'd be able to make sense of things in this binary, which I'm gonna reveal in my next post.

[1]: https://blog.quarkslab.com/deobfuscation-recovering-an-ollvm...

That’s interesting to know

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.