Leaderboard

23-2-0-libmkl_core.dylib 23-2-0-Adaptive Wide Angle.plugin 23.2.1-Adaptive Wide Angle 23.2.1-libmkl_core.dylib 23-2-1_Shake Reduction Shake reduction problem discovered by @Nyaomi(thank you) enjoy!

Grazie! l’idea era di tenerlo originale, è un Mac “da show” .. È ancora work in progress quindi sono aperto a spunti per migliorare l’airflow! Attendo con ansia 🙂

si certo ma puoi decidere se attivarla. o meno..importante e' uscire dallo schermo nero 🙂

tu non consideri il fatto @savana88che molti che sono felici con quella piattaforma usano la scheda grafica discreta e non solo l'interna Farei attenzione a questo dettaglio 😉

si infatti ho avuto problemi di ram Sudo chmod 755 fatto …. Ma non va. ne riparliamo lunedì , oggi ho finito la libera uscita, appena posso mi ci rimetto con calma. Probabilmente non ho bisogno di rifare il kext tuttavia la prima volta non mi aveva dato quella risposta: non mi ha mai negato i permessi. Grazie per l’aiuto e scusami se ti rompo. 🙏

Asus, Asrock, Gygabyte, Msi .....alla fine ho seguito la strada di @Gengik84, non avevo voglia di "sbattermi troppo" per il mio ritorno in Hack ,dopo la mia love story con il mio Macbook pro 🥰 . Asrock extreme 4 non mi ha deluso . Anche se come si vede dalla mia firma ho fatto un hack senza troppi problemi con una Msi.

