[orik]

“There’s also no way to replace the iOS kernel and drivers with the macOS equivalents: macOS only supports M1 devices, and no iOS devices past the iPhone X have known bootloader exploits.”

I believe the Apple Silicon dev kit ran on a A series cpu, might be the entry point to try to investigate, especially if a boatloader exploit is found.

[sweetjuly]

I think one of the big unstated challenges (but implied by the reference to needing a bootloader exploit) is that KTRR/CTRR [1] prevents new executable kernel code from being introduced after the device boots, even if the kernel is fully compromised. This is a hardware feature and is not one that has (publicly) been bypassed in recent memory. In other words, without a bootloader exploit it is not possible to map the macOS kernel on an iOS device

[1] https://blog.siguza.net/KTRR/

[spike021]

>I believe the Apple Silicon dev kit ran on a A series cpu

Are any of these even still in the wild? I thought they were basically loaners until the M1 Mini's (and other computers) were unveiled/released.

[johndoe0815]

At least one of the dev kits is still out there - a video was posted on yt last week: https://www.youtube.com/watch?v=kpzW63pQdHI

[saagarjha]

A handful of people still have theirs.

[mouse_]

You're right. M1 is a SoC, not an architecture. macOS used to only support Intel chips but that never stopped the hackintosh crowd from getting it working on certain AMD chips.

[uni_rule]

Imagine just how much low level fuckery it would take to get MacOS booted in a Snapdragon device of any sort. It would support absolutely nothing there by default.

[dmitrygr]

https://opensource.apple.com/source/xnu/xnu-4903.221.2/pexpe...

The kernel can boot on the rPI

[etaioinshrdlu]

On an iOS device without bootloader exploit - any reason we can't do somthing similar to a kexec()? That is, replace a running kernel with a new one.

[saagarjha]

Can’t bring in new executable code.