Monterey Bluetooth.reg fix for LE devices

[sqrootnegative1]

trafficstars

Looks like Bluetooth.reg generated on Monterey (12.1) does not need the "ERand" value to be reverted which is to say (b) is not needed in ERand entry in the .reg file. I was having issues with getting Bluetooth.reg file generated on Monterey to work on Linux and Windows 10. Fiddled around a bit and turns out the "ERand" value needs to be written as it is, without being reverted.

So currently, using Hackintool v3.8.3, if the .reg file contains the following line: "ERand"=hex(b):15,2e,f1,6b,77,8e,14,b2 The correct ERand entry for Windows would be 15,2e,f1,6b,77,8e,14,b2 and on Linux would be 1526422767594771634 but due to the (b) in .reg file, it gets written as little-endian which is b2,14,8e,77,6b,f1,2e,15 (which does not work).

Bluetooth.reg file generated on Catalina works fine though, so Catalina does require the values to be reverted. Probably has something to do with Bluetooth stack on Monterey being revised.

[benbaker76]

So the (b) in hex(b) must mean big-endian. I've been reversing bytes and also using hex(b) so they are getting reversed twice. To avoid confusion I've removed all hex(b) entries. Can you please try the attached version and let me know if all the entries are in the correct order now.

[sqrootnegative1]

Thanks for the quick update! Unfortunately, it still didn't work so I tried to find out why by reading more about .reg files, and from Wikipedia, the two entries we're interested in are:

"Value B"=hex:<Binary data (as comma-delimited list of hexadecimal values)> "Value M"=hex(b):<QWORD value (as comma-delimited list of 8 hexadecimal values, in little endian byte order)>

Seems like without the (b), data is read as binary (of variable length), but with (b), data is read as a QWORD, so its length is defined (8 bytes). I'm not sure, just guessing that this minor difference is what's causing the issue. Removing the (b) from ERand and Address as you did in the .zip file you provided lead to both ERand and Address values being stored as just raw binary data (which didn't work), however, when (b) is added, the values are now interpreted by Windows Registry and their decimal equivalents are shown in parenthesis.

If I'm being confusing, let me know, I'll provide some screenshots. But to sum up, we need to detect which version of macOS Hackintool is running on, and based on that generate the .reg file.

• If Hackintool runs on Catalina, v3.8.3 works fine, no edits needed.
• If Hackintool runs on Monterey, just revert the ERand value from v3.8.3 one more time to change its endianness. Rest all entries work just fine. I'd try and do it myself but I don't have any experience with Objective C.
• Unsure about Big Sur, maybe someone who currently is on that version can help. It should be one of the above two, most probably Catalina.

[benbaker76]

It looks like I misunderstood the meaning of the (b) completely then. So the previous version works fine except ERand needs reversing. Please try the attached version.

[sqrootnegative1]

Yes, now its working fine with Monterey and Windows 10. Thanks for the update. Not sure about Catalina though, maybe someone currently on Catalina could try.

[stantravels]

Hi, @headkaze ! thanks for your work! However I can't make mybluetooth Huawei mouse to work between the latest MacOS Monterey 12.5.1 and Windows 11. I tried all the described methods across the internet, even copying the values manually from the keychain and reverting them manually and pasting into the windows registry. So if we talk about hackintool, it creates the .reg file successfully if the mouse is paired but switched off. Keychain and the generated .reg file both contain MAC address of the mouse which differs from the one saved in the windows registry - only in one character at the end. Thus importing the generated file into windows creates an extra folder in the registry. If I rename the newly created folder name and/or "Address" value in it to the one windows previously had - mouse still doesn't work. If I copy the values of Erand, IRK, LTC etc into the original windows registry entry - it still doen't connect. Also I tried to fill the MasterIRK value with the remote one, but it doesn't help. I've ran out of options. Is there any way to make it work?