macOS 10.15 Catalina on Unsupported Macs

[jackluke]

Then repeated the boot part of the exercise.
- verified that the .libraryvalidation.plist is in place on the clean-installed dsik and on the over-installed.
- reset the nvram
- the clean-installed doesn't boot, with the AMFI messages shown in single user mode.
- csrutil status in single user mode shows SIP disabled, but there is no csr-related entry in nvram
- the over-installed disk boots nevertheless...

Then in terminal of the bootable USB installer. Also here csrutil status shows SIP disabled. Still did csrutil disable. Now there is this entry in nvram: csr-active-config w%00%00%00.

Now booting works again with both disks (clean-installed and over-installed).

After csrutil disable I have the exactly same entry for nvram -p : csr-active-config w%00%00%00

This key means that SIP is correctly disabled on an EFI mac

and of course for me any amfi_get_out_of_my_way=1 disabling method (nvram, com.apple.boot.plist , disablelibraryvalidation.plist) worked too.

So now that through "csrutil disable" from a recovery terminal environment you can use "amfi_get_out_of_my_way=1" in nvram when you need, on next catalina ota update you could continue testing the catalinaswufix that includes all the amfi methods too, provided that SIP is correctly disabled.

 

[Flacko]

I haven't found a way to debug the origin of the window closing as it doesn't seem to emit any errors or warnings into the system log. If it works on the MacPro 5,1, that might suggest that Apple is using some SSE 4,2 opcodes in the TV.app.

Same bug here. TV app window opens briefly and plays about a second. This is with a cMP 4.1>5.1 with no patches (just using nvram arg) and a Sapphire RX580. Using 10.15.4 - update went smoothly using patcher 1.3.1 and install to this machine.

 

[hvds]

After csrutil disable I have the exactly same entry for nvram -p : csr-active-config w%00%00%00

This key means that SIP is correctly disabled on an EFI mac

and of course for me any amfi_get_out_of_my_way=1 disabling method (nvram, com.apple.boot.plist , disablelibraryvalidation.plist) worked too.

So now that through "csrutil disable" from a recovery terminal environment you can use "amfi_get_out_of_my_way=1" in nvram when you need, on next catalina ota update you could continue testing the catalinaswufix that includes all the amfi methods too, provided that SIP is correctly disabled.

Thanks jackluke.
Looking forward to try OTA again when betas of 10.15.5 will arrive.
I guess it will work fine on my internal SATA SSD.
On the external SSD I would probably have again the issue of access to USB failing in one of the OTA phases (with my mid 2009 machine). I'll then try to overcome this hurdle, maybe with your advice, and if I don't succeed, hook this SSD on SATA temporarily to keep my production SSD free from betas.

(MBP5,2 17" mid 2009, 2.8GHz T9600, 8GB, APFS ROM patch applied, Samsung SSD 840/860 EVO with APFS. Catalina 10.15.4)

 

[kral84]

my Nvidia GTX 860 has an black screen ... i have testd with 1.3.1 and 1.3.2 ... i have no efi but after 10 sec the screen came on ... but on 10.15.4 complete black ... i wait for an easy solution..

 

[jackluke]

About AMFI, SIP and 10.15.4 for non-metal mac , I just tried this non-clever test and I anticipate it worked (this is just an experiment so don't use it):

1) Using any of the known AMFI disabling method (amfi_get_out_of_my_way=1 or ASentientBot disablelibraryvalidation.plist)

2) Using this @ASentientBot patched 10.15.4 boot.efi and copied it (overwrite) in this path:

/Volumes/Preboot/UUID-Catalina-numbers/System/Library/CoreServices/

3) Removing from /Library/Extensions/SIPManager.kext and rebuild a kextcache without it

4) Reset PRAM (re-enable SIP) or from a macOS recovery or USB Installer terminal : csrutil enable


Result: Catalina 10.15.4 (with AMFI disabled) using non-metal patches boot correctly to GUI and boot process seems even faster.

This method allow to those who use multiple macOS installation to keep SIP enabled on their "supported macOS" while keep SIP correctly disabled only on the 10.15.4 aka the AMFI Catalina release.

To summarise: this is a valid alternative to SIPManager.kext (that from 10.15.4 has issues with AMFI) , thanks @ASentientBot .

edit:
to mount preboot from terminal:
sudo mount -uw / ; killall Finder ; diskutil mount Preboot ; open /Volumes/Preboot/

 

[HouseofG]

No working video with Zoom on non-metal patched Macs: this is what I did on my Catalina-patched MacMini 2011 and MacBook 2009.
Zoom up to version 4.4.53909.0617 installed a mini-webserver which was found to be vulnerable to hackers. As of version 4.4.53932.0709 this webserver was removed and a different approach implemented. Alas, this version does not show video on non-metal patched Macs with Mojave or Catalina. Sentientbot posted a link to this earlier version, but that is not very safe. There is a workaround:

* Uninstall Zoom with the built-in uninstaller
* Install Zoom 4.4.53909.0617 (see link in post from Sentientbot #8.969: https://d11yldzmag5yn.cloudfront.net/prod/4.4.53909.0617/Zoom.pkg )
* It will automatically start, after that close zoom.us
* Right-click on the app zoom.us, ‘Show package contents’, go to folder Frameworks: remove item ‘Zoomopener’
* Use terminal to remove ~/.zoomus or have Finder show hidden files (Command-Shift-Dot), go to your home-directory and remove folder .zoomus
* Restart Zoom and check your video, it should all work by now

One drawback (as expected) is that clicking a zoom meeting-link you receive will not open Zoom automatically. No big issue: you can use the meeting number+password for that. The other drawback is this version of Zoom not supporting a nice dark mode. All other functionality is there and working.

Thank you! I needed to get my old 17" 2010 MBP set up for my girls to do Zoom remote classes with their teachers. This did the trick. You're a lifesaver!

 

[jackluke]

No working video with Zoom on non-metal patched Macs: this is what I did on my Catalina-patched MacMini 2011 and MacBook 2009.
Zoom up to version 4.4.53909.0617 installed a mini-webserver which was found to be vulnerable to hackers. As of version 4.4.53932.0709 this webserver was removed and a different approach implemented. Alas, this version does not show video on non-metal patched Macs with Mojave or Catalina. Sentientbot posted a link to this earlier version, but that is not very safe. There is a workaround:

* Uninstall Zoom with the built-in uninstaller
* Install Zoom 4.4.53909.0617 (see link in post from Sentientbot #8.969: https://d11yldzmag5yn.cloudfront.net/prod/4.4.53909.0617/Zoom.pkg )
* It will automatically start, after that close zoom.us
* Right-click on the app zoom.us, ‘Show package contents’, go to folder Frameworks: remove item ‘Zoomopener’
* Use terminal to remove ~/.zoomus or have Finder show hidden files (Command-Shift-Dot), go to your home-directory and remove folder .zoomus
* Restart Zoom and check your video, it should all work by now

One drawback (as expected) is that clicking a zoom meeting-link you receive will not open Zoom automatically. No big issue: you can use the meeting number+password for that. The other drawback is this version of Zoom not supporting a nice dark mode. All other functionality is there and working.

Well done @ErkSmeijer !

Using these from a Catalina terminal:

rm -r /Applications/zoom.us.app/Contents/Frameworks/ZoomOpener.app
rm -r  ~/.zoomus

fixed the Camera and Microphone allowing on 10.15.4 Catalina "Security & Privacy" Privacy tab. Adding it correctly to the Privacy permissions list.

 

[jhowarth]

I guess this AMFI issue is also related on how the kextcache (prelinkedkernel) is build from the post install patches, and it seems that “csrutil disable” is more effective from a macOS Recovery than an USB Patcher, I used a patched APFS Catalina Recovery (not the usb installer), running csrutil from HighSierra Recovery HD worked too for 10.15.4 .

I'm a bit confused by this discussion of 'csrutil disable'. Is this for machines which don't have SIP disabled yet? If your machine already had SIP disabled from a prior installation of patched Mojave or Catalina, I would think it would be a total non-issue, no?
[automerge]1585402966[/automerge]

After csrutil disable I have the exactly same entry for nvram -p : csr-active-config w%00%00%00

This key means that SIP is correctly disabled on an EFI mac

and of course for me any amfi_get_out_of_my_way=1 disabling method (nvram, com.apple.boot.plist , disablelibraryvalidation.plist) worked too.

So now that through "csrutil disable" from a recovery terminal environment you can use "amfi_get_out_of_my_way=1" in nvram when you need, on next catalina ota update you could continue testing the catalinaswufix that includes all the amfi methods too, provided that SIP is correctly disabled.

Silly question, wouldn't having the patched installer execute 'sudo nvram csr-active-config=w%00%00%00" be a viable replacement for executing "csrutil disable"?

 

[jackluke]

I'm a bit confused by this discussion of 'csrutil disable'. Is this for machines which don't have SIP disabled yet? If your machine already had SIP disabled from a prior installation of patched Mojave or Catalina, I would think it would be a total non-issue, no?
[automerge]1585402966[/automerge]


Silly question, wouldn't having the patched installer execute 'sudo nvram csr-active-config=w%00%00%00" be a viable replacement for executing "csrutil disable"?

Since you are using a Metal GPU and almost surely you have this /Library/Extensions/SIPManager.kext preloaded in kextcache you don't encountered these issues , but for non-metal gpu from 10.15.4 the way how to disable SIP is an issue.

I don't think apple will let to disable SIP simply with an "nvram csr-active-config command", because when SIP is enabled nvram is protected from storing any values.

 

[jhowarth]

Since you are using a Metal GPU and almost surely you have this /Library/Extensions/SIPManager.kext preloaded in kextcache you don't encountered these issues , but for non-metal gpu from 10.15.4 the way how to disable SIP is an issue.

I don't think apple will let to disable SIP simply with an "nvram csr-active-config command", because when SIP is enabled nvram is protected from storing any values.

What is the mechanism that couples Metal graphics to SIPManager.kext's functionality? Is there some system library included in the legacy video patches that breaks that kernel extension?

 

[jackluke]

What is the mechanism that couples Metal graphics to SIPManager.kext's functionality? Is there some system library included in the legacy video patches that breaks that kernel extension?

Till 10.15.3 SIPManager.kext worked correctly, but from 10.15.4 apple enforced on non-apple signature framework some AMFI checks incompatible with SIPManager.kext , instead using "csrutil disable" the "amfi skip checks" work.

Metal GPU can boot with AMFI enabled, but if you attempt to use for example Night Shift patch (that is a patched CoreBrightness.framework with non-apple signature) , you also could incur in this AMFI non-booting issue.

 

[K two]

I guess this AMFI issue is also related on how the kextcache (prelinkedkernel) is build from the post install patches, and it seems that “csrutil disable” is more effective from a macOS Recovery than an USB Patcher, I used a patched APFS Catalina Recovery (not the usb installer), running csrutil from HighSierra Recovery HD worked too for 10.15.4 .

Booted from the USB patcher. Ran Terminal, entered only "csrutil disable" saw confirmed, selected the dot4 installed partition, reboot. WHAM!! Success!🤪 No AMFI demote since the EEPROM is unpatched MCP79, dosdude1 sez no. The observation that AMFI hooks are not present in barefoot machines is valid. So far, everything we use works.

Hope this helps in the quest? Dot4 seems as snappy as dot3 on this Mini3,1. Haven't rebooted the install, yet. Will advise further.🥳

 

[jhowarth]

Till 10.15.3 SIPManager.kext worked correctly, but from 10.15.4 apple enforced on non-apple signature framework some AMFI checks incompatible with SIPManager.kext , instead using "csrutil disable" the "amfi skip checks" work.

Metal GPU can boot with AMFI enabled, but if you attempt to use for example Night Shift patch (that is a patched CoreBrightness.framework with non-apple signature) , you also could incur in this AMFI non-booting issue.

I'm not seeing any such problem here on a fresh install of patched 10.15.4 using Catalina Patcher 1.3.1 after installing and enabling the patched Night Shift. It reboots fine with no issues.

 

[jackluke]

Booted from the USB patcher. Ran Terminal, entered only "csrutil disable" saw confirmed, selected the dot4 installed partition, reboot. WHAM!! Success!🤪 No AMFI demote since the EEPROM is unpatched MCP79, dosdude1 sez no. The observation that AMFI hooks are not present in barefoot machines is valid. So far, everything we use works.

Hope this helps in the quest? Dot4 seems as snappy as dot3 on this Mini3,1. Haven't rebooted the install, yet. Will advise further.🥳
View attachment 901949

Well done, but since you booted the 10.15.4 on non-metal gpu with acceleration, surely you have at least one "AMFI disabler" installed, probably you have this file: /Library/Preferences/com.apple.security.libraryvalidation.plist

I mean on any EFI Mac with a non-metal gpu with OpenGL acceleration, at least an AMFI disable method is mandatory.

 

[K two]

Well done, but since you booted the 10.15.4 on non-metal gpu with acceleration, surely you have at least one "AMFI disabler" installed, probably you have this file: /Library/Preferences/com.apple.security.libraryvalidation.plist

I mean on any EFI Mac with a non-metal gpu with OpenGL acceleration, at least an AMFI disable method is mandatory.

[automerge]1585413020[/automerge]
Yes, /Library/Preferences/com.apple.security.libraryvalidation.plist is there from the v1.3.1 patcher install. Will try a reboot, now.

 

[jhowarth]

[automerge]1585413020[/automerge]

Yes, /Library/Preferences/com.apple.security.libraryvalidation.plist is there from the v1.3.1 patcher install. Will try a reboot, now.

It seems really bizarre that Metal vs non-Metal could have any impact on the functionality of "csrutil disable". Am I correct to say that we don't have any reports of that failing on Metal hardware?

 

[jackluke]

I'm not seeing any such problem here on a fresh install of patched 10.15.4 using Catalina Patcher 1.3.1 after installing and enabling the patched Night Shift. It reboots fine with no issues.

This is strange since CoreBrightness patched has non-apple signature , then AMFI is restricted only for CoreDisplay and SkyLight frameworks that contribute to Metal GPU acceleration.

It seems really bizarre that Metal vs non-Metal could have any impact on the functionality of "csrutil disable". Am I correct to say that we don't have any reports of that failing on Metal hardware?

Yes, with a Metal GPU you can have AMFI enabled so you don't need to disable it.

AMFI enabled ≠ SIP enabled

 

[hal90088]

In my macbook 5.2 I tryed to apply OSX 10.15.4. At first boot i noticed that the progress bar stoped, so i rebooted with the USB installer and in terminal I wrote the sentence "csrutil disable" and I restarted the computer.

I think that all is now working, except this things.

- The Facetime app works, but I can't see my webcam. It's strange, because in Photo booth the cammera works perfect.

- The Music app doesn't want to start. It shows me an error

I don't use TV application, so i didn't try it.

¿Is there any patch for this troubles with facetime and music app?

I'll wait some weeks to update my other computers. This little computer is great to make some tests, but in my other "production" computers I want to apply the patch when it be more tested.

Regards.

 

[jhowarth]

This is strange since CoreBrightness patched has non-apple signature , then AMFI is restricted only for CoreDisplay and SkyLight frameworks that contribute to Metal GPU acceleration.



Yes, with a Metal GPU you can have AMFI enabled so you don't need to disable it.

AMFI enabled ≠ SIP enabled

On my MacPro 3,1 with GTX680 under 1.3.1 patched 10.15.4, I am seeing...

% sudo csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled
BaseSystem Verification: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Is there a matching way to obtain AMFI status on a running machine?

 

[chris1111]

➣ Legacy Video Patch Package
install now for macOS Catalina 10.15.4+ /Library/Preferences/com.apple.security.libraryvalidation.plist

 

[jackluke]

Is there a matching way to obtain AMFI status on a running machine?

You can notice AMFI checks booting in verbose mode, but there is no known status command to verify it.

 

[jhowarth]

You can notice AMFI checks booting in verbose mode, but there is no known status command to verify it.

Okay. I was wondering if it would be one of those things where machines with upgraded boot ROMs from Apple would have a mechanism. Maybe in 10.16, however I have severe doubts that the unsupported patching will work there even if Apple retains some support for legacy kernel extensions.

 

[K two]

Anyone else seeing the "deleted" process running constantly in dot4? Not seen in dot3.

 

[serafin79]

Anyone else seeing the "deleted" process running constantly in dot4? Not seen in dot3.

not that I'm seeing

 

[honestone33]

not that I'm seeing

View attachment 902006

So, are you running OS 10.15.4? And if so, how did you "get there", ie, via just the "delta" Updater, the Combo Updater, or a full. clean installation?