Experimental Fork of OCLP 3.0.0 Nightly – modern Wi-Fi, AWDL and AppleHDA Fully Working under Tahoe

[kgp]

3 hours ago, MakAsrock said:

I want to ask you friends: Should I continue to refine the OCLP-Plus Tahoe Patch Set or freeze it in its current form?

 

My dear friend,

 

you should absolutely continue refining OCLP-Plus — without any doubt or reservation from my side. I fully support your work and the progress you have made.

At the same time, the recent transition from OCLP 3.1.7 Nightly to OCLP-Plus introduces structural changes that make it somewhat more challenging for me to keep my documentation and references fully aligned, or to continue our collaboration in the same way as over the past months (external branch and thread). For this reason, I will currently maintain my own stable baseline separately, while continuing to follow your work with great interest.

From a user perspective, I would also suggest considering a slightly more consolidated release rhythm, as very frequent updates can make it harder for users to follow and test consistently.

 

For transparency and fairness within the community, I would like to add a small remark for context:

1.) To my understanding, some of the recent improvements regarding APFS and modified HFS+ mounting in OCLP-Pus build upon earlier implementations from OCLP-Mod 3.1.5 by @laobamac_yyds.
2.) Similarly, the use of -amfipassbeta with OCLP 3.0.0 Nightly (amfipassbeta variant) is enabled through the PatcherSupportPkg provided by @laobamac_yyds, which I integrated into my preserved 3.0.0 repository, after adding AppleHDA of macOS 26.0 Beta 1 to the PatcherSupportPkg (PatcherSupportPkg-laobamac), without making any additional changes to the patcher code itself. A comparable approach now appears to be used in OCLP-Plus to avoid relying on amfi=0x80.

3.) In addition, the stability and functionality of OCLP 3.1.7 Nightly also benefited from extensive testing and feedback on my side through our detailed discussions via PM.

4.) I am not in a position to judge whether all other recent modifications in OCLP-Plus are necessary. I can only confirm that OCLP 3.0.0 Nightly (amfipassbeta variant) continues to work flawlessly with macOS 26.4 using the boot argument -amfipassbeta, when the code is kept closely aligned with the preserved lzhoang2801 snapshot from December 24, 2025, requiring only adjustments to the PatcherSupportPkg.

 

This is simply meant as clarification to provide proper context to the development path — and of course, many thanks to @laobamac_yyds for his awesome work all over the recent months.

 

Hugs,
KGP 🤗

Edited March 23 by kgp

[MakAsrock]

3 hours ago, kgp said:

 

My dear friend,

 

you should absolutely continue refining OCLP-Plus — without any doubt or reservation from my side. I fully support your work and the progress you have made.

At the same time, the recent transition from OCLP 3.1.7 Nightly to OCLP-Plus introduces structural changes that make it somewhat more challenging for me to keep my documentation and references fully aligned, or to continue our collaboration in the same way as over the past months (external branch and thread). For this reason, I will currently maintain my own stable baseline separately, while continuing to follow your work with great interest.

From a user perspective, I would also suggest considering a slightly more consolidated release rhythm, as very frequent updates can make it harder for users to follow and test consistently.

 

For transparency and fairness within the community, I would like to add a small remark for context:

1.) To my understanding, some of the recent improvements regarding APFS and modified HFS+ mounting in OCLP-Pus build upon earlier implementations from OCLP-Mod 3.1.5 by @laobamac_yyds.
2.) Similarly, the use of -amfipassbeta with OCLP 3.0.0 Nightly (amfipassbeta variant) is enabled through the PatcherSupportPkg provided by @laobamac_yyds, which I integrated into my preserved 3.0.0 repository, after adding AppleHDA of macOS 26.0 Beta 1 to the PatcherSupportPkg (PatcherSupportPkg-laobamac), without making any additional changes to the patcher code itself. A comparable approach now appears to be used in OCLP-Plus to avoid relying on amfi=0x80.

3.) In addition, the stability and functionality of OCLP 3.1.7 Nightly also benefited from extensive testing and feedback on my side through our detailed discussions via PM.

4.) I am not in a position to judge whether all other recent modifications in OCLP-Plus are necessary. I can only confirm that OCLP 3.0.0 Nightly (amfipassbeta variant) continues to work flawlessly with macOS 26.4 using the boot argument -amfipassbeta, when the code is kept closely aligned with the preserved lzhoang2801 snapshot from December 24, 2025, requiring only adjustments to the PatcherSupportPkg.

 

This is simply meant as clarification to provide proper context to the development path — and of course, many thanks to @laobamac_yyds for his awesome work all over the recent months.

 

