Nyaomi

Per la prima parte, mi illudevo che AirPortOpenBSD potesse avere uno spiraglio di senso per le schede ethernet Intel (sarebbe molto carino); Per la seconda parte, mannaggia, sta AX200 è inutile. Riconosco di aver sparato una baggianata con Ethernet, ma ormai sto cercando ogni spiraglio di speranza dopo la morte di SmallTree (e AppleIGB che non funziona per niente bene). Io purtroppo ho una I211.

Ma le features AirPort funzionano o no su questo kext? Io avrei voglia di switchare dato che non riesco a usare Continuity. Poi, funziona solo per WiFi e BT? Niente Ethernet?

Vi presento AMDFriend, uno strumento per riga di comando che è la perfetta combinazione della guida di @tomnicsul patching delle librerie per farle girare sugli hackintosh AMD e pigrizia e desiderio di semplice automazione. Come scritto sulla pagina GitHub: Istruzioni aggiornate su come installare, aggiornare e usare lo strumento son su GitHub (in inglese): https://github.com/NyaomiDEV/AMDFriend. Questo strumento non rimpiazza in nessun modo il patching manuale (per ora), dato che occhio e cervello umani son sicuramente più capaci di un pattern matcher; ma già adesso esso riesce a patchare alcune librerie comuni (trovate in After Effects, Photoshop, Premiere Pro, Discord, possibilmente anche altre). Quindi, perché questo strumento è differente rispetto ai comandi `perl` comunemente usati? Per iniziare, esso usa le espressioni regolari come esse dovrebbero essere usate, cioè, lo strumento accoppia sempre dei pattern e mai delle stringhe esatte o set di stringhe. Questo comportamento gli dà l'abilità di esser flessibilmente usato per molti programmi e revisioni differenti dello stesso programma; qualcosa che non era stato fatto prima. Per esser chiari, questo comportamento è replicabile anche usando solo comandi `perl`, ma avere uno strumento per fare patching anziché comandi lunghi è sempre più carino. Qual è l'immediato futuro di questo strumento? Spero di raggiungere un punto di stabilità generale dove esso possa far matching almeno della roba super comune in modo super affidabile, e la roba meno comune in modo più o meno affidabile; spero di raggiungere questo risultato con contributi della comunità, dato che non posseggo tantissimo software con cui testare lo strumento, quindi se tu che leggi hai un'applicazione che ha bisogno di patching, per favore, fammelo sapere! E quali sono i piani nel medio termine? Dopo che lo strumento raggiunge la stabilità generale, probabilmente scriverò una GUI semplice in Electron che verrà usata per dare un appeal allo strumento anche nei confronti di gente che non è molto addentrata nel mondo dell'informatica, e questo taglierà via il bisogno di preoccuparsi di installare Homebrew, NodeJS e Yarn nel sistema. Nel frattempo, spero di poter migliorare lo strumento al punto da essere stabile e più veloce possibile, il che mi permetterebbe di fare più cose con esso (per esempio, trascinare un'applicazione sulla finestra dello strumento per patchare tutte le sue librerie "problematiche" su AMD). Crediti @tomnic e @fabiosun dato che loro sono stati i tester iniziali (a sorpresa di nessuno, mi sa); anche, tomnic ha scritto la guida iniziale ed è quello il punto cardine che permette l'esistenza di questo strumento.

