Installing new macOS on unsupported hardware (OCLP patcher and others)

[miliuco]

@deeveedee

I don't have such card, be sure that I would be happy to be able to collaborate with you. When tests are finished, we hope a very interesting how to about BCM 94352HMB and Sonoma 👏

Edited August 5, 2023 by miliuco

[deeveedee]

@miliuco I grepped the OCLP source and see that OCLP commonly uses IONameMatch to identify properties for patching.  So far, my own testing is going well, but I'd feel more confident in my solution if someone else tested with me.

[deeveedee]

For those who have a different Wi-Fi device that is not detected by OCLP 0.6.9 (not a BCM 94352HMB), you should be able to create your own patch by following my instructions here (see EDIT2).

[mnfesq]

On 8/5/2023 at 8:39 AM, deeveedee said:

For those who have a different Wi-Fi device that is not detected by OCLP 0.6.9 (not a BCM 94352HMB), you should be able to create your own patch by following my instructions here (see EDIT2).

 

I have the Dell DW1560 wifi card with the Broadcom 4352 chipset.  I used @deeveedee's patching method and it worked for me.  But I use a custom DSDT and it shows my device as pci14e4,43a0.  I don't know if that is a spoof or not.  Either way, I used @deeveedee's SSDT that spoofed the wifi card to 4353 and it works.  BTW, at his suggestion, I removed the patch changing the device name from PSXS to ARPT and then edited the SSDT to remove the references to ARPT and replaced them with PSXS.  All is working just fine.

[miliuco]

@mnfesq

Your wifi is 14e4:43b1, my Fenvi is 14e4,43a0, yours is detected now like a BCM4360. 

[deeveedee]

@mnfesq I have consolidated all of my Wi-Fi spoofing / OCLP patching posts into a single post here.  With my simplified Wi-Fi spoofing, macOS will detect your Wi-Fi as its original (unspoofed) device.  My simplified Wi-Fi spoofing (only changing Wi-Fi IOName and not renaming PXSX) affects only OCLP detection (for modern_wifi patching) and does not affect the way macOS detects your Wi-Fi.

 

If after following my revised instructions and simplified Wi-Fi patching here, you are still seeing that macOS is detecting your Wi-Fi as something other than its original Wi-Fi identity, please post your EFI so we can examine and debug.

 

EDIT: @mnfesq  I think I may have misunderstood your post.  I thought you were still having problems with the way your Wi-Fi is being detected after spoofing Wi-Fi with my ACPI patch, but after re-reading your post, it appears that my simplified ACPI patch (only changing IOName) fixed your issue.  Forgive me if I misunderstood.  If you are still having issues, just ask for help.  Thanks.

Edited August 7, 2023 by deeveedee

[mnfesq]

53 minutes ago, miliuco said:

@mnfesq

Your wifi is 14e4:43b1, my Fenvi is 14e4,43a0, yours is detected now like a BCM4360. 

 

That is exactly right.  Now that I have Sonoma patched with OCLP, I can disable the SSDT that spoofs my wifi to 4353.  I suppose I could remove the DSDT spoof to 4360 and just use the native PID.

[deeveedee]

1 hour ago, mnfesq said:

 

That is exactly right.  Now that I have Sonoma patched with OCLP, I can disable the SSDT that spoofs my wifi to 4353.  I suppose I could remove the DSDT spoof to 4360 and just use the native PID.

Just to clarfiy, the new patching method affects only OCLP (allowing OCLP to detect your Wi-Fi for patching).  It does not affect the way macOS detects your Wi-Fi, so macOS will detect the original, unspoofed Wi-Fi without removing the ACPI patch.

[mnfesq]

3 hours ago, deeveedee said:

Just to clarfiy, the new patching method affects only OCLP (allowing OCLP to detect your Wi-Fi for patching).  It does not affect the way macOS detects your Wi-Fi, so macOS will detect the original, unspoofed Wi-Fi without removing the ACPI patch.

 

First off, I removed the spoof in my DSDT that makes macOS recognize my wifi card as 4360 instead of 4352.  @miliuco was correct that my native PID is pci14e4,43b1. Post-patch, wifi worked for that device in Sonoma and it also works in Ventura.

 

I suspect that later versions of OCLP will recognize more device IDs so that spoofing will be unnecessary but, for now, I will keep my SSDT with the spoof info in my ACPI folder and will keep it disabled unless I need to re-apply OCLP patches, in which case, if needed, I can re-enable it.

