Comment by daeken | Hacker News Reader

Comment by daeken | Hacker News Reader

This is really awesome for kernel exploitation and such, but for more practical application testing, I've been working on an alternative solution for the last two months. Apple's iOS Simulator ships x86_64 binaries for all the iOS frameworks, so you need to build your application specifically for the Simulator in order for it to run; obviously a no-go for most cases, e.g. apps from the store. So I wrote a translation layer that does ARM64 emulation of the app, while translating calls from ARM->Native libraries and vice versa.

It currently supports most non-Swift apps and a small number of Swift apps; once I have proper Swift support, pretty much everything should Just Work (TM). Planning on releasing by end of month (hopefully) for $100/year, aimed primarily at bug bounty hunters and pentesters, though there's nothing stopping you from just using it to play an iOS-specific game or somesuch. If you're curious, you can see Xcode debugging an ARM64 app from the App Store here -- all of their inspection tools work out of the box! https://twitter.com/daeken/status/1242684576738271233

Cool! Is this using something like libffi to translate calls at the application↔system framework boundary?

I wish! Haha. No, it's a custom set of trampoline generators that handle the transition. I have one for Objective-C (where I can use the internal reflection tools to get function signatures; fails for variadic functions, so I wrote my own implementations of those, which live on the ARM side), one for C (I generated a function signature database for every header file on the system; otherwise, it shares the trampoline generator with Obj-C), and one for Swift (this is my WIP right now, where I'm generating a similar function database. By far the hardest part so far, if only because I'm so much less familiar with Swift).

There's also a native ARM build of libc++ and libc++abi, so that it doesn't have to cross the ARM<->Native boundary for C++ stuff, and a bunch of custom hooks on both sides.

What are you using for the emulation? QEMU?

I was using Unicorn (based on QEMU), but the license isn't conducive to a closed-source project. So I built my own emulator, which is released under a more friendly license: https://github.com/daeken/libmoonage

I was wondering how the code was that small, and then I saw the LLVM include ;) How are you planning on competing with people running binaries directly on their iOS devices?

For folks with existing setups they're happy with, my tool doesn't provide much value (aside from more easily working with existing dev tools in Xcode). But the ability to test real-world apps on any iOS version (mostly) and any device is pretty damn nice. Definitely a better testing experience than dealing with jailbreaks, wiping devices all the time, etc.

Wait, I don't understand what your tool does, but it sounds really interesting. So what will this $100/year service provide specifically?

The tool takes in an ARM64 iOS app and spits out one that will run in the Simulator. It basically just makes testing iOS apps as easy as testing Android apps.

How does one get the binary app to begin with?

Unfortunately, that's a tough one to answer. Since it needs to be decrypted, the only routes right now are: 1) download it on a device and then decrypt it, 2) download it from extremely sketchy, illegal sites, or 3) for bug bounty cases, hope they give you an IPA that you can just use. Given the primary use case is making life better for bug bounty hunters, #1 and #3 will cover the vast majority of uses initially, but I really think a better solution is needed down the road.

Reply on news.ycombinator.com