Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
bcc9

Script to patch AppleHDA binary for osx10.7/10.8/10.9

166 posts in this topic

Recommended Posts

And would it be possible to specify both patch-codec and target-codec as numbers instead of via lookup?

Right, the target codec can already be specified as a number, just not the patch codec, currently. Proper sanity checking on the patch codec would be a bit messy (it should ideally match one of the real codec ids found in AppleHDA). But it wouldn't be hard to make the command line just accept a full hex codec ID without performing any checking...

 

It would be nice if the script could be started with an option to output Clover config.plist KextsToPatch data. My perl understanding is not where it would need to be to implement such a feature... Perhaps for your consideration. At the present, I use xxd/diffmerge to determine the binary diffs and create Find/Replace sets manually.

It would be pretty easy to spit out some XML for the user to apply, slightly harder to auto-patch an XML config file with the changes.

Does clover yet have a config syntax that is standard&safe against aliasing? http://clover-wiki.zetam.org/Configuration/KernelAndKextPatches just shows Find/Replace operators, which leaves open the chance that the runtime-patch is going to be mis-applied. patch-hda.pl is careful to make sure that the number of matches found exactly match what is expected (to avoid any issues with false matches). Find/replace does not...

Do not know if insanely has a wiki for this, 

github would be a bad idea? 

Please correct me if I'm wrong.

In general I would think a US hosted server may not be a great choice for projects that are about binary patching OSX, because of potential DMCA claims. But I'm not a lawyer, etc., etc.

Share this post


Link to post
Share on other sites

Right, the target codec can already be specified as a number, just not the patch codec, currently. Proper sanity checking on the patch codec would be a bit messy (it should ideally match one of the real codec ids found in AppleHDA). But it wouldn't be hard to make the command line just accept a full hex codec ID without performing any checking...

I was aware of the target codec being able to be specified, but then it always defaults to patch codec 'ADI 1984'... If one of the three codecs in AppleHDA could be specified directly that would be great.

 

It would be pretty easy to spit out some XML for the user to apply, slightly harder to auto-patch an XML config file with the changes.

Not looking for config.plist auto-patch. Just the find/replace(hex) strings...

 

Does clover yet have a config syntax that is standard&safe against aliasing? http://clover-wiki.zetam.org/Configuration/KernelAndKextPatches just shows Find/Replace operators, which leaves open the chance that the runtime-patch is going to be mis-applied. patch-hda.pl is careful to make sure that the number of matches found exactly match what is expected (to avoid any issues with false matches). Find/replace does not...

Just find/replace. I usually include the byte prior ('3d' corresponding to cmpl instruction)...

 

eg. this is find/replace pairs for ALC283:

find: <3d8408ec 10> replace: <3d000000 00>
find: <3d8508ec 10> replace: <3d000000 00>
find: <3d8419d4 11> replace: <3d8302ec 10>
I usually test the find/replace pairs with patcho (a simple binary patcher by SJ_Underwater) to verify (binary compare against the results from patch-hda).

 

In general I would think a US hosted server may not be a great choice for projects that are about binary patching OSX, because of potential DMCA claims. But I'm not a lawyer, etc., etc.

Maybe not, but there is a bit of that out there :-)

Share this post


Link to post
Share on other sites

 

 

Just find/replace. I usually include the byte prior ('3d' corresponding to cmpl instruction)...

 

eg. this is find/replace pairs for ALC283:

find: <3d8408ec 10> replace: <3d000000 00>
find: <3d8508ec 10> replace: <3d000000 00>
find: <3d8419d4 11> replace: <3d8302ec 10>
 
What is the difference in using the '3 d 'Corresponding to CMPL instruction 
and not use?

Share this post


Link to post
Share on other sites

What is the difference in using the '3 d 'Corresponding to CMPL instruction 

and not use?

Just some insurance that you're not going to mistakenly replace some random data/code that happens to correspond to the 8-byte pattern. The more bytes you can provide in the find pattern, the less likely a 'false match.' Still there is a possibility of a false match with the 10-byte pattern, but with each extra byte in the find pattern, the less likely is a false match. A more careful analysis might reveal trailing byte(s) that could be used:

 

eg.

find: <3d8408ec 1077> replace: <3d000000 0077>
find: <3d8508ec 1074> replace: <3d000000 0074>
find: <3d8419d4 1175> replace: <3d8302ec 1075>
With each byte added, however, you decrease the chances the patch will work with future versions of the binary.

Share this post


Link to post
Share on other sites

Generally speaking I don't like making the match string contain extra stuff that isn't being changed just to lower the chance of a false match. I think it'd be much better for the syntax to support an expect count, so the program can throw a warning if the match is being potentially mis-applied. The perl script does this now.

 

Going ahead and supporting a syntax for clover that doesn't allow for this is a bit of a step backwards. But if everyone is happy with sloppy matching, I can make this script output the XML as is... I think there are almost no cases where this has been burning folks so far.

Maybe not, but there is a bit of that out there :-)

Yes, and it'd be debatable whether there really is any violation going on. I just don't want to be putting up any such web page myself.

@bcc9 this is the wiki: http://wiki.osx86project.org/wiki/

you need something in particular? I can propose the changes you need..

Yes, that seems like the right place. I wasn't sure that was really being maintained; all the tech details seem to be buried into 1 flat FAQ. If the FAQ was broken out into a knowledge base for the main problem categories: Sound, video, bootloader, etc., then perhaps this info would be a sub-item within the main audio/sound knowledge base category.

Share this post


Link to post
Share on other sites

Ok, I've posted a new version that includes support for outputting a clover compatible XML configuration, instead of patching AppleHDA directly. The new version number is 3.3. New command line switch -x to enable this XML output. Example:

% ./patch-hda.pl 10ec0892 -c 2 -x
OSX version 10.9.2 detected
Default target codec: 10ec0892 detected.
Patching AppleHDA codec 11d4198b with 10ec0892
1 codec range comparison(s) to patch
Patching range comparison 11d41984
                        <dict>
                                <key>Name</key>
                                <string>AppleHDA</string>
                                <key>Comment</key>
                                <string>Expect 2 matches</string>
                                <key>Find</key>
                                <string>8419d411</string>
                                <key>Replace</key>
                                <string>00000000</string>
                        </dict>
                        <dict>
                                <key>Name</key>
                                <string>AppleHDA</string>
                                <key>Comment</key>
                                <string>Expect 2 matches</string>
                                <key>Find</key>
                                <string>8b19d411</string>
                                <key>Replace</key>
                                <string>9208ec10</string>
                        </dict>
% 
The above example works for me on my z87 system.

 

Now if clover would take an expect count here and report an error when there isn't a match, that'd make this work a lot better I think.

Share this post


Link to post
Share on other sites

Wow, yes the WIKI is "perfectable" :P:hysterical: ...

 

...but the new script is awesome!

 

...I'll send a PM to Slice, so to make see your post, then at least he will know this!

Thanks for your great work :lol:

 

Micky

Share this post


Link to post
Share on other sites

Hi,

I am very glad to see new method to work. Should I do anything for this?

Thanks. How about an <expect> XML keyword that takes an argument that is a number or a range, representing the number of times the <find>/<replace> pair should match? For example <key>expect</key><string>2</string> or <string>0-2</string> If the find/replace doesn't match the right expected number of occurrences, log an error.

Wow, yes the WIKI is "perfectable"

Yes a wiki will always be a moving target, never "done". But a wiki knowledge base built off of the popular, working guides could cut down on the need for so many newbie guides. Less to moderate at that point.

Share this post


Link to post
Share on other sites

Ok, I've posted a new version that includes support for outputting a clover compatible XML configuration, instead of patching AppleHDA directly. The new version number is 3.3. New command line switch -x to enable this XML output. Example:

% ./patch-hda.pl 10ec0892 -c 2 -x
OSX version 10.9.2 detected
Default target codec: 10ec0892 detected.
Patching AppleHDA codec 11d4198b with 10ec0892
1 codec range comparison(s) to patch
Patching range comparison 11d41984
                        <dict>
                                <key>Name</key>
                                <string>AppleHDA</string>
                                <key>Comment</key>
                                <string>Expect 2 matches</string>
                                <key>Find</key>
                                <string>8419d411</string>
                                <key>Replace</key>
                                <string>00000000</string>
                        </dict>
                        <dict>
                                <key>Name</key>
                                <string>AppleHDA</string>
                                <key>Comment</key>
                                <string>Expect 2 matches</string>
                                <key>Find</key>
                                <string>8b19d411</string>
                                <key>Replace</key>
                                <string>9208ec10</string>
                        </dict>
% 
The above example works for me on my z87 system.

 

Now if clover would take an expect count here and report an error when there isn't a match, that'd make this work a lot better I think.

 

Very cool. Thanks!

 

BTW, the entries starting with 'Conexant' do not work. There is some kind of problem with any name that starts with a valid hex digit!? Thus why I called mine 'Nexant' instead of 'Conexant'. Either all 'Conexant *' needs to change to something like 'Nexant *' or the bug in the script needs fixing...

 

Error results:

Couldn't find a codec map to apply for 'Conexant CX20752'.
This codec-id does not appear to be valid.  Aborting.
Even 'Nexant CX20752' does not work. Have to use something like 'Nexant 510f' (not sure if that works either -- got tired of testing different combos). Not sure what is going on here...

Share this post


Link to post
Share on other sites

 

Error results:

Couldn't find a codec map to apply for 'Conexant CX20752'.
This codec-id does not appear to be valid.  Aborting.

I don't have this error Here everything works fine.

Captura de Tela 2014-05-26 Ã s 20.06.46.png

Share this post


Link to post
Share on other sites

Error results:

Couldn't find a codec map to apply for 'Conexant CX20752'.
This codec-id does not appear to be valid.  Aborting.
I don't have this error Here everything works fine.

 

I'm talking about using the codec name instead of number...

 

# as in...
perl ./patch-hda.pl 'Conexant CX20752'

Share this post


Link to post
Share on other sites

Very cool. Thanks!

 

BTW, the entries starting with 'Conexant' do not work. There is some kind of problem with any name that starts with a valid hex digit!? Thus why I called mine 'Nexant' instead of 'Conexant'. Either all 'Conexant *' needs to change to something like 'Nexant *' or the bug in the script needs fixing...

 

Error results:

Couldn't find a codec map to apply for 'Conexant CX20752'.
This codec-id does not appear to be valid.  Aborting.
Even 'Nexant CX20752' does not work. Have to use something like 'Nexant 510f' (not sure if that works either -- got tired of testing different combos). Not sure what is going on here...

 