Hugs,
KGP 🤗

My dear friend,
1. You're right that I spied  @laobamac_yyds's method for implementing privilege escalation for OCLP-Plus 3.1.5/3.1.6 and 3.1.7 Tahoe Patch Set.
2. However, I implemented everything else myself, including switching to the APFS file system (at that time,  @laobamac_yyds hadn't implemented this yet).
3. My patch set isn't completely identical, but is based on the official Dortania package. I took two folders from @laobamac_yyds's build:
4. The patch set for modern wireless. Aside from an annoying typo in the paths to the folders themselves. However, this and the typo correction later allowed AirDrop to function properly again.
5. The "Applications" folder, which allowed the familiar interface with icons to function properly, has now stopped working.
I should probably ask @laobamac_yyds why, but for now I've excluded it from the patch process but left it in the patch image until further notice.
6. AmfiConfigurationDetection Rewrite: for checking via vm.cs_library_validation and csrutil status. This was because the previous method didn't work in Clover without AMFIpass.kext loaded.
I wanted to give users the choice of both the bootloader and the method for managing Apple Mobile File Integrity (AMFI=80) without relying on the whims of AMFIpass.kext (with the -amfipassbeta boot argument), which sometimes works, sometimes causes kernel panics.
7. My future plans include trying to restore functionality to video adapters without metal support, but I'm not very hopeful, mainly due to the lack of suitable hardware for testing.
Мany thanks to @laobamac_yyds for his awesome work all over the recent months and to you for your continuous testing.
Hugs,
MakAsrock 🤗

Edited March 23 by MakAsrock

[kgp]

4 hours ago, MakAsrock said:

My dear friend,
1. You're right that I spied  @laobamac_yyds's method for implementing privilege escalation for OCLP-Plus 3.1.5/3.1.6 and 3.1.7 Tahoe Patch Set.
2. However, I implemented everything else myself, including switching to the APFS file system (at that time,  @laobamac_yyds hadn't implemented this yet).
3. My patch set isn't completely identical, but is based on the official Dortania package. I took two folders from @laobamac_yyds's build:
4. The patch set for modern wireless. Aside from an annoying typo in the paths to the folders themselves. However, this and the typo correction later allowed AirDrop to function properly again.
5. The "Applications" folder, which allowed the familiar interface with icons to function properly, has now stopped working.
I should probably ask @laobamac_yyds why, but for now I've excluded it from the patch process but left it in the patch image until further notice.
6. AmfiConfigurationDetection Rewrite: for checking via vm.cs_library_validation and csrutil status. This was because the previous method didn't work in Clover without AMFIpass.kext loaded.
I wanted to give users the choice of both the bootloader and the method for managing Apple Mobile File Integrity (AMFI=80) without relying on the whims of AMFIpass.kext (with the -amfipassbeta boot argument), which sometimes works, sometimes causes kernel panics.
7. My future plans include trying to restore functionality to video adapters without metal support, but I'm not very hopeful, mainly due to the lack of suitable hardware for testing.
Мany thanks to @laobamac_yyds for his awesome work all over the recent months and to you for your continuous testing.
Hugs,
MakAsrock 🤗

 

My dear friend,
I appreciate your detailed clarification — and it’s great to see how your own implementations have evolved further on top of the existing work.

One small suggestion for completeness and transparency in your thread:
it might be helpful to also briefly mention the role of the PatcherSupportPkg (v1.9.9 / v2.0.0) by @laobamac_yyds, as it plays a key role in enabling the -amfipassbeta approach. I also noticed that you have transitioned very recently to these newer PatcherSupportPkg versions, so it might be worth adding a few details about this for clarity. It would be interesting to hear your thoughts on this here too, if you’d like to share them.

Thanks also for your kind words — I’m glad my testing could contribute a bit.

Looking forward to your further progress.

Hugs,
KGP 🤗

Edited March 23 by kgp

[MakAsrock]

4 hours ago, kgp said:

 

My dear friend,
I appreciate your detailed clarification — and it’s great to see how your own implementations have evolved further on top of the existing work.

One small suggestion for completeness and transparency in your thread:
it might be helpful to also briefly mention the role of the PatcherSupportPkg (v1.9.9 / v2.0.0) by @laobamac_yyds, as it plays a key role in enabling the -amfipassbeta approach. I also noticed that you have transitioned very recently to these newer PatcherSupportPkg versions, so it might be worth adding a few details about this for clarity. It would be interesting to hear your thoughts on this here too, if you’d like to share them.

Thanks also for your kind words — I’m glad my testing could contribute a bit.

Looking forward to your further progress.

Hugs,
KGP 🤗

My dear friend,.
 PatcherSupportPkg (v1.9.9) was compiled from Patcher3.0.pkg.zip and updated from dortania.

PatcherSupportPkg (v2.0.0 ) is compiled from PatcherSupportPkg (v1.9.9 ) + two patches from laobamac PatcherSupportPkg (folders 13.7.2-25 and 26.0 Beta 2).

Assembled locally and uploaded to GitHub manually (named 2.0.0 because, in my opinion, this is the next version after 1.9.9) What is honestly written on GitHub PatcherSupportPkg (Synced with laobamac 2.0.0).
I can't use @laobamac_yyds's PatcherSupportPkg directly. It seems to be incompatible. 🙁
I already thanked @laobamac_yyds, in my last post. 
Hugs,
 MakAsrock 🤗
P.S.
Looking for the missing folder 13.2.1-25  🤔

Edited March 23 by MakAsrock

[deeveedee]

@MakAsrock and @laobamac_yyds You're both doing great work.  Would it make sense to combine efforts to produce a single experimental OCLP 3 patcher, or do you think there are advantages to maintaining two separate forks?

[laobamac_yyds]

@deeveedee

The purpose of OCLP-Mod is to provide users in Chinese Mainland with easier patch tools.

 

Therefore, it supports Chinese display and pulls network resources from the API node I personally funded, because Chinese Mainland cannot access Github.

 

So I won't merge it with which projects, but will stop updating it after the original OCLP Repo archived.

 

Best regards,

laobamac

Edited March 26 by laobamac_yyds

[deeveedee]

@laobamac_yyds I will certainly accept your preferred approach without argument. I will only suggest that you and makasrock could work together in a single Github repo that you fork for China.

Edited March 26 by deeveedee

[Alpha22]

Question: macOS Sequoia, what is the latest version of OCPL available?

Thanks

[kgp]

2 minutes ago, Alpha22 said:

Question: macOS Sequoia, what is the latest version of OCPL available?

Thanks

official version OCLP 2.4.1 of Dortania.

[Alpha22]

7 minutes ago, kgp said:

official version OCLP 2.4.1 of Dortania.

I thought it was OCPL 3.0.0, but I was wrong

thanks 

[MakAsrock]

1 hour ago, Alpha22 said:

Question: macOS Sequoia, what is the latest version of OCPL available?

Thanks

For this version of MacOS, I recommend the official OpenCore Legacy Patcher 2.4.1 😉

My unofficial OCLP-Plus 3.1.9 (Tahoe Patch Set) also works, but you need to insert the -amfipassbeta boot argument to your's config.
Otherwise, their behavior is the same. Pay attention to the models!!!
Experimental Fork of OCLP 3.0.0 Nightly also works fine, but does not support Legacy patches (Intel/Nvidia/AMD). 🤗

Edited April 6 by MakAsrock

[kgp]

OCLP 3.0.0 Nightly (amfipassbeta variant) is now also working with the Intel 3165, adding another Intel chipset to the compatibility list alongside already confirmed ones such as the Intel AX200/210 and Intel 7260. Wi-Fi and AWDL are fully operational.

 

Big thanks to @kaoskinkae for an exciting and very interesting collaboration over the past few days.

 

Below is his resulting video for all friends familiar with Spanish:

 

 

 

 

Also attached is the resulting EFI folder for OCLP with his Intel 3165 chipset.

 

Buenas noches a todos,

 

KGP 👍

EFI-final.zip

Edited April 16 by kgp

[kgp]

Major update of Post #1 of this thread:

 

 

[dogansan]

I have Intel WI-FI BE200  and I could only make Bluetooth work but all my attempts failed with itlwm open driver solution. Do you think this method enable us BE200 wifi to work?

[kgp]

1 hour ago, dogansan said:

I have Intel WI-FI BE200  and I could only make Bluetooth work but all my attempts failed with itlwm open driver solution. Do you think this method enable us BE200 wifi to work?

Try AirportItlwm.kext (Ventura) with Broadcom spoofing by following my guidelines and taking my Intel EFI distribution as the baseline 😉
If you encounter problems, upload your EFI-folder and IOReg here or if you prefer, just write me a PM by linking or attaching the latter. 

Edited April 19 by kgp

[kgp]

Intel BE200 not supported by AirportItlwm.kext

 

After several hours of setup and testing together with @dogansan, we came to the conclusion that his Intel BE200 is not supported by AirportItlwm.kext.

The EFI is now fully and correctly configured:

- Proper IOSkywalkFamily replacement in place

- SecureBootModel = Disabled

- csr-active-config = 03080000

- DisableIOMapper = true (AppleVTD disabled)

- Boot-arg: -amfipassbeta

- Broadcom spoofing via DeviceProperties (config.plist)

- All required ACPI properties implemented via SSDT-PC00-RP01-ARPT.aml

 

 

Modern Wi-Fi and Audio root patches have been successfully applied, and the system boots without any issues.

 

However:

 

There is no AirportItlwm driver attached under PC00/RP01/ARPT

 

This clearly indicates that AirportItlwm.kext does not match or support the Intel BE200, despite the correct configuration and successful OCLP patching.

 

This is therefore not a configuration issue, but a missing driver support for the BE200 (Wi-Fi 7 generation).

 

A straightforward but unfortunate conclusion.

 

There is even an open feature request (“Hope to increase driver support for BE200”) on the OpenIntelWireless GitHub, indicating that BE200 support is not yet implemented in AirportItlwm.

 

Additional info:
The final EFI folder for the
- ASUS ROG Maximus Z790 Dark Hero (with Intel I226-V using AppleIGC.kext v1.8)
- and the Intel BE200

is attached below for reference (SMBIOS removed).

EFI-DS-Final.zip

Edited April 19 by kgp

[dogansan]

On 4/20/2026 at 1:19 AM, kgp said:

Intel BE200 not supported by AirportItlwm.kext

 

After several hours of setup and testing together with @dogansan, we came to the conclusion that his Intel BE200 is not supported by AirportItlwm.kext.

The EFI is now fully and correctly configured:

- Proper IOSkywalkFamily replacement in place

- SecureBootModel = Disabled

- csr-active-config = 03080000

- DisableIOMapper = true (AppleVTD disabled)

- Boot-arg: -amfipassbeta

- Broadcom spoofing via DeviceProperties (config.plist)

- All required ACPI properties implemented via SSDT-PC00-RP01-ARPT.aml

 

 

Modern Wi-Fi and Audio root patches have been successfully applied, and the system boots without any issues.

 

However:

 

There is no AirportItlwm driver attached under PC00/RP01/ARPT

 

This clearly indicates that AirportItlwm.kext does not match or support the Intel BE200, despite the correct configuration and successful OCLP patching.

 

This is therefore not a configuration issue, but a missing driver support for the BE200 (Wi-Fi 7 generation).

 

A straightforward but unfortunate conclusion.

 

There is even an open feature request (“Hope to increase driver support for BE200”) on the OpenIntelWireless GitHub, indicating that BE200 support is not yet implemented in AirportItlwm.

 

Additional info:
The final EFI folder for the
- ASUS ROG Maximus Z790 Dark Hero (with Intel I226-V using AppleIGC.kext v1.8)
- and the Intel BE200

is attached below for reference (SMBIOS removed).

EFI-DS-Final.zip 65.41 MB · 2 downloads

I have some good news on this. I decided to use modified version of Airportitlmw.kext for Ventura given here issue 955 of itlmw github.  It now enable wi-fi but the only issue it can not scan the available wi-fi networks, I have to enter my preffered wi-fi settings. The speed is same as the speeds I am obtaining with ethernet.

[LockDown]

6 hours ago, dogansan said:

modified version of Airportitlmw.kext for Ventura

Link?

[kgp]

On 4/22/2026 at 1:47 AM, LockDown said:

Link?

 

First successful Intel BE200 Wi-Fi 7 connection under macOS Tahoe using a modified AirportItlwm (Ventura build) with OCLP.

 

@dogansan, many thanks for your IOREG and spx. I can confirm that AirportItlwm.kext (Ventura build from Issue #955, go to https://github.com/OpenIntelWireless/itlwm/issues/955 and download Ventura.zip) is properly attaching and working with OCLP!

 

Congrats @dogansan ! 💯 

 

 

 

However, as you pointed out, network scanning is currently still inconsistent, which suggests incomplete driver support for the Intel BE200 rather than a configuration issue.

Edited June 12 by kgp

[kgp]

Minifix for sporadic AirDrop / AWDL issues after wake (Tahoe 26.x)

 

 

After wake from sleep, nearby devices may sometimes become invisible in AirDrop, and the Hackintosh itself may also not be discoverable by other devices.

Important observations:
- Wi-Fi is fully functional
- Bluetooth is powered on and devices (Magic Mouse, Magic Keyboard) remain connected
- awdl0 is up and reports "status: active"
- AirDrop UI is available, but sometimes no nearby devices appear

The key difference I observed is the AWDL state:

- Non-working state after wake:
Schedule State: Idle

- Working state:
Schedule State: Unknown (44) (active / expected behavior)

This indicates that AWDL is not fully re-initialized after wake, even though the interface itself is active.

A quick manual fix is either:
- toggling Bluetooth off/on via the menu bar, or
- running:
sudo killall -9 bluetoothd

As a temporary workaround, this can be automated using SleepWatcher:

 

If Homebrew is not installed, you can install it with:
 

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

1. Install SleepWatcher (e.g. via Homebrew):

brew install sleepwatcher

2. Create a wake script:

nano ~/.wakeup

Content:

#!/bin/zsh
sleep 2
/usr/bin/killall -9 bluetoothd

Then:

chmod +x ~/.wakeup

3. Create LaunchAgent:

mkdir -p ~/Library/LaunchAgents
nano ~/Library/LaunchAgents/de.kgp.sleepwatcher.plist

Content:
 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>de.kgp.sleepwatcher</string>

<key>ProgramArguments</key>
<array>
<string>/opt/homebrew/sbin/sleepwatcher</string>
<string>-V</string>
<string>-w</string>
<string>/Users/kgp/.wakeup</string>
</array>

<key>RunAtLoad</key>
<true/>

<key>KeepAlive</key>
<true/>
</dict>
</plist>

Note: Adjust the path to sleepwatcher and your username if needed.

4. Load the LaunchAgent:

launchctl load ~/Library/LaunchAgents/de.kgp.sleepwatcher.plist

 

To unload or disable it again:
 

launchctl unload ~/Library/LaunchAgents/de.kgp.sleepwatcher.plist

 

From then on, the wake script is executed automatically after each wake event and restores AirDrop functionality without requiring manual Bluetooth toggling.

This workaround proved to be reliable in practice.

Note: This is only an optional workaround for a sporadic AirDrop post-wake issue under macOS Tahoe. It does not affect normal Wi-Fi or Bluetooth functionality.

 

Edited April 23 by kgp

[miliuco]

@kgp

Excellent manual for using Sleepwatcher!

[kgp]

Update of post #1 of this thread: Adding Section: General Troubleshooting Notes for OCLP on macOS Tahoe (26.x)

Edited April 23 by kgp

[kgp]

Total revision of post #1 of this thread! 

 

Post #1 has been fully revised and now reflects all settings, recent findings, fixes and optimisations — including AWDL/AirDrop behavior, sleep/wake improvements and FileVault guidance.

 

Thanks to everyone for the feedback and testing — seems we are doing fine 

 

 

 

Edit:

 

While updating some of my GitHub profile links, I noticed something I had never really paid attention to.

One of my old Hackintosh guides from the iMac Pro / X99-X299 era has now surpassed 2 million views, despite having been closed for further replies since 2019.

 

 

Looking back, it is quite remarkable how far the community has come since those Clover and early OpenCore days.

Back then, much of our focus was on X99, X299, SSDTs, ACPI, USB mapping and getting iMacPro1,1 systems running as smoothly as possible.

Today, almost a decade later, we are discussing completely different topics such as OCLP, modern Wi-Fi, AWDL, AppleHDA, AMFIPass and macOS Tahoe.

 

Nevertheless, it is nice to see that some of the old guides still remain part of the historical record of the Intel Hackintosh era.

Many thanks to everybody who contributed, tested, reported issues and shared ideas over all those years. 🙂

Cheers,

KGP 👍

Edited May 28 by kgp
Added an interesting historical finding from the X99/X299 iMac Pro era that I recently stumbled across while updating my GitHub profile links.

[jorsh]

Hey everyone. I followed the guide for Tahoe but when I rebooted after installing kexts and modifying the required EFI entires -and before running OCLP, I got a black screen after boot. The curious thing is that the other method for getting wifi to work in the official guide, the "Apple Broadcom Wi-Fi Companion" method also gave me the same results which makes me believe there is something else wrong with my build. Any suggestions? my chip is the Broadcom BCM943602 

[kgp]

2 minutes ago, jorsh said:

Hey everyone. I followed the guide for Tahoe but when I rebooted after installing kexts and modifying the required EFI entires -and before running OCLP, I got a black screen after boot. The curious thing is that the other method for getting wifi to work in the official guide, the "Apple Broadcom Wi-Fi Companion" method also gave me the same results which makes me believe there is something else wrong with my build. Any suggestions? my chip is the Broadcom BCM943602 

 

Hi dude,
I’m writing from my phone and will be home late tonight, so I can’t check your system specs right now.

Try booting with -v to get more detailed output.

Please send me a PM with a WeTransfer link including your EFI folder, IOReg, and Hackintool .txt exports.

Thanks in advance,
KGP