Hacker News Reader

Comment by codys | Hacker News Reader

I feel like we're missing some of the details/steps here, perhaps because the folks at corellium have a bunch of existing experience with apple SoCs and as a result had non-public knowledge about the platform.

For example: determining that interrupts were being routed to FIQ. It's unclear how one would have figured that was occurring. Or that there was an special AIC (apple interrupt controller) that needed talking to, and how to talk to it. It feels like there's a lot of "reverse engineer some Apple kernel bits" that's potentially being elided over.

Edit: or alternately, some debug interface that isn't being mentioned (swd/jtag/itm).

View on HN

Presumably, they used the macOS/iOS kernel source code as a reference? I'm no expert on kernels, but a quick grep reveals plenty of references to "AIC" and "FIQ", in osfmk/arm64 for example.

https://github.com/apple/darwin-xnu

They already ported Linux to Apple A10 in iPhone before, the M1 shares a lot with those chips.

https://projectsandcastle.org/history

Corellium was founded by some veterans from the iOS jailbreak community: https://www.reddit.com/r/jailbreak/comments/8rmpqt/question_...

Yes, this is well known, what isn't and what OP is describing is how they arrived to their understanding of the solution.

I think there's probably some sort of understanding between them and Apple which allows them to do their thing as long as they don't publish too much publicly.

EDIT: In fact, it might not even be that. It doesn't exactly make commercial sense for a company whose entire existence is based on their extensive IP knowledge of apple hardware to post every detail publicly for others to copy. They are a for profit organization after all.

> "I think there's probably some sort of understanding between them and Apple which allows them to do their thing as long as they don't publish too much publicly."

You know the macOS kernel for M1 hardware is open source, right? This stuff isn't exactly a proprietary secret.

Yes, the core of the kernel is, the majority of drivers are not. XNU is a hybrid kernel, not monolithic.

> I think there's probably some sort of understanding between them and Apple which allows them to do their thing

Apple are literally suing Corellium.

> To actually connect the USB port inside the M1 to the USB type-C connectors on the back of the Mac Mini, we had to interact with a chip on I2C (which means GPIO and I2C drivers) which has customized firmware. We've seen the protocol for these while building our virtualized models; nothing is a big surprise if you have a bird's eye view of the system.

You're not kidding. This is more of a flex than an explanation.

I think this was one of the goals of Asahi also - to document the process of porting Linux to the new arch.

I had the same thought. How does one even know where to start when reverse engineering?

You start with a problem, then you think what system might be interacting with that particular subsystem. Then you start to poke around in there trying to intercept, dump code, add debugging and so on.

But are you poking around macOS? If it’s totally unique hardware unlike anything else, what would you even poke around?

Side channels like timing during different tests is one possibility. You can also reverse the operating system to understand more about how it may be handling interrupts or unique hardware. Then there's also dumping any onboard firmware memory to learn about the boot process. With some creativity, there's loads of ways to infer functionality of the processor/system enough to develop over it.

Reply on news.ycombinator.com