New style of AppleHDA.kext patching (take II)

In a previous blog article I wrote about a New style of AppleHDA.kext patching and I guess that most of you have tried it, but… Toleda told me that it fails for people with Chameleon/Chimera when kernelcache is used. Folks using Clover appears to be fine I’m told. I also don’t have issues with it with RevoBoot (a private unreleased version).

Not only that. It was also too complicated, and that is why I wrote a script called My first public version was 0.2 but I have since updated my Github repository with a slightly modified version. I am far from done, and a next update should be more fun to use, but please give this version a go and help me to improve Oops. I even ran out of time to add more text. Later!

A new major update to is now available from my Github repository. This version supports Realtek ALC 885, 887, 888, 889, 892, 898 and 1150 and will look in AppleHDA.kext and FakeSMC.kext for ConfigData. If can’t locate the required ConfigData, then it will try to download a file from Toleda’s Github repository and unzip it in a sub-directory of /tmp.

There are probably a couple of checks that I should add, but this has to be it for now. Later folks.

Good news. has been updated to version 1.5 and now supports four new arguments:

Usage: ./ [-hald]
-h print help info
-a target ALC
-l target layout-id
-d target directory

Note: Currently it is not possible to copy/bin-patch the AppleHDA executable with (it only creates a symbolic link) but version 1.6 should change this. I also plan on adding support to copy/bin-patch the AppleHDAHardwareConfigDriver executable.

Update-3: has been updated to version 1.6 and now supports a new argument:

-b AppleHDA

A next version will expand this so that you can use something like:

-b AppleHDA:\x8b\x19\xd4\x11,\x92\x08\xec\x10
-b AppleHDA:x8bx19xd4x11,x92x08xecx10

Edit: Already implemented!

The last hurdle is to let you bin-patch the AppleHDAController binary, but that should be fine by the time we reach v2.0

Edit: Already implemented!

Update-4: has been updated to version 2.0 and I think that this is it. Everything seems to work now so go ahead and give it a go.

Thanks for testing!

