[Release] Hackintool v3.x.x

[zzmadd]

Can you copy your config.plist to your desktop and apply the patch using Hackintool then attach both your working config.plist and the one patched by Hackintool so we can compare the two.

Hi, thanks for your reply!!

I've created a tex file with the two patches:
one from the TonyMac Thread, the other from Hackintool.

I guess al the rest of the config is not necessary.

 

[headkaze]

Hi, thanks for your reply!!

I've created a tex file with the two patches:
one from the TonyMac Thread, the other from Hackintool.

I guess al the rest of the config is not necessary.

Let's focus on one setting from the two configs: framebuffer-con0-pipe

First of all looking at the official ASRock Z390M-itx/ac and Coffee Lake CPU config at the bottom of the thread, the value is set as:

                <key>framebuffer-con0-pipe</key>
                <data>
                EgAAAA==
                </data>

According to the configs you sent the value applied by Hackintool is:

                <key>framebuffer-con0-pipe</key>
                <data>
                EgAAAA==
                </data>

But your working config has the value as:

                <key>framebuffer-con0-pipe</key>
                <data>
                CQAAAA==
                </data>

So as far as I can tell Hackintool is applying the patch correctly. So it looks like you're actually applying one of the Gigabyte or MSI Z390M patches and not the ASRock one.

 

[headkaze]

Hackintool v2.4.0 Released
- Now includes iMessageDebug data (ElNono / mdmwii / flux84 / sugarface / pokenguyen)
- Export system info data
- View model info (everymac.com)
- Check serial feature
- Preliminary OpenCore support (thanks vit9696)

 

[dracon]

Hackintool v2.4.0 Released
- Now includes iMessageDebug data (ElNono / mdmwii / flux84 / sugarface / pokenguyen)
- Export system info data
- View model info (everymac.com)
- Check serial feature
- Preliminary OpenCore support (thanks vit9696)

Would it be possible to follow the original authors repo for IntelMausiEthernet (https://github.com/Mieze/IntelMausiEthernet). It's a newer version in the repo than RebhabMan's since it's the original author of the kext.

 

[headkaze]

Would it be possible to follow the original authors repo for IntelMausiEthernet (https://github.com/Mieze/IntelMausiEthernet). It's a newer version in the repo than RebhabMan's since it's the original author of the kext.

Done

 

[zzmadd]

Let's focus on one setting from the two configs: framebuffer-con0-pipe

First of all looking at the official ASRock Z390M-itx/ac and Coffee Lake CPU config at the bottom of the thread, the value is set as:

                <key>framebuffer-con0-pipe</key>
                <data>
                EgAAAA==
                </data>

According to the configs you sent the value applied by Hackintool is:

                <key>framebuffer-con0-pipe</key>
                <data>
                EgAAAA==
                </data>

But your working config has the value as:

                <key>framebuffer-con0-pipe</key>
                <data>
                CQAAAA==
                </data>

So as far as I can tell Hackintool is applying the patch correctly. So it looks like you're actually applying one of the Gigabyte or MSI Z390M patches and not the ASRock one.

Thanks for your reply!
Indeed my working config has a weird data.
But still the version from the thread and from hackintool are different.

I now corrected my config.plist with the on from the thread.
Thanks

 

[headkaze]

now corrected my config.plist with the on from the thread.

I'm not going to spend my time comparing the two. I already proved you were patching using data other than you claimed. It's now your job to prove to me there is a bug or problem with Hackintool rather than your patching process.

 

[zzmadd]

Fair enough.
It's like if Hamilton was saying let's meet at the end of a F1GP.
If you win I listen to you. How in god's sake do I have the knowledge to prove to you that you are the app developer.

You're saying the two patches are the same.
Look at the attached picture.
The two versions of the patch. The second (Tonymac thread version) is twice as long.
All I'm saying is they differ. They're not the same. And by pasting the Hackintool one I had plenty of freezes.

 

[headkaze]

The two versions of the patch. The second (Tonymac thread version) is twice as long.
All I'm saying is they differ. They're not the same. And by pasting the Hackintool one I had plenty of freezes.

Hackintool only patches data that differs from the default values so that could account for the the Tonymac version being longer.

Try this. Make sure you're running Hackintool v2.4.0. Click the Mine button (little eye button next to Platform ID) so you are on your system's correct Platform ID. Go to the Connectors tab and apply the Z390M patch. You can see what changes the patch makes to them. Take a screenshot of them. Then click the Reload button (little round arrow button next to the Platform ID) and it should put the Connector data back to defaults. Now import your working config.plist and it should now apply the patches to the Connectors. Take another screenshot. Are they the same?

So at the very least doing this will allow us to see if the two patches are the same. After this we can then look at values the Tonymac version is applying that Hackintool is not. You can copy/paste these into the Calculator/Base64 area to view the actual byte data.

PS I apologize for losing my patience with you last night I understand that Hackintool lacks documentation and so it can be difficult to figure out how it works.

 

[headkaze]

Clover has vastly improved the injection of Critical System ID's since i wrote that guide but this is still an important debug step to perform when iMessage is not working correctly and is usually the primary cause of iMessage not working, additionally I think it would be useful for users to view this info so that they know that Critical System ID's are set correctly you could even add a export function (like iMessage Debug has) that saves the info as a report so that if they have to reinstall a system from scratch they can know what their System ID's where to avoid any iMessage issues.

Just a suggestion ... one to maybe add to you future features list

I'm surprised you haven't noticed my latest release as I implemented all the above features you requested

BTW I do credit the authors of iMessageDebug even though I couldn't find the source code to it. After looking at it in a hex editor I figured out where it was reading the data from. It did have me a little confused at first as they appear to be system keys hidden from the user (you can't see them in IORegistryExplorer for example) yet if you read them directly you get the data.

PS Thanks for your great tutorials they have been very helpful for me especially back when I was having issues with iMessage. Hopefully Hackintool can make the process slightly easier now also.