VOODOOHDAINJECTOR
Bootloader-level kext injection · macOS 11 → 26

VoodooHDABootloaderInjector

Since Big Sur, VoodooHDA.kext can't be injected straight from the bootloader. This tool makes it work anyway — one script, two patched kexts, zero SIP compromises. Clone it, run it, drop both kexts in your EFI.

Quick start
1Clone the repository
git clone https://github.com/chris1111/VoodooHDA-Bootloader-Injector.git
2Run the tool
VoodooHDA Injector.tool
macOS 11 → 26 OpenCore 1.0.7 Clover x86_64 SIP fully enabled
Boot console · without the fix

↳ the failure every VoodooHDA user knows — explained in §01, fixed by this tool.

§01
The problem

Why direct injection fails

01

Since macOS Big Sur (11), injecting VoodooHDA.kext directly from the bootloader fails. The booter — OpenCore and Clover alike, they share the same injection engine — cannot link VoodooHDA because its parent classes live in Apple's IOAudioFamily.kext, which is not in the boot kernel collection (BootKernelExtensions.kc). The result, every single boot:

OpenCore · verbose boot, every time
[ 0.018990] OC: Prelinked injection VoodooHDA.kext () - Invalid Parameter

The script solves this automatically. Here is exactly what it does, step by step.

§02
The fix

The idea, in one sentence

02

Ship a renamed copy of Apple's IOAudioFamily.kext alongside VoodooHDA — and make VoodooHDA link against the renamed copy. The booter then resolves everything at prelink time.

everything else on this page is the careful execution of that sentence

§03
What the script does

Step by step

03
01

Safety guards exits early if anything is wrong

EXIT

VoodooHDA.kext is installed in /Library/Extensions — bootloader injection and an installed kext cannot coexist. The script prints the removal + rebuild commands for you.

DELETE + EXIT

VoodooHDA.kext is already patched (previous run) — prevents double-patching a distributed kext.

RESET

The script uses the kext provided in the ORIG-2.6.2 folder (unpatched VoodooHDA.kext) — it systematically regenerates the functional kext from this base.

02

Get a real IOAudioFamily.kext

Apple increasingly ships IOAudioFamily as a hollow stub — no binary inside (verified on Ventura 13 and Tahoe 26). The script finds a real one, in this order:

A

/System/Library/Extensions — used only if the binary is really there.

B

Kernel Debug Kit — auto-downloaded from Dortania's KdkSupportPkg:

  • matches your exact running build (sw_vers)
  • no exact match? it asks you: closest build (risky) or abort
  • mounts the .dmg in /private/tmp
  • expands the .pkg inside — yes, the dmg contains a pkg
  • extracts IOAudioFamily.kext from the payload
  • deletes the dmg + temp files automatically

Only KDK (or a real /S/L/E) binary is in the required pre-link state. Extracting from SystemKernelExtensions.kc does not work — those binaries are pre-relocated by Apple and hang the boot.

03

Patch the copy — the alias trick

The copy is modified so it can coexist with Apple's stock IOAudioFamily:

  • binary thinned to x86_64 (arm64e slice removed)
  • identifier renamed everywhere — inside the Mach-O binary and in Info.plist

Without the rename, the duplicate identifier stalls early boot (DriverKit stage). With it, the kernel loads both stacks happily — tested and verified.

04

Patch VoodooHDA.kext

Its OSBundleLibraries is rewritten:

com.apple.iokit.IOAudioFamily net.voodoo.IOAudioFamily ↳ so at prelink time the booter resolves VoodooHDA's 191 audio imports against the aliased copy injected just before it.
05

Sign both kexts ad-hoc

Both kexts are re-signed after patching, so signatures verify cleanly.

§04
After the script

Installation

04

Two kexts come out of the script — IOAudioFamily.kext (the renamed alias) and VoodooHDA.kext (patched). Both go into your EFI.

Clover

