MacBookAir8,1 boots with restrictevents enabled but…

[zkennedy137]

MacOS still sees the native board-id when spoofing with opencore smbios. It shows the MacBookPro16,4 for model in ioreg. However the board-Id in ioreg is still the real one of the MacBookAir8,1. That has to be the only thing holding the installer back. I did recompile RestrictEvents.kext with a couple fixes for warnings in Xcode. Now the kext loads and the usb installer goes back to its normal problem of not getting past the language screen. However I can boot into Sonoma and launch the installer. It just sees the board-id then stops at the normal incompatibility screen. However the RestrictEvents.kext is loaded as well as Lilu and others.

I tried to use an ssdt to hotpatch the board-id but no luck.

The thought process for me now is a way to either spoof the board-id with SMCSpoof.kext or something of that nature. I haven’t tried it yet. When I get home I will make an attempt.

I do think the reason RestrictEvents.kext prevents apfs from doing its job is because of the patches being done at the incorrect offsets for Tahoe 26.7 or something to do with the firmware of the MacBookAir8,1. If at all possible could one of you @Medelcartelinc @albert-mueller find or tell me how to find the offsets it is supposed to be patching. Also “ osbundlelibraries” has new additions in the Tahoe 26.7 version of the kext vs the one in Sonoma and I am going to assume Sequioa as well. That may need to be hooked in RestrictEvents.kext somehow for it to load properly.

updated RestrictEvents.zip

This is the zip of the new kext version I compiled on Tahoe 26.7 and fixed the warnings in.

So either we need a way to patch the installer (running it on desktop through Sonoma, internal partition installer of Tahoe installer, or usb installer) or a way to help RestrictEvents.kext to be able to properly execute the patches. Another way could be to patch “AppleACPIPlatformExpert” class/kext and patch the board-id manually at least for install.

[zkennedy137]

ok so ive narrowed it down to the "-revasset" part of RestrictEvents.kext. I am assuming it is because the installer is calling to firmware for board-id and RestrictEvents.kext is trying to inject the board-id or something of that nature. The second half of my guess is that it is causing a sort of idk "mini-kernel panic" or something. Basically it is causing board-id to not get defined I think. Something to that respect. If we could find a way to patch the installer to accept the MacBookAir8,1 board-id or spoof the existing one without RestrictEvents.kext

[albert-mueller]

Yes, I used to use the registry bypass, but it’s quite fragile at best, and means after 3 yrs no security updates, unless you write GPO policies or re-imaging. It’s better to use FlexTPM to fix this security gap and receive all updates.
@zkennedy137

[albert-mueller]

And Rufus has the same caveat too. It works until updates stop flowing and the computer becomes vulnerable to known vulnerabilities.
@zkennedy137

[zkennedy137]

Oh ok see by the time windows 11 is pulled I’ll just either use the newer windows or go to CachyOS myself haha. My server already runs on Linux so it wouldn’t be that big a jump. Anyways I made have made some headway on the T2 and board-Id issue etc. As far as the compatibility UI Gate. I haven’t tested any of it yet but I have a theory. I’ll share it later when I’m home from work and get to test it.

Is there any kind of discord or teamspeak 3 or ventrillo? Something we can communicate with each other more directly. If we talk directly and use ai together then we might all be able to make some real progress faster.

@albert-mueller @Medelcartelinc

[albert-mueller]

Oh ok see by the time windows 11 is pulled I’ll just either use the newer windows or go to CachyOS myself haha. My server already runs on Linux so it wouldn’t be that big a jump. Anyways I made have made some headway on the T2 and board-Id issue etc. As far as the compatibility UI Gate. I haven’t tested any of it yet but I have a theory. I’ll share it later when I’m home from work and get to test it.

Is there any kind of discord or teamspeak 3 or ventrillo? Something we can communicate with each other more directly. If we talk directly and use ai together then we might all be able to make some real progress faster.

@albert-mueller @Medelcartelinc

Eastern European Time, it's 21:37. I think you may be in a different time zone?

[zkennedy137]

I am on Eastern Standard Time it is currently 4:38 or on 24 hour clock it is 16:38. Also I had a sort of possible breakthrough on the T2 Compatibility UI Gate. I haven't tested it just yet. I will share in just a bit when I do test it and see if it works. @albert-mueller @Medelcartelinc

[zkennedy137]

Ok so some good progress, I noticed that even using the spoof option on advanced from the T2 OCLP Patcher and booting the board-id and model didn't change even when booted into Sonoma(Desktop) or Tahoe(Installer) through opencore. So I tried manually editing the config.plist to spoof MacBookPro16,4 and spoof the appropriate board-id. That MacBookPro is supported by Tahoe by default. So I tried that and the model changed but the board-id did not. So I over the course of talking with claude and coming up with my own hypothesis found something. In the opencore bootlog the board-id is being spoofed but as soon as user land boots the real MacBookAir8,1 board-id shows up in the terminal. So I had claude add to the SpoofVMM.kext the ability to change the board-id before userland boots. This did work.... to a point but the original board-id was still present as well as the spoofed one. This was caused by the secure boot model still coming through as my real one J140kAP = MacBookAir8,1 which is found in the /efi/platform node model "MacBookAir8,1". So this is a step closer to the problem. So I told claude to change that board-id as well.This achieved getting the board-id to be that of the MacBookPro16,4. However the Compatibility UI Gate still fires and I can't get past it.

So now I am trying to change the model in the /efi/platform node to MacBookPro16,4 now and I'll get back with results. I am assuming because the board-id spoof doesn't work properly in opencore on the MacBookAir8,1 then maybe the secure boot options don't either. Causing the information to passthrough rather than be disabled. I am going to test further and see what I find.

This is still huge progress im my opinion. :)

@albert-mueller @Medelcartelinc

P.S. Ill update the SpoofVMM repo as soon as I confirm this will get us past the Compatibility UI Gate

[zkennedy137]

ok so turns out there was a mixup with the version designed to delete bridge-model. I inadvertently told it to also spoon the model which was already spoofed and seems to have caused a kernel panic. I resolved that by going back before that version and telling it to just add the board-model delete and spoof functionality. Attached is a zip with the new experimental but able to boot reliably version.

SpoofVMM Boot Arguments.txt
SpoofVMM-v4.1.zip

as well as a list of boot arguments.

@albert-mueller @Medelcartelinc

I GOT IT TO WORK IM PAST THE COMPATIBILITY UI GATE!!!!!!!

The boot Arguments I used are as follows:
the normal ones from the Opencore legacy Patcher T2 Credits @albert-mueller
these ones specifically for SpoofVMM.kext:
-spoofvmmdbg -spoofvmmbeta -spoofvmmnodelete

this zip is the one with the Kext that achieved the bypass and the installer does start. The question is now will it boot after install.
SpoofVMM-v4.4.zip

[zkennedy137]

[zkennedy137]

And another problem yet still further than before.

[zkennedy137]

I’m off to bed but still this is an accomplishment I think at least.

[zkennedy137]

Potential workaround for this.

1. Formatting the disk before installing. I just tried to upgrade my install on the internal ssd I only did this because I wanted to see if it would try to do it or error when I clicked install.
2. installing to an external SSD which I will try tomorrow. I will try it after restoring Sonoma and booting it up. Then install to the external ssd.
3. Not having an os on the internal at all.

either way now we can get down to working :)

[jakecaley]

@zkennedy137 did you delete restrictevents.kext and then put SpoofVMM.kext in there and put the boot-args, i want to try this on my macbookpro16,3 on a fresh apfs partition.

[zkennedy137]

Well I will caution you that it may change the outcome for the MacBookPro16,3. I can’t confirm this or deny this just saying your results may vary. Also yes RestrictEvents.kext is responsible for the apfs failure and the reason for being stuck at the language screen. Also I used a normal Tahoe 26.7 usb installer because booting from internal did nothing but bypass the glitch caused by RestrictEvents.kext.

@jakecaley

[zkennedy137]

Also again it failed when running stage 2 but I can only test on a MacBookAir8,1 as that is the only T2 I have at the moment. I would love if you could test it just make sure you don’t force it to install the update at stage 2. The main reason is I do not know what the hang is and it could be BridgeOS related and any attempt that is half successful or successful at updating it could brick the T2. I was told by Claude that I should check the log in stage 2 from terminal. If terminal isn’t available at stage 2 of update then use the installer and boot in and check it using this command.

grep -iE "prepar|personaliz|image4|apticket|bridgeos|sep|authenticat|BIError|nonce|not eligible|error" /var/log/install.log | tail -100”

That will tell us what the true error is.
@jakecaley

[zkennedy137]

Also this should be noted this is the full information about the Stage 2 hang from Claude:

That screen is the second-stage Update Assistant failing at the "preparing" step — you got all the way through the gate and into the actual update, and it choked right where we predicted the T2 boundary would bite. "An error occurred preparing the software update" is the generic message; the real reason is in the logs. Before anything else, a couple of things:

What "preparing" actually does, and why it likely failed here. After the ETA appears, the assistant stops being about compatibility and starts doing T2-bound work:

• Personalizing the boot objects — it asks the Secure Enclave to sign/personalize the new kernelcache + boot chain (the Image4 / APTicket step, the "Needs Authenticator" territory). Spoofing can't produce a valid SEP signature because we don't hold the T2's keys.
• A bridgeOS (T2 firmware) update — a macOS upgrade on a T2 Mac usually carries a matching T2 firmware payload. Your spoofed identity says MacBookPro16,4, but the actual T2 is the Air's. A mismatch there fails exactly at "preparing."

Either of those is the Secure-Enclave wall the findings doc flagged as the remaining open item — and it showing up here, after the gate, is consistent with everything we mapped.

Safety first: a prepare step that errored and rolled back has not flashed anything — that's the safe outcome. Don't repeatedly hammer "OK → retry," and don't try to force the bridgeOS update through, because that's the step that could actually brick the T2 if it ever half-applied a wrong-model firmware. Clicking OK should roll you back to your intact Sonoma.

Get the exact reason. Once it rolls back and you can boot again (Sonoma, or the OpenCore installer USB → Utilities → Terminal), read the install log from this attempt:

grep -iE "prepar|personaliz|image4|apticket|bridgeos|sep|authenticat|BIError|nonce|not eligible|error" /var/log/install.log | tail -100

and, if logd is alive there:

log show --last 1h --predicate 'process == "softwareupdated" OR process CONTAINS "SoftwareUpdate" OR process == "OSISetup"' --info --debug 2>/dev/null | grep -iE "prepar|personaliz|image4|bridge|error"

Paste me whatever those show — the specific line (personalization vs. bridgeOS

[sonimcrinebru-art]

@zkennedy137 Do you know how i can test this for macbookpro15,1? Is there something I need to put inside config.plist other than the boot args and kexts?

[sonimcrinebru-art]

have you tried this yet my? any luck?

I've gotten stuck on a new hang point currently. This is with -radvesa and both -radvesa and -igfxvesa. It gets stuck on ""AppleKeyStore":pid77,13297, operation failed" Do you have a discord i can send to you so i can send you the video?

@zkennedy137

[zkennedy137]

Here ya go

[zkennedy137]

Interesting I mean I can only test it on the one I have so this is new. But maybe we can figure it out.

[sonimcrinebru-art]

Here ya go

Gave u a friend request. Please accept

[jakecaley]

@zkennedy137 you still installing it to a external ssd?

[albert-mueller]

I haven't tested on my Mac mini 2018 yet, I expect the results to be identical to the MacBookAir8,x since it has only iGPU. Would you like to test it on my Mac mini 2018, @zkennedy137 ?

[zkennedy137]

Yeah you should try it. It should work fine. That would confirm it is stable across a couple platforms at least.

Also what do you think of the approach?

Also I know of one issue I will be testing when I get home. It breaks WiFi because the board-id spoof loads the incorrect driver info. So I created a variant of the kext based off the one that allows the installer and it spoofs board-I’d to everything except the network iokit that should fix WiFi. I’ll test when I get home.

[albert-mueller]

Yeah you should try it. It should work fine. That would confirm it is stable across a couple platforms at least.

Also what do you think of the approach?

Also I know of one issue I will be testing when I get home. It breaks WiFi because the board-id spoof loads the incorrect driver info. So I created a variant of the kext based off the one that allows the installer and it spoofs board-I’d to everything except the network iokit that should fix WiFi. I’ll test when I get home.

Yes, it's a good idea to test it across different T2 models (I have only Mac mini 2018 and MacBook Pro 2020 4 thunderbolt 3 ports).

[zkennedy137]

Ok so let me know what happens. It shouldn’t be affected as it a static smbios and static bridge-model. So as long as the variables on IODeviceTree stay the same the patch should work. However anything is possible.

I say anything is possible because the board-If changes between OpenCore and early boot which gives macOS the real one. It’s crazy but it must be an early boot call from the T2.

[jakecaley]

@zkennedy137 @albert-mueller im going to try this I have the proper boot args set but im compiling the kext ill tell u the results. macbookpro16,3 also

[jakecaley]

@zkennedy137 i just got hit with the same old Mac OS isn’t compatible with this Mac idk if I did something wrong but is there any commands to check and I noticed that when making the debug version of the kext it provides lilu and one of the other kexts should I be using those

[jakecaley]

@zkennedy137

[jakecaley]

current boot args are keepsyms=1 debug=0x100 -ibtcompatbeta -revbeta revpatch=sbvmm ipc_control_port_options=0 -v nvme_shutdown_timestamp=0 igfxgl=1 igfxmetal=1 -disable_sidecar_mac -disable_media_analysis -amfipassbeta igfxonln=1 igfxfw=2 forceRenderStandby=0 agdpmod=vit9696 rddelay=10 -disable_ext_panics -no_compat_check agdpmod=pikera AMFIPass=0x1 amfi=0x80 -oas_skip_attestation cryptex=0 -spoofvmmdbg -liludbgall msgbuf=1048576 spoofvmm-bridge=J223AP -spoofvmmnodelete this is the old kext I will try the pre compiled one now

[jakecaley]

[zkennedy137]

try using this next rather than recompiling.
SpoofVMM.kext.zip
I think it's a source code error from the build it may have been the wrong kext. It is version 4.4 I think. either way this is the kext from the EFI that worked so try it.

[jakecaley]

@zkennedy137 i was looking into it I may have the wrong boot args because i was looking into it and it was reporting as 2 different things I will get back when I try it again with fixed boot args

[jakecaley]

@zkennedy137 you hate to see it let me check terminal

[jakecaley]

@zkennedy137 where did my bridge go actually that may have been what I was injecting.

[jakecaley]

@zkennedy137 I just realized. why is the bridge id identical to a MacBookpro16,3 but the board id was spoofing a 16,4 that doesn't work it was like that in the previous pictures. nevermind I looked it up the bridge is just like the model of the t2 chip

[zkennedy137]

So two things I figured out. The board-id is meaningless to the spoof for the incompatibility issue. The model and bridge-model however need to be spoofed. I used opencore to spoof the model, and the next to spoof the bridge-model to the proper one. So use this boot argument -spoofvmmnodelete along with the opencore spoof model of MacBookPro16,4. Your platform settings of opencore should look like this.

[zkennedy137]

I will be posting an updated kext here in a few minutes

[jakecaley]

@zkennedy137

is this ok also these are my boot args that I'm using right now keepsyms=1 debug=0x100 -ibtcompatbeta -revbeta revpatch=sbvmm ipc_control_port_options=0 -v nvme_shutdown_timestamp=0 igfxgl=1 igfxmetal=1 -disable_sidecar_mac -disable_media_analysis -amfipassbeta igfxonln=1 igfxfw=2 forceRenderStandby=0 agdpmod=vit9696 rddelay=10 -disable_ext_panics -no_compat_check agdpmod=pikera AMFIPass=0x1 amfi=0x80 -oas_skip_attestation cryptex=0 -spoofvmmdbg -liludbgall msgbuf=1048576 -spoofvmmnodelete

[zkennedy137]

this is the complete list of boot arguments:
keepsyms=1 debug=0x100 -ibtcompatbeta ipc_control_port_options=0 -v nvme_shutdown_timestamp=0 -disable_sidecar_mac -disable_media_analysis -amfipassbeta igfxonln=1 igfxfw=2 forceRenderStandby=0 agdpmod=vit9696 rddelay=10 -disable_ext_panics -no_compat_check agdpmod=pikera AMFIPass=0x1 amfi=0x80 -oas_skip_attestation cryptex=0 -lilubetaall

also UpdateSMBIOSMode should be set as Create not Custom

and use this new version also I haven't updated the SpoofVMM repo yet that version doesn't do any spoofing just boots past the language selector.

use this zip it is the latest one I just compiled.

SpoofVMM.kext.zip

[albert-mueller]

At the end, which version to try?
@zkennedy137

[albert-mueller]

From here https://github.com/albert-mueller/Spoof-VMM ?

[zkennedy137]

this is the complete list of boot arguments:
keepsyms=1 debug=0x100 -ibtcompatbeta ipc_control_port_options=0 -v nvme_shutdown_timestamp=0 -disable_sidecar_mac -disable_media_analysis -amfipassbeta igfxonln=1 igfxfw=2 forceRenderStandby=0 agdpmod=vit9696 rddelay=10 -disable_ext_panics -no_compat_check agdpmod=pikera AMFIPass=0x1 amfi=0x80 -oas_skip_attestation cryptex=0 -lilubetaall

also UpdateSMBIOSMode should be set as Create not Custom

and use this new version also I haven't updated the SpoofVMM repo yet that version doesn't do any spoofing just boots past the language selector.

use this zip it is the latest one I just compiled.
SpoofVMM.kext.zip v4.9

Use this zip version v4.9 it’s the most stable so far. I will update the repo later.

[zkennedy137]

As a side note I just confirmed that the bypass works in Sonoma by running the installer app.

IMG_1040-compressed-2.mp4

[jakecaley]

Hey @zkennedy137 good luck on your external ssd and really good news

[zkennedy137]

You should be good to go now. Fingers crossed. :). Also it should also spoof sequoia as well because it works in Sonoma. Anyways yeah give it a try now. But again it fails when installed to the internal drive so I would try a flash drive or external ssd for now. That’s what I am doing now.

