Halt in iBoot Stage 1 and in iBoot Stage 2 don't work

[steven-michaud]

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, patched LLB.vma2.RELEASE.img4, iBSS.vma2.RELEASE.img4 and/or iBoot.vma2.RELEASE.img4 files (generated from files in Apple's IPSWs), along the lines of this document.

[steven-michaud]

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.

[steven-michaud]

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.

[saagarjha]

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.