How to Fix iMessage
How to Fix iMessage
and OSX ID Configuration
(also for Appstore, iTunes & iCloud..etc)
11-01-2015: Restoring iMessage on Genuine Macs
06-01-2015: Latest revison to FileNVRAM 1.1.4
31-12-2014: Apple now reacting to cloned ID's ?
23-12-2014: Updated Status on Latest iMessage Issue
08-12-2014: New Version of FileNVRAM now available
27-11-2014: New iMessage issue confirmed - See News
18-11-2014: Guide re-fresh and new section/step separators
17-11-2014: Confirmed working with OSX 10.10.1 - See News
14-11-2014: Update S/N & Model Identifier info (Step 3 - Clover)
18-10-2014: Information for OS X 10.10 Yosemite.
14-10-2014: New Version of iMessage Debug (V2.0) - See News
09-10-2014: Added warning Step-5f: Using leached ID's
04-10-2014: Big update to Step 5d - MLB & ROM values
25-09-2014: Simplify Step-2 - Check Network Interfaces
22-09-2014: Updated Info on iMessage Customer Code issue
04-09-2014: Update Step 5d - Persistent MLB & ROM Values
29-08-2014: Add Step 5e - Clarify NVRAM plist reset
26-08-2014: Update Step 5d for Clover Users (MLB & ROM)
18-08-2014: Added Section 5d - iMessage Debug utility
10-08-2014: News: Recent iMessage Outages
09-06-2014: Add Important note about S/N changes to Step 3
08-06-2014: Add NIC EFI injection to Step 2
19-05-2014: Part-2 of the guide moved to Post #2
18-05-2014: Confirmed Working - OSX Mavericks 10.9.3
15-05-2014: Update Step 5C for Chimera V3.0+ users
23-04-2014: Re-write and simplify Step-2
17-04-2014: SId Bug Fix and UUID miss-match
10-04-2014: New iMessage issues identified
31-03-2014: Rewrite Step-5c and consolidate notes
30-03-2014: Updated info on Credit Card expired
06-03-2014: Updated info on issue effecting RAID users
03-03-2014: Updated info on Apple ID validation check
02-03-2014: Reformat and re-order entire guide
02-03-2014: Confirmed Working - OSX Mavericks 10.9.2
30-12-2013: Confirmed Working - OSX Mavericks 19.9.1
26-10-2013: Updated info on BSD Name issue
24-10-2013: Confirmed Working - OSX Mavericks 10.9.0
30-09-2013: First release of guide made public
25-08-2013: Confirmed Working - OSX Mountain Lion 10.8.5
01-08-2013: Confirmed Working - OSX Mountain Lion 10.8.4
Jump forward to Part-2
NEWS: 11th Jan 2015
Restoring iMessage Functionality on Genuine Macs after Cloning ID's
Many users who cloned the MLB & ROM values from their genuine Mac's to one or more Hackingtosh systems have been unable to use iMessage and other iCloud services on all their OSX systems following the updated validation protocol changes implemented by Apple at the end of Dec 2014 (see News item dated 31st Dec 2014 below)
Obviously this has caused a fair amount of alarm with many users posting reports that they have been black-listed/blocked ... etc. If your in this situation and need to restore iMessage on your genuine Mac then don't panic.
First Logout of iMessage on all your OSX devices (hacks and genuine), now remove all the cloned ID's from all of your hacks, go back to non-cloned / locally generated values (see Part-1, Step-5d of the guide)
Ensure that after changing the ID's that you attempt to connect/login to iMessage on each OSX device, obviously it wont work on your hacks due to MLB failing validation but it should generate a new customer code and more importantly re-associate the device in Apples database.
Note: You may not get a customer code on your genuine Mac, this is normal ...
You just have to play a waiting game now ... eventually the server side security tokens will expire, after which iMessage and iCloud functionality should return to your genuine Mac without the need to contact Apple.
If after a week or so you are still unable to use iMessage on your genuine Mac then call Apple, ensure you give them your genuine S/N and AppleID, they should be able to reset all the blocks on your AppleID after which iMessage and Facetime should work again on your genuine Mac.
There are posts now coming in that this method does indeed work, it's possible that Apple have had to back-out or alter the validation protocols as too many genuine Mac's were being effected. It's also possible that Apple were sending a warning to us - Don't Use cloned Values if you want to continue to use iCloud services on your genuine Mac's.
If you have an old or non-functional Mac then that's a different story. I'm using the MLB (13 digit) & ROM from my old 2009 MacBook Pro 5,5 which has a broken screen on my Sony Vaio Laptop Hack which is configured as a Macbook Pro 8,3 for the last six months and iMessage and all iCloud services have continued to work perfect - all other critical ID's such as SmUUID & OSX S/N are locally generated as detailed in the guide below.
NEWS: 6th Jan 2015
Revised version of FileNVRAM 1.1.4 now available for public testing
Revised version of iMessage Guide coming soon
As reported in the News dated 8th Dec 2014 (See Below) an updated version of FileNVRAM (V1.1.4) was made available by the dev group xZenue which included several new features but only worked with OSX Yosemite when used in-conjunction with specific versions of Chameleon.
I'm now able to report that dev's here at TMX have been working on a Chimera/Yosemite compatible version of FileNVRAM 1.1.4 for the past few months and it is now ready for public testing. For more information and download links please see the following thread :-
FileNVRAM Modded for OS X Yosemite - Fix iMessage using Chameleon/Chimera
Please be aware that this new version of FileNVRAM will not help to negate the current iMessage issues but will enable the use of NVRAM values for those people wanting to continue with a legacy boot-loader. I recommend that you use it with locally generated ID's to begin with and test for NVRAM persistence using iMessage debug (See Step-5d).
If your not aware of the current iMessage issues then please read the news articles below before continuing.
For the moment this should be considered a public beta release so we need feedback good or bad, please be sure to read all the installation instructions as it consists of both a boot module and a kext.
Any feedback should be posted to this thread.
I'm also happy to report that i'm working on a index driven version of this iMessage guide which will dump the current format of everything being in one big post and will favour separate articles for each section of the guide with a new navigation method. Hopefully it will be ready in a few weeks.
News .... 31st Dec 2014
Apple now reacting to systems using cloned ID's ?
It would seem that Apple have implemented yet another update to the iMessage validation protocols that seems to effect systems using real (cloned) MLB & ROM values. This new issue started sometime between the 28th and 29th of December 2014 depending upon location.
I'm not entirely sure what is causing the new issue ..... it's possible that Apple are now black-listing devices that are using cloned ID's or Apple may have implemented a new cross check to the System Type and/or anther system identifier such as SmUUID ... something i've been speculating since Apple introduced tighter SmUUID (or Hardware UUID) validation last year.
Symptoms of this latest issue seem to be no messages being sent or received from OSX devices despite being able to log in and out of iMessage without issues, mobile devices such as iPhone and iPad are unaffected.
I think this issue is only effecting OSX systems that are using the same MLB & ROM values and are logged in to iMessage at the same time, this is my best guess as to what may be going on until proven otherwise.
One can only assume at this stage that Apple have responded to the recent increase in people using cloned MLB & ROM values since the 17th of November MLB validation changes .... I guess the desire to get iMessage working no matter the cost by some people has forced Apples hand. It's not effecting everybody at the moment, but like all recent changes to iMessage validation it may take a few days or even weeks for the change to effect everyone it is targeted at.
I'll try and dig a little deeper over the next few days but until then ..... to those of you using cloned values, if they are from a Mac your own, you should seriously think about this recent escalation, if you can live without iMessage then i would strongly suggest that you switch to using locally generated and unique MLB & ROM values ASAP (use the guide - Part-1, Step 5d) whist this of course will stop iMessage working it should hopefully stop your ID's being black-listed or flagged by Apple.
This latest issue is also effecting iMessage on some real Mac's who's ID's have been used on hackingtosh systems so it may well be a MLB/ROM black-list, early reports from users who have contacted Apple about the issue indicate that restoring iMessage functionality on Apple hardware can be hit and miss ...
More info will be posted once the issue is better understood .....
NEWS: 23rd Dec 2014
Status of latest iMessage Issue
The latest iMessage issue detailed in the news below (27/11/2014) still remains. As I speculated when the problem first started, the issue has been confirmed by the rest of the community and is basically caused by improvements to Apples verification process of the MLB value during iMessage authentication, it's also possible that the ROM value is also now subject to enhanced verification although this is still unconfirmed.
Update 23rd Dec 2014
Some of you may come across a number of so called 'MLB generators', at the moment these are all work in progress and none of them currently provide a complete solution which is why i'm not posting them here just yet. However they do offer a framework to add to as each element of the MLB is deciphered and fine tuned. I'm in contact with some of the primary developers and between us and and community I hope that a working utility will be released soon.
In the meantime I would appreciate that no one posts any of these utilities as links or attachments, at this stage there is no point and i don't want to get peoples hopes up just yet and flood this thread with posts about a utility that is not quite ready. It is better that the focus stays where it currently is rather than spreading unfinished code around the internet.
I hope you all understand my reasoning for this and any post's relating to these early releases may be moderated, once ready and confirmed working the guide will be updated ...please be patent....the solution is coming soon.
Confirmed improvements to iMessage Authentication Process
MLB & ROM must be white-listed
Having done extensive testing with various combinations of MLB & ROM values (real and generated) it is apparent that both the MLB & ROM values must now be white-listed on Apples servers, real Mac's have their ID's added to the Apple database during the manufacturing process.
It's still unclear if the ROM value must conform to an Apple standard, although it is apparent that it must now be white listed.
From this point onwards it will not be possible to use iMessage when using user generated MLB & ROM values without calling Apple first to activate/white list your ID's. But please do not Contact Apple unless you are 100% sure your MLB is correctly formatted (which can only be currently done with a fair bit of manual research at the moment), using the old method of taking the OSX S/N and adding random alpha/numeric digits as detailed in Step 5d will no longer work.
17 Digit MLB's
Systems using a legacy user-generated, 17 digit, non-Apple MLB will not work at all, if you do call Apple, it may activate for a short period (up-to a few hours) but ultimately the MLB will fail the improved verification checks and be deactivated resulting in the call Apple dialogue again. Currently there is no automatic method for generating a valid 17 digit MLB which will pass Apple verification, however this is the focus of much attention by myself and others and it is hopeful that the syntax/make-up of 17 digit MLB's will be fully understood soon.
13 Digit MLB's
13 Digit MLB's must still conform to some basic back-end verification, however since they lack the more complex parts of the 17 digit MLB format it is possible to user-generate a valid 13 digit MLB that will pass the looser back-end Apple verification (once white-listed), but simply using your OSX S/N + extra random digits like in the past will not work. You can use some elements of the OSX S/N but it should ideally contain a manufacturing date and batch code that is earlier than the date code in the OSX S/N, additionally it must also contain valid Apple ''EEE' - this is yet another Apple part/type reference and some examples can be obtained by researching replacement system boards, some sites list the 'EEE' code in the product description.
Like 17 digit MLB's there is currently no easy automatic method to do this so it requires a fair bit of effort by the end user, but it does work. I may write a method to assist in this approach but there are already a few other forums that detail the MLB in more detail so for the time-being if you want to try this approach then this is a good place to start.
Currently there is no back-end verification required for iMessage to work between the MLB/ROM syntax and the System Type and/or S/N.
However .... If everyone starts using a 13 digit MLB against a more recent System def then it would only be a matter of days before Apple did something about it .... we need to satisfy the Apple verification process in a more complete way thus ensuring longevity rather than short term stop gaps.
NEWS: 8th Dec 2014
New version of FileNVRAM released
While I was on vacation I got an email from meklort and the developers of FileNVRAM informing me that they have implemented my suggestion of supporting a user defined location for the nvram.uuid.plst in a new version of FileNVRAM (see the Additional notes for RAID users in the guide for more info on the issue) - this feature is going to really help those of us who have RAID systems or complex multi-disk installs.
The new version now also works with OSX Yosemite but you must use the latest build of Chameleon as your boot-loader, hopefully TonyMac/MacMan will release a new version of Chimera soon that will work with it.
The main changes to FileNVRAM Version 1.1.4 are:-
- Add ability to read NVRAM file from disk if not passed in by bootloader.
- Add ability to configure kext using the nvram command
- Add ability to save nvram configuration to nvrma file.
- Prepare for public release, source code cleanup.
- Update macros for passing information between module and kext.
- Add method to enable logging using an nvram variable.
When i get chance i'll update the guide with the new features for RAID users, in the meantime , any one who want to try it out can download the new release of FileNVRAM direct from the xZenue server here:
FileNVRAM Version 1.1.4 (Build 77)
Note: This will not solve the current iMessage issue for anyone but will allow Chameleon users to boot OSX Yosemite with working NVRAM support and it solve's a big headache for RAID users. It should allow the use of iMessage once a fix is found for the issue.
As always a big thanks to xzenue, meklort and all the other guys involved with FileNVRAM
NEWS: 27th Nov 2014
New iMessage Activation/Authentication Issue
As of mid November 2014 it would appear that Apple have once again updated their iMessage client authentication and verification processes on their backend servers. If iMessage is still working for you DO NOT LOG-OUT or perform any operation that will cause a logout such as a OS update .... etc.
Once you do logout the existing iMessage security token will no longer be valid and will not be replaced with a a new token due to failure of ID verification on logging back in. As in the past, i'm sure those of us who still have working iMessage will get kicked out/logged-off .... including myself due to periodic iMessage disconnect messages which get pushed out every once in a while.
The main symptom is a return of the following iMessage alert box :-
- The issue effect's all existing installs of OSX Mavericks and Yosemite using any Boot-loader.
- The issue only effects iMessage and Facetime, all other iCloud services seem unaffected.
- Once effected you will no longer be able to re-activate iMessage by calling Apple Support with the displayed customer code despite it being apparently valid and accepted by Apple Support should you decide to try.
- If you have not changed any OSX ID's such as S/N, MLB, ROM ... etc then the customer code should be the same as the last time you called Apple to activate iMessage.
- Generating a complete set of new OSX ID's will not resolve the issue despite a new customer code being generated, it does not matter if is this on existing or completely new hardware.
- Creating a new AppleID and associating the hackingtosh with either the existing or new ID's does not resolve the issue.
- If you do call Apple support and give them the displayed customer code iMessage will continue to display the same alert message and the same customer code no matter how many times you call Apple.
- Restoring a backup or booting from a clone of the system when iMessage was working will not resolve the issue due to the security token at Apples end being flagged as expired.
- It would seem that Apple Customer Support is not aware of the enhanced verification process as they will continue to try and help you resolve the issue but it seems that no matter what they do the issue remains.
- There are a few small changes to the Apple self-solve web-site and notable changes to the Apple support web-site - when logging a support issue, the path to the correct support department has changed and you now have to select a pre-registered Apple device to log the ticket against were as in the past you were able to enter any S/N of any device.
- The symptom you see localy relates to the iMessage security token, normally when you login to iMessage your id's are verified by the server and a new security token is generated and passed back to the client were it is stored locally, after which it is used in conjunction with the server side token each time you use iMessage for verification and message packet encryption. If you logout then the token is physically deleted locally and made invalid at the server side. You will not be able to use iMessage again until you have a new and valid security token. When you try to log back in, the server side will try to generate a new security token but the id's now fail the new validation checks thus triggering the contact Apple alert message and failure to receive a new token.
- The locally stored iMessage security token will automatically expire after 5 to 6 weeks, after which MLB & ROM are re-verified and a new token sent to the client. Obviously now that the ID verification process has been enhanced this no longer happens.
- Current Diagnosis: I'm now 100% sure its the MLB that is failing verification ultimately resulting in the loss of a new iMessage security token being generated and sent to the client. There is a confirmed patten to the MLB which needs to be understood. In the past we were able to use our OSX S/N + additional/random values to make the MLB value the correct length for the system type being used (either 13 or 17 digits).
- Current Investigation: I am researching how the component values of the MLB are made up, it is a similar format (but different) to the way the OSX S/N is derived.
As in the past when iMessage stops working some users go back to using ID's form real mac's to get iMessage working again ... i've continually advised through-out the life of this guide and thread not to do this .... all your going to do is make Apple more vigilant to secure iMessage even further and you may run the risk of black-listing the source Mac's ID's if you use them too many times on non-Apple Hardware.
It's been known for a longtime that using the MLB & ROM value from a real Mac will allow iMessage to work without having to call Apple but we have to try and find a way that can satisfy Apples validation and security without resorting to using cloned/leached values if at all possible - See Step 5f.
I will continue to update this news item with further info on the issue as and when new information is found. If a solution is found i'll post a new news item along with any new steps required.
NEWS: 17th Nov 2014
OSX Yosemite 10.10.1 - Combo Update
If you are running Yosemite 10.10.0 in conjunction with Clover boot-loader and have configured your system as per the guide then I can happily confirm that iMessage should continue to function perfectly after applying the latest Yosemite OSX 10.10.1 Combo update:-
My recommended Update Method is:-
- Download the standalone combo update installer using the above link
- Ensure you have a good/current backup
- Run Disk-Utility and repair file persimmons on your OSX startup drive
- Disconnect from internet
- Ensure you have an-up-to date copy of iMessage Debug output & your SmUUID
- Run the Combo Installer, OSX will update and reboot.
- If you have dynamic Clover patches for Audio, Trim, BT4, WiFi .. etc then the system should restart and work as before.
- Those not using dynamic Clover patching will have to re-install Audio, Trim enabler .. etc from multibeast and re-apply any binary or info.plist patches for BT4, Wifi ..etc
- After Restart run iMessage Debug and check output against your previous values .... ensure Hardware(Platform)UUID, S/N, MLB & ROM are all the same, if Hardware UUID is the same as before then SmUUID will be the same so no need to check.
Using the above method i have successfully updated three different systems to OSX 10.10.1 - two desktop's and one Laptop (for safety i installed nullcpumanagment.kext before updating the laptop and removed it once finished)
It's probably not necessary to have to disconnect from the internet and do the ID check, it's your choice, you just never know whats going to happen ... so best to be safe at least for the first time you do a Combo-Update running via clover boot-loader....
If all your ID's are ok, re-connect to your network, you may have to re-enter your iCloud password again.
You should now be back up and running .....
Once everything is working and to ensure everything continues trouble free I recommend running anther Disk Permissions Repair via DiskUtil.
I've seen no problems so far...
NEWS: 18th Oct 2014
OSX Yosemite 10.10.0
With the public release of OS X 10.10 comes a new iMessage and as expected a few new iMessage issues.
The Good News
If you followed my advice from the last six months and you've already made the transition to using Clover as your boot-loader then the good news is you don't have to do anything in order to get iMessage working. If your not already using r2953 then i would advise that you update Clover before installing OS X 10.10.
I made a Unibeast 5 USB installer for OSX 10.10 and simply installed OS X 10.10 over my existing Mavericks install (just like a real mac) after the install finished I re-booted again with the Unibeast USB still in place and loaded the new OS. Once loaded I used the latest version of Multibeast to update all critical kext's such as FakeSMC, Audio, Trim, Ethernet ... etc, after a little bit of fine tuning i removed the Unibeast USB and rebooted back into OS X 10.10 via Clover. Finally I ran iMessage Debug to ensure that all my ID's were the same as before the update and iMessage is working great, love the updated look, notifications ... etc
Please ensure that you use the new kernel boot flag 'kext-dev-mode=1' otherwise some 3rd party kexts might not load, in Clover Configurator simply tick the option in the kernel boot options.
The BAD News
If you not using Clover as your boot-loader then you will not be able to use iMessage, it as simple as that at the moment. I will not be adding a method for installing Clover to this guide as its off topic and there are many ways it can be done. There are loads of guides and resources out there, find one that works for your level of knowledge and understanding.
It is very unlikely that the older method of using FileNVRAM (see Step 5) will be updated to work with OS X 10.10, I'm not saying that it won't happen, and I hope that it does, otherwise what use is Chimera and Chameleon ?, but you should realise that the way Clover works is light years beyond these old (legacy) methods of running OS X and it would require a big re-write to catch up see post #1624 for a bit more info.
Those of you not using clover and have already tried to get OS X 10.10 working, I suggest that you go back to your 10.9.x backup and get Mavericks working with Clover first, that way you'll reduce the amount of issues you have to deal with in one go as your working with a known good build.
If you've not tried Clover yet and you don't understand how EFI booting differs from legacy BIOS booting then it might be worth reading up on that first before installing Clover, try starting with the Technical Background document .... it's part of the official Clover wiki which is an excellent resource when working with Clover, however if you are a beginner to DSDT patching and low level hackingtosh methods then you may find some of the documentation a bit vague in which case you should research each option more closely, simply searching with any good search engine should result in something that will help you.
Once you have Clover working use the Clover tips in each section of this guide to resolve iMessage issues such as Sid bug and non persistent ROM & MLB values ... etc, if you had already fixed all of the issues using the older methods you should re-use/keep all of your existing ID's with Clover which should reduce any device changes being detected by Apple.
NEWS: 14th Oct 2014
New Version of iMessage Debug Released
ElNono has released an updated version to his extremely useful iMessage Debug Tool. Version 2.0 has a new cleaner output and now also displays your SystemId (SmUUID) so no need now to check the IORegistry for SystemId ... it also has the ability to dump the output directly to a text file.
Big thanks to ElNono as always ....
iMessage Important Tip
Clover Migration Preparation
If you are migrating from a legacy boot-loader to Clover, please use all your existing ID's from your Mavericks install (assuming iMessage was working OK)
This includes all of the following :-
- SMUUID (SystemId)
- OSX S/N
You can get these from your old build using iMessage Debug and IOJones
Failure to do this will result in a new device being logged with Apple and you will not be able to access iMessage, please make sure that you put the SystemID UUID in the SMUUID field on the SMBIOS page, do not put it in the Custom UUID field on the System Parameters page but do ensue that 'Inject System ID' is checked.
Before trying iMessage run iMessage Debug and ensure that all your ID's match your previous Mavericks build including the Hardware (platform) UUID, if all ok try iMessage and it should work. If ANY ID's are not the same or are changing on each boot then resolve the issues before trying iMessage or Contacting Apple to Unlock AppleID/Device.
Do not confuse the SmUUID (systemId) with the Hardware (Platform) UUID on your old build, you should only need to add the SmUUID to Clover's config.plist, then OSX should automatically generate the same Hardware UUID as before.
I've been using Clover Version r2953 and have had no issues updating to Yosemite on five machines so far and iMessage is working on them all using each machines existing ID's.
As previously suggested if your new to Clover I recommend that you install Clover first on your existing Mavericks build and ensure that iMessage is working before installing OSX 10.10.
iMessage Important Tip
Contact Apple with Customer Code Alert
If you get a iMessage alert asking you to contact Apple with a customer code there is nothing you can do locally to resolve the issue, the customer code must be applied to your AppleID to unlock iMessage on your device, this can only be done by Apple (this will not effect any mobile devices ability to send/receive messages such as iPhone, iPad .. etc)
Recently many more users are seeing this alert, I believe that Apple have made further changes to security checks on their systems in early August 2014. The above message is explained in further detail in Part-2, Step-8 of this guide.
If this is the first time you have got this message then I suggest that you check ALL your ID's to ensure they are the correct syntax and are persistent on each boot. Many installs allow the ROM & MLB values to change on each boot or have a miss-matched System Type and/or S/N. If this happens then you will continue you get this message again after a few weeks.
This guide covers all of the necessary checks and provides the solutions, I recommend that you read the entire guide at least once as you will learn a lot about debugging iMessage, as a very minimum if you are getting the above alert then I suggest the following :-
- Read Part 2 of the guide up-to Step 7, check if you have the SId bug, if so fix it
- Check your S/N is correct for the System Type you are using - see Part-1, step 3
- Check for persistent MLB & ROM values, see Part-1, Step 5d
- If you changed anything in steps 3,5 or 7 then perform all of step 4 and 5e
Once your ready to contact Apple use the method described in Part-2 Step 8 of the guide which should get you through to correct support department without them asking you too many questions.
Only contact Apple if you get the above message with a Customer Code.
Important Note: Due to the changes made by Apple in November 2014 (see news above) I do not recommend contacting Apple to resolve iMessage activation issue until further notice.
If you are getting the more generic login or authentication alerts then use the guide to resolve your issues, at some point you may start getting the above alert in which case iMessage is now working on your OSX system but you must contact Apple to remove the device/AppleID lockout and or white list your MLB & ROM values.
Before jumping to the conclusion that your iMessage problem is local to your OSX machine its always worth checking to see if there is a more general service outage. you can check the official status of Apple's backend systems here :-
yo can also track iMessage issues in your country by using Down Detector :-
For USA use this link:-
For UK use this link:
(for other countries use either of the two links and click on the appropriate country flag on the right)
If you find this guide helpful please consider clicking on the 'Recommended' button at the top of this page, doing so will help to keep the link to the guide on the home page making it much easer for others to find.
iMessage - Apple's cross-device, instant messaging system built into OSX (and IOS) is quite possibly the most finicky software element to get working correctly when OSX is running on non-Apple hardware.
As you will find, there are many different factors that can effect iMessage and stop it from working and I am quite sure that there are still more to be found, I will continue to update the guide as new solutions are found and confirmed.
I would suggest that you read through the entire guide first and digest each of the steps before making any changes to your system. I have tried to explain the reasons behind each issue and solution. I believe that its important to learn and understand how things work, anybody can upload a file and tell you what to do with it but nobody learns from that, some steps of the guide are critical, others are optional - this is made clear at each step of the guide.
It is best to think of this guide as a 'Tool Box' rather than a step by step guide, although i have tried to put the guide into a logical order, solving iMessage can be a nightmare but armed with all the knowledge contained in Parts 1 and 2 of the guide you should be able to resolve most iMessage issues, I apologise for the length of the guide, however as you will find out there is a lot to cover.
Each step or section of the guide will fall in to the following categories identified by the icon next to the title of that step or section:
Directly related to iMessage Functionality and Maintenance Background information behind a iMessage issue or solution Warning
Be aware of this information
Before you start make sure you've got an up-to-date TM or CCC backup, there is nothing here that should cause any problems, all the steps are relatively straight forward and easy to apply, just take your time and be sure to follow the instructions carefully. I am not responsible for any damage or loss of data you may incur by using this guide.
If your using Chameleon or Chimera as your boot loader and boot OSX from a Apple software RAID (or Fusion drive) then there is an added complication (this does not effect users of Clover so you can skip down to the next section).
To negate this complication you must clone your RAID volume to a standalone HDD using Carbon Copy Cloner or similar utility, install Chimera and modify the chameleon plist in /Extra so that you can boot OSX from this non RAID clone (be sure to remove Kernel Cache=Yes and the RAID uuid from the boot flags). Once booted from the clone HDD, apply the necessary steps from the guide to get iMessage working.
When your happy that everything is working ok, take a deep breath and delete your existing RAID set, it's also worth erasing the two RAID member drives just so you know that everything is fresh and makes for a good opportunity to update your boot loader, then re-create your RAID so a new RAID uuid is generated,
Now clone the standalone HDD back to the new RAID set, make the RAID bootable by installing the boot loader via the command line method to each of the RAID helper partitions and copy the entire /Extra folder to the two RAID helper partitions, be sure to edit the chameleon plist so that it boots using the new RAID uuid and Kernel Cache=Yes.
Its sounds a pain and it is, it's time consuming and carries a certain amount of risk but all OSX software RAID users should be familiar with this method as its how we get our RAID's woking in the first place, so if you think of it along those lines and it wont seem quite so daunting, just be sure to cover yourself with multiple backups if possible.
Warning: If you don't understand the above then please stop now, do some research and make yourself familiar with the way a OSX RAID is created and made bootable on a Hackingtosh system, you can use this guide as a starting point. Please be sure to read the additional RAID notes towards the end of the guide.
August 2014: Anyone running a Raid or Fusion drive should seriously think about changing to Clover as a boot loader as it resolves all of the above problems. On my GA-Z77X-UD5H i had an old 40Gig SATA-II drive kicking around. I installed clover on to that and set it as the UEFI Boot drive. I can now start OSX up from the Raid without having to use helper partitions .. etc. I've added many tips to the guide to cover each issue for Clover Users.
Credit Cards and Verifying your AppleID
There are four different types of AppleID account:-
- Basic Verified
- Pro (Verified)
- Developer (Verified)
It doesn't matter what type of account you have or if your AppleID is registered as @me.com, @mac.com, @icloud.com or a non-Apple email address, if your going to use it with iMessage it must be verified and the easiest way of making your AppleID verified is to register a credit card against it.
You can check the 'Verified' status of your AppleID by logging into Apple's on-line Account manager :-
By registering a credit card against your Apple ID, Apple's servers and systems know that your AppleID has a verified name and address, the main reason behind this is to stop people from creating false AppleID's and using them to send spam.
The most secure way to register a credit card against your AppleID is through iTunes or the App Store, do not use a web address in a browser, there have been several reports of fake AppleID phishing sites, most of these scams work via fake emails that contain a rouge link to a fake AppleID log-in page, the email usually asks you to confirm or update your AppleID, don't be fooled even if the address looks like it might reside on legit server.
Note: Some users have reported success at using their PayPal Account as a means of AppleID Verification and payment. I personally can not confirm this but there are positive posts on this thread that it works, if you do try this and it works for you then please post some feedback.
For veteran OSX users its possible that you have an old AppleID (@mac.com ..etc) which you haven't used for a while, but if it has a credit card registered against it that is still current then you could try using it to test iMessage.
If your AppleID already has a Verified status but you are still having trouble with iMessage login or authentication, you could try changing your AppleID password, this is one of the oldest tricks in the book for resolving iMessage login issues. It has also been reported that sometimes updating your account details (address ..etc) or purchasing something from the AppStore or iTunes (even a free item) can also revive iMessage functionality.
Do not be tempted to remove your credit card info once your account is verified, iMessage will stop working at some point if you do.
You should also be aware that once the credit card expires on your AppleID, you are given a grace period which seems to be around 30 days to register a new one. If you do not register a new, valid credit card within the grace period, iMessage will stop working.
Step-1 Summary: Your Apple ID must have a Verified status for iMessage to work.
Check your Network Interfaces
Open 'System Information' [About this MAC -> More Info -> System Report] and click on 'Ethernet Cards' , you should see a list of installed NIC's on your system, for each NIC you will see a list of parameters such as Type, Bus, VendorID, DeviceID ... etc
Look at the parameter called 'BSD name' for each of your network interfaces, they should be called 'en0', 'en1' ... etc
I have a Gigabyte GA-Z77-UD5H motherboard's which has two built-in LAN ports (Intel and Atherios). In this example I could access the internet and email on either port but could not use any Apple on-line service such as iMessage, iCloud, App Store and iTunes (on either port).
On investigating my BSD names I found that the Intel port was named 'en2' and the Atherios port was 'en1', there was no 'en0' .... how this occurred during OSX install i'm not sure ? but I've seen this happen more than once on different systems.
If you find that you have no 'en0' or have 'gaps' in the BSD Names number sequence or things just don't seem correct with your network hardware/software then the first thing you could try is re-setting all of OSX's Network Settings ...
Re-setting OSX's Network configuration.
Using Finder navigate to :-
Delete the following two files :-
Empty the trash and reboot.
OSX should re-discover all your Network Interfaces and rebuild the network hardware and software settings, hopefully with the correct BSD names. If the BSD names are still not correct and you have add-on NIC's such as PCI or USB then try removing all of them and delete the two files again, reboot and let OSX assign the 'built-in' NIC's first, then re-install your add-on NIC's one by one.
This method has a 60% chance of working .... if not then a re-install usually does the job.
You'll know if this particular issue is resolved once you can use some iCloud service such as the App Store and Software updates, but iMessage may still not work....
It's always worth checking your BSD names first-thing after a OSX install, or after you've added or removed any NIC's. As stated above, if your system has 'built-in' ethernet port(s) then the BSD names should start with those first and then cover any additional 'add-on' NIC's such as WiFI or USB, make sure they start at en0 and are numbered sequentially with no gaps.
If all your Network Interface's have good BSD names then it time to check if they are flagged as 'Built-In'.
For this task I recommend using DPCIManager 1.5, which you can download from here:-
Once installed run it and make sure your on the 'Status' tab, the top part of the Status screen will identify all your network interfaces and display their BCD names, as explained above, the BCD names should start at 'en0', additionally the 'Builtin' check box next to each interface must be checked for iMessage to work on each of the detected network interfaces.
if you do have this key and string in your plist but the 'Built-in' check box is not ticked then click on the 'eye' icon for the appropriate interface (at the right hand side of each entry), you will be given an EFI string that you can add to your boot.chameleon.org.plist in /Extra, this string is required for correct iMessage operation, for most users the Boot-Loader will identify the correct EFI string and automatically inject it, however in some rare instances this does not work in which case you should manually inject the NIC(s) EFI string(s) identified by DPCIManager.Code:<key>EthernetBuiltIn</key> <string>Yes</string>
If it does not work straight away, you may have to try one or two of the other steps such as deleting all previous iMessage setup data (See Step 3 below), reset password, delete nvram.uuid.plist in /extra ... etc.
All of my hackingtosh builds are using 'en0' and 'en1' for the on-board ethernet NIC's, if you have both ethernet and WiFi like my trusty Sony Vaio-SE2 laptop hackingtosh, the LAN port should be assigned to 'en0' and the WiFi should be 'en1' (see above DPCIManager 'Status' screen grab).
I personally recommend that you get iMessage working on a wired interface before moving to WiFi, if your working on a new build its best to get everything else working via wired network then add/enable the WiFi interface. If you jump straight to the WiFi interface then you may experience odd BCD NIC naming.
There is a bit more information on the issue with BSD names and a possible way to avoid the problem in the future here.
Step-2 Summary: NIC BSD names should be 'en0', 'en1' ... etc, numbered sequentially with no gaps.
OSX S/N, SMBIOS and the Boot-loader
OXS Serial Number
It is critical that you have a unique OSX Serial Number (S/N). Under no circumstances should you use someone else's OSX S/N it isn't necessary and can cause a miss-match with your System Type and lead to security issues.
Important: Try to keep the number of times you change the OSX S/N to an absolute minimum as Apple will detect the change against your devices UUID, if done too many times Apple will block your device's UUID against your AppleID (See Part-2 of the guide for more details on this, you can override your SystemId (UUID) by means of the SId Bug fix). While resolving some iMessage issues like BCD names and fixing ID's I recommend going off line that way you avoid Apple's servers detecting any changes which could be flagged as a miss-matches.
Note: Changing your OSX S/N can cause certain user profile settings being reset such as BT Mouse settings and Launchpad layout ..... additionally some registered applications that use the S/N as part of its licensing system may also be affected and need to be re-registered.
Anatomy of OSX S/N
The OSX S/N on MAC's manufactured after 2010 is normally 12 Digits long and can be broken up thus:
AA B CC DDD EEEE
AA = Manufacturing Country/Facility - 2 digit - alpha numeric
B = Generation Usually 2 - early MAC's such as Mac Pro 3,1 do not have this digit so S/N is 11 digits long
CC = Year and Week of manufacture as code - 2 digit - alpha-numeric
DDD = Unique Number - 3 digit - alpha-numeric
EEE = Suffix = Specific Model & Year/Type - 4 digit - alpha-numeric
The Prefix (AA) specifies the production facility were the MAC was made, getting this information is proving difficult but here is a list of confirmed country codes known so far ...
QP : USA
G8 : USA
CK : Ireland
C0 : Taiwan (Quanta Computers)
YM : China
W8 : China
RM : Remanufactured Model
Most OSX S/N generators such as Chameleon Wizard and Clover's 'Magic Wand' will set the prefix to either 'CK' or 'CO' as these locations manufacture many types os Apple Devices where as some plants only produce 1 or 2 models.
The Suffix (DDDD) consists of four digits depending on the model type and year it was made - pikeralpha maintains lists that you can use to check your OSX S/N suffix is correct for the model type your trying to emulate. It should be noted that it's not a complete list and only covers Apple hardware made in the last four years.
OSX S/N Suffix - F000-FZZZ
OSX S/N Suffix - G000-GZZZ
Also note that for most MAC's there are multiple entries for each year and model type, these are generally for the different configurations available for each model/year such as CPU/GPU/Memory ...etc follow the link against each suffix to confirm the exact specification. Some OSX features are only available on certain models/year so this may be an important factor in getting all of OSX features working correctly.
You should try to ensure that your S/N prefix and suffix is correct for the model type your using. I generally only use iMac 13,1 or 14,2 depending Intel Chipset and CPU type. As of late Oct 2014 - I have a theory that its possible that Apple are now checking the manufacturing country code (S/N Prefix) aginst the model type identifier ....
Example: MacPro 6,1 with a S/N starting with C0 or CK would be invalid as the new Mac Pro is only manufactured in Austin TX, USA so could never have a S/N prefix of C0 (Taiwan) or CK (Cork - Ireland) ... so if anyone is using MacPro 6,1 then that could easily lead to problems - this is purely a theory of mine at the moment but could explain what why some users are having trouble especially those using MacPro 6,1... I am investigating this trail of thought further and will update the guide soon.
I suspect many users are manually editing the SMBIOS.plist or Clover's config.plist and changing the System Type without realising the importance of the prefix or suffix in the S/N thus causing a S/N - System-Type miss-match.
Make sure your OSX S/N is valid but not registered ...
I recommend that you check any existing or newly generated OSX S/N using Apple's Self Solve website which can be accessed at the following URL:-
Simply copy and paste your OSX S/N into the form and click on continue, if your S/N passes the validation checks and is not registered then site will return with the following message:-
We're sorry, the number you have provided cannot be found in our records. Please verify the number and try again
This is good and is the only message you really want to see ..... it means your OSX S/N does not match an existing MAC's S/N but it does pass all of Apples S/N validation checks, this is also useful when calling Apple support as the S/N will appear valid but will not show up on their systems .. in-most cases making them think the issue is with their registration database and not your OSX S/N.
If the site returns with summary of the device and a page detailing the current warranty status then it means that the S/N is already registered and assigned to anther machine:-
This is bad, using someone else's OSX S/N is a very bad idea, if you own the MAC then I guess its not so bad but I still don't recommended it.
Its very easy for Apple's systems to detect that more than one machine is using the same S/N and/or other critical ID's such as ROM, MLB .. etc at the same time which may cause security authentication issues and you may be locked out using iMessages on all of your other devices or worse your AppleID could be deactivated, please read Step-5f for more information on this subject.
There have been a number of post's on this thread from users who it would seem have black-listed their own real Mac OSX S/N by cloning it across multiple hackingtosh machines. I can't personally confirm this but i have no reason to doubt those reports .... it would make sense given the heightened security Apple seems to apply to iMessage compared to all of its other online-services.
Finally, if you get the message :-
We're sorry, but this serial number is not valid. Please check your information and try again
Then the S/N your using is either black-listed or failing the OSX S/N validation checks, do not use it otherwise you will have iCloud/iMessage authentication and/or login issues, generate new S/N and try again.
System Type & SMBIOS
Its very important that you match the 'System Type' to the PC hardware you have in your hackingtosh for maximum system stability and performance.
If your not sure which System Type to use, download and install MAC Tracker ... compare the hardware of the various Apple Model types with the CPU and Motherboard chipset generation you are using, don't worry too much about the video type as you can override this using Boot-Loader options. Whats important is to try and match the CPU and Chipset as close as possible. OSX internal optimisations for Ivy & Haswell CPU based systems will only be activated if using the correct System Type .
Although many OSX Hardware build guides recommend using Mac Pro 3,1 because its considered 'safe' it can cause issues with iMessage because it has a 11 digit S/N - which in-turn can effect the MLB value.
OSX uses the System Type ID along with the PID's & VID's of your hardware in order to optimise some of the more advanced Apple only kernel features. EG you have a Haswell Z87 PC Based system but are using a Mac Pro 3,1 system definition which is pre Sandy Bridge Architecture ... Mac Pro 3,1 was discontinued in 2009 making its hardware specification over 5 years old - in PC technology terms this is light years - so in this instance many of OSX's power saving features of the Haswell Architecture will not be activated.
Updating the SMBIOS & OSX S/N - Chimera or Chameleon method
Open Chameleon Wizard and click on the 'SMBios' icon then 'Open' and navigate to the /Extra folder in the root of your startup disk and select your SMBIOS.plist.
Note: OSX RAID uses will have to mount the two RAID helper partition(s) to access the /Extra folders - see here.
Once your SMBIOS is loaded in the editor, Selecting a pre-made SMBIOS will automatically fill-in all the details and ensure that the 1st two digits of the S/N are correct for the system type you have selected (see Important note above).
Once your happy with the Systems Type, click a few times on the two <Random> buttons to generate a new batch number and week of manufacture then click on 'Save', if you boot from a OSX RAID then use the 'Save As' button to save the updated SMBIOS.plist to the two raid helper partition(s) - see here.
Updating the SMBIOS & OSX S/N - Clover Method
If using Clover, mount the EFI Partition and run Clover Configurator, load you config.plist and select the SMBIOS page. You can use Clovers 'Magic-Wand' to select a pre-made SMBIOS which works very similar to Chameleon Wizards .... you can update and replace any of the values if necessary.
Alternatively you can run Chameleon Wizard as detailed above and copy the values in to the respective fields in Clover Configurator.
Note: This is also the page where you can manually inject a uneque SmUUID (SystemId) See Part-2.
As mentioned elsewhere in the guide try to keep the number of incremental changes to your SMBIOS ID's to a minimum and always try to keep the system your configuring off-line until your happy with all the changes.
Once you have a working set of OSX ID's keep them safe and always try use them on the same machine to avoid iMessage being disabled again, remember that non of these ID's would ever change on a real MAC as they are baked into the system board.
If too many of your ID's are miss-matched then those ID's could also become black-listed in which case it is best to create a whole new identity for your system by generating a new SmUUID ID (See Part-2 of the guide), OSX Serial Number and new MLB & ROM values if necessary (See Part1,Step-5d of guide).
If your using Chimera (or Chameleon) as your boot-loader then ensure that the core version is 2.2 or later, if not then download and install the latest version of Chimera from the downloads section of this website or use Chameleon Wizard to update the Chameleon Boot-Loader before going any further.
OSX RAID users will need to manually install Chimera (or Chameleon) by extracting the '/usr/standalone/ i386' folder from the boot-loader install package (I use Pacifist) and then use terminal commands to install the boot-loader files on to your RAID helper partitions - see this guide if your not familiar with the procedure.
As explained in Step-5, if your running OSX 10.10.X Yosemite and want to use iMessage then you need to be using Clover as your boot-loader, for all other previous versions of OSX you can use Chimera or Chameleon.
Time to switch to Clover ....
As of mid 2014 I recommend everyone take a look at using Clover as their boot-loader, it's been written from the ground up to work with newer hardware and addresses many of the problems that cause iMessage to fail when using Chimera or Chameleon. I know a lot of you may think it's more complex than the older boot-loaders that your used to but in reality it's not that much different and gives you far more control and solves so many problems especially for Raid and Fusion drive users (no more cloning to fix iMessage).
I think much of the confusion is more to do with understanding how EFI booting works rather than Clover itself, if your not sure then it's worth searching for and reading a guides that explain how EFI booting works before jumping straight into Clover.
If you find that you have hardware that does not work with Clover try getting in-touch with the developers, they are keen and clover has nightly builds. I personally think Clover is the future for all of us, you just need to devote some time to it, I promise once you make the switch you'll never go back.
Step-3 Summary: You must have a unique, non-registered but valid OSX Serial Number, correct System Type and up-to-date OSX boot-loader.
Reset iMessage configuration files
If you are starting with a clean OSX install then there is no need for you to perform this step so jump forward to Step 5, however if you have been trying to get iMessage to work for sometime then the chances are that the iMessage plists could contain invalid or non-useful data and/or settings.
Ensure that you have ‘Show all Files’ or similar utility for displaying hidden files and folders in Finder.
You can download 'Show all Files' form the community section.
Enable ‘Show all Files’, start-up Finder and navigate to:-
Delete all files beginning with the following prefixes:-
Now navigate to:-
Delete all files beginning with the following prefixes:-
Now delete the folder:-
Note: This folder is your local message store, if you want to keep your existing messages make a backup of this folder before removing it, once i message is working you can restore the backup or recover it from a Time-machine backup.
You can switch off 'Show all Files' now.
You should not loose any messages or contacts by performing this action as both are stored in your iCloud account and should sync up again once iMessage is working correctly.
Update: Aug 2014
After a 'glitch' in Apples backend servers that occurred sometime around the 8th or 9th of August 2014 many users found that they were unable to reactivate iMessage despite following the above and the other tips in this guide.
If you have tried all the guides steps and iMessage is still not working then you could try the following:-
With 'Show all Files' enabled navigate to:-
Delete all files beginning with the following prefixes:-
This should be done in conjunction with all of Step-4 (remove all other iMessage plists)
Some users have found that they were unable to delete the security plists because they are being accessed by the security processes. If you find this is the case, open Activity Monitor and kill securityd_service, then securityd and try again (you may have to do this a few times before you can remove the plists)
Ensure you empty the trash before rebooting.
This optional step has been confirmed working by myself and several other users on this thread who were affected by this recent iMessage issue. Removal of these plists has not caused any additional side effects however as with all things Hackingtosh be sure you have a backup before you implement this fix. Any positive or negative feedback from applying this fix would be appreciated.
NVRAM - The Problem
On all genuine Apple Mac's, OSX stores some critical system keys and values in Non Volatile RAM (NVRAM) rather than writing them to a config file or plist on your startup drive. The NVRAM is Apple bespoke hardware built into a Mac's system board and forms part of Apple's OSX authentication system, as such PC motherboards & laptops do not have this hardware.
iMessage stores several important key values in NVRAM which form part of a long chain of crypto key's used by OSX for keeping content secure, an important factor in Apple's on-line eco system and one which iMessage relies on. If certain keys are not saved in NVRAM then the next time the system is powered off or re-booted iMessage may suffer from login and/or activation problems.
There has been much work done in the community to try and resolve this issue and the latest versions of Chameleon and Chimera include a fix that try's to maintain these critical values in OSX's NVRAM cache. However for reasons outside the scope of this guide it does not work reliably for everyone.
NVRAM - The Solution
Clover Boot-loader users:
Clover creates a much more complete NVRAM cache at boot time than legacy Boot-Loaders such as Chameleon and Chimera, OSX reads NVRAM values from a cache rather than the slow Non Volatile RAM ... as such this negates most of the problems associated with not having the NVRAM hardware, please skip down to Section 5d.
Chameleon and Chimera Users:
Note: The following method will only work for OSX 10.9.x Mavericks or earlier, If you want to run OSX 10.10 Yosemite and still want to use iMessage then the only solution at the moment is to update your boot-loader to Clover.
Update: 08-12-2014: New Version of FileNVRAM now available
A new version of FileNVRAM (1.1.4) has been released with limited support for Yosemite, you must use it in conjunction with the latest release of Chameleon - it does not currently work with Chimera - Please see the News article at the top of the guide dated 08-12-2014 for more information and download link.
The Hackingtosh group xZenue has released a boot-loader plug-in module called 'FileNVRAM' that simulates Apple's Non Volatile RAM hardware through software emulation and store's the NVRAM keys and values in a plist called nvram.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.plist located in the /Extra folder of your OSX startup drive.
The nvram plist is automatically generated by the FileNVRAM module the first time it is initialised and allows OSX to maintain NVRAM keys and values through power cycles and reboots. Depending on your system type, additional OSX settings may also be written to the simulated NVRAM such as brightness & volume levels.
You can check the content of OSX's NVRAM by starting a terminal window and typing 'nvram -x -p' and pressing return (do not include the quotes), the resulting output should list the current contents of the NVRAM, please note that many of the key values are encrypted or displayed as base64 values.
NVRAM - Installing FileNVRAM
For older systems (pre Chimera 2.6) download the attached file ‘modules.zip’ and extract it, the contents are a folder called 'modules' that has a single file in it named 'FileNVRam.dylib', copy the ‘modules’ folder and paste it in the ‘/Extra’ folder in the root of your startup drive
Important: Because of the way FileNVRAM works it must exist in /Extra/modules in the root of your OSX Start-Up Drive, if you boot using a USB key or from another drive the you need to address this before continuing. Normally this will involve using the stand-alone installer for your chosen boot-loader and install it on you OSX drive - RAID and Fusion drive users may have to use the terminal method to install the boot-loader - see both sections of the guide that deal specifically on Raid (Fusion) drives.
Remember you only need to install FileNVRAM if your using Chameleon or Chimera, if your using Clover as your boot loader then you should skip down to the next step.
For Systems that already have a 'modules' folder in /Extra then download the additional attached zip file that contains both versions of FileNVRAM (V1.1.2 & 1.1.3) and use the required version (see note 4 below)
Important notes about installing NVFileRAM:-
1. More recent versions of Multibeast now create the 'modules' folder in /Extra and place other '.dylib' files inside it, if you already have a 'modules' folder then just merge the contents of the attachment with the existing folder.
2. If you use the tip to move the /Extra folder and boot-loader files to the unused EFI partition then the chances are that FileNVRAM will not work for long, it is similar to the issue that effects RAID users in that once OSX is booted the EFI partition is unmounted so OSX no longer has access to the nvram.uuid.plist. To resolve this issue move the /Extra folder to the root of your startup drive and reinstall Chameleon or Chimera to the default location on the same drive, then use Disk Utility to erase the EFI partition (you will have to mount it first). This will not work for RAID or Fusion Drive systems. You could also try using EFI Mounter which is available in the Community Downloads sections of this site, This utility ensures that the EFI partition is mounted once OSX is booted which should allow FileNVRAM to function normally.
3. In addition to having a unique OSX S/N (see Step-3) you must also have a unique OSX platform UUID, this is anther unique system identity and is normally generated by OSX via a key passed from the BIOS called 'SystemID'.
In April 2014, Apple implemented new checks on their severs to make sure all iMessage packets are authenticated, these new checks ultimately led to the discovery of the "SId Bug" in the BIOS of some motherboard's which can cause a hackingtosh to have an invalid or duplicated platform UUID because 'SystemId' is not initialised correctly.
Since FileNVRAM also needs to use the value of 'SystemId' it is important to make sure your BIOS does not suffer from the 'SId Bug' so now is a good time to jump over to Part-2 of the guide and check to see if your BIOS is effected by it and apply the fix if necessary.
4. The version of FileNVRam.dynib included in the modules attachment of this guide is V1.1.2 this version is recommend for all Chimera Versions up-to 2.2.1. If you are using Chimera Version 3.0 or later then TonyMacx86 recommends that you use version 1.1.3 of FileNVRAM which you can download directly from this link, download and unzip the archive, you only need the file called 'FileNVRAM.dylib' copy and paste it in the /Extra/modules folder, delete the old version first if already there - alternatively download the attached archive which contains both version of FileNVRAM and replace your exsisting version with the correct one.
A small number of users have encountered issues with Chimera Version 3+ and have either stuck with FileNVRAM V1.1.2 or backed out Chimera to version 2.2.1 and FileNVRAM V1.1.2 this seems to effect some users running OSX 10.8 x (Mountain Lion). If your running Mavericks then use the latest versions of Chimera and FileNVRAM.
Please note that if you have recently updated to Chimera V3.0 or later and are injecting 'SystemId' in order to negate the SId bug then you must use the SMBIOS injection method, please see Part-2 (Step-7, Path B) for more info if you have not already done this.
Step-5 Summary: If using Chimera or Chameleon you must have FileNVRAM installed in /Extra/modules.
NVRAM - MLB & ROM Values
There are two critical values stored in NVRAM that iMessage uses when authenticating the iMessage security token. These are the MLB (Mac Logic Board) and ROM data values. Chameleon and Chimera users can view the NVRAM values using the terminal command 'NVRAM -x -p' which will display the values encoded in base64, you can use an on-line base64 converter to convert the <data> values to hexadecimal values, i use this one:-
Which can convert in both directions ...
A easer way to check these values is to use the attached utility 'iMessage Debug' which should work for all boot-loaders including Clover.
Update Oct 2014: New version of iMessage Debug (V2.0) available - see the news item dated 14th Oct 2014 at start of guide.
To use iMessage Debug download the attachment at the end of Part-1 and extract, there is no install required, simply double click on it in Finder to run it. It will dump all of the critical iMessage values from the NVRAM Cache including Platform UUID, S/N .. etc in a readable form.
The MLB and ROM values will be prefixed by a UUID and will look something like this:-
Note: Version 1.0 of iMessage Debug surrounds the The ROM value with '<' and '>' and will also insert a space between the 8th and 9th digit, this is a formatting issue and you should ignore these when referencing the ROM Value, just use the 12 Hex numbers.
If the values (xxx..) following these prefixes are incorrect, such as all zeros or blank then iMessage will have issues. Note that the UUID prefix should not and must not be the same as SM-UUID or Hardware (Platform) UUID - in most cases it will be the same as above which is ok.
The MLB Value Should be 13 digits in length if you have an 11 digit OSX S/N or 17 digits long if you have 12 digit OSX S/N. It is made up of a series of alpha-numeric characters much like the OSX Serial Number (see Part-1, Step-3). 13 digit MLB's are associated with Pre 2011/12 hardware and its syntax/format is largely understood where as more recent Apple hardware use the 17 digit MLB format which is still not fully understood.
The ROM value Should be 6 Bytes long (12 hexadecimal digits)
In addition to having valid values for MLB and ROM it is vital that these values are also persistent between shutdowns and reboots, as already discussed in Step-5 above, if these NVRAM values are not maintained either by Clover or FileNVRAM then the boot-loader will generate new random values on each boot.
If this is the case then iMessage may continue to work for a while, but Apples servers will detect the change in these values the next time you log-in. If this happens too often then it will cause a IP/Device lockout to be placed on your AppleID. This is a part of Apples backend security checks to stop hackers from cloning OSX system identities either for sending spam or gaining access to iCloud data.
Checking for persistent nvram values is easy, simply run iMessage Debug and make a note of the MLB and ROM values or take a screen dump of the iMessage Debug window.
Note: Version 2.0 of iMessage Debug has the facility to dump the output to a text file (see News 14th Oct 2014 at start of guide)
Once you've got a note of your initial ID values, shutdown and power back up and re-run iMessage Debug, if the simulation of NVRAM are working correctly then the MLB and ROM values will be the same as before.
If you have invalid MLB and/or ROM values (all zeros, blank, invalid syntax) or the values are changing on each boot-up then you must address this issue before going any further, whist working on these types of issues I recommend keeping disconnected from all of Apple iCloud services (logout from iMessage, iCloud .. etc) do not try to login until your happy that everything is correct.
If your running Clover then skip this list and continue with 'Manual Injection of MLB & ROM Values' below.'
If you using Chimera or Chameleon as your boot-loader then check these things first :-
- There is a new version of Chimera - Version 4.0 you may want to try this first if using Chimera, although there is no mention of better support for FileNVRAM in the change log.
- There have been reports that UEFI can cause problems on some systems, if you have the option available and are not running Windows 8 in UEFI mode then disable all UEFI options in the BIOS and use legacy boot options (SATA-P0 .. etc)
- Chimera and Chameleon can have issues with FileNVRAM if too many 'dylib' files are in the modules folder, try removing some or all of the other dylib files and see if that helps.
- It has also been reported that ACPICodec.dylib will cause problems with FileNVRAM, if it exists in your modules folder - remove it.
- Ensure that all files in the modules folder are .dylib files, if any other file types are in the modules folder remove them, it has been reported that some versions of the boot-loader will try to load any file as a module even if it does not have a .dylib suffix, which could abort the SMBIOS/NVRAM initialisation process.
- Try updating your BIOS, whist not directly related to MLB and ROM issues it has been found to help some users. If your using a custom/patched DSDT you may need to rebuild it using a new BIOS's native AHCI DSDT table as the source.
- If you are running a version of OSX earlier than OSX 10.9.x then consider updating to Mavericks. there have been a few reports that some users were not able to get the MLB and ROM values persistent until they updated to Mavericks, this is not something I can not confirm as i've not personally experienced it.
Manual Injection of MLB & ROM values
Important: You will find many posts on this and other forums quoting the use of real Apple Mac MLB and ROM values and OSX Serial Numbers. I strongly advise against using these shared/leeched values. Apple is getting more wise to cloned ID's and you may find that by using such values you will loose the ability to associate other Apple devices with your AppleID and you may even be locked out of your account if too many people use the same MLB and/or ROM values. By using someone else's MLB and ROM values you are effectively cloning/spoofing that persons system on Apples iMessage servers which can't be good for them or for you from a security point of view - Please see Step 5f "Using Leached ID Values" for more information.
With that said and out of the way, many users have had good success re-activating iMessage by manually injecting new unique and correctly formatted MLB and ROM values:-
For the MLB value use your OSX S/N + random alpha/numeric values to make correct length based upon the length of your OSX S/N (11 digit S/N = 13 digit MLB, 12 digit S/N = 17 digit MLB)
The ROM value is a heated discussion on many OSX Hackingtosh forums, some people think on a real Mac it is the MAC address of the firewire port, others believe that iMessage will only work if it is a cloned value form a real Apple Mac. The truth is that it has to be unique and 6 bytes long (12 Hexadecimal numbers), since a Network MAC address is 6 bytes and unique its a good value to use.
An easy to get a MAC address is to open 'System Preferences', click on 'Network' and select a Ethernet port (any will do) from the list of available network devices, then click on the 'Advanced' button and select the 'Hardware' tab, make a note of the MAC address, it will be 6 bytes ( 6 x 2 Hexadecimal numbers) each separated by a colon, do not include the colons when injecting a MAC address as a ROM value - you just need the hex numbers.
Important Warning: The above method of substituting the OSX S/N and adding additional random characters to make MLB the correct length no longer works - See News item dated 27-Nov-2014 at the top of the guide - the solution will be to inject a correctly formatted MLB, however no viable system of generating a valid 17 digit MLB currently exists - I'm looking into this and hope to document a solution soon.
It is also possible that the ROM value may also now need to follow a Apple based standard and be registered (white-listed) rather than using a generic MAC address, I'll update the guide again once proven.
Method for Chameleon & Chimera Users:
To inject new nvram values open terminal and use the following commands :-In each case, replace 'xxxxx' with the appropriate value and be sure to always use the same prefix UUID as displayed via iMessage Debug (normally 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14)Code:sudo nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB=xxxxxxxxxxx sudo nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM=xxxxxxxxx
When injecting the ROM value place a '%' in front of each byte
Ethernet MAC address = 23:f4:e7:65:4a:44
To inject the above as a ROM value execute:Important: FileNVRAM must be installed and working correctly in order for OSX to remember the new MLB and ROM values after a power down or reboot (Chimera & Chameleon only)Code:sudo nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM=%23%f4%e7%65%4a%44
After changing the MLB and/or ROM values, run iMessage Debug again and check the change, then reboot the computer and run iMessage Debug again, ensure the the new values are persistent, if they are then try a few more reboots/power downs ..etc, if all still looks good then jump down to the next step (5e)
If they keep changing then the most likely cause is a software incompatibility between the FileNVRAM module and your Boot-Loader, this is a very common issue and may not be straight forward to resolve.
Your only real option now is to try different versions of FileNVRAM and/or Chimera/Chameleon, If your using Chimera try switching to Chameleon.
I recommend using Chameleon Wizard version 4.4.1 or later to install different versions of Chameleon - on the 'Install page' use the drop down to select the Chameleon version you want to try and set the install method to 'Update' ensure you check the box 'Install more boot-loader files' then click on the 'Install' button. Thats - it. You can easily switch between different versions of Chameleon using this method, to switch back to Chimera run the appropriate standalone installer. Some of your boot.plist options may need adjustment to get optimum performance and full GPU support.
If after trying all of the above you find that your MLB & ROM values are still changing on each boot AND your motherboard's BIOS suffers from the SId bug (See Part-2 of the guide) then your very likely to find yourself in a rather frustrating situation. Due to version incompatibilities with the SMBIOS memory tables between Chameleon (Chimera) and FileNVRAM you may find that you can not solve both the SId bug and Non-persistent NVRAM values at the same time.
If you don't know if your motherboard suffers from the Sid bug then stop and read Part-2 of the guide now, check to see your BIOS has it, if it's OK and is not suffering from the Sid bug then carry on trying different versions of Chameleon you have a fair chance of finding a combination that will work.
However, if your BIOS does have the SId bug and a BIOS update does not help, then I seriously suggest you consider switching to Clover as your boot-loader right now, you could save yourself a lot of time and frustration. If you've been thinking about taking a look at Clover then do it now. Whilst it is possible to resolve both of these issues without using Clover I would say that you now have a 12% or less chance of it working (depending mostly on hardware).
Don't be afraid to learn something new, it really is worth the effort and once you've got it working resolving any SMBIOS/NVRAM Injection issues is straightforward and you'll kick your-self for not doing it sooner. I consider Clover the future for OSX hackingtosh systems especially with OSX 10.10 on the near horizon. Personally I find it easer to install OSX using unibeast and then Install Clover as the boot-Loader (see Post #1272 for more info)
Method for CLOVER Users:
The most recent version of Clover I have tested is r2999 which works well for OS X 9.5X and 10.10. For novice Clover users I recommend using Rt Variables method of injection as its a bit easer to understand and should result in predictable results however you should be aware that Clover is changing the default way it injects/generates MLB & ROM values in the future (See Update below).
I also recommend that you use Clover Configurator for maintaining Clover's config.plist which you can download from here, whilst it's quite easy to to manually edit the config.plist using text wangler or any other editor some of Clover's plist formatting is very specific so I personally always use the configurator.
When working on Clover in EFI mode you will need to mount the normally hidden EFI Partition. Clover Configurator has an option to do this for you when you run it but i use a small OSX menu utility called Semulov which can be download for free from the developers web site here, die hard terminal users can mount it from the console using diskutil.
Run Clover Configurator and mount the EFI Partition if not you've not already done so. Click on the 'Home' Icon and load the config.plist from your /EFI/Clover folder. If this is the first time you've run Configurator then you may need to use the import option to load the config.
Once loaded, click on 'Rt Variables' on the left selection plane and enter the values for MLB and ROM (hex numbers only as detailed above) in the appropriate fields.
Clover Update October 2014:Code:<key>RtVariables</key> <dict> <key>MLB</key> <string>XXXXXXXXXX</string> <key>ROM</key> <data>YYYYYYYYYYY</data> </dict>
As of Oct 2014 the Clover developers are making the Rt Variables method of injecting MLB & ROM values deprecated, if your already using the above Rt Variables method to inject the MLB & ROM values then there is no need to panic or change anything right now as this method will still work and is still my recommended method.
However the Official Clover Wiki now states the default method used to specify the ROM & MLB values is as follows:
ROM: This will now be read from the last 6 bytes of the 'SmUUID' field. If you have nothing in the SmUUID field then Clover will try to use your BIOS's SystemId (see Part-2 of the guide) however, I personally think it's always best to override The BIOS (even if it does not suffer from the SId bug) and to use the terminal command 'uuidgen' to generate a new random value (See Part-2, Step 7, Path-C). Enter the generated UUID as the SmUUID value on the SMBIOS page. If this is a new OSX Install then you can leave it like that. If you want to keep you old ROM value then replace the last 6 bytes of SmUUID with the ROM value you were using before which is normally the MAC address of an ethernet port (usually en0).
Note: It is important to understand that configuring Clover like this will cause your existing Hardware (Platform) UUID to change ... whilst this in-it's-self is not a problem it will change the identity of your system from your previous install which in-turn may cause some user profile settings to be changed due to the Hardware (Platform) UUID being used as a key value for storing some OSX configuration data against.
MLB: This is now read from the 'Board Serial Number' field on the SMBIOS page, on a clean Clover install this is defaulted to Clovers own pre-set static value which is of-course black-listed on Apples systems. You therefore must replace this with your existing MLB value (on an existing install) or use your OSX S/N + Random Alpha / Numeric digits to make it up to 17 digits.
iMessage Debug not Working: There are quite a few versions of iMessage Debug floating around on GitHub. Since it is a terminal framework utility the version's attached to this guide may not work on older versions of OSX, if it does not work for you try finding an alternate version or downloading a source file and compile it on your own system or you can use Darwin Dumper as an alternative.
Credits: iMessage Debug was originally created by @ElNono based on the iMessage login research done by @tflux back in September 2013 a big thank you goes out to those guys.
Reset FileNVRAM Plist (Chimera & Chameleon only)
Sometimes the key data stored within FileNVRAM's plist can get out of sync, for instance if you change your OSX S/N the MLB value in NVRAM may not match the new one. There are multiple reasons for resetting FileNVRAM plist.
I recommend resetting the NVRAM plist when ever you change anything to do with the system identities (UUID, S/N, System Type .. etc) or after using step 4 of the guide. I tend to do this all the time when working on fixing iMessage.
Because FileNVRAM's job is to keep the nvram.uuid.plist in /Extra updated at all-times - on some systems the file can be recreated during a OSX shutdown in which case it may not pick up changes to certain SMBIOS parameters. So we need to temporally disable FileNVRAM - this fail-safe method will ensure that you always get an entirely new and correct uuid.nvram.plist.
- Disconnect from Internet
- Copy FileNVRAM.dylib from /Extra/modules to your Desktop
- Remove FileNVRAM.dylib from the /Extra/modules
- Remove all nvram.uuid.plist's and empty the Trash
- Ensure that there are no nvram.uuid.plist's in /Extra.
- Make any necessary changes to SMBIOS
- Copy FileNVRAM.dynlib from your Desktop back to /Extra/modules
- Open a terminal window and execute the following command:-This console command clears the value of the 'boot-args' key stored in the OSX NVRAM cache which can sometimes interfere with creating a new 'nvram.uuid.plist' file in /Extra if set.Code:sudo nvram boot-args=""
- Check that a new nvram.uuid.plist has been recreated in /Extra
- Check uuid in filename matches (IORegistry: IODeviceTree : efi / platform / system-id)
- Check MLB & ROM using iMessage Debug
- You may have to re-inject your MLB & ROM value if so inject it and reboot, check again
- If all looks well reconnect to the Internet
NVRAM - Using Leached ID/Stolen Identity - Warning
There have been several posts in this thread about using leached 'Real MAC' ID's rather than using random, unique values. Whilst this method is known to work and several forum members are using this method, unless you own the Mac who's ID's you are going to clone, then I strongly recommend that everyone else avoid this method. When the device is registered with Apple, the ID's are used to create an iMessage 'authentication token' which is then used to secure all iMessage traffic between your device and Apple.
If you use the 'Stolen Identity' method then your iMessage data is essentially using the same authentication token as the machine who's ID's you've cloned/stolen. Even if you change the ID's after registering with iCloud, the iMessage authentication token remains in place until you logout. Thats why if you get logged out and your ID's have changed (such as MLB or ROM) then the token can no longer be authenticated.
Since it's relatively easy to intercept IP packets (especially on non-secure wifi) it's a security hole that could potently be used to receive someone else's iMessage packets.
My main concern is that if too many people use leached ID's then Apple will be forced to change the whole iMessage protocol which could be a real problem for us hackingtosh users, potentially locking us all out of the service for good which would be a real shame.
I understand why some of you are getting frustrated and resorting to this method, but i think it can only end badly for everyone if it becomes a common practice.
As already mentioned, for some of you this will mean ditching the familiarity of Chameleon/Chimera and moving over to Clover which may seem daunting especially for novices but it really is not and once you have got your head around it you'll wonder why you didn't do it sooner. It really is the future for hackingtosh systems.
Please don't resort to using hackers methods, as it will give this community a bad name and could make things very difficult for all of us in the future. My personal feeling is that Apple are actually ok with people using OSX on their PC's. After all the OS is free .... surely it would be better for Apple if PC users dropped Windows in favour of OSX ? .... leading to increased awareness of Apple eco systems and features ... it could even be considered clever marketing by Apple .... it's advertising that money cant buy (literally for a lot of us) .... however if the hackingtosh community abuse this oversight then we should not be surprised if Apple do something about it, especially when it concerns the on-line security of their customers.
Time to Try iMessage
After applying any of the steps from Part-1 and/or Part-2 of the guide, and before trying iMessage I recommend running Disk Utility and repair permissions on your startup disk, this is optional but a worth while step.
Now reboot your system ....
If you installed or updated Chameleon (or Chimera) then its best to pause the boot process the first time round and check that you have the correct version installed, press the <Tab> key to switch to text mode while still in the boot-loader, the version will be displayed at the top, it needs to be 2.2 or later.
If all is well, let OSX load ...
If your using Chimera or Chameleon then open Finder and check that 'nvram.uuid.plist' has been created in /Extra, if not then something is wrong with your install, recheck everything.
Right moment of truth time, on a clean install or refresh of ID's i tend to check the basic iCloud services first such as the App Store, Notes, iTunes .. etc if these work then load up iMessage and if required login - Hopefully things will be fine and you'll be up and running.
If things don't work the first time do not give up, sometimes you may need to repeat a step or perform a step that you skipped the first time round, be sure to read all of the notes.
Observations and Credit
I've successfully used all of the above steps in various combinations to get iMessage working on OSX Mountain Lion 10.8.4/5, Mavericks 10.9.0/1/2/3, Yosemite 10.10.0/1 on a multitude of hackingtosh systems both desktop and laptops. Please post your success or fail stories to this thread and if you found this guide helpful then please click on the 'Recommended' tab at the very top of this post to help others find it.
Special thanks to xzenue for creating the FileNVRAM fix.
Further notes for RAID Users
As detailed at the start of Part-1, if you boot OSX from a software raid then unfortunately it causes a problem for FileNVRAM. Because the boot loader has to be accessible outside of OSX (a software raid can only work once the kernel is up and running) the boot-loader and /Extra folder must reside on the raid helper partition(s), unfortunately the raid helper partition(s) are unmounted once OSX starts up, thus FileNVRAM is unable to access the /Extra folder which means that the contents of nvram.uuid.plist can not be updated.
You can use the RAID clone method detailed at the start of the guide to get iMessage working initially but if you ever get logged out of iMessage for any reason then you will need to repeat the clone procedure so that the NVRAM cache, nvram.uuid.plist and the iMessage plists can get updated with new keys and data.
Once you have re-cloned the volume back to your raid you need to copy the new nvram.uuid.plist to the /Extra folder on both the raid helper partitions (be sure to delete the old ones first), it is not necessary to blow away the raid on a re-clone but copying the nvram plist on its own will not work, you have to clone the whole drive back to the raid as-well.
I'm sure that there must be a better way like updating some OSX configuration files with keys or UUID's, but as yet i have not found one, if anybody else finds a better solution to resolve the raid issue with FileNVRAM please post.. I have a RAID 0 on my primary OSX development system and come against this problem from time to time.
Update: I have reported this issue to the developers of FileNVRAM and suggested a possible work around, once we have a better solution for Raid users I will update the guide. Please see this Link for the problem & enhancement request.
In order or for iMessage to work on a Hackingtosh computer the following must all be true.
- You should have a valid credit card registered against your Apple ID - See Step 1.
- Your AppleID must have a verified status - See Step 1.
- NIC BSD names should start at en0 and be sequentially named with no gaps - See Step 2.
- NIC being used to access the Internet must have a 'Built-in' status - See Step 2.
- You must have a unique OSX S/N and up to date boot-loader - See Step 3.
- The S/N prefix should match the the System Type ID - See Step-3.
- If using a legacy boot-loader you must have FileNVRAM.dylib in '/Extra/modules' - See Step - 5.
It Still Doesn't Work ?
Whilst this guide should work for the majority of you there are a few more odd situations that can still cause iMessages to fail. First if you haven't already done so, you should read through Part-2 of the guide below and check that you have a unique BIOS SystemId and OSX platform UUID, make sure your not effected by the SId Bug.
Although rare, some issues such as the ROM value always returning zero's have been resolved by updating the BIOS. Whilst updating the BIOS has never resolved anything for me it has helped a few people on this thread/forum so it's worth considering if your continuously having problems and the fixes don't seem to work.
Warning: You should only update the BIOS if you know sure about what your doing .... if you are using a DSDT with your boot-loader then updating the BIOS may break your DSDT's system compatibility. Idealy after updating the BIOS you should extract a native DSDT and re-patch.
Sometimes it is necessary to try some of the steps in the guide more than once, iMessage is very very fussy, so much so that sometimes the order of the things you do can effect the out come, the order given is the guide is a logical one for a system that has just had OSX installed with no prior knowledge of iMessage fixes.
There is a basic set of requirements (see Part-1 Summary above) that must be met for iMessage to work on a Hackingtosh, if these requirements are met then iMessage should work. Thats why I've tried to write this guide as a tool box of procedures (steps) for you to use in resolving iMessage issues, just about everyone will have a different set of issues requiring the use of different 'tools', no one step can cover all the issues.
If you understand the problems then you learn and can give feedback which helps everyone.
iMessage can be very frustrating and can take a lot of time to fix, there are countless tips on hundreds of forum sites all over the internet, some are useful, some are not, many just tell you to do something without any real understanding of what the issue is and thats not good for the community...blind leading the blind.
If you continue to have issues, try searching this thread - its possible that someone has already found a solution to your issue, one suggestion that keeps coming up is to use a real MAC to reinitialise the effected AppleID, although I can not personally confirm this suggestion, it does seem to have helped others but like so many tips out there it could also be coincidence as this also works when using another Hackingtosh to reinitialise an AppleID as discussed in Step-1.
Finally I'll end this part of the guide by stating that Apple are constantly evolving and updating their on-line eco and message systems with new features and security measures, as such do not be surprised if we see new and even stranger issues with iMessage in the future. If you think you've encountered a new iMessage issue please post to this thread with as much info as you can, including screen shots of any alerts and/or console log snippets and i'll try to help.
Thanks for reading & good luck.