[zkennedy137]

Hey @zkennedy137 good luck on your external ssd and really good news

I hope you don’t install to the internal….. but give it a go. If it fails at stage 2 you need to perform internet recovery. That’s the only way to get it back if you completely formatted the internal ssd or tried upgrading sequoia.

[jakecaley]

@zkennedy137 made that mistake before I have my sequoia install on a separate partition

[zkennedy137]

Phew ok haha had me worried lol

[zkennedy137]

Sad news still getting the install error.

[jakecaley]

@zkennedy137 weird I was on a internal ssd I have no clue how or what Mac OS does when its in the recovery phase and installing so idk. although this is much better then just being told its not compatible

[zkennedy137]

@zkennedy137 weird I was on a internal ssd I have no clue how or what Mac OS does when its in the recovery phase and installing so idk. although this is much better then just being told its not compatible

yeah its a shot at getting it to work. Anyways its progress but far from perfect.

[albert-mueller]

@zkennedy137 I sent an invitation to contributing for OpenCore Legacy Patcher T2 (the patcher itself), if you want, you can accept it.

[albert-mueller]

My boot arguments look like this:
keepsyms=1 debug=0x100 -ibtcompatbeta -revbeta revpatch=sbvmm ipc_control_port_options=0 -v nvme_shutdown_timestamp=0 -disable_sidecar_mac -disable_media_analysis -amfipassbeta igfxonln=1 igfxfw=2 forceRenderStandby=0 agdpmod=vit9696 rddelay=10 -disable_ext_panics -no_compat_check agdpmod=pikera AMFIPass=0x1 amfi=0x80 -oas_skip_attestation cryptex=0
I guess some of them are certainly unnecessary. Why AMFIPass=0x1 and then amfi=0x80?
@zkennedy137 @Medelcartelinc

[albert-mueller]

My boot arguments look like this:

keepsyms=1 debug=0x100 -ibtcompatbeta -revbeta revpatch=sbvmm ipc_control_port_options=0 -v nvme_shutdown_timestamp=0 -disable_sidecar_mac -disable_media_analysis -amfipassbeta igfxonln=1 igfxfw=2 forceRenderStandby=0 agdpmod=vit9696 rddelay=10 -disable_ext_panics -no_compat_check agdpmod=pikera AMFIPass=0x1 amfi=0x80 -oas_skip_attestation cryptex=0

I guess some of them are certainly unnecessary. Why AMFIPass=0x1 and then amfi=0x80?

@zkennedy137 @Medelcartelinc

@zkennedy137 I tried to add igfxvesa flag and stuck at the same Apple logo and same white screen.
@Medelcartelinc

[albert-mueller]

And my sepOS panicked again.
Im'm pretty sure something with the framebuffers that the patcher sets isn't right, can you check the EFI, @zkennedy137

[albert-mueller]

panic(cpu 0 caller 0xffffff8007057095): "AppleSEPManager panic for "AppleKeyStore": sks request timeout" @AppleSEPManagerIntel.cpp:809
Panicked task 0xffffff95f68c69a0: 225 threads: pid 0: kernel_task
Backtrace (CPU 0), panicked thread: 0xffffff9129759548, Frame : Return Address
0xffffffde6d86c0c0 : 0xffffff8005758d31 mach_kernel : _handle_debugger_trap + 0x421
0xffffffde6d86c110 : 0xffffff80058e57d2 mach_kernel : _kdp_i386_trap + 0x122
0xffffffde6d86c150 : 0xffffff80058d4a88 mach_kernel : _kernel_trap + 0x778
0xffffffde6d86c210 : 0xffffff80056eb971 mach_kernel : _return_from_trap + 0xc1
0xffffffde6d86c230 : 0xffffff8005759107 mach_kernel : _DebuggerTrapWithState + 0x67
0xffffffde6d86c330 : 0xffffff8005758799 mach_kernel : _panic_trap_to_debugger + 0x269
0xffffffde6d86c4a0 : 0xffffff8005fa0b5d mach_kernel : _panic + 0x81
0xffffffde6d86c590 : 0xffffff8007057095 com.apple.driver.AppleSEPManager : _ZN15AppleSEPManager12requestPanicEPKcS1 + 0x1f
0xffffffde6d86c5a0 : 0xffffff8006ece827 com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore21sep_deliver_msg_gatedEP18ipc_callback_ctx_tjP12ipc_args_all.cold.2 + 0x1b
0xffffffde6d86c5c0 : 0xffffff8006e7ad4f com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore21sep_deliver_msg_gatedEP18ipc_callback_ctx_tjP12ipc_args_all + 0xb9d
0xffffffde6d86c670 : 0xffffff8005ecb588 mach_kernel : _ZN13IOCommandGate9runActionEPFiP8OSObjectPvS2_S2_S2_ES2_S2_S2_S2 + 0xa8
0xffffffde6d86c6d0 : 0xffffff8006e75cb0 com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore15sep_deliver_msgEP18ipc_callback_ctx_tjP12ipc_args_all + 0x58
0xffffffde6d86c720 : 0xffffff8006edbde5 com.apple.driver.AppleKeyStore : __ipc_get_capabilities + 0x119
0xffffffde6d86c870 : 0xffffff8006e7b08b com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore17init_sep_endpointEv + 0x5d
0xffffffde6d86c8e0 : 0xffffff8006e7aebd com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore12sep_endpointEv + 0x3d
0xffffffde6d86c920 : 0xffffff8006e7a1d4 com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore21sep_deliver_msg_gatedEP18ipc_callback_ctx_tjP12ipc_args_all + 0x22
0xffffffde6d86c9d0 : 0xffffff8005ecb588 mach_kernel : _ZN13IOCommandGate9runActionEPFiP8OSObjectPvS2_S2_S2_ES2_S2_S2_S2 + 0xa8
0xffffffde6d86ca30 : 0xffffff8006e75cb0 com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore15sep_deliver_msgEP18ipc_callback_ctx_tjP12ipc_args_all + 0x58
0xffffffde6d86ca80 : 0xffffff8006ed8527 com.apple.driver.AppleKeyStore : __ipc_perform_operation + 0x10e
0xffffffde6d86cbd0 : 0xffffff8006e79ef3 com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore17perform_operationEyijPKvjPPvPj + 0x93
0xffffffde6d86cc40 : 0xffffff8006eccfb2 com.apple.driver.AppleKeyStore : __ZN13AppleKeyStore25perform_operatation_gatedEP23_ref_key_operation_args + 0x32
0xffffffde6d86cc60 : 0xffffff8005ecb588 mach_kernel : _ZN13IOCommandGate9runActionEPFiP8OSObjectPvS2_S2_S2_ES2_S2_S2_S2 + 0xa8
0xffffffde6d86ccc0 : 0xffffff8006ecd06c com.apple.driver.AppleKeyStore : _kern_perform_operation + 0xa8
0xffffffde6d86cd30 : 0xffffff8006ec1c1c com.apple.driver.AppleKeyStore : __aks_operation + 0x3f
0xffffffde6d86cd60 : 0xffffff8006ec3402 com.apple.driver.AppleKeyStore : _aks_system_key_get_public + 0xd6
0xffffffde6d86cdd0 : 0xffffff8006f70812 com.apple.driver.AppleMobileFileIntegrity : __Z42AMFIInitializeLocalSigningPublicKey_ThreadPvi + 0x12d
0xffffffde6d86ce80 : 0xffffff8006f82484 com.apple.driver.AppleMobileFileIntegrity : _ZL20_init_thread_wrapperPvS + 0x17
0xffffffde6d86cea0 : 0xffffff80057bc678 mach_kernel : _thread_call_delayed_timer + 0x588
0xffffffde6d86cee0 : 0xffffff80057bd688 mach_kernel : _thread_call_delayed_timer + 0x1598
0xffffffde6d86cfa0 : 0xffffff80056eb19e mach_kernel : _call_continuation + 0x2e
Kernel Extensions in backtrace:
com.apple.driver.AppleSEPManager(1.0.1)[0D42925E-8B07-3064-80D1-328D43196288]@0xffffff800704e000->0xffffff800705dfff
dependency: com.apple.driver.IOSlaveProcessor(1)[70B0AED1-5344-3608-B342-45E9C11B79A5]@0xffffff8007f47000->0xffffff8007f48fff
dependency: com.apple.iokit.IOPCIFamily(2.9)[0D3C5E4A-9717-3C1B-A470-D9F4F95B0CED]@0xffffff8007de5000->0xffffff8007e38fff
dependency: com.apple.kec.corecrypto(26.0)[054C32E8-7085-33FB-A9B8-1FD60CBF50C5]@0xffffff8008716000->0xffffff80087a8fff
com.apple.driver.AppleMobileFileIntegrity(1.0.5)[34556CFD-5BAC-3A0B-B8ED-79508481D13F]@0xffffff8006f6e000->0xffffff8006faafff
dependency: com.apple.iokit.CoreAnalyticsFamily(1)[C2AB7174-29B1-3101-8E7A-5F5FB4E9E0BD]@0xffffff8007374000->0xffffff800737efff
dependency: com.apple.kec.corecrypto(26.0)[054C32E8-7085-33FB-A9B8-1FD60CBF50C5]@0xffffff8008716000->0xffffff80087a8fff
dependency: com.apple.kext.CoreTrust(1)[12D8061F-4687-36E3-AEBA-87C3AA341D49]@0xffffff8007443000->0xffffff8007452fff
dependency: com.apple.security.AppleImage4(7.0.0)[EB240802-3A75-3739-95A4-FAAB08A8501B]@0xffffff8006de6000->0xffffff8006e0dfff
com.apple.driver.AppleKeyStore(2.0)[060C7A7E-28E1-3FED-BDB3-586E4210C064]@0xffffff8006e73000->0xffffff8006f20fff
dependency: com.apple.driver.AppleCredentialManager(1.0)[BB2FF697-37BA-370F-B477-CDDF1ECE7FB7]@0xffffff8006ca5000->0xffffff8006d2bfff
dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[34556CFD-5BAC-3A0B-B8ED-79508481D13F]@0xffffff8006f6e000->0xffffff8006faafff
dependency: com.apple.driver.AppleSEPManager(1.0.1)[0D42925E-8B07-3064-80D1-328D43196288]@0xffffff800704e000->0xffffff800705dfff
dependency: com.apple.driver.AppleUSBTDM(562)[756B411A-120E-3D5A-BE96-764395143258]@0xffffff80070e2000->0xffffff80070e9fff
dependency: com.apple.driver.IOSlaveProcessor(1)[70B0AED1-5344-3608-B342-45E9C11B79A5]@0xffffff8007f47000->0xffffff8007f48fff
dependency: com.apple.kec.corecrypto(26.0)[054C32E8-7085-33FB-A9B8-1FD60CBF50C5]@0xffffff8008716000->0xffffff80087a8fff
dependency: com.apple.kext.CoreTrust(1)[12D8061F-4687-36E3-AEBA-87C3AA341D49]@0xffffff8007443000->0xffffff8007452fff