Parallels (così come altre soluzioni all'infuori di VirtualBox) dipende da AppleHV che correntemente non gira su AMD. Versioni veramente datate di Parallels, come la 13.1.0, possono funzionare ma è un enorme rischio per la sicurezza del sistema.

The discussion thread is available here:

Note: There are at least two known variants of this method, https://github.com/Carnations-Botanica/IntelMKLFixup and https://github.com/JonathanFerraz/FriendlyAMD please remember to quote and/or write in this thread for discussing and talking with us about forking and developing this methodology. Work must be respected! This is the discussion thread that references this post: Feel free to discuss, share excitement, errors and whatnot! Let's bring AMD hackintoshes on par with their Intel counterparts!

Note: There are at least two known variants of this method, https://github.com/Carnations-Botanica/IntelMKLFixup and https://github.com/JonathanFerraz/FriendlyAMD please remember to quote and/or write in this thread for discussing and talking with us about forking and developing this methodology. Work must be respected! I present you with AMDFriend, a command-line tool that is the perfect combination of @tomnic 's guide on patching libraries for AMD hackintoshes and laziness and desire for simple automation. As stated in the GitHub page: Up to date instructions on how to install, update and use it are on GitHub: https://github.com/NyaomiDEV/AMDFriend. This in no way replaces manual patching (for now), as a human's eye and brain are certainly more capable than a pattern matcher; but it already successfully patches some common libraries (found in After Effects, Photoshop, Premiere Pro, Discord, possibly more). So, why is this different than the commonly used `perl` commands? For starters, this actually uses regular expressions as they are supposed to be used, meaning that it always matches a pattern and it never matches an exact string or set of strings. This gives it the ability to be flexible across programs and different revisions of the same program; something that wasn't achieved before. To be clear, this kinda usage is achievable with just `perl` commands, but having a tool to do it instead of long commands is always nicer. What's the immediate future of this tool? I hope to reach a point of general stability where it matches at least the super common stuff super reliably, and the less common stuff more or less reliably; I hope to achieve this with community contributions, since I don't own a lot of software to test the tool with, so if you have a need-to-be-patched application please report back! And what are the mid term plans? After the tool reaches general stability, I will probably write a simple GUI in Electron that will be used to make the tool appealing also to non-tech-savvy users, and it will also cut the need to worry about Homebrew, NodeJS and Yarn being installed in the system. Around this time, I hope to get the tool into a position to be stable and as fast as possible, so that more things can be done about patching (for example, dragging an application to the tool's window to patch all of its AMD-unsafe libraries). Credits @tomnic and @fabiosun since they were the initial testers (as a surprise to no one, I guess); also tomnic wrote the initial guide and that's like the whole point of this tool existing.

Reporting in to give some more information about PS library patching: From my research, those framework libraries have intel specific calls and are not patched (by tomnic's guidelines): - libiomp5.dylib (probably shared with AE and PR) - libmkl_avx512.dylib (probably also shared) - libmkl_avx2.dylib - libmkl_mc3.dylib - libippiy8.dylib - libippil9.dylib - libippik0.dylib (what do those three libs offer?) And it seems we're missing the "Shake Reduction" plugin! EDIT: Added my version (remember to codesign it), but sadly I am still using 23.2.0 PS 23.2.0 Shake Reduction.zip

From extensive research, those other two plugins needed patching: - AEFilterLumetri - AEFilterMask Here they are in their patched version. Remember to codesign! PR 22.1.2 AE Filters 2.zip

Patched libraries to make Premiere Pro 22.1.2 work on AMD Hackintoshes. REMEMBER THIS IS NOT A CRACK! Those libraries go to: /Applications/Adobe Premiere Pro 2022/Adobe Premiere Pro 2022.app/Contents/Frameworks Remember to codesign! AE Filters are in the post below! PR 22.1.2 Frameworks.zip Patched AE effects for Premiere Pro 22.1.2 / AMD Hackintoshes. Those plugins go to the respective bundles in: /Applications/Adobe Premiere Pro 2022/Adobe Premiere Pro 2022.app/Contents/Plug-Ins/Common/<AE Filter Name>.bundle/Contents/MacOS Remember to codesign and to mark as executable! Notes: AEFilterMorphCut dropped the intel CPU check! PR 22.1.2 AE Filters.zip

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

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.

...e scoprì che anche loro, come me, godono del frutto proibito. Salve a tutti! Mi chiamo Naomi e giro un hackintosh da relativamente poco tempo, per motivi legati allo studio in accademia d'arte. La mia build è una improvvisata e imperfetta, che descrivo di seguito: - ASRock X570 Taichi - Ryzen 7 3800XT - Sapphire Nitro+ RX 580 8GB - 32GB RAM - SSD SATA Samsung 870 EVO da 500GB per il boot - MacOS Big Sur (di cui onestamente non sto a citare l'esatta versione, che non ricordo) su OpenCore 0.7.8 Non ho comprato addon cards e roba extra e cerco di usare ciò che già ho, o meglio non ho, dato che la vita su Ryzentosh è fatta di continue privazioni (per ora si spera). Piacere di esser parte di questa avventura!

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?