[deeveedee]

14 hours ago, mnfesq said:

I suspect that later versions of OCLP will recognize more device IDs so that spoofing will be unnecessary but, for now, I will keep my SSDT with the spoof info in my ACPI folder and will keep it disabled unless I need to re-apply OCLP patches, in which case, if needed, I can re-enable it.

 

OCLP Devs have made it very clear that they are supporting only real Macs and now OCLP may include a warning that hackintoshes are not supported.  If the OCLP devs do add non-Mac Wi-Fi IONames to their supported device list, that would definitely be a welcomed departure from their current approach. 👍

 

EDIT: I've seen comments in other forums that imply that there is a version of OCLP that is for hackintoshes and a version that is for real Macs.  There is no version of OCLP for hackintoshes (unless modified by someone other than OCLP Devs, e.g., the modification to force modern_wifi patches).

Edited August 8, 2023 by deeveedee

[matxpa]

2 hours ago, deeveedee said:

... and now OCLP includes a warning that hackintoshes are not supported. ...

Hi

Not now may be in few days if khronokernel accepts the PR (#1090) from Jazzzny

  content available in
 (       repo :                    Clover-Legacy-Patcher
        branch :                hackintosh-warn
        component :        .../resources/wx_gui/gui_main_menu.py  (code lines 213 to 225) )

Regards

 

And it would look like this ...

 

Spoiler

 

Edited August 8, 2023 by matxpa
Add Pic

[deeveedee]

14 minutes ago, matxpa said:

Hi

Not now may be in few days if khronokernel accepts the PR (#1090) from Jazzzny

  content available in
 (       repo :                    Clover-Legacy-Patcher
        branch :                hackintosh-warn
        component :        .../resources/wx_gui/gui_main_menu.py  (code lines 213 to 225) )

Regards

Thanks!  I will modify my previous post.

[Stefanalmare]

I have an iMac 2010 with first generation processor. Intel Power Gadget support start with 2d generation. I want to monitories the CPU frequencies. Anybody knows a solution, apart from terminal command?

Edited August 14, 2023 by Stefanalmare

[cyberjunkie]

I have a few questions regarding the installation of unsupported Mac OS versions on an old Mac Pro 3,1 (2008).
For now I'm starting with two simple questions.
First I guess I have to report about the current state of affairs.

Hardware wise, I upgraded the RAM to 22GB (from the original configuration of 6GB), all modules 800Mhz.
At first I used an old AMD HD 5770 with Mac firmware, then I installed an XFX FX 580 GTS (with 8GB video RAM, oddly recognised as 6GB),

using a dual GPU configuration, and now I finally managed to get rid of the old graphic card, using the boot picker provided by OCLP.
Before trying to install Catalina I removed the wireless module from the motherboard, but the Bluetooth module didn't come out.

The screws were stuck and eventually I ended up stripping one of them. I found that I could disable it plugging an old USB Bluetooth dongle.

Now Bluetooth seems to work.
I have 5 HDs, two SSDs and three magnetic. The fifth is a SATA SSD lying inside the CD/DVD drawer, along a PATA DVD reader/burner that replaced the (broken) original one.

I have installed High Sierra, Mojave and Catalina using DosDude patcher.
The only installation that gave no problems at all was High Sierra. Originally the computer was gifted to me with Yosemite, I immediately updated to El Capitan but it was practically unusable. No compatible browser supporting HTTPS certificates.

I decided to just jump Sierra and installed High Sierra using DosDude patcher on a different HD.
Installing Mojave was more difficult, but I ended up with a working installation that I still keep to use 32bit apps.
Catalina was a real nightmare. I regularly ended up back at step one, restarting the installation process.
I tried almost everything. I swapped graphic cards (powering the 580 externally), disks, USB/DVD install medium, etc etc.
In the end I managed to have Catalina installed, but there must be an additional EFI partition , because it can be booted from two separate options in the boot picker.

One has the label of the disk it sits on, and the other looks different from all the others and is called "EFI".
While I was busy with all that, I ordered a Fervi FV8303 PCI-E card with a recent wireless a/b/g/n chip and a Bluetooth 4.0 chip (check the EDIT at the end about it).
Yesterday I also got a dual mini 6-pin to standard 8-pin GPU power cable, that allowed me to get rid of the external power brick.
Now I have Mojave and Catalina on two separate disks, both available from the OCLP boot picker.
Big Sur is installed on two other disks. One is the main install on the bigger SSD, the other one has a minimal installation of Big Sur, and has OCLP EFI boot installed.

This way I don't need to have the USB thumb drive to boot the various operative systems from the boot picker.
With the present configuration the computer boots off a smaller (64GB) SSD disk that sits on top of the CD/DVD drive, using a molex>SATA power adapters,

and one of the two SATA cables that I routed through a small hole, and are connected to the two SATA connectors that are available on the mainboard.

I want to replace the 64GB son, using a new 1TB SSD disk that could be used for a Windows 11 installation, or maybe Monterey...

 

I hope my lengthy description has given an accurate picture of my current config. Here comes the first question:
can I also install OCLP EFI boot on the main SSD disk that hosts the main, full scale installation of Big Sur?

In practice, I'm asking if multiple Open Core EFI boot partitions can coexist in the same system?

If I can do that, I could remove one of the two disks without any adverse effect, and still have a bootable Open Core boot that gives me the boot picker..

 

Second question:
When I was using El Capitan (and probably also High Sierra) I had one of the four Mac Pro main disk drawers dedicated to a Windows 11 installation.

Everything worked great, using the original AMD HD 5770 GPU. I could either boot MacOS or Win11.
Since then I took the drawer out of the case, to avoid potential interactions with all my tentatives to install successive MacOS versions.
Today I tried to put the disk back, and surprise surprise, the Open Core boot picker cannot see it!
Of course if I load Big Sur the disk is perfectly visible (and readable).
Am I missing something? Is there a simple way to make the Win 11 installation available again?
I kind of remember I read that somebody bricked his Mac Pro booting off a Windows disk with EFI boot.

I find it strange. Is it true? Any specific caveat I should be aware of?

 

EDIT:

It seems that the FV8303 PCI-E card won't work on my Mac Pro 3,1.

I just purchased an FV-T919, which has four (!) antennas and also comes with the cable to connect the card to a USB header. This card is sold as Mac/Hackintosh compatible, so I guess I will be OK with it.

 

 

Thanks in advance to whoever will be so gentle to answer my questions.

Cheers

Paolo

Edited September 30, 2023 by cyberjunkie

[deeveedee]

Admins - please tolerate and allow this post in multiple threads. It may hurt feelings and ruffle feathers - I'm beyond that and can't help that.

 

I am pleased with the Dev responses in the OCLP Security Thread. One of my reasons for assisting with the creation of the OCLP Thread was to have a public repository of OCLP security issues until messaging and warnings are implemented. Unfortunately, the Dev responses suggest more potential security vulnerabilities in OCLP than I had anticipated.

 

I will not be using OCLP to apply post-install patches on any 'production' systems where my private credentials, secure data and digital identity need to be protected and could be at risk.

 

There are many who are angry with me because I had the audacity to challenge the Devs and their generosity. That makes no sense. This is not personal, not a popularity contest, not a game of playing nice. This is serious and those who are treating the issue as a hobby and a game should only be using OCLP in a no-risk, hobby environment to play games.

 

I accept responsibility for helping to promote the use of OCLP. I am now trying to make all aware of the dangers.  Computer/data security happens to be my area of expertise and I recognize that there will be challenges and claims of overdoing it by those who have no idea what they are talking about.

 

BTW: This is so serious that I am suspicious of anyone who tries to clutter the OCLP thread with tangential garbage or makes attempts to damage my credibility or that of the OCLP security thread. There are people who want security vulnerabilities to remain unknown, unaddressed and fully exploitable. They will go to great lengths to win trust and popularity while hacking your data and stealing your identity. Ask Sam Bankman-Fried and Bernie Madoff how their customers loved them (until they didn't).

 

In this case, we must look a gift horse in the mouth. How quickly we have forgotten the lessons of the Trojan Horse and plenty of more current examples that should make us at least cautious.

[LockDown]

On 5/31/2023 at 9:03 AM, deeveedee said:

With the introduction of AMFIPass.kext by the OCLP team, we now have a way to keep AMFI enabled when we install the legacy non-metal and metal kexts.  This development gets us closer to having perfect operation of new versions of macOS on legacy Macs and Hacks.

 

EDIT: It should be noted that non-metal l

In short, AMFIPass.kext & amfi=0x80 are the same?

Edited October 26, 2023 by LockDown

[miliuco]

4 hours ago, LockDown said:

In short, AMFIPass.kext & amfi=0x80 are the same?

No. The boot arg disables AMFI completely. The kext allows to have SIP disabled but AMFI enabled. 

[miliuco]

Sonoma 14,1 successfully installed on iMac16,2 (iMac 21" late 2015). OCLP 1.1.0. Updated from Ventura 13.6.1.

Root patches for Broadwell iGPU and Modern Wireless.

So far, everything seems to work fine.

Spoiler

 

[Cyberdevs]

@Stefanalmare, @deeveedee, @MacNB, @Slice, @cankiulascmnfye and others

I've created a new topic for discussing sleep/wake issue in older Macs here:

 

[miliuco]

Good afternoon. Those who have installed OCLP 1.3.0. Are you seeing a slow closing of the app, with the cursor bussy for 10-15 seconds?

This is happening to me in the hack.

Going back to a previous version, the app closes normally.

 

Edited December 14, 2023 by miliuco

[eSaF]

42 minutes ago, miliuco said:

Good afternoon. Those who have installed OCLP 1.3.0. Are you seeing a slow closing of the app, with the cursor bussy for 10-15 seconds?

This is happening to me in the hack.

Going back to a previous version, the app closes normally.

 

Didn't see or notice any different in this  OCLP 1.3.0. version but will test and report.

 

I Just launch the new OCLP 1.3.0. version and done a re-patch on my system and the whole operation took 5 seconds including the message to re-boot.

Edited December 14, 2023 by eSaF

[stephenstud]

Good Morning Everyone😁

I have a Macbook Pro 8,1 running on OpenCore 1.3.0. After updating Sonoma, I lost wireless. I have run the post install menu a few times with no luck. I have Vmware Fusion running Win 11, with no network issues.
Does anyone know what I did wrong?
Can I fix this, or do I need to wipe?

Thank you for any help.

[deeveedee]

@stephenstud InsanelyMac is focused on hackintoshes.  While you will find people here who can help, you might want to post your question in MacRumors which is focused on real Macs.  Look here for help with installing Sonoma on unsupported Macs.

 

EDIT: Wow - I just noticed that you posted almost a year ago.  Oh well, better late than never? 

Edited October 23 by deeveedee

[deeveedee]

For those who use boot-arg amfi=0x80 (equivalent to boot-arg amfi_get_out_of_my_way = 0x1), I was helping someone in MacRumors and noticed that OCLP inserts boot-arg amfi=0x80 (when "Disable AMFI" checked in OCLP GUI) only when "Disable Library Validation" is also checked in the OCLP GUI.  If "Disable Library Validation" is unchecked, amfi=0x80 will not be inserted into the OC config.plist boot-args when "Disable AMFI" is checked.  Note that checking "Disable Library Validation" in OCLP GUI causes OCLP to insert a Kernel Patch which you can view by examining an OCLP-generated OC EFI.

 

I first noticed this relationship between OCLP's "Disable AMFI" and "Disable Library Validation" in OCLP 1.4.3, but it may have been this way in earlier versions.

Edited October 24 by deeveedee

[Matgen84]

19 hours ago, deeveedee said:

For those who use boot-arg amfi=0x80 (equivalent to boot-arg amfi_get_out_of_my_way = 0x1), I was helping someone in MacRumors and noticed that OCLP inserts boot-arg amfi=0x80 (when "Disable AMFI" checked in OCLP GUI) only when "Disable Library Validation" is also checked in the OCLP GUI.  If "Disable Library Validation" is unchecked, amfi=0x80 will not be inserted into the OC config.plist boot-args when "Disable AMFI" is checked.  Note that checking "Disable Library Validation" in OCLP GUI causes OCLP to insert a Kernel Patch which you can view by examining an OCLP-generated OC EFI.

 

I first noticed this relationship between OCLP's "Disable AMFI" and "Disable Library Validation" in OCLP 1.4.3, but it may have been this way in earlier versions.

Hi @deeveedee Thanks a lot for this clear explanation. Fortunalty, for not advanced users like me, "Disable AMFI" and "Disable Library Validation" are checked by default in OCLP settings. I generate an EFI folder to explore OCLP config.plist for my old Ivybridge.
Have a nice day 😊