Some History, facts and strategy Certain Mac apps use the infamous Intel MKL libraries, now called Intel OneAPI: those libraries are x86_64 compliant but in the macOS porting certain functions are intended to work only on genuine intel cpus: these are __intel_fast_memset.A and __intel_fast_memcpy.A. We can fool these libraries redirecting their calls to __intel_fast_memset.J and __intel_fast_memcpy.J which both work perfectly on AMD Hackintoshes, and as fast as possible given the fact that we lack AVX512. But we also need to fool them changing the function __mkl_serv_intel_cpu_true returning TRUE even when running on AMD cpus!!! This fix is based on Daniel de Kok's hint on his brilliant article https://danieldk.eu/Posts/2020-08-31-MKL-Zen.html given that the old trick of setting the environmental variable MKL_DEBUG_CPU_TYPE to 5 has been deprecated by Intel for obvious reasons on rather recent MKL libs implementations. Using only these three "patches" we can virtually make every Intel only app run on our AMD Hacks natively without using hypervisors and without bypassing or deleting important functions / files of our specific app. I'm trying to write a tutorial to make everybody who has a very minimal knowledge of x86_64 assembly and machine language code able to patch any offending binary for AMD cpus. The goal is trying to keep bare metal execution of macOS instead of circumventing any issue using macOS virtualization, which I think is more complex and can be used profitevoly only in high end configurations (16 cores or more, 64 gigs of ram or more). With modern kernel patches the execution of the mach vanilla kernel is virtually perfect, not losing any kind of GPU performance: https://github.com/AMD-OSX/AMD_Vanilla. The procedure in detail To start searching for the correct hex patterns we can use two really useful programs: one is Hexfiend (I use version 2.14.1), an Hex Editor for macOS, which is totally free, and the other one is Hopper (I use version 5.3.1-demo), a disassembler, which is not free but is sufficient for us to "look into" suspect binaries in the search of those three procedures in the demo version, which is free for 30 minutes. So fire up Hopper and click Try the demo: Drag and drop a "suspect" binary, like libtbb.dylib, found in numerous app like Autodesk Autocad 2022 and Maya 2022: Leave all the default options on, be sure to keep Mach-O 64bits as Loader selected (here you could select other type of architectures if found in the binary). Configure the preferences according to this screen: Now wait for some time to let Hopper disassemble all the binary (some minutes for the biggest ones), write to the top left side of the main windows the word "Intel", select Proc. next to the box you've just written and you should get this screen: Focus your attention to the list of the procedures in the left part of the window: you can clearly see __intel_fast_memcpy.A and __intel_fast_memset.A in this binary. Let's click on the first procedure: The first number of this part of the window is 0x000000000035350: it is the Offset (your position in the binary), the second, 56, is the Machine Language translation of its mnemonic Assembly command push rsi: it uses only one byte of memory... after the ; you can read a human readable comment. The second line, 0x000000000035351, one exact byte later, has 5 bytes of code: E8 6A 00 00 00, and it means call (E8) the procedure which starts 00 00 00 6A bytes ahead (byte's order of data is reversed in x86 machine language and the Assembly call function needs four signed bytes after it, positive for a jump ahead, negative for a jump backwards) which is __intel_fast_memcpy, confirmed by the comment. We need to change this line of code to call __intel_fast_memcpy.J, which starts 0A (ten in decimal) bytes ahead so that it will become: 0x000000000035351 E80A000000 call __intel_fast_memcpy.J ; ... You can easily verify that at the end the __intel_fast_memcpy.J calls the AMD compatible procedure ___intel_new_memcpy. Using a familiar approach with Clover / OC Kernel patches (excluding bit masks) we can say: Find: 56 E8 6A 00 00 00 59 C3 Replace: 56 E8 0A 00 00 00 59 C3 We can easily do this using Hexfiend, open it and drag your binary into its main window, go to the program's menu and select Edit -> Find -> Find..., choose hex, put Find values in the top write field, Replace values in the second one, hit Next and the found pattern should be highlighted, finally hit Replace: Note: only one instance of the Find pattern must be found and replaced. Save the patched binary (on the desktop for example for now), let's double check our work opening it with Hopper and clicking on the __intel_fast_memcpy.A procedure: Yes, the line 0x000000000035351 appears exactly as we wanted! Good work... If something looks different, try again following the instructions from the beginning of this tutorial or ask for further explanations in this thread: Next, we can go on patching the __intel_fast_memset.A procedure. Same kind of work, click on this procedure in Hopper and inpect the code: ...let's focus our attention to its code: ...similarly to the latest patching procedure we need to change the second line (offset 0x000000000035481) to: 0x000000000035481 E80A000000 call __intel_fast_memset.J ; ... ...in Find / Replace terms: Find: 56 E8 4A 00 00 00 59 C3 Replace: 56 E8 0A 00 00 00 59 C3 Use Hexfiend exactly as before remembering only to replace one instance of the found hex pattern, save the binary to the desktop, open it with Hopper, select the __intel_fast_memset.A procedure and double check the resulting patched code with Hopper: Great! Even this time the AMD compatible J revision is called correctly as expected with our simple patch, and this revision finally calls the AMD friendly ___intel_new_memset procedure. Overwrite the original unpatched binary with yours on the desktop, then don't forget to recodesign it with this terminal command: sudo codesign --force --deep --sign - /path/to/the/binary/file.ext Note: using the offsets to find the hex patterns is not always a good idea because the way Hopper and Hexfiend calculate them could be different and with the demo version of Hopper we cannot directly write changes to files. Now we must explain how to patch the __mkl_serv_intel_cpu_true procedure, let's try with the krisp binary: open it with Hopper. If Hopper finds a FAT binary select 64 bit Intel Architecture and then always Mach-O 64 bit structure. Always write Intel on the procedure searching box then wait for Hopper to stop decompiling everything... finally click on the __mkl_serv_intel_cpu_true string: ...switch to the "recompiled" c view in Hopper and we can see that this procedure does a specific series of tests on the CPU registers to find out if you're running your code on an authentic Intel processor. Focusing on the Machine language code, the original procedure is 53 48 83 EC 20 8B 35 19 CC 67 04... and so on (85 F6 7C 08...): _mkl_serv_intel_cpu_true: 0x0000000100256440 53 push rbx ; ... 0x0000000100256441 4883EC20 sub rsp, 0x20 0x0000000100256445 8B3519CC6704 mov esi, dword [_cached.601.0.6] ; ... 0x000000010025644b 85F6 test esi, esi 0x000000010025644d 7C08 jl loc_100256457 loc_10025644f: 0x000000010025644f 89F0 mov eax, esi ; ... 0x0000000100256451 4883C420 add rsp, 0x20 0x0000000100256455 5B pop rbx 0x0000000100256456 C3 ret ; endp What can we use as a replace? We can easily cheat creating a function which always returns true without any register testing at all and replacing the original one, so as you can see using Hopper this Assembly code (which is in x86 Machine Language 55 48 89 E5 B8 01 00 00 00 5D C3) _mkl_serv_intel_cpu_true: 0x0000000100219580 55 push rbp ; ... 0x0000000100219581 4889E5 mov rbp, rsp 0x0000000100219584 B801000000 mov eax, 0x1 0x0000000100219589 5D pop rbp 0x000000010021958a C3 ret ; endp ...is the same than this trivial C code program: function _mkl_serv_intel_cpu_true { return 0x1; } What if we do this Find / Replace? Find: 53 48 83 EC 20 8B 35 19 CC 67 04 Replace: 55 48 89 E5 B8 01 00 00 00 5D C3 Just like with the other two patched procedures above, open Hopper and drag your binary into its main window, go to the program's menu and select Edit -> Find -> Find..., choose hex, put Find values in the top write field, Replace values in the second one, hit Next and the found pattern should be highlighted, finally hit Replace... again make sure to do this only once and double check the results with Hopper opening the patched binary, the __mkl_serv_intel_cpu_true needs to appear as in this picture: Note that we can stop at 11 bytes in the find pattern since the replace ends with C3 which is a RET Assembly instruction: take it as "a kind of an END", so even if the original procedure was longer when we call the patched one the code beyond the 11 patched bytes won't be executed, ever! Always remember to overwrite the unpatched binary and recodesign the patched binary: sudo codesign --force --deep --sign - /path/to/the/binary/file.ext The final result is that even with an AMD CPU our patched Intel testing procedure always returns TRUE, fooling the binary that it is running on a Genuine Intel processor. Combining this with the two above patches virtually any problematic app for our AMD Hackintosh can be run without crashes, without deleting program functionalities, but only modifying what is needed, not any byte more, even with SIP enabled. How can I find which binaries do I need to patch? The crash log of our problematics apps are very useful to get a list of libraries to get patched: the info you get from the crashed thread is crucial. For example, if we try to run the latest Krisp we can get this crash log: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: krisp [56056] Path: /Applications/krisp.app/Contents/MacOS/krisp Identifier: ai.krisp.krispMac Version: 1.32.16 (1.32.16) Code Type: X86-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2022-02-19 12:53:40.1955 +0100 OS Version: macOS 12.2.1 (21D62) Report Version: 12 Anonymous UUID: 904323A8-BF9D-B98D-DD83-B25231CAC583 Time Awake Since Boot: 480000 seconds System Integrity Protection: disabled Crashed Thread: 0 Dispatch queue: ai.krisp.vp Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0x00007ff7b9356ff8 Exception Codes: 0x0000000000000002, 0x00007ff7b9356ff8 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [56056] VM Region Info: 0x7ff7b9356ff8 is in 0x7ff7b5b57000-0x7ff7b9357000; bytes after start: 58720248 bytes before end: 7 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL MALLOC_MEDIUM (reserved) 7f9e1f800000-7f9e20000000 [ 8192K] rw-/rwx SM=NUL ...(unallocated) GAP OF 0x5995b57000 BYTES ---> STACK GUARD 7ff7b5b57000-7ff7b9357000 [ 56.0M] ---/rwx SM=NUL ... for thread 0 Stack 7ff7b9357000-7ff7b9b57000 [ 8192K] rw-/rwx SM=PRV thread 0 Thread 0 Crashed:: Dispatch queue: ai.krisp.vp 0 libtbbmalloc.dylib 0x10bdd22d1 _intel_fast_memset.A + 1 1 libtbbmalloc.dylib 0x10bdd22d6 _intel_fast_memset.A + 6 Thread 1: 0 libsystem_pthread.dylib 0x7ff81dc66fec start_wqthread + 0 As you can see the offending binary, libtbbmalloc.dylib, can easily be detected by the crashed thread, which is Thread 0 in this case, and even the offending procedure can be deduced clearly: _intel_fast_memset.A If you patch only this lib and this procedure and try to run again Krisp you will find new infos in the new crash log, _intel_fast_memcpy.A in the same libtbbmalloc.dylib, then running again and analyzing the last crashlog libtbb.dylib with _infel_fast_memset.A and then _intel_fast_memcpy.A and so on, till the app running error free just like on Intel hackintoshes. It's a process of trial and error. Sometimes the app seems to work perfectly but triggering one or more specific functions in its menu makes it hanging or crashing... Generally in the crash logs take note of all the libraries loaded in all the threads, exclude the Apple System ones which are always compatible, focus on the third party ones... 70% of the time they are part of the MKL suite, 10% part of the Intel Threading / IO system, 10% third party ones (for example GenericMacIntel.dylib or AVXMacIntel.dylib in Waves) and sometimes the main app binary is also a possible candidate to be patched. You may also need to search the possible offending files in "/Library/Application Support/Appname" or "~/Library/Application Support/Appname" if you can't figure out them in the canonical Application folder. Which applications work with these patches? The list of apps I've found and verified totally working by now is in this thread (the list is growing): Can we generalize / automatize this method? If you follow my tutorial point by point for every binary you will find out the EXACT pattern to be searched and replaced for each procedure incompatible with AMD to be patched. But during the patching of many possible binaries we can find out some variations in the Find hex pattern... for __mkl_serv_intel_cpu_true the most generic find is, besides being always 11 bytes long: Find: 53 48 83 EC 20 8B 35 xx yy zz ww where xx yy zz ww are generic bytes, different one from another, and the replace is always: Replace: 55 48 89 E5 B8 01 00 00 00 5D C3 With __intel_fast_memset.A and __intel_fast_memcpy.A functions we need to expand the search pattern to avoid patching wrong regions of our binary: Find: xx xx xx xx 56 E8 yA 00 00 00 59 C3 where xx are 4 bytes all equal to 90 or FF and y is a nybble (half a byte) equal to 6, 5, 4 or 3 Replace: xx xx xx xx 56 E8 0A 00 00 00 59 C3 We should use perl to do searching and replacing using this syntax, taking as an example a Waves 12 specific plugin to be patched, but we cannot use find/replace masks, only direct searching: sudo perl -i -pe 's|\x90\x90\x90\x90\x56\xE8\x4A\x00\x00\x00\x59\xC3|\x90\x90\x90\x90\x56\xE8\x0A\x00\x00\x00\x59\xC3|sg' /Applications/Waves/Plug-Ins\ V12/ArtistDlls1.14_12.7/1196704578.bundle/Contents/MacOS/GenericMacIntel.dylib s|\x90\x90\x90\x90\x56\xE8\x4A\x00\x00\x00\x59\xC3 is the find string byte by byte |\x90\x90\x90\x90\x56\xE8\x0A\x00\x00\x00\x59\xC3 is the replace string byte by byte We could try to create a Lilu's plugin, or an EFI module, to intercept and patch such patterns in memory on the fly, but this goes beyond my skills. I'll leave this possibility open to the most advanced coders / developers here. I hope everything is crystal clear... remember to post here your comments / doubts / improvements / critics: Tomnic

