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

[Mirone]

Do not know if insanely has a wiki for this, 

github would be a bad idea? 

Please correct me if I'm wrong.

[bcc9]

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.

[Micky1979]

Hi all,

 

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

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

 

Micky

[RehabMan]

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 :-)

[Mirone]

 

 

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?

[RehabMan]

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.

[bcc9]

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.

[bcc9]

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.

[Micky1979]

Wow, yes the WIKI is "perfectable" ...

 

...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

 

Micky

[Slice]

Hi,

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

[bcc9]

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.

[RehabMan]

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...

[Mirone]

 

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.

[RehabMan]

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'

[Mirone]

understood, but what changes in use the codecID or use the name of the codec?

[pokenguyen]

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};

[bcc9]

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.

[RehabMan]

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...

[RehabMan]

@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;
}

[bcc9]

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.

[RehabMan]

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

[bcc9]

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 "

[RehabMan]

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?

[bcc9]

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...

[rosendo]

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