Mykextinstaller

[Alpha22]

14 hours ago, Mirone said:

@eSaF @Oyecomova @naiclub

try this: MyKextInstaller.zip

Note: I tested it on a clean install of Tahoe Beta 5 and it restored the audio without changing the new icons.

@Mirone I tried this working audio version, but it changed the icon

 

Spoiler

 

[Mirone]

@Alpha22

Have you made any changes before?

[Alpha22]

6 hours ago, Mirone said:

@Alpha22

Have you made any changes before?

no

[LockDown]

11 hours ago, Alpha22 said:

but it changed the icon

Mine did not even with custom icon. changed to what?

Edited August 8, 2025 by LockDown

[Alpha22]

2 hours ago, LockDown said:

Mine did not even with custom icon. changed to what?

See photos

[LockDown]

49 minutes ago, Alpha22 said:

See photos

i see now. it was blank earlier

[Mirone]

18 hours ago, Alpha22 said:

See photos

In a clean installation that I did, the icon was not changed, well anyway I think this must be something related to the KDK that we used from Beta 1 when it didn't have these icons yet, but you can restore the new icons easily if you want. Navigate to: /System/Library/Extensions/IOStorageFamily.kext/Contents/Resources

[Alpha22]

18 hours ago, Mirone said:

In a clean installation that I did, the icon was not changed, well anyway I think this must be something related to the KDK that we used from Beta 1 when it didn't have these icons yet, but you can restore the new icons easily if you want. Navigate to: /System/Library/Extensions/IOStorageFamily.kext/Contents/Resources

I see these icons in the path indicated, but not those of Beta 5

Spoiler

 

[Mirone]

On 8/9/2025 at 3:25 PM, Alpha22 said:

I see these icons in the path indicated, but not those of Beta 5

  Reveal hidden contents

 

Was it fixed in beta 6?
Did you try restoring the Snapshot?

[iaihc]

Install AppleHDA Error

[Alpha22]

15 hours ago, Mirone said:

Was it fixed in beta 6?
Did you try restoring the Snapshot?

@Mirone Beta 6 update using MyKextInstaller (version 1.2) l have working audio, but I need to restore the disk icon

Edited August 12, 2025 by Alpha22

[Anto65]

10 minutes ago, Alpha22 said:

@Mirone Beta 6 update using MyKextInstaller (version 1.2) l have working audio, but I need to restore the disk icon

https://www.insanelymac.com/forum/topic/361162-pre-release-macos-tahoe/page/139/#findComment-2838961

[Alpha22]

14 minutes ago, Anto65 said:

https://www.insanelymac.com/forum/topic/361162-pre-release-macos-tahoe/page/139/#findComment-2838961

That's right, done as instructed by @Mirone

[tlac]

I set csr-active-config=03080000 in OpenCore and installed the Kernel Debug Kit 26.0 build 25A5279m, so I have the old AppleHDA.kext as well.

 

The next step would be to use MyKextInstaller, but I don’t really like the idea of using a tool that modifies the system without knowing what it’s doing. Unfortunately, there’s no source code available either.

 

Could you tell me the manual steps I could run from the command line or share the relevant code so I can figure it out myself?

[miliuco]

@tlac

But you probably use many apps for which you don't have the source code, starting with macOS. And that doesn't stop you from using them. You're looking for the trustworthiness of the developer or the security features the app has.

In the case of MykextInstaller, @Mirone has submitted latest version 1.2 to be signed and notarized, as you can see in Terminal:

 

I think this deserves enough trust.

[tlac]

@miliuco

Well, I mostly use open-source apps, but for me it’s not just about trust.
Everyone has a different tolerance level, for some people it’s totally fine to use someone else’s EFI build.
Personally, I prefer manual methods over one-click solutions because I like to know exactly what’s happening in the background.
If this tool is doing some kind of hack that I don’t agree with, I might just wait for a better method (Linux is my main OS) or simply use a USB sound card, which I’ve already tested and works out of the box.

[miliuco]

@tlac

Expanding on my previous post, I'm also an open source enthusiast and believe that GitHub is a place for sharing code among developers, so I like that GitHub projects have source code, which isn't always the case.
Apps notarized by Apple are supposed to have been checked by Apple without finding any issues or malicious code, but it's true that this is a different matter than having the source code available.
In any case, the vast majority of users can't or don't know how to check all the source code of the open source apps they use. Small apps, perhaps, or if the programming language is accessible to us. Large or complex apps, most likely not, because how many Ubuntu users (or any other Linux distro) check every line of source code?
As you say, everyone has a different tolerance level.

But yes, your arguments are completely valid and I quite agree with them.

[Mirone]

1 hour ago, tlac said:

Could you tell me the manual steps I could run from the command line or share the relevant code so I can figure it out myself?

You can read the KDK README and perform a manual installation if that makes you more comfortable.

[tlac]

21 minutes ago, Mirone said:

You can read the KDK README and perform a manual installation if that makes you more comfortable.

 

That's a good starting point. According to the ReadMe:

The easiest way to copy the files is to copy the entire /System directory of the KDK into the /System directory of your mounted disk, as shown in the following example:
sudo ditto /Library/Developer/KDKs/<KDK Version>/System /Users/jappleseed/livemount/System

 