Ho fatto una lista dei device-id supportati ad ogni versione di macOS e messo tutto su un foglio excel, così gli utenti possono avere almeno un'idea sul fatto che una data versione di macOS possa riconoscere o meno un dato device-id https://docs.google.com/spreadsheets/d/1CNrDxBsmCbCTL_y9ZB7m3q3jHw5X2N8YaYb7IonQ3MI/edit#gid=0 Non ho incluso fake-id possibili o kext in aggiunta per sistemare il supporto di vecchie schede per mantenere la lista più pulita possibile. In futuro probabilmente vedrò se si potrà aggiungere qualcosa, una nota o simili per dire "guarda questa scheda con un device-id diverso funziona"

no, better to post here (in an external link) both files to be patched or if you like follow @tomnictutorial you can find here:

Mds Store ok confermo, ma tieni presente che non ho (avevo) la beta. mai avuto quel problema su BS (Big Sur oppure Bici Sport noto mensile da ciclisti) ma su Monterey avevo risolto lanciando da terminale il comando di indicizzazione di spotligth (che richiederà un pò di tempo per essere completata). Adesso non riesco a ritrovare su google la fonte ma domani, max lunedì da casa dovrei poterla linkare se ti interessa. Siu Daemons avevo eseguito altri comandi (tipo sudo killal????) ma è moooolto probabile che abbiano sputtanato parecchia roba. Tanta. "Ora -pausa di sospensione- si da il caso che siano anni... che chiamo PS PS ma, -breve pausa- EVIDENTEMENTE -altra breve pausa- qualcuno ha ancora voglia di ironizzare... vero signor Potter?" Immaginatelo detto con la voce e il tono di Severus Piton.

buonasera, e benarrivato ma io leggo solo in notturna di giorno porto gli occhiali e non vedo bene 🤣