How to Fix iMessage

[TreeMan2011]

jaymonkey, thank you for answering my questions.

If thats the case and your statement in post #480 is correct :-



Then you have not followed the instructions correctly, Path A states to remove any SystemId injection code in SMBIOS and add code to inject SystemId via the chameleon.plist, you have done the opposite.

That was NOT correct, that was just a case of me sitting here composing a message while I was tired and frustrated, and copying the wrong filename and block of text to my message. I actually made a couple other mistakes when I wrote that message but fixed them after my son caught them, but we still both missed that. As I said the day we did this, my son and I were both sitting here working through the instructions, and I remember checking SMBIOS.plist to make sure that string that's not supposed to be there was not in fact there (and it wasn't), then closing that file and moving on to org.chameleon.Boot.plist and adding the string there:

<key>SystemId</key>
<string>********-****-****-****-************</string>

But when you are tired and trying to write a message, it's easy to copy-paste the wrong filename and block of text from another post, and that's what happened here. When we actually did this process, we were both here and both wide awake and alert, so I'm sure we didn't use the wrong string or put it in the wrong place.

Anyway that key and string are GONE now, so my real question is, how is the boot sequence still finding them? If I could get rid of that it would be very helpful. But I wonder if this is the key...

You don't need to convert the value in the ioreg, the 16 numbers should match the injected UUUD in the same sequence, you just need to add the dashes. Once you inject SystemId via the chameleon.plist it should work.

That confirms that right now IORegistryExplorer is reporting my "old" SystemId, not the new one, which I can confirm because it's the same number that was used the filename of an older nvram.********-****-****-****-************.plist file (and that same name is on the same file currently in the Extras directory, though that is probably because we restored the directory from a Time Machine backup). So if I put that OLD value into org.chameleon.Boot.plist under the SystemID key temporarily, that should clean up any places where the "new" value might be lingering, right? I figure it is worth a try and have already added it using TextWrangler, just in case my system unexpectedly crashes or something. If it still picks up any other SystemID during boot then I have no idea where it is getting it.

I wouldn't be adverse to trying it again with another generated number if I wasn't afraid it would mess up the ability of Mail and Messages to interact with Google. That was the #1 reason this project was abandoned and we tried to revert to what we originally had; not being able to POP mail from Gmail would be a REALLY big problem. And the issue was that it simply would not recognize our valid passwords; even re-entering them simply produced another request for the same password.

 

[jaymonkey]

jaymonkey, thank you for answering my questions.

But when you are tired and trying to write a message, it's easy to copy-paste the wrong filename and block of text from another post, and that's what happened here. When we actually did this process, we were both here and both wide awake and alert, so I'm sure we didn't use the wrong string or put it in the wrong place.

Understood.....

That confirms that right now IORegistryExplorer is reporting my "old" SystemId, not the new one, which I can confirm because it's the same number that was used the filename of an older nvram.********-****-****-****-************.plist file. So if I put that OLD value into org.chameleon.Boot.plist under the SystemID key temporarily, that should clean up any places where the "new" value might be lingering, right?

Should be no need as if it is not injected by the boot-loader then the BIOS will automatically inject the invalid SystemId so you should be back to how things where ... but that still leaves you in a problematic situation with regards to Apples on-line system ...

Since Apple implemented the changes on their servers, all hackingtosh systems who's BIOS has the SId Bug will be effected because it is impossible for OSX to have a truly unique UUID, its possible that it may effect more than just iMessage, if not now then in the future.

The fix does work, I can understand your reticence to try a fresh install because everything was working before but sometimes that happens with a hackingtosh, sometimes nothing is straight forward, we are so lucky to have all the tools and guides to make it relatively easy these days.... sometimes a fresh OSX install can do wonders and you end up with an even more stable build, each time you do it you will get more confident and learn. I would recommend that you get another drive and use carbon copy cloner to keep a active backup that you always boot back-in to if things go wrong.

I wouldn't be adverse to trying it again with another generated number if I wasn't afraid it would mess up the ability of Mail and Messages to interact with Google. That was the #1 reason this project was abandoned and we tried to revert to what we originally had; not being able to POP mail from Gmail would be a REALLY big problem. And the issue was that it simply would not recognize our valid Google passwords; even re-entering them simply produced another request for the same password. Whereas a POP account that I have on a different service worked fine; the problem was something specific to Gmail and Google Talk.

With regards to the gmail issue, I don't really understand whats going on there, no one else has reported such wideness, it's possible that google also uses the uuid and/or S/N somewhere along the line but thats just a guess, from the sound of it you've been through the mill with a cascade of s/n and uuid changes so all sorts of stuff could have happened, thats the point of the fix to make sure you have a unique s/n & SystemId to stop this sort of wideness.

Good Luck, i'll try to help you further if i can.
Cheers
Jay

 

[lisai9093]

Thats great news,

Could you post the method you used to inject SystemId via clover.

I can then add it as an instruction to the guide, rather than the somewhat vague description for clover users that i have right now.

Cheers
Jay

Actually I don't think changing System ID is necessary for Clover user, just UUID should be fine. I didn't even have system-id property in IOreg before with working iMessage.

Anyways here is how to change system ID under Clover:
Using Clover Configurator, check inject system ID option. Then put desired system ID into Custom UUID box. If inject system ID is unchecked, Custom UUID will be your hardware UUID.

 

[jayw8888]

I tried the Part 1 to the letter without success. The iMessenger would not Identify any of my contacts as valid contacts.

