Mirone Posted May 23, 2014 Share Posted May 23, 2014 Do not know if insanely has a wiki for this, github would be a bad idea? Please correct me if I'm wrong. Link to comment Share on other sites More sharing options...
bcc9 Posted May 23, 2014 Author Share Posted May 23, 2014 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. Link to comment Share on other sites More sharing options...
Micky1979 Posted May 23, 2014 Share Posted May 23, 2014 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 Link to comment Share on other sites More sharing options...
RehabMan Posted May 24, 2014 Share Posted May 24, 2014 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 :-) Link to comment Share on other sites More sharing options...
Mirone Posted May 24, 2014 Share Posted May 24, 2014 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? Link to comment Share on other sites More sharing options...
RehabMan Posted May 24, 2014 Share Posted May 24, 2014 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. 1 Link to comment Share on other sites More sharing options...
bcc9 Posted May 24, 2014 Author Share Posted May 24, 2014 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. 1 Link to comment Share on other sites More sharing options...
bcc9 Posted May 26, 2014 Author Share Posted May 26, 2014 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. 1 Link to comment Share on other sites More sharing options...
Micky1979 Posted May 26, 2014 Share Posted May 26, 2014 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 Link to comment Share on other sites More sharing options...
Slice Posted May 26, 2014 Share Posted May 26, 2014 Hi, I am very glad to see new method to work. Should I do anything for this? Link to comment Share on other sites More sharing options...
bcc9 Posted May 26, 2014 Author Share Posted May 26, 2014 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. Link to comment Share on other sites More sharing options...
RehabMan Posted May 26, 2014 Share Posted May 26, 2014 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... Link to comment Share on other sites More sharing options...
Mirone Posted May 26, 2014 Share Posted May 26, 2014 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. Link to comment Share on other sites More sharing options...
RehabMan Posted May 26, 2014 Share Posted May 26, 2014 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' Link to comment Share on other sites More sharing options...
Mirone Posted May 26, 2014 Share Posted May 26, 2014 understood, but what changes in use the codecID or use the name of the codec? Link to comment Share on other sites More sharing options...
pokenguyen Posted May 27, 2014 Share Posted May 27, 2014 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}; 1 Link to comment Share on other sites More sharing options...
bcc9 Posted May 27, 2014 Author Share Posted May 27, 2014 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. Link to comment Share on other sites More sharing options...
RehabMan Posted May 27, 2014 Share Posted May 27, 2014 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... Link to comment Share on other sites More sharing options...
RehabMan Posted June 2, 2014 Share Posted June 2, 2014 @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; } Link to comment Share on other sites More sharing options...
bcc9 Posted June 2, 2014 Author Share Posted June 2, 2014 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. Link to comment Share on other sites More sharing options...
RehabMan Posted June 2, 2014 Share Posted June 2, 2014 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 Link to comment Share on other sites More sharing options...
bcc9 Posted June 2, 2014 Author Share Posted June 2, 2014 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 " Link to comment Share on other sites More sharing options...
RehabMan Posted June 2, 2014 Share Posted June 2, 2014 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? Link to comment Share on other sites More sharing options...
bcc9 Posted June 5, 2014 Author Share Posted June 5, 2014 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... Link to comment Share on other sites More sharing options...
rosendo Posted June 6, 2014 Share Posted June 6, 2014 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 Link to comment Share on other sites More sharing options...
Recommended Posts