31 thoughts on “New style of AppleHDA.kext patching (take II)

  1. Thanks for revisiting this–I will give this a go tomorrow. You mentioned in the last post on this topic that one could load the rest of their kexts into the plugin folder so that they had only a single kext to install or maintain.

    Should that plugin folder be in AppleHDA or in this legacy kext? Do you have any more to say about instituting it? It seemed like an excellent and tidy approach.

    • It isn’t just for ALC 892, but since that is what I use… that is what I used as default in my script. You can use the same script – though you need to change the 892 into 1150. Good news. My local tree includes changes to make this a bit more flexible. However. I first want to test it after work and then I commit it.

  2. What am I doing wrong? I just copy and pasted it into a text file in my users home directory (using nano on terminal). And then ran it via “sudo ./ /System/Library/Extensions”. And then it just tells me (a hundred times): “This script ^[[4mmustESC[[0m be run as root!”

    And maybe that’s a stupid question. But where to get “Platforms.xml.zlib” and “layout892.xml.zlib” from?

  3. Hi, Pike
    Nice script you have, but lines 259-261 could be replaced with something like this:

    /usr/libexec/PlistBuddy -c “Set :CFBundleShortVersionString string 9.1.1” “$gTargetFile”

  4. I don’t know if you look at the comments of your old posts, though I thought I’d simply post it here:

    You wrote something about delays within AppleIntelFramebufferAzul.kext. I patched that file for my Motherboard (Gigabyte Z87MX-D3H with Intel i7 4770K) with the information from your previous posts about AppleIntelFramebufferAzul.kext and after a few attempts I now have sound via onboard, DP and HDMI! Really great! 🙂
    Here’s what I use (for platform id = “03 00 22 0D”):
    01 05 12 00 00 08 00 00 06 00 00 00
    02 04 14 00 00 04 00 00 87 00 00 00
    03 06 10 00 00 04 00 00 87 00 00 00

    The reason I write is: I have mouse lags (the cursor jumps quite often, but video and keyboard input seems to be smooth/normal) when I connect my HDMI TV and turn it off. It only(!) happens when HDMI is connected by the HDMI display is turned off… pretty strange. Even if I unplug the power cord of my TV, OSX still recognizes it via HDMI. My second display is at the DisplayPort, and the mouse is wired and USB.

    The problem also occures with the original AppleIntelFramebufferAzul.kext contents:
    01 05 12 00 00 04 00 00 87 00 00 00
    02 04 14 00 00 04 00 00 87 00 00 00
    03 06 10 00 00 04 00 00 11 00 00 00

    I tried some solutions from the internet (a tool called SmoothMouse, delete AppleUpstreamUserClient.kext, change some mouse settings within system settings, etc.), but nothing solved the problem. Somewhere I read it could possibly belong to HDCP.

    And after all those useless attempts I thought that it could maybe belong to those “delays”?! Or are they just for connector-negotiation? Maybe you can think of some other solution, or at least the source of that jumpy mouse cursor.

    Kind regars & appreciation for your great blog posts,

    • Sure. Just copy/past the text to it and I will clean this one up for you.

      But unfortunately… I have no idea where the delays are coming from. Let me check this with my new 4K Dell monitor (when it gets delivered tomorrow).

  5. Hope your HDMI display has arrived and you can test that strange behavior.

    Maybe you can elaborate a bit on the “delay”. I don’t really understand why you call it “delay” if it’s just used as some kind of precedence flag.

    BTW: I can’t copy & paste it to the right blog post. It says: “Comments are closed”.

    • It would not have arrived here before the weekend so I drove two hours south to get it. The bad thing is that now I don’t have any time left to use it myself. Not until next week. What a bummer.

      And I have to look into the why I called it a delay. Might be due some name in the executable, but again… I first have to check this. Sorry. Can’t remember everything.

  6. Pike, I’d like to report the latest does work great on my ASRock Z77E-ITX (Realtek ALC898 with Mavericks 10.9.1 and the latest Chameleon). Is there any way to check if something is wrong, besides the obvious System Preferences panel?

    • Great! Thank you for this confirmation.

      I used DEBUG=1 to fix bugs in and issues reported by Toleda so I think that this flag is a good starting point – the script calls kextutil -qtnk /mach_kernel to verify the created kext so that should help.

  7. Could you explain?
    Furthermore: on Asus Z87i Pro, intel 4770k, I tried your method, but HDMI Audio (from Apple cinema display) doesn’t show up. Patching ALC1150 with MultiBeast (with edited Azul) works. Any clues? Should I provide some dump?

    • You can specify the target ALC like so: ./ -a 1150 (I committed a new update that made -h show the supported types).

      And using: -b AppleHDA -b AppleHDAController will use the default search/replace patterns, but you can override them with (examples) -b AppleHDA:\x8b\x19\xd4\x11,\x00\x09\xec\x10 and -b AppleHDAController:\x0c\x0c\x00\x00\x75\x61\xeb\x30,\x0c\x0c\x00\x00\x75\x61\xeb\x0e

      So when the defaults aren’t working for you (but Toleda said that 1150 worked for him) then you may have to use a different pattern (check multi beast to see if this is the case) but you probably have to do the frame buffer edits yourself to get it working

  8. Now it works ok. Maybe I’ve made some mistake editing Azul. Now I think I got it: if the command is ./ -b AppleHDA, I get just analog audio. If I put ./ -b AppleHDAController, that will give me ONLY hdmi audio. Then if I put -b AppleHDA -b AppleHDAController, I get them both. That’s really interesting, you know, I’m light years behind you, man!
    A little OT: I had to install Mav on a MBR partition with this board (even with PMPatched bios).
    I’m digging into that.

  9. Hi pike…I’m trying to implement ur trick on REALTEK ALC269 but I couldn’t figure where I’m doing wrong. I was trying the whole day yday and don’t know what’s wrong sometimes controls appear in sound settings but no sound and sometimes mic disappears. But finally I fail to do it and approaching you.please help…I’ll give u links to working kext and patching guide of alc269 ,.plz cud you make a dummy kext n send me. If u think binary linking shud be done in my system thats OK …u do the rest of it and send me..thanks 🙂

    I’m using mountain 10.8.5 with the following kext

    And here is the guide of bin patching

    Sorry I forgot to mention the layout id of mine its layoutid28.XML.zlib


  10. Hi pike…the above are my patched kexts and guide could you please do me a dummy kext and i’ll link binaries to it . The reason I’m asking is i tried many times and didn’t make it work for ALC269. But I got same method working for ALC889…not sure whats going arong with ALC269, does it need plugins too? No idea? Please have a look.
    Thanks 🙂

    • You seem to have missed the supported codecs i.e. there is no support for your codec. And I will not make a kext for you, nor for anyone else, simply because I do not have time for it. In short. You’re on your own here.

      I will see what I can come up with for a next update, but since there is no (known) repo with all kind of patched XML files…

  11. Pingback: New style of AppleHDA.kext patching (take III) | Pike's Universum

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s