[Discussion] Tutorial for patching binaries for AMD Hackintosh compatibility

[fabiosun]

In this thread we can discuss about any tips/tricks about this guide:

 

 

[Nyaomi]

I am not sure if the method described can be then generalized by pattern matching instead of hard find/replace. If we can match a pattern, then I'd assume someone can also make an userspace library patcher that works without having to disassemble the library code every time. Also, how do you guys patch libraries as of now? Do you decompile each and every library or do you just find and replace in the hex editor?

[tomnic]

Hi Nyaomi, as you can read directly on the guide we look for the crashing libs analyzing the apple crash report, then we open each library with a decompiler (hopper) looking for the three mentioned "intel only" procedures and finally we patch each one of them with HexFiend.

 

They say in the discord that a Lilu plugin isn't possible on Big Sur+ macOS revisions... So this is the only way to successfully patch apps for AMD right now.

[Nyaomi]

On 3/2/2022 at 1:22 PM, tomnic said:

Hi Nyaomi, as you can read directly on the guide we look for the crashing libs analyzing the apple crash report, then we open each library with a decompiler (hopper) looking for the three mentioned "intel only" procedures and finally we patch each one of them with HexFiend.

 

They say in the discord that a Lilu plugin isn't possible on Big Sur+ macOS revisions... So this is the only way to successfully patch apps for AMD right now.

 

Yeah, I did read that, sadly enough.

However, what about writing a routine that finds and patches libraries? I've been wanting to write one, but I need to know if I understood what's explained in the guide correctly enough.

 

For example, you cite this sequence of bytes as the most general one yet for __mkl_serv_intel_cpu_true:

 

53 48 83 EC 20 8B 35 xx yy zz ww

 

Then you say that bytes xx, yy, zz and ww are different from each other, but different how? Let me give out two example cases and you'll tell me if I am correct on my interpretation.

 

Case 1: 53 48 83 EC 20 8B 35 63 1A 00 1D
Case 2: 53 48 83 EC 20 8B 35 63 1A 63 1D

 

In case 1 we have bytes all different from each other, while in case 2 bytes xx and zz do match. Then, is the first one the "correct" one to search for?

 

--

 

Now, for __intel_fast_memset.A and __intel_fast_memcpy.A, you wrote this sequence of bytes:

 

xx xx xx xx 56 E8 yA 00 00 00 59 C3

 

Now, the nibble part is simple and it can be checked against pretty easily; but the xx bytes, you said they are all equal to FF or 90. As I interpret this, I imagine three scenarios:

 

Case 1: 90 90 90 90 56 E8 yA 00 00 00 59 C3
Case 2: FF FF FF FF 56 E8 yA 00 00 00 59 C3
Case 3: 90 FF 90 FF 56 E8 yA 00 00 00 59 C3

 

Now, giving for granted that the first two example cases are correct, is the third one also correct?

 

With this kind of information, I could seriously begin to write a prototype that finds those patterns, matches a set of rules, and automates the dirty work for us all.

[tomnic]

For __mkl_serv_intel_cpu_true I mean that after the FIXED sequence 53 48 83 EC 20 8B 35 you will have other four RANDOM bytes, they CAN be all different as case 1 but they can also be as case 2, to be more clear:

 

53 48 83 EC 20 8B 35 01 02 03 04
53 48 83 EC 20 8B 35 01 01 02 03
53 48 83 EC 20 8B 35 01 01 01 02
53 48 83 EC 20 8B 35 01 01 01 01

 

Can be all possible matches.

 

Speaking with find masks you need to find, for instance: 

 

FIND: 53 48 83 EC 20 8B 35 D1 C1 A2 23
MASK: FF FF FF FF FF FF FF 00 00 00 00

 

FF means find the EXACT byte, 00 means find WHATEVER byte.

 

For the fastmem routines only case 1 and case 2 can happen, speaking with find mask as above:

 

FIND: 90 90 90 90 56 E8 5A 00 00 00 59 C3
MASK: FF FF FF FF FF FF 0F FF FF FF 00 00

 

FIND: FF FF FF FF 56 E8 4A 00 00 00 59 C3
MASK: FF FF FF FF FF FF 0F FF FF FF 00 00

 

I've found out just today patching the PyTorch libraries that the last two bytes can change, thus the 00 00 final part of the mask.

 

I hope this is clearer than before 😉

 

It would be nice to have a working tester and patcher, I mean your program could also be used to detect and show possible matching patterns before actually patch the binary, giving it just an input folder. And don't forget to write code to recodesign all the patched binaries!!! It is important as @fabiosun always remembers me!

[Nyaomi]

Okay, so, as general thoughts the find pattern for __mkl_serv_intel_cpu_true would be, in a regex, the following:

 

\x53\x48\x83\xEC\x20\x8B\x35[\s\S]{4}

 

and for the others, the masked regex would be:

 

(\xFF{4}|\x90{4})\x56\xE8(?:\x6A|\x5A|\x4A|\x3A)\x00\x00\x00([\s\S]{2})

 

Now, does anyone love PCRE around here? I sure do.

 

The next step is putting the replace patterns in a regex, so for the first one, essentially, the replace is

 

\x55\x48\x89\xE5\xB8\x01\x00\x00\x00\x5D\xC3

 

For the second one, things get tricky:
 

\1\x56\xE8\x0A\x00\x00\x00\2

 

where \1 and \2 are direct references to what we matched earlier.

 

Now, this should in theory work with PERL, so if anyone wants to plug 'em into a command, be my guest.

 

EDIT: Commands? Here they are!

 

perl -i -pe 's/\x53\x48\x83\xEC\x20\x8B\x35[\s\S]{4}/\x55\x48\x89\xE5\xB8\x01\x00\x00\x00\x5D\xC3/sg' /path/to/library.dylib

perl -i -pe 's/(\xFF{4}|\x90{4})\x56\xE8(?:\x6A|\x5A|\x4A|\x3A)\x00\x00\x00([\s\S]{2})/\1\x56\xE8\x0A\x00\x00\x00\2/sg' /path/to/library.dylib

 

Edited March 9, 2022 by Nyaomi
add commands

[Driftwood]

Have you done Waves plugins? trying to demo Clarity FX and doesnt seem to open on AMD / causes crash in Davinci - others plugins work from Waves!