Do you also restore all of the old system files?

Or is there a minimum set of files that needs to be replaced for things to work?

[Mirone]

3 hours ago, tlac said:

 

That's a good starting point. According to the ReadMe:

The easiest way to copy the files is to copy the entire /System directory of the KDK into the /System directory of your mounted disk, as shown in the following example:
sudo ditto /Library/Developer/KDKs/<KDK Version>/System /Users/jappleseed/livemount/System

 

Do you also restore all of the old system files?

Or is there a minimum set of files that needs to be replaced for things to work?

Look this: 

 

 

[tlac]

@Mirone

I see a very similar ditto command there, so can you confirm that your app restores all of the old system files?

[Mirone]

42 minutes ago, tlac said:

@Mirone

I see a very similar ditto command there, so can you confirm that your app restores all of the old system files?

The application follows exactly what the KDK README says. You can choose to use the application or simply follow the steps described by @fusion71au

[fusion71au]

On 8/13/2025 at 7:02 AM, tlac said:

Do you also restore all of the old system files? Yes

Or is there a minimum set of files that needs to be replaced for things to work? No, they work as a set so can't pick and choose.  Note: ideally, KDK version should match the current macOS version.

 

Since Ventura, all on disk kexts in /S/L/E have their binaries removed so in order to generate a new Kernel Collection/cache, you must install the corresponding KernelDebugKit (or closest version, in this case Apple has only released KDK for Tahoe Beta1 so far) to your macOS version and "ditto" merge it with the current S/L/E ie all kexts must be overwritten with the KDK ones (since only these ones have binaries inside).

 

Edit

Apple has just made available Beta6 KDK_25A5338b for download...

Spoiler

Now you can properly root patch Tahoe B6 with B1 AppleHDA and B6 KDK_25A5338b 😀....

 

Spoiler

fusion71au@iMac ~ % sudo mount -o nobrowse -t apfs /dev/disk1s4 /System/Volumes/Update/mnt1 
Password:
fusion71au@iMac ~ % sudo ditto /Library/Developer/KDKs/KDK_26.0_25A5338b.kdk/System /System/Volumes/Update/mnt1/System
fusion71au@iMac ~ % sudo cp -R /Users/fusion71au/Desktop/Backup\ Kexts/AppleHDA.kext /System/Volumes/Update/mnt1/System/Library/Extensions
fusion71au@iMac ~ % sudo touch /System/Volumes/Update/mnt1/System/Library/Extensions
fusion71au@iMac ~ % sudo kmutil create --allow-missing-kdk --volume-root /System/Volumes/Update/mnt1 --update-all --variant-suffix release --no-authentication --no-authorization
checking collections...
Warning: com.apple.driver.KextExcludeList was not found!
updated kernel binaries (Mach-O UUID changed from <unknown> to <unknown>)
rebuilding release collections:
	boot kernel collection
	system kext collection
rebuilding local auxiliary collection
kmutil rebuild done
fusion71au@iMac ~ % sudo bless --folder /System/Volumes/Update/mnt1/System/Library/CoreServices --bootefi --create-snapshot

 

Mirror download, thanks to @laobamac_yyds.

Edited August 15, 2025 by fusion71au
Mirror download provided as Apple removed B6 KDK from Apple Developer Website.

[tlac]

9 hours ago, fusion71au said:

 

Since Ventura, all on disk kexts in /S/L/E have their binaries removed so in order to generate a new Kernel Collection/cache, you must install the corresponding KernelDebugKit (or closest version, in this case Apple has only released KDK for Tahoe Beta1 so far) to your macOS version and "ditto" merge it with the current S/L/E ie all kexts must be overwritten with the KDK ones (since only these ones have binaries inside).

 

Thanks, that makes things clearer. But this really doesn’t sound ideal. We are mixing older beta kexts and system files with a newer macOS release, basically creating a Frankintosh. It doesn’t seem very future-proof.

I don't think it's worth losing a vanilla macOS setup if a cheap USB sound card or some other option is available.

 

But what I still don’t understand is why we can’t just pick only the AppleHDA.kext and its dependencies from the DebugKit.

[miliuco]

@tlac

Hackintosh is always Frankintosh in some way. Even the most vanilla versions inject third-party bootloaders and kexts not designed or authorized by Apple at boot. Different hardware requires major modifications. It depends on your machine.
We work with SIP and SecureBootModel settings (Apple Secure Boot of real Macs with OpenCore) that relax the security level of macOS, sometimes not for fun but because it's the only way to have macOS on a specific PC or because a task we want to perform requires it.
The vast majority of us boot the Hack with UEFI Secure Boot disabled so we don't have to digitally sign the OpenCore files with each new version.
Some people prefer USB audio and not messing with S/L/E; others prefer to restore integrated audio even if it means messing with S/L/E; others prefer to try both options (like me). All three options are valid for me.
In short, a Hack will never be a real Mac; it will always be some kind of Frankintosh. Everyone has to decide where they draw the line at modifying the original.
As you say, "everyone has a different tolerance level" which is a great truth.