Process name corresponding to current thread (0xffffff9129759548): kernel_task
Boot args: keepsyms=1 debug=0x100 -ibtcompatbeta -revbeta revpatch=sbvmm ipc_control_port_options=0 -v nvme_shutdown_timestamp=0 -disable_sidecar_mac -disable_media_analysis -amfipassbeta igfxonln=1 igfxfw=2 forceRenderStandby=0 agdpmod=vit9696 rddelay=10 -disable_e

Mac OS version:
25G83

Kernel version:
Darwin Kernel Version 25.6.0: Fri Jul 31 19:11:49 PDT 2026; root:xnu-12377.161.14~5/RELEASE_X86_64
Kernel UUID: 39CC2C26-3F72-3565-89C4-94DFE36DFDF2
roots installed: 0
KernelCache slide: 0x0000000005400000
KernelCache base: 0xffffff8005600000
Kernel slide: 0x00000000054e8000
Kernel text base: 0xffffff80056e8000
__HIB text base: 0xffffff8005500000
System model name: Apple000,0
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
Hibernation exit count: 0

System uptime in nanoseconds: 131586774806
Last Sleep: absolute base_tsc base_nano
Uptime : 0x0000001ea32ee11d
Sleep : 0x0000000000000000 0x0000000000000000 0x0000000000000000
Wake : 0x0000000000000000 0x0000000a48675012 0x0000000000000000
Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space
Zone info:
Zone map: 0xffffff8129bda000 - 0xffffffa129bda000
. VM : 0xffffff8129bda000 - 0xffffff85f68a6000
. RO : 0xffffff85f68a6000 - 0xffffff879024a000
. GEN0 : 0xffffff879024a000 - 0xffffff8c5cf16000
. GEN1 : 0xffffff8c5cf16000 - 0xffffff9129be2000
. GEN2 : 0xffffff9129be2000 - 0xffffff95f68ae000
. GEN3 : 0xffffff95f68ae000 - 0xffffff9ac357a000
. DATA : 0xffffff9ac357a000 - 0xffffffa129bda000
Metadata: 0xffffffa129bea000 - 0xffffffa149bea000
Bitmaps : 0xffffffa149bea000 - 0xffffffa14cbea000
Extra : 0 - 0

[zkennedy137]

My boot arguments look like this:
keepsyms=1 debug=0x100 -ibtcompatbeta -revbeta revpatch=sbvmm ipc_control_port_options=0 -v nvme_shutdown_timestamp=0 -disable_sidecar_mac -disable_media_analysis -amfipassbeta igfxonln=1 igfxfw=2 forceRenderStandby=0 agdpmod=vit9696 rddelay=10 -disable_ext_panics -no_compat_check agdpmod=pikera AMFIPass=0x1 amfi=0x80 -oas_skip_attestation cryptex=0
I guess some of them are certainly unnecessary. Why AMFIPass=0x1 and then amfi=0x80?
@zkennedy137 @Medelcartelinc

@zkennedy137 I tried to add igfxvesa flag and stuck at the same Apple logo and same white screen. @Medelcartelinc

You still have restrict events boot args. Also I don’t see -igfxvesa and if you typed igfxvesa then it will not do anything it has to be “-igfxvesa”

[zkennedy137]

I am working on something to potentially fix the issue and also trying to boot the disk I installed the Tahoe installer to in UTM to see if we can boot it there and run it just to see if getting through the update and then trying to boot from it on the bare metal works.

I get opencore to boot up on UTM but I can't get out to show the disk img I made of the external that I installed Tahoe to. I am a newbie to UTM I usually use lib-virt on ubuntu or vmware on windows. lol help please haha @Medelcartelinc @albert-mueller

[albert-mueller]

I didn't use UTM for quite a long time, so I forgot how to use that virtual machine manager.

[zkennedy137]

I have put out the first official release of the SpoofVMM.kext it is v4.9. This one is stable and has important changes that fix the broken WiFI issue. Now you can boot into your working install be it Sonoma-Sequioa they will not mind the changes it makes to the bridge-model variable. Also the bypass works on if you try to install from Sonoma-Sequioa /Applications folder

[zkennedy137]

sorry guys I forgot I had that error and it made me cd into the directory in terminal before doing the command that is on me sorry.

[albert-mueller]

When I tried to boot my Mac mini 2018 into the macOS 26 installer I got a white screen:

Will try resetting the NVRAM and try again.
@zkennedy137 @Medelcartelinc

[zkennedy137]

try -igfxvesa boot arg

if that doesn't work try -wegoff

more than likely the igpu not playing nice

[jakecaley]

hey @zkennedy137 I found it through my main sequoia install but it took me a bit
ia.log

[jakecaley]

@zkennedy137 scrap that that my be a sequoia install.

[albert-mueller]

After resetting the NVRAM, I got stuck at Apple logo when I was trying to boot the installer:

And then the sepOS panicked.
Are these patches here broken:

def _t2_handling(self) -> None:
"""T2 Security Chip Handler."""
if not self._is_t2_mac():
logging.error(f"{self.model} is not a T2 Mac.")
return
else:
logging.info(f"{self.model} is a T2 Mac.")
builder = support.BuildSupport(self.model, self.constants, self.config)
self.config.setdefault("Kernel", {}).setdefault("Patch", [])

        # Prerequisite kext checks
        for kext, ver, path in [
            ("WhateverGreen.kext", self.constants.whatevergreen_version, self.constants.whatevergreen_path),
            ("CryptexFixup.kext", "1.0.5", self.constants.kexts_path),
            # ("AMFIPass.kext", "1.4.1", self.constants.kexts_path) # Temporarily disabled for testing AMFI stall
        ]:
            obj = builder.get_kext_by_bundle_path(kext)
            if not obj or obj.get("Enabled") is not True:
                logging.info(f"- Enabling {kext}")
                builder.enable_kext(kext, ver, path)

        # Handle explicit performance/timeout panics on specific MacBook lines
        # Der Grund warum MinKernel auf 24.0.0 (Sequoias Version von Darwin) stattdessen von 25.x.x eingestellt ist, ist es die Installationsprogramm läuft auf Darwin 24 noch, auch die von 26 Tahoe.
        if self.model in ["MacBookAir8,1", "MacBookAir8,2", "MacBookAir9,1", "MacBookPro16,3"]:
            logging.info(f"- {self.model}: Applying Unsupported Mantissa Speed kernel panic patches")
            try:
                logging.info(f"- {self.model}: Disabling USB-Map.kext and USB-Map-Tahoe.kext if any is there")
                m1 = builder.get_kext_by_bundle_path("USB-Map.kext")
                m2 = builder.get_kext_by_bundle_path("USB-Map-Tahoe.kext")
                if m1: m1["Enabled"] = False
                if m2: m2["Enabled"] = False
            except Exception as e:
                logging.info(f"- {self.model}: Great news! We tried disabling USB-Map.kext and USB-Map-Tahoe.kext but we didn't find them.")
                logging.info("You don't have to worry about this message.")
        try:
            APPLE_NVRAM_UUID = "7C436110-AB2A-4BBB-A880-FE41995C9F82"
            logging.info("- Defining NVRAM variable APPLE_NVRAM_UUID")
        except Exception as e:
            logging.error("We failed to define APPLE_NVRAM_UUID. It failed to do so because of the following error:")
            logging.exception("Stack Trace:")
            logging.info("Please try again later.")
            sys.exit(3)

        try:
            logging.info("- Adding T2-specific boot arguments for macOS 15/26")
            # agdpmod=pikera is required for models with a discrete Polaris/Navi dGPU to prevent
            # the Tahoe AGDP display-policy check from deadlocking WindowServer (black screen).
            # iGPU-only models use agdpmod=vit9696 instead.
            _agdpmod = "pikera" if self.computer.dgpu else "vit9696"
            self._update_nvram_string(APPLE_NVRAM_UUID, "boot-args",
                f"-v rddelay=10 igfxfw=2 igfxonln=1 -disable_ext_panics -no_compat_check -revbeta "
                f"agdpmod={_agdpmod} forceRenderStandby=0 revpatch=sbvmm ipc_control_port_options=0 AMFIPass=0x1 amfi=0x80")
        except Exception as e:
            logging.error("Injecting T2 specific boot arguments failed due to the following error:")
            logging.exception("Stack Trace:")
            logging.info("Please try again later.")
            sys.exit(3)

        # Structure guarding for OpenCore NVRAM delete layout
        self.config.setdefault("NVRAM", {}).setdefault("Delete", {})
        if APPLE_NVRAM_UUID not in self.config["NVRAM"]["Delete"]:
            self.config["NVRAM"]["Delete"][APPLE_NVRAM_UUID] = []
        if "boot-args" not in self.config["NVRAM"]["Delete"][APPLE_NVRAM_UUID]:
            self.config["NVRAM"]["Delete"][APPLE_NVRAM_UUID].append("boot-args")

        try:
            logging.info("- Set SIP to allow Root Volume patching on T2 Macs (03080000)")
            self._set_nvram_value(APPLE_NVRAM_UUID, "csr-active-config", binascii.unhexlify("03080000"), overwrite=True)
        except Exception as e:
            logging.error("Setting SIP to 03080000 failed due to the following error:")
            logging.exception("Stack Trace:")
            logging.info("Please try again later.")
            sys.exit(3)

        # Allows booting macOS 26 Tahoe's installer via OpenCore on T2 Macs
        self.config.setdefault('Kernel', {}).setdefault('Patch', [])
        kernel_patches = self.config['Kernel']['Patch']


        # --- Patch 2: Force FileVault on Broken Seal ---
        if not any(p.get("Comment") == "Force FileVault on Broken Seal" for p in kernel_patches):
            new_patch = {
                "Arch": "x86_64",
                "Identifier": "com.apple.filesystems.apfs",
                "Base": "_apfs_filevault_allowed",
                "Comment": "Force FileVault on Broken Seal",
                "Count": 0,
                "Enabled": True,
                "MinKernel": "20.4.0",
                "MaxKernel": "",
                "Find": b"",
                "Replace": binascii.unhexlify("B801000000C3"),
                "Mask": b"",
                "ReplaceMask": b"",
                "Limit": 0,
                "Skip": 0
            }
            if self._validate_patch(new_patch):
                logging.info("- Injecting Force FileVault on Broken Seal patch")
                kernel_patches.append(new_patch)

        # --- Patch 3: Disable Library Validation Enforcement ---
        if not any(p.get("Comment") == "Disable Library Validation Enforcement" for p in kernel_patches):
            new_patch = {
                "Arch": "x86_64",
                "Identifier": "kernel",
                "Base": "_cs_require_lv",
                "Comment": "Disable Library Validation Enforcement",
                "Count": 0,
                "Enabled": True,
                "MinKernel": "20.0.0",
                "MaxKernel": "",
                "Find": b"",
                "Replace": binascii.unhexlify("B800000000C3"),
                "Mask": b"",
                "ReplaceMask": b"",
                "Limit": 0,
                "Skip": 0
            }
            if self._validate_patch(new_patch):
                logging.info("- Injecting Disable Library Validation Enforcement patch")
                kernel_patches.append(new_patch)

        # --- Patch 4: Disable _csr_check() in _vnode_check_signature ---
        if not any(p.get("Comment") == "Disable _csr_check() in _vnode_check_signature" for p in kernel_patches):
            new_patch = {
                "Arch": "x86_64",
                "Identifier": "com.apple.driver.AppleMobileFileIntegrity",
                "Base": "__ZL22_vnode_check_signatureP5vnodeP5labeliP7cs_blobPjS5_ijPPcPm",
                "Comment": "Disable _csr_check() in _vnode_check_signature",
                "Count": 1,
                "Enabled": True,
                "MinKernel": "22.0.0",
                "MaxKernel": "",
                "Find": binascii.unhexlify("01000000E80000000085C075"),
                "Replace": binascii.unhexlify("01000000B80100000085C075"),
                "Mask": binascii.unhexlify("FFFFFFFFFF00000000FFFFFF"),
                "ReplaceMask": b"",
                "Limit": 0,
                "Skip": 0
            }
            if self._validate_patch(new_patch):
                logging.info("- Injecting Disable _csr_check() in _vnode_check_signature patch")
                kernel_patches.append(new_patch)

        # Bypass osinstallersetupd bridge device validation checks (Fixes Attestation Error -10000)
        try:
            logging.info("- Injecting User-Space Attestation bypass flags (Fixes Error -10000)")
            self._update_nvram_string(APPLE_NVRAM_UUID, "boot-args", "-oas_skip_attestation")
            self._set_nvram_value(APPLE_NVRAM_UUID, "IAS_ENV_SKIP_ATTESTATION", "1", overwrite=True)
        except Exception as e:
            logging.error("Failed to inject Attestation Error -10000 bypass flags:")
            logging.exception("Stack Trace:")
            logging.info("Please try again later.")
            sys.exit(3)
        # dieses Patch bringt dazu, dass T2 Macs den Fehler nach 29 Minuten verbleibend weiter mit die Installation fährt statt einen Fehler zu zeigen
        try:
            logging.info("- Disabling UEFI updates for T2 Macs to prevent errors after 29 minutes remaining")
            logging.info("This patch will block UEFI updates on T2 Macs. To update the UEFI on T2 Macs while running unsupported macOS versions, if you care about your UEFI being up to date, you'll need to update it via exiting OpenCore and entering DFU mode using another Mac.")
            self._set_nvram_value(APPLE_NVRAM_UUID, "run-efi-updater", "No", overwrite=True)
        except Exception as e:
            logging.error("Failed to disable UEFI updates for T2 Macs after 29 minutes remaining due to an error:")
            logging.exception("Stack Trace:")
            logging.info("Please try again later.")
            sys.exit(3)

@zkennedy137 @Medelcartelinc

[zkennedy137]

You don’t spoof MacBookAir16,4 in your smbios or the quirks in platform section of OpenCore are not right

[zkennedy137]

[albert-mueller]

MacBookPro16,4 isn’t suitable for a Mac mini 2018 - it expects then laptop thermals, battery and sleep states a desktop computer doesn’t have.
iMac20,1 (iMac 2020) is the closest SMBIOS to the Mac mini 2018 that actually supports Tahoe.
MacPro7,1 has PCIe GPUs and hard drives, and that wouldn’t work well on a Mac mini as well.

[albert-mueller]

@zkennedy137

[albert-mueller]

Isn’t MacBookPro16,4 the wrong SMBIOS profile for a desktop computer?
@zkennedy137

[jakecaley]

@albert-mueller wierd and off topic question but you said you have a separate partition so it doesn't mess with your windows efi did you just make a fat 32 partition and put the win efi on there because I have a win 11 modded to work on my MacBook version but I don't want it messing with my efi

[albert-mueller]

thanks @albert-mueller.

You're welcome

[albert-mueller]

By the way my Mac mini 2018 also has Windows 11, similar to yours, except the fact I'm using FlexTPM instead because I've fed up of registry bypasses that afterwards don't let me download feature updates unless I write group policies for which build to install, otherwise it wouldn't even install unless I repair upgraded my image. I prefer to meet the requirements rather than bypass.
@jakecaley

[albert-mueller]

https://flextpm.com/ - it's more like a vTPM. And I even managed with this running to install 26H2 from Windows Update without ever touching the GPOs for the first time!

[zkennedy137]

By the way my Mac mini 2018 also has Windows 11, similar to yours, except the fact I'm using FlexTPM instead because I've fed up of registry bypasses that afterwards don't let me download feature updates unless I write group policies for which build to install, otherwise it wouldn't even install unless I repair upgraded my image. I prefer to meet the requirements rather than bypass. @jakecaley

Did it let you install Tahoe did the compatibility bypass work?

[albert-mueller]

FlexTPM is for Windows
Otherwise, I attempted to boot the macOS 26 installer, but stuck at Apple, but I accidentally injected an Ethernet kext not suitable for the Mini at all

[albert-mueller]

How to select the profile only using keyboard? Unfortunately my mouse uses Bluetooth, not USB and doesn't have a USB-A dongle, unlike most mices. My mouse is MX Master 3S for Mac. I can try in Sequoia if this does work to launch the Tahoe installer, but currently can't use a mouse, only a keyboard.
@zkennedy137

[zkennedy137]

wat kind of fix did you have in mind because it seemed as though just adding EnableVMX in UEFI > Quirks is the answer and was simply not set by default with the OpenCorePkg from what I understand

[albert-mueller]

Ah, I thought you’d need to fix a bug in OpenCorePkg itself, and not a missing entry, sorry for misunderstanding.
@zkennedy137

[albert-mueller]

wat kind of fix did you have in mind because it seemed as though just adding EnableVMX in UEFI > Quirks is the answer and was simply not set by default with the OpenCorePkg from what I understand

So with this enabled it should work?
@zkennedy137

[zkennedy137]

It didn't work also I discovered there was remanance of the real model but I did get that fixed with an updated SpoofVMM and some opencore config stuff however in an earlier version v4.2 it failed to boot installer and could do the same so as a precaution a new boot arg is added -spoofvmmmodel that way if necessary it can be disabled by removing the boot argument.

[zkennedy137]

well good and bad news I think I found out why the install is failing

from claude

"Good find, but it says something different than what you were told — worth correcting before we build on it.

The page doesn't state a "minimum required" bridgeOS version at all. What it actually lists is a running table of what bridgeOS version each Tahoe build updates T2 Macs to — e.g. 23.16.5283.0.7 is the bridgeOS version that installing Tahoe Beta 1 pushes your T2 chip to, as part of that install. That's an outcome of updating, not a gate you have to clear beforehand. So "minimum required... is 23.16.5283.0" isn't quite right; it's "Tahoe Beta 1 leaves your T2 on bridgeOS 23.16.5283.0.7 afterward."

That reframe is actually more useful than the original claim, though, because of something already sitting in your config:

Will not update firmware because run-efi-updater is set to false

That's deliberate — OCLP sets run-efi-updater=No specifically to stop macOS from attempting a bridgeOS/firmware update during install on unsupported hardware, because that update can fail or brick the T2 chip if attempted on a configuration Apple didn't test. The tradeoff: your bridgeOS stays frozen at 24P6005 and will never advance to whatever version (23.16.5283.0.7-style, under Tahoe's newer versioning scheme) the Tahoe installer normally expects to leave it at.

This gives a cleaner, more specific hypothesis than before: if Stage 2's root-hash/manifest process expects to coordinate with — or at least be consistent with — a bridge firmware update that your config is explicitly and intentionally blocking, that mismatch could plausibly be exactly what's producing Code=-81. Not "wrong identity," but "the installer can't finish personalizing a system whose bridge firmware state doesn't match what it's trying to install," because the piece that would normally reconcile that (the firmware updater) never runs.

The way to actually test this would be flipping run-efi-updater to Yes and re-attempting — but I want to flag clearly: that's a real risk, not a casual toggle. It's disabled specifically because unsupported T2 hardware can fail or hang during that firmware update step, and a bad bridgeOS flash is one of the few failure modes on this hardware that can be genuinely hard to recover from without DFU restore tools and another Mac. Do you want to go there, or would you rather look for a safer way to test the theory first (e.g., checking whether Apple's actual Tahoe installer requires a firmware update to proceed past Stage 2, versus just performing one opportunistically when allowed)?

Possibly, but whether it would actually help depends entirely on how that version gets reported, and that's the part we don't know yet.

There are two very different cases:

1. If the bridgeOS version is just a static string/property the installer reads out of something like IORegistry, a sysctl, or a cached plist (similar to how Model/board-id/SystemProductName work) — then yes, in principle a kext patch could intercept that read and report a newer version string, the same mechanism as everything else we've spoofed so far.

2. If it's a live, authenticated query to the actual T2 chip — which is far more likely for something like firmware version on a security coprocessor — then spoofing the reported string wouldn't actually help, because the real manifest/personalization process on a T2 Mac isn't just comparing a version number in software; it's validating against the T2's actual signed capabilities (Image4 manifests chained to Apple's root of trust, SEP-backed). If Stage 2 needs the bridge chip to actually do something a newer firmware can do (generate or validate a specific manifest format, support a newer signing scheme), lying about the version string wouldn't make the real chip capable of doing that — it would just mean the installer thinks it can proceed, tries the real operation against the actual old firmware, and likely fails at a different, possibly less clear, point than -81.

Given everything we've seen so far — board-id, bridge-model, VMM presence, the Model DataHub key — all turned out to be case (1), cosmetic/software-only properties that don't gate the real failure. Firmware version for the actual security chip feels much more likely to be case (2), which would make this a dead end the same way, just a more plausible-sounding one.

Before attempting a patch here, it'd be worth first finding out where the installer actually reads bridgeOS version from during Stage 2 — is it querying the chip live, or reading something cached/static? That's exactly the kind of thing the paniclog/process-identification approach could answer definitively, rather than guessing and building a kext patch against an unknown target. Want to go that route now, given how many of the software-only angles have already dead-ended?"

[zkennedy137]

So we need to confirm that bridgeOS firmware version is in ioreg first. If it is what is the variable name? Then spoof it with the correct Tahoe version. This may work but it may not even if the variable in ioreg exists. It comes down to how the installer/macOS checks the firmware (bridgeOS) version.

Another possibility is when the installer/macOS sees older firmware it attempts to update bridgeOS and fails. That the failure is because of “run-efi-updater” being set to False. It prevents firmware updates from macOS. However the huge unknown risk is it could brick the computer, cause dfu mode and restore, in the most benign it just fails to install still or installs.

If the attempt to spoof the bridgeOS firmware hits a dead and I am heavily considering biting the bullet and attempting on my macbookair8,1 allowing the run-ego-updater = True and potentially “take one for the team” if it fails.

[albert-mueller]

boyan1@Mac-mini-von-Boyan ~ % ioreg -c AppleEmbeddedOSSupportHost -r

This returns empty
@zkennedy137

[albert-mueller]

boyan1@Mac-mini-von-Boyan ~ % ioreg -lw0 -p IODeviceTree -n efi -r -x

+-o efi <class IOService, id 0x100000103, !registered, !matched, active, busy 0, retain 8>
| {
| "firmware-revision" = <00000100>
| "device-properties" = <1c0700000100000003000000700200000500000002010c00d041030a000000000101060000027fff04001e000000730061007600650064002d0063006f006e006600690067000000ee000000470000000000000000000000000000000000030007009b3e00ce560000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010102020010acd3a102024000000000000000000260ff640e000aa005a0000000290000003000200003000500400684033200010001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d006900640000000800000007009b3e200000004100410050004c002c004700660078005900540069006c006500000008000000010000002400000067007200610070006800690063002d006f007000740069006f006e0073000000080000000c0000002e0000004700720061007000680069006300730044006900730070006c00610079005300650074007500700000009000000000000100000000000200000018150000010000000000010000000200000060ff640e00000000000a0000a0050000a0000000000000000000000029000000000000000000000030000000200000000103000000050000000000010001000000000002000000020000000000000101000000000000000100400600008403000000190000010000000000000000500200000800000002010c00d041030a000000000101060001010101060000000101060000000101060000007fff0400280000005400680075006e0064006500720062006f006c00740043006f006e006600690067000000240000000002010002000503010004000503020003000503010001000303020002000100240000005400680075006e0064006500720062006f006c007400440052004f004d00000084000000c90058d22c5d82010026f2ec4301580001000d000100088180028000000008829001800000000883800480010000088490038001000005850901000586090100028703882003898002ca02cb0d014170706c6520496e632e000c024d6163696e746f736800000000000000000000000000000000000000000000000000000000240000005400680075006e0064006500720062006f006c00740055005500490044000000140000000fd4881f8100d55d9e53c0579d8ddeea22000000540042005400440050004c006f00770054006f00480069006700680000000800000001000000120000007000610074006800630072000000540000000400000000000000000007001000100005000000000000000000070010001000010000000b000e000e0000000000000002000000000000000000040002000100030000000000000000000700020001001c0000006c0069006e006b00440065007400610069006c00730000000c0000000800000003000000180000007300730063004f006600660073006500740000000600000000071600000054004200540046006c006100670073000000080000000b000000500200000800000002010c00d041030a000000000101060002010101060000000101060000000101060000007fff0400280000005400680075006e0064006500720062006f006c00740043006f006e006600690067000000240000000102010002000503010004000503020003000503010000000303020004000300240000005400680075006e0064006500720062006f006c007400440052004f004d00000084000000da0158d22c5d820100ac103e5501580001000d000100088181028100000008829101810000000883810481010000088491038101000005850901000586090100028703882003898002ca02cb0d014170706c6520496e632e000c024d6163696e746f736800000000000000000000000000000000000000000000000000000000240000005400680075006e0064006500720062006f006c00740055005500490044000000140000002d6222f93695f955a4bf3b6685f8fba722000000540042005400440050004c006f00770054006f00480069006700680000000800000001000000120000007000610074006800630072000000540000000400000000000000000007001000100005000000000000000000070010001000010000000b000e000e0000000000000002000000000000000000040002000100030000000000000000000700020001001c0000006c0069006e006b00440065007400610069006c00730000000c0000000800000003000000180000007300730063004f006600660073006500740000000600000000071600000054004200540046006c006100670073000000080000000b000000>
| "firmware-abi" = <454649363400>
| "name" = <65666900>
| "firmware-vendor" = <4100700070006c0065000000>
| }
|
+-o kernel-compatibility <class IOService, id 0x100000104, !registered, !matched, active, busy 0, retain 4>
| {
| "name" = <6b65726e656c2d636f6d7061746962696c69747900>
| "x86_64" = <33a0d9e3>
| }
|
+-o runtime-services <class IOService, id 0x100000105, !registered, !matched, active, busy 0, retain 4>
| {
| "name" = <72756e74696d652d736572766963657300>
| "table" = <18eed77800000000>
| }
|
+-o configuration-table <class IOService, id 0x100000106, !registered, !matched, active, busy 0, retain 16>
| | {
| | "name" = <636f6e66696775726174696f6e2d7461626c6500>
| | }
| |
| +-o F2FD1544-9794-4A2C-992E-E5BBCF20E394 <class IOService, id 0x100000107, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <46324644313534342d393739342d344132432d393932452d45354242434632304533393400>
| | "guid" = <4415fdf294972c4a992ee5bbcf20e394>
| | "table" = <00e0ec7800000000>
| | }
| |
| +-o EB9D2D31-2D88-11D3-9A16-0090273FC14D <class IOService, id 0x100000108, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <45423944324433312d324438382d313144332d394131362d30303930323733464331344400>
| | "guid" = <312d9deb882dd3119a160090273fc14d>
| | "table" = <0000ed7800000000>
| | }
| |
| +-o 8868E871-E4F1-11D3-BC22-0080C73C8881 <class IOService, id 0x100000109, !registered, !matched, active, busy 0, retain 4>
| | {
| | "alias" = <414350495f323000>
| | "name" = <38383638453837312d453446312d313144332d424332322d30303830433733433838383100>
| | "table" = <14e0ff7800000000>
| | "guid" = <71e86888f1e4d311bc220080c73c8881>
| | }
| |
| +-o EB9D2D30-2D88-11D3-9A16-0090273FC14D <class IOService, id 0x10000010a, !registered, !matched, active, busy 0, retain 4>
| | {
| | "alias" = <4143504900>
| | "name" = <45423944324433302d324438382d313144332d394131362d30303930323733464331344400>
| | "table" = <00e0ff7800000000>
| | "guid" = <302d9deb882dd3119a160090273fc14d>
| | }
| |
| +-o 49152E77-1ADA-4764-B7A2-7AFEFED95E8B <class IOService, id 0x10000010b, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <34393135324537372d314144412d343736342d423741322d37414645464544393545384200>
| | "guid" = <772e1549da1a6447b7a27afefed95e8b>
| | "table" = <1068ec6500000000>
| | }
| |
| +-o 4C19049F-4137-4DD3-9C10-8B97A83FFDFA <class IOService, id 0x10000010c, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <34433139303439462d343133372d344444332d394331302d38423937413833464644464100>
| | "guid" = <9f04194c3741d34d9c108b97a83ffdfa>
| | "table" =
| | }
| |
| +-o 7739F24C-93D7-11D4-9A3A-0090273FC14D <class IOService, id 0x10000010d, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <37373339463234432d393344372d313144342d394133412d30303930323733464331344400>
| | "guid" = <4cf23977d793d4119a3a0090273fc14d>
| | "table" = <18304a7800000000>
| | }
| |
| +-o 05AD34BA-6F02-4214-952E-4DA0398E2BB9 <class IOService, id 0x10000010e, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <30354144333442412d364630322d343231342d393532452d34444130333938453242423900>
| | "guid" =
| | "table" = <705cec6500000000>
| | }
| |
| +-o EE4E5898-3914-4259-9D6E-DC7BD79403CF <class IOService, id 0x10000010f, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <45453445353839382d333931342d343235392d394436452d44433742443739343033434600>
| | "guid" = <98584eee143959429d6edc7bd79403cf>
| | "table" = <98e7507800000000>
| | }
| |
| +-o A31280AD-481E-41B6-95E8-127F4C984779 <class IOService, id 0x100000110, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <41333132383041442d343831452d343142362d393545382d31323746344339383437373900>
| | "guid" =
| | "table" = <18e8507800000000>
| | }
| |
| +-o 026C0F80-22EC-11E2-AA02-3C07540E73B4 <class IOService, id 0x100000111, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <30323643304638302d323245432d313145322d414130322d33433037353430453733423400>
| | "guid" = <800f6c02ec22e211aa023c07540e73b4>
| | "table" = <00204c7800000000>
| | }
| |
| +-o 674ABEA3-0FE5-11E5-988E-B8E8562CBAFA <class IOService, id 0x100000112, !registered, !matched, active, busy 0, retain 4>
| {
| "name" = <36373441424541332d304645352d313145352d393838452d42384538353632434241464100>
| "guid" =
| "table" = <98ec507800000000>
| }
|
+-o platform <class IOService, id 0x100000113, !registered, !matched, active, busy 0, retain 20>
{
"apple-coprocessor-version" = <00000200>
"boot-chime-on-last-boot" = <00000000>
"Model" = <4d00610063006d0069006e00690038002c003100>
"FSBFrequency" = <00105e5f00000000>
"board-id" = <4d61632d3742413542324446453232444444384300>
"board-rev" = <01>
"system-id" =
"StartupPowerEvents" = <4f00000000000000>
"InitialTSC" =
"IOCompatibilityProperties" = {"IOClass"="IOService","IOName"="platform","IOPath"="IODeviceTree:/efi/platform","system-id"=}
"DevicePathsSupported" = <01000000>
"name" = <706c6174666f726d00>
"SystemSerialNumber" = <43003000370058004e003000500034004a00590057003000>
}