This Part 2 is what did the trick for my setup. http://www.tonymacx86.com/general-help/110471-how-fix-imessage-9.html#post795297

I am using ASROCK Z77PRO3 Chameleon v2.2

Followed the "Path A" pasting the SystemId in the org.chameleon.Boot.plist and generating a new UUID. All works again upon reaching step 8. Reboot asked for passwords again for facetime, imessenger and icloud. There was a few moments where iMessage would not accept my password but quitting and restarting the iMessenger worked.

Its all working flawlessly now. Thanks to jaymonkey!!

 

[kiwinz]

Thanks for you work jaymonkey, this had been a pain in the rear end for me and thanks to everything you have put together I have managed to get my messages working again.

 

[rad-we]

Hello,
There is something strange in the guide of post #40x.
After I execute "sudo nvram boot-args=""", the nvram file gets immediately recreated! I deleted it again and rebooted with -f, but I get always the same filename, something like:
nvram.xxx-8004-####-####-E40700080009.plist
At the time being, my Hardware UUID is
xxx-D2D9-####-####-088C2B4AEFFD
and this is clearly different from my SystemId (as for NVRAM filename).


I read in some posts to modify the content of the file NVRAM, is it correct? does it help to modify name and contents manually?


Before giving the "sudo nvram boot-args" command I had I generated the SystemId as suggested and, after the reboot with -f, I get in IOReg:
<xx xx xx 76 eb e9 ## ## ## ## 53 59 02 ad a4 dd>


I don't understand where is the problem. I did not need to cut out anything from smbios.plist, because I installed just yesterday and it was clean.


I would like to activate iMessage without needing to call Apple... but that is the request I get when I try to login.

 

[rad-we]

Apparently, since I tried the iMessage solution explained in this thread, the machine cannot reliably stay in sleep: it wakes up something like 5 seconds after getting to sleep (that means, after the power LED turns off).
After turning itself on, it takes 20 seconds to go to sleep again, just to wake up again and to repeat the cycle.

 

[rad-we]

I checked right now in bdmesg and I found:

Type: 1, Length: 27, Handle: 0x1
SystemInformation:
    manufacturer: Apple Computer, Inc.
    productName: MacPro3,1
    version: 1.0
    serialNumber: #########
    uuid: xxx-8004-####-####-E40700080009  [B](this is what I see in the nvram.uuid.plist file)[/B]
    wakeupReason: 0x6
    skuNumber: To be filled by O.E.M.
    family: Mac Pro
...
Customizing SystemID with : xxx-ebe9-####-####-535902ada4dd  [B](this is what I see in IOReg)[/B])
ACPI table not found: DSDT.aml
ACPI table not found: SSDT.aml
FADT: ACPI Restart Fix applied!
Found ACPI CPU: CPU0

...
Found ACPI CPU: CPU7
SSDT with CPU C-States generated successfully
P-States: min 8, max 35
SSDT with CPU P-States generated successfully
RSDT: Added 2 SSDT table(s)
FADT: ACPI Restart Fix applied!
Added 2 SSDT table(s) into XSDT
Starting Darwin x86_64
Boot Args: boot-uuid=xxx-24F8-####-####-40685A6A4552 rd=*uuid [B](I cannot find that boot-uuid anywhere else)[/B]

Thank you all in advance


Edit: I tried to place in or.gchameleon.plist the UUID I got in the nvram.UUID.plist file, so now IOReg, nvram, all match. Only the boot-uuid boot arg is different, but I think it's not a problem, because it's not among the checks that should match, as suggested in the guide final summary. The question is... is that unique or something Gigabyte used many times?

I tried deleting iMessage files and it still doesn't work, I get UUID lockout.
Maybe I should call.

 

[jaymonkey]

I tried deleting iMessage files and it still doesn't work, I get UUID lockout.
Maybe I should call.

See next post ....

Cheers
Jay

 

[jaymonkey]

Hello,
There is something strange in the guide of post #40x.
After I execute "sudo nvram boot-args=""", the nvram file gets immediately recreated! I deleted it again and rebooted with -f, but I get always the same filename, something like:
nvram.9402DE03-8004-####-####-E40700080009.plist
At the time being, my Hardware UUID is
11F8CEF1-D2D9-####-####-088C2B4AEFFD
and this is clearly different from my SystemId (as for NVRAM filename)

Executing sudo nvram boot-args="" does not delete the nrvam.uuid.plist file. It only removes the key values from OSX internal nvram cache it will only get re-created if you manually delete the file and reboot.

The uuid in nvram.plist should always be different from the OSX hardware ID.

I read in some posts to modify the content of the file NVRAM, is it correct? does it help to modify name and contents manually?

Should be no need and unless your sure about the value your changing i would not recommend it, if you make a mistake it will make the miss-mataches even worse.

I would like to activate iMessage without needing to call Apple... but that is the request I get when I try to login.

As stated in the guide, if you are getting the iMessage alert to contact Apple with a Customer Code and you want to keep you existing AppleID then that is the only corse of action, the lockout is on your AppleID at apples end. It is not an issue to state you have a hackingtosh but you must have at least one valid Apple device registered against the AppleID.

There is nothing you can do locally to cleat the lockout, the only possible way around it would be (disconnect fro the iCloud, change your S/N & SystemId again, then create a new AppleID, then reconnect back to the iCloud, which should register your hack as a new device against a new user.

Hope you get it sorted
Cheers
Jay