top | item 34293984

(no title)

orik | 3 years ago

“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.

discuss

sweetjuly|3 years ago

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|3 years ago

>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|3 years ago

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|3 years ago

A handful of people still have theirs.

mouse_|3 years ago

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|3 years ago

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.

etaioinshrdlu|3 years ago

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|3 years ago

Can’t bring in new executable code.