@zkennedy137

[zkennedy137]

No — nothing in that snippet is the bridgeOS firmware build version we've been comparing (24P6005-style, or the 23.16.5283.0-style format). Here's what's actually in there, field by field:

• firmware-revision = <00000100> and firmware-abi = "EFI64", firmware-vendor = "Apple" — these are generic UEFI firmware identifiers (the EFI spec revision, 64-bit ABI tag, vendor string), not bridgeOS/T2 firmware at all. Every Mac, T2 or not, has these.
• apple-coprocessor-version = <00000200> — this one's interesting and new. Decoded as a major/minor pair, that's version 2.0. This looks like it's identifying the T2 coprocessor's hardware/protocol generation, not a specific firmware build string — more like "which generation of Apple coprocessor is this" than "what build is currently flashed on it."

None of these are the actual bridgeOS build number (what system_profiler SPiBridgeDataType reports as Firmware Version). So this dump doesn't give us a direct comparison point for the firmware-staleness question.

That said, apple-coprocessor-version is a genuinely new key we haven't looked at on your machine yet — it wasn't in anything we've pulled so far. Worth checking what your own system reports for it, using the exact same command this other user ran:

ioreg -lw0 -p IODeviceTree -n efi -r -x

Then look specifically at the platform node's apple-coprocessor-version value and compare it to this 2.0 reading. If yours differs (or is missing), that could be a more meaningful signal than anything we've checked so far, since it's closer to actual coprocessor capability than a cosmetic identity string. Want to run that and paste back your platform section?

I still have to run the command when I get home but we may be into something and it would be spoofable if that is the case.

[zkennedy137]

no dice with this unfortunately but I will continue to research this thought. However if we can't bypass this I can still try the fi update but more than likely at best it will just trigger dfu mode at worst it will ruin the macbookair8,1 and make it a brick but I may test it idk yet. if we could spoof the bridgeos firmware it should at least fix the main error.

[albert-mueller]