StepActionDetail
1Copy BOTH kextsEFI/CLOVER/kexts/Other/
2Kernel → BlockNo entries needed
3SIPNo changes — works fully enabled
4Rebootthat's it

OpenCore

Kernel → Add — required order. The array order is the link order; wrong order = Invalid Parameter — see the live demo in §06.

StepActionDetail
1Copy BOTH kextsEFI/OC/Kexts/
2OC config: Kernel → AddArray order = link order — wrong order = Invalid Parameter (table below)
3Kernel → Addorder-criticalIOAudioFamily.kext TOP — must be first
4Kernel → Addorder-criticalVoodooHDA.kext BELOW IOAudioFamily
5SIPNo changes — works fully enabled
6Rebootthat's it

SIP verified: macOS Tahoe 26.7.1 · OpenCore 1.0.7 · csr-active-config = 00000000 — fully enabled, no changes required.

§05
Post-reboot

Verify

05
Terminal · after reboot
# confirm the stack is loaded
$ kmutil showloaded | grep -i voodoo
$ system_profiler SPAudioDataType
# expect: net.voodoo.IOAudioFamily + VoodooHDA among the loaded kexts
§06
Why the order matters · Kernel → Add

Order decides everything

06

The booter resolves each injected kext's imports against the kexts injected before it in the Kernel → Add array. IOAudioFamily first = VoodooHDA's classes resolve. VoodooHDA first = nothing to resolve against = Invalid Parameter.

Try both orders below — the simulator runs the exact prelink sequence your bootloader performs.

Kernel → Add · link-order simulator
EFI/Kexts — waiting
IOAudioFamily.kext
imports → com.apple.kpi.* (kernel)
alias of com.apple.iokit.IOAudioFamily
VoodooHDA.kext
imports → net.voodoo.IOAudioFamily
191 audio symbols
inject
BootKernelExtensions.kc — prelink buffer
empty
Pick an order, then run the prelink.
§07
Why the alias matters

Two kexts, one binary, zero collision

07

Two kexts with the same identifier cannot coexist. The stock IOAudioFamily (lives in the SystemKC) plus our injected copy = collision at early userspace. Renaming ours to net.voodoo.IOAudioFamily makes the kernel treat them as two different kexts — AppleHDA keeps its family, VoodooHDA gets its own.

com.apple.iokit.IOAudioFamily net.voodoo.IOAudioFamily ↳ renamed inside the Mach-O binary and in Info.plist
SystemKC com.apple.iokit.IOAudioFamily serves AppleHDA — untouched
Injected net.voodoo.IOAudioFamily serves VoodooHDA — via bootloader
same binary · different identifier · zero collision
§08
Why KDK binaries matter

Pre-link, or not at all

08

A kext binary extracted from a kernel collection has its relocations already applied by Apple's kcgen. The booter needs pre-link binaries (relocations intact) to place them at a new address. KDK ships pristine pre-link binaries — that is why the script refuses to use anything else.

SystemKernelExtensions.kc

relocations already applied by kcgen — binary is pre-relocated. The booter cannot place it at a new address → boot hangs.

Kernel Debug Kit

pristine pre-link binaries — relocations intact. The booter resolves and places them at prelink time → boot succeeds.

§09
Field report

Tested

09
VoodooHDA V-2.9.2 audio CONFIRMED — analog + HDMI · macOS 26.3 CONFIRMED
VoodooHDA V-2.9.2 use for old machines · e.g. HP ProDesk 600 G1 LEGACY HARDWARE
OpenCore + Clover both verified · shared OcAppleKernelLib engine DUAL BOOTLOADER
§10
Thanks

Credits

10
chris1111alias technique · script · VoodooHDA contributor
Slice · AutumnRain · Zenith432original VoodooHDA developers
DortaniaKDK mirrors
AcidantheraOcAppleKernelLib — the injection engine we patched through
Copied to clipboard