I second this, "Conexant xxxxx" input will cause error, and the problem is caused by this:

    if (hex($codec_arg)) {
	$target_id = hex($codec_arg);
	%codec_nums_to_name = reverse %codec_names_to_num;
	$target_codec_name = $codec_nums_to_name{$target_id};
    } else {
	$target_codec_name = $codec_arg;
	$targ

If I remove the condition, it's solved temporarily

$target_codec_name = $codec_arg;
$target_id = $codec_names_to_num{$target_codec_name};

Share this post


Link to post
Share on other sites

Thanks for the bug report on hex parsing & analysis. Now I get why you were using the "Nexant" shorthand in that codec table change.

 

So perl's built-in hex() function isn't sanity checking its input like I expected; I've added my own checking instead, and posted this as version 3.4.

Also, in the codec map tables, I renamed the new "Nexant" entry to Conexant, to match the other entries.

Share this post


Link to post
Share on other sites

Thanks for the bug report on hex parsing & analysis. Now I get why you were using the "Nexant" shorthand in that codec table change.

 

So perl's built-in hex() function isn't sanity checking its input like I expected; I've added my own checking instead, and posted this as version 3.4.

Also, in the codec map tables, I renamed the new "Nexant" entry to Conexant, to match the other entries.

Thanks... works great now...

Share this post


Link to post
Share on other sites

@bcc9...

 

Slight problem with the xml patch output. It should be data instead of string. Although both data and string work with Clover itself, Clover Configurator only handles data and tends to corrupt the patch if it is entered as string.

 

My changes:

sub output_xml_patch
{
    my $find, $replace, $count;
    my $pretty_indent;
    
    my $find_b64, $replace_b64;

    $find = hexstr($_[0]);
    $replace = hexstr($_[1]);
    
    $find_b64 = `echo -n "$find"|xxd -r -p|base64|tr -d '\n'`;#rehabman
    $replace_b64 = `echo -n "$replace"|xxd -r -p|base64|tr -d '\n'`\;#rehabman
    
    $count = $_[2];
    $pretty_indent = "\t\t\t";
    printf "%s<dict>\n", $pretty_indent;
    $pretty_indent = "\t\t\t\t";
    printf "%s<key>Name</key>\n", $pretty_indent;
    printf "%s<string>AppleHDA</string>\n", $pretty_indent;
    printf "%s<key>Comment</key>\n", $pretty_indent;
    printf "%s<string>Expect %d matches</string>\n", $pretty_indent, $count;
    printf "%s<key>Find</key>\n", $pretty_indent;
    printf "%s<data>%s</data>\n", $pretty_indent, $find_b64;#rehabman
    printf "%s<key>Replace</key>\n", $pretty_indent;
    printf "%s<data>%s</data>\n", $pretty_indent, $replace_b64;#rehabman
    $pretty_indent = "\t\t\t";
    printf "%s</dict>\n", $pretty_indent;
}

Share this post


Link to post
Share on other sites

1. That sounds like a bug in clover configurator that should be fixed there, not here.

The hex output is actually readable since the patches are just for hex codec ids. Converting the patches to data strings makes the patches unreadable.

2. I don't like your change as having perl convert the numbers to hex strings and then externally forking xxd to convert them back makes no real sense.

 

The XML I'm generating works as is if you aren't using clover configurator.

Share this post


Link to post
Share on other sites

1. That sounds like a bug in clover configurator that should be fixed there, not here.

The hex output is actually readable since the patches are just for hex codec ids. Converting the patches to data strings makes the patches unreadable.

2. I don't like your change as having perl convert the numbers to hex strings and then externally forking xxd to convert them back makes no real sense.

 

The XML I'm generating works as is if you aren't using clover configurator.

The xxd converts the hex "text" to binary as required by base64.

 

The wiki for config.plist states the patches should be data: http://clover-wiki.zetam.org/Configuration/KernelAndKextPatches#KextsToPatch

Share this post


Link to post
Share on other sites

Yes, I know xxd does, but it's rather senseless to convert from integer to hex string, back to binary, then to base64. My patch_codec routine already converts to binary, no xxd required. Perl even has base64 conversions functions available, though I haven't checked whether osx ships with these.

 

The wiki page you list is one of the ones I checked before making my xml code, and it includes an example that uses find/replace with hex as a string. The example doesn't work for kext binary patching though, as the example prefixes the hex strings with 0x, but that doesn't parse. Since the wiki is wrong, I had to check the code to see what is really supported, and that's how I knew how to format the hex strings correctly.

Per clover's GetDataSetting() routine:

 

"data can be specified in <data></data> base64 encoded

or in <string></string> hex encoded "

Share this post


Link to post
Share on other sites

Yes, I know xxd does, but it's rather senseless to convert from integer to hex string, back to binary, then to base64. My patch_codec routine already converts to binary, no xxd required. Perl even has base64 conversions functions available, though I haven't checked whether osx ships with these.

I never claimed to be an expert in perl. I was just fixing it for my purpose...

 

The wiki page you list is one of the ones I checked before making my xml code, and it includes an example that uses find/replace with hex as a string. The example doesn't work for kext binary patching though, as the example prefixes the hex strings with 0x, but that doesn't parse. Since the wiki is wrong, I had to check the code to see what is really supported, and that's how I knew how to format the hex strings correctly.

No. The example you refer to is an Info.plist patch not a binary patch (the 0x is thus perfectly valid).

 

Per clover's GetDataSetting() routine:

 

"data can be specified in <data></data> base64 encoded

or in <string></string> hex encoded "

Yes, I know both work, but one causes issues with CC, which I was pointing out. I haven't found a thread to report bugs on CC yet...

 

Maybe an option to output data/base64 is appropriate?

Share this post


Link to post
Share on other sites

The wiki under-specifies the syntax for find/replace, and includes examples of both hex and base64. The code clarifies that both are in fact legal formats, and there are several commands that take find/replace strings with hex, not just the one in question (the ati driver patch commands come to mind, though the keyword is different). So this other configuration program must be able to handle hex strings, and it's simply a bug that it is failing to do so in this case.

 

As for perl, sure, I'm not an expert either, but clearly converting in&out of a format needlessly is not great and isn't something I'd integrate.

 

Certainly an option to output base64 directly would be easy, though I still maintain that the result is unreadable whereas the current output is readable...

Share this post


Link to post
Share on other sites

How about vt1802?

i search binary patch for vt1802 so long time ago. I did with version 1.1 but it didn't work

somebody can help me please!

thanks

 

Hi iazzy

 

 

did you make it work, im struggling with that and can't find the solution

 

Mirone, that advice of yours for this codec where is it that i should find and replace?

 

thank you

bye

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Posts

    • Did you tried use ACPIBatteryManager.kext for the Battery? And for brightness you can use IntelBacklight  Both created by @RehabMan 
    • I have put it into clover drivers 64uefi folder on Yosemite thru High Sierra which allows me to edit my High Sierra disk if needed in Yosemite system.   There is no functionality of apfs in other versions but it does allow other clover bootloaders and systems to recognize the HS apfs drive or open it for inspection.   If you don’t have it you can’t see your HS drive or access it in another macOS version.
    • Hi! Is it possible to get codec AD1981 running with AppleHDA on HP Compaq 8710w? It works nicely with VoodooHDA. Speakers and HP are switching automatically.  Internal and HP mic also work - no switching in SysPref but it works when mic is plugged in and internal mic works when hp mic is unplugged.   It has same weird pathmap - connected directly:  Playback: nid=5 [pin: Speaker (Analog)] | + <- nid=3 [audio output] [src: pcm] bindSeq=00008001 nid=6 [pin: Headphones (Grey Left)] | + <- nid=3 [audio output] [src: pcm] bindSeq=00008001   But inputs are really weird. There are 5 nodes from input to HP mic/Internal mic nid=4 [audio input] | + <- nid=21 [audio selector] [src: mix] bindSeq=00000003 | + <- nid=12 [audio mixer] [src: mix] bindSeq=00000003 | + <- nid=30 [audio selector] [src: mic] bindSeq=00000001 | + <- nid=8 [pin: Microphone (Grey Left)] [src: mic] bindSeq=00000001 + <- nid=31 [audio selector] [src: monitor] bindSeq=00000002 | + <- nid=24 [pin: Microphone (Analog)] [src: monitor] bindSeq=00000002 Can pathmap like that even work with AppleHDA? What codec should I patch? I tried patches from AD1984 but no luck.    These are manually patched verbs: 00571c10 00571d01 00571e17 00571f90 00570C02 00671c20 00671d10 00671e21 00671f03 00771cf0 00771d00 00771e00 00771f40 00871c30 00871d10 00871e81 00871f03 00971cf0 00971d00 00971e00 00971f40 00a71cf0 00a71d00 00a71e00 00a71f40 01671cf0 01671d00 01671e00 01671f40 01771cf0 01771d00 01771e00 01771f40 01871c40 01871d01 01871ea0 01871f90 01971cf0 01971d00 01971e00 01971f40   Codecgraph and linux codecdump attached. Thx for any help or suggestions.              codec.txt 2.svg codec.txt
    •   Yes, 'cause APFS log is coming before clover boot screen.
    • and you suspect apfs on before clover issues  


×