boyan1@Mac-mini-von-Boyan ~ % ioreg -lw0 -p IODeviceTree -n efi -r -x
+-o efi <class IOService, id 0x100000103, !registered, !matched, active, busy 0, retain 8>
| {
| "firmware-revision" = <00000100>
| "device-properties" = <1c0700000100000003000000700200000500000002010c00d041030a000000000101060000027fff04001e000000730061007600650064002d0063006f006e006600690067000000ee000000470000000000000000000000000000000000030007009b3e00ce560000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010102020010acd3a102024000000000000000000260ff640e000aa005a0000000290000003000200003000500400684033200010001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d006900640000000800000007009b3e200000004100410050004c002c004700660078005900540069006c006500000008000000010000002400000067007200610070006800690063002d006f007000740069006f006e0073000000080000000c0000002e0000004700720061007000680069006300730044006900730070006c00610079005300650074007500700000009000000000000100000000000200000018150000010000000000010000000200000060ff640e00000000000a0000a0050000a0000000000000000000000029000000000000000000000030000000200000000103000000050000000000010001000000000002000000020000000000000101000000000000000100400600008403000000190000010000000000000000500200000800000002010c00d041030a000000000101060001010101060000000101060000000101060000007fff0400280000005400680075006e0064006500720062006f006c00740043006f006e006600690067000000240000000002010002000503010004000503020003000503010001000303020002000100240000005400680075006e0064006500720062006f006c007400440052004f004d00000084000000c90058d22c5d82010026f2ec4301580001000d000100088180028000000008829001800000000883800480010000088490038001000005850901000586090100028703882003898002ca02cb0d014170706c6520496e632e000c024d6163696e746f736800000000000000000000000000000000000000000000000000000000240000005400680075006e0064006500720062006f006c00740055005500490044000000140000000fd4881f8100d55d9e53c0579d8ddeea22000000540042005400440050004c006f00770054006f00480069006700680000000800000001000000120000007000610074006800630072000000540000000400000000000000000007001000100005000000000000000000070010001000010000000b000e000e0000000000000002000000000000000000040002000100030000000000000000000700020001001c0000006c0069006e006b00440065007400610069006c00730000000c0000000800000003000000180000007300730063004f006600660073006500740000000600000000071600000054004200540046006c006100670073000000080000000b000000500200000800000002010c00d041030a000000000101060002010101060000000101060000000101060000007fff0400280000005400680075006e0064006500720062006f006c00740043006f006e006600690067000000240000000102010002000503010004000503020003000503010000000303020004000300240000005400680075006e0064006500720062006f006c007400440052004f004d00000084000000da0158d22c5d820100ac103e5501580001000d000100088181028100000008829101810000000883810481010000088491038101000005850901000586090100028703882003898002ca02cb0d014170706c6520496e632e000c024d6163696e746f736800000000000000000000000000000000000000000000000000000000240000005400680075006e0064006500720062006f006c00740055005500490044000000140000002d6222f93695f955a4bf3b6685f8fba722000000540042005400440050004c006f00770054006f00480069006700680000000800000001000000120000007000610074006800630072000000540000000400000000000000000007001000100005000000000000000000070010001000010000000b000e000e0000000000000002000000000000000000040002000100030000000000000000000700020001001c0000006c0069006e006b00440065007400610069006c00730000000c0000000800000003000000180000007300730063004f006600660073006500740000000600000000071600000054004200540046006c006100670073000000080000000b000000>
| "firmware-abi" = <454649363400>
| "name" = <65666900>
| "firmware-vendor" = <4100700070006c0065000000>
| }
|
+-o kernel-compatibility <class IOService, id 0x100000104, !registered, !matched, active, busy 0, retain 4>
| {
| "name" = <6b65726e656c2d636f6d7061746962696c69747900>
| "x86_64" = <33a0d9e3>
| }
|
+-o runtime-services <class IOService, id 0x100000105, !registered, !matched, active, busy 0, retain 4>
| {
| "name" = <72756e74696d652d736572766963657300>
| "table" = <18eed77800000000>
| }
|
+-o configuration-table <class IOService, id 0x100000106, !registered, !matched, active, busy 0, retain 16>
| | {
| | "name" = <636f6e66696775726174696f6e2d7461626c6500>
| | }
| |
| +-o F2FD1544-9794-4A2C-992E-E5BBCF20E394 <class IOService, id 0x100000107, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <46324644313534342d393739342d344132432d393932452d45354242434632304533393400>
| | "guid" = <4415fdf294972c4a992ee5bbcf20e394>
| | "table" = <00e0ec7800000000>
| | }
| |
| +-o EB9D2D31-2D88-11D3-9A16-0090273FC14D <class IOService, id 0x100000108, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <45423944324433312d324438382d313144332d394131362d30303930323733464331344400>
| | "guid" = <312d9deb882dd3119a160090273fc14d>
| | "table" = <0000ed7800000000>
| | }
| |
| +-o 8868E871-E4F1-11D3-BC22-0080C73C8881 <class IOService, id 0x100000109, !registered, !matched, active, busy 0, retain 4>
| | {
| | "alias" = <414350495f323000>
| | "name" = <38383638453837312d453446312d313144332d424332322d30303830433733433838383100>
| | "table" = <14e0ff7800000000>
| | "guid" = <71e86888f1e4d311bc220080c73c8881>
| | }
| |
| +-o EB9D2D30-2D88-11D3-9A16-0090273FC14D <class IOService, id 0x10000010a, !registered, !matched, active, busy 0, retain 4>
| | {
| | "alias" = <4143504900>
| | "name" = <45423944324433302d324438382d313144332d394131362d30303930323733464331344400>
| | "table" = <00e0ff7800000000>
| | "guid" = <302d9deb882dd3119a160090273fc14d>
| | }
| |
| +-o 49152E77-1ADA-4764-B7A2-7AFEFED95E8B <class IOService, id 0x10000010b, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <34393135324537372d314144412d343736342d423741322d37414645464544393545384200>
| | "guid" = <772e1549da1a6447b7a27afefed95e8b>
| | "table" = <1068ec6500000000>
| | }
| |
| +-o 4C19049F-4137-4DD3-9C10-8B97A83FFDFA <class IOService, id 0x10000010c, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <34433139303439462d343133372d344444332d394331302d38423937413833464644464100>
| | "guid" = <9f04194c3741d34d9c108b97a83ffdfa>
| | "table" =
| | }
| |
| +-o 7739F24C-93D7-11D4-9A3A-0090273FC14D <class IOService, id 0x10000010d, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <37373339463234432d393344372d313144342d394133412d30303930323733464331344400>
| | "guid" = <4cf23977d793d4119a3a0090273fc14d>
| | "table" = <18304a7800000000>
| | }
| |
| +-o 05AD34BA-6F02-4214-952E-4DA0398E2BB9 <class IOService, id 0x10000010e, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <30354144333442412d364630322d343231342d393532452d34444130333938453242423900>
| | "guid" =
| | "table" = <705cec6500000000>
| | }
| |
| +-o EE4E5898-3914-4259-9D6E-DC7BD79403CF <class IOService, id 0x10000010f, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <45453445353839382d333931342d343235392d394436452d44433742443739343033434600>
| | "guid" = <98584eee143959429d6edc7bd79403cf>
| | "table" = <98e7507800000000>
| | }
| |
| +-o A31280AD-481E-41B6-95E8-127F4C984779 <class IOService, id 0x100000110, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <41333132383041442d343831452d343142362d393545382d31323746344339383437373900>
| | "guid" =
| | "table" = <18e8507800000000>
| | }
| |
| +-o 026C0F80-22EC-11E2-AA02-3C07540E73B4 <class IOService, id 0x100000111, !registered, !matched, active, busy 0, retain 4>
| | {
| | "name" = <30323643304638302d323245432d313145322d414130322d33433037353430453733423400>
| | "guid" = <800f6c02ec22e211aa023c07540e73b4>
| | "table" = <00204c7800000000>
| | }
| |
| +-o 674ABEA3-0FE5-11E5-988E-B8E8562CBAFA <class IOService, id 0x100000112, !registered, !matched, active, busy 0, retain 4>
| {
| "name" = <36373441424541332d304645352d313145352d393838452d42384538353632434241464100>
| "guid" =
| "table" = <98ec507800000000>
| }
|
+-o platform <class IOService, id 0x100000113, !registered, !matched, active, busy 0, retain 20>
{
"apple-coprocessor-version" = <00000200>
"boot-chime-on-last-boot" = <00000000>
"Model" = <4d00610063006d0069006e00690038002c003100>
"FSBFrequency" = <00105e5f00000000>
"board-id" = <4d61632d3742413542324446453232444444384300>
"board-rev" = <01>
"system-id" =
"StartupPowerEvents" = <4f00000000000000>
"InitialTSC" =
"IOCompatibilityProperties" = {"IOClass"="IOService","IOName"="platform","IOPath"="IODeviceTree:/efi/platform","system-id"=}
"DevicePathsSupported" = <01000000>
"name" = <706c6174666f726d00>
"SystemSerialNumber" = <43003000370058004e003000500034004a00590057003000>
}

boyan1@Mac-mini-von-Boyan ~ %

@zkennedy137

[zkennedy137]

The compatibility gate shouldn’t be checking your igpu. You may need to enable -wegbeta sometimes if it wasn’t built on the newest lilu it may fail to see -lilubetaall

if that doesn’t work try disabling whatevergreen.kext entirely. If it is disabled enable it and that is your problem.

[zkennedy137]

Since the original problem here RestrictEvents.kext for all intents and purposes is fixed. I opened a new discussion here
#519
Because the thread here is just getting so long. Also if you have issues with SpoofVMM post in the issues forum on the OpenCore Legacy Patcher T2.

@albert-mueller @Medelcartelinc @gandolf243