Open steven-michaud opened 1 year ago
I've dug further into this, and as best I can tell the "Halt in iBoot Stage1" and "Halt in iBoot Stage2" settings are no-ops. Apple has left them unimplemented -- unlike "Boot into DFU", which does work properly.
It's a bit hard to be sure about this, because all three settings are implemented in the Virtualization framework's com.apple.Virtualization.VirtualMachine
XPC service, which has its symbols stripped. But looking (in a disassembler) at all matches for "forceDFU", "stopInIBootStage1" and "stopInIBootStage2" in the Virtualization framework itself, only "forceDFU" is found in the names of "substantive" methods -- ones that do more than just read or write the settings.
Another interesting tidbit:
If you set a VirtualApple VM to "Boot into DFU", you get meaningful output from irecovery -q
in the host. So I could use irecovery
to interact with the VM in this state. I don't know if I'll be able to get the VM to boot fully, but I'll be looking into it.
To be honest I implemented this a while back and never looked at it again, so it's entirely possible that it doesn't do anything anymore. I don't really do iBoot stuff but I did find that the debugger can kinda sorta interact with it if you're looking to emulate this functionality yourself.
Or at least I don't understand how they're supposed to work.
I tried setting either or both of them on macOS 14 Beta 2 and macOS 13.4 VMs, but those settings seemed to make no difference. Both VMs booted normally. I'm doing this on a macOS 14 Beta 2 host, with XCode 15 Beta 2 installed (plus its commandline tools).
I'm trying to get them to halt so I can use
irecovery
to feed them my own, patchedLLB.vma2.RELEASE.img4
,iBSS.vma2.RELEASE.img4
and/oriBoot.vma2.RELEASE.img4
files (generated from files in Apple's IPSWs), along the lines of this document.