Talking of reminiscent bit-filtering issues, due to persistence of @startergo and reverse engineering from Vit, we eventually worked out why bit 0x10 (APPLE_INTERNAL) of csr-active-config was having an effect on some hacks (basically: routing to an internal Apple update server, therefore breaking updates), but not on most Macs, when using OpenCore:Little inside info on the setting of the NVRAM variables during boot, although in this case is for thecsr-active-config
:
Modify SIP in normally booted system
I have MacBook Pro (2017) with macOS High Sierra (10.13.6). I have SIP and amfi disabled. I want to enable a part / the majority of SIP (e.g. csrutil enable --without fs) without having to reboot i...apple.stackexchange.com
In x86 (but not M1), whether a system is Apple Internel or not is baked into boot.efi and the filtering out of this bit is done unconditionally in there on consumer builds, so the 0x10 bit should never be visible (via get_csr_active_config() sys call) to anything in-OS, in any consumer build, whether or not it is set in NVRAM. (The reason it was not working like this on many hacks (but essentially no Macs, even when using OC) was a bug that Vit found and fixed in OpenCore, which was pushing the original value back through to macOS via a hook (when ProvideCustomSlide was enabled), after boot.efi had already cleared it.)
So in that case if you look in NVRAM (even in-OS) the bit looks set, but if you look at the effect it has (get_csr_active_config()) it looks like it was never set.
Last edited: