How to Fix iMessage

How to fix

Change Log

06:03:2014: Updated info on issue effecting raid users
03-03:2014: Updated info on Apple ID validation check
02-03:2014: Re-format 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: Additional new Step [2] to try
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


iMessage, the cross device instant messaging system built into Apple's OSX and IOS is quite possibly the most finicky element when it comes to getting OSX running on non-Apple hardware. Having built and installed many hackingtosh systems over the past few years, i've run into this problem many times and in each case it was a different cause requiring a new solution each time.

Click image for larger version. 

Name: Screen+Shot+2012-07-27+at+9.38.57+AM.png 
Views: 3464 
Size: 112.6 KB 
ID: 85651
Symptoms of iMessage problems usually show as a sign in or activation error

I wrote this guide to share my findings for those of you who are having problems running iMessage, it offer's a variety of things to check and change in some sort of logical order, some steps of the guide are critical other are optional, this is made clear at each step of the guide.

As i hinted above, there are many different factors that can effect iMessage and stop it from working, I am quite sure that there are still more solutions and tips to be found, as such I can not guarantee that this guide will fix your problem 100% but it has helped many many users and should have at least a 95% chance of working for you. I will continue to update the guide as new solutions are found and confirmed.

I would suggest that you read through the complete guide first and digest the various different steps before making any changes on your system, I have tried to explain the reasons behind the problems and each solution, it maybe that you can solve your issue with just one or two of the steps. As always make sure you have a up-to-date backup of your OSX startup drive.

Important info for software RAID users

If you boot OSX from a standard AHCI single drive (HDD or SSD) then skip forward to step 1, but if you boot OSX from a Apple software raid then there is an added complication. For reasons outside the scope of this guide it is not possible to resolve all the iMessage issues on a active software raid.

In order for this fix to work you must first clone your raid using Carbon Copy Cloner to a standalone HDD, install the boot loader and modify the chameleon plist in /Extra so that you can boot OSX from this non raid clone. Once booted from the clone HDD, apply the necessary steps from the guide below to get iMessage working.

When your happy that everything is working ok, and you've got a backup of your backup, take a deep breath and delete your existing raid set and then re-create it so a new raid uuid is generated, its worth erasing the two raid member drives before re-creating the raid just so you know that everything is fresh and makes for a good opportunity to update your raid boot loader.

Finally clone the standalone HDD on 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 generated nvram.xxxxx.plist from the standalone HDD /Extra folder to the two raid helper /Extra folders, be sure to edit the chameleon plist so that it boots using the new raid uuid.

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 the above method as that's how we get our raids woking in the first place, so just think of it along those lines and it wont seem quite so daunting, just be sure to cover yourself with multiple backups if possible.

If you don't understand the above then please stop now, do some research and make yourself very familiar with the way a OSX raid is created and made bootable on a hackintosh in the first place.

Please see the raid specific notes towards the end of the guide for further information on this problem, my thanks to stradivari2 for confirming this issue.

Step-1: Do you have a 'Validated' Apple ID account ?
Updated: 03-03-2014

There are a few different types of Apple ID / accounts and they are all treated slightly differently by Apple's servers. As far as i know the different types of Apple ID are :-

  • Basic
  • Basic Validated
  • Pro (Validated)
  • Developer (Validated)

The Apple ID you use with iMessage must be a validated account and the easiest way of making your account validated is to register a credit card against the Apple ID. If you have already bought apps or music via your Apple ID then the chances are your Apple ID is already validated, you can check the status of your account by logging into Apple's on-line Account manager.

By registering a Credit Card to your Apple ID, Apple's servers and systems know that the Apple ID has a valid name and address (validated via the credit card info) this means that all messages sent/received by that Apple ID are traceable to someone (or somewhere !) .... when you think about it, it sort of makes sense that Apple would limit iMessage to a validated ID, especially in light of the recent NSA disclosures so don't expect too much privacy on Apple's systems .... it's in the small print somewhere .... apparently ....

You can register a credit card against your Apple ID either through iTunes or the App Store.

Once you Apple ID is validated and you have iMessage working you can remove the credit card if your worried about others using the account and running your bill up with iTunes and App purchases.

Step-1 Summary: Your Apple ID must be validated in order for iMessage to work.

Step-2: Check your Network Device ID's
Updated: 26:10:2013

This is a new step which i figured out while assisting a good mate of mine with getting iMessages to work, one thing that was different for him was that both iCloud and the AppStore where also not working despite having an otherwise perfect system with internet and local LAN all working fine. We have identical builds so after walking him through this method a few times, we started to dig a little deeper. Im pretty sure that if you've tried everything and are still having issues this step could really be important.

Open 'System Information' [About this MAC -> More Info -> System Report] and click on 'Ethernet Cards' section, You will see a list of your ethernet cards, for each network card in your system 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've got a Gigabyte GA-Z77-UD5H Motherboard that has two LAN ports, one is a Atherois controller and the other is a Intel LAN controller, The Intel port is 'en0' and the Atherios port is 'en1'.

When I compared this info with my mates system his Intel port was 'en2' and the Atherios port was 'en1' there was no 'en0'. How this can happen i'm not sure, maybe something to do with installing a firewall or some extra step in the install.

Although all of my Desktop MAC builds are using 'en0', I'm pretty certain that iMessage and iCloud should also work on 'en1' because the old MacBook Pro's had a LAN port as-well as WiFi, OSX assigns a <BSDname> of 'en1' to the WiFi Interface, this is also true for my trusty Sony Vaio-SE2 Hackingtosh laptop, the RealTek LAN port is assigned to 'en0' and the WiFi is assigned to 'en1' (also now running OSX Mavericks)

Update: 4 Dec 2013

Based on further research by myself and other members posting their findings to this thread, I think the situation with network BSD name(s) is that if you connect to the internet via ethernet your interface must have a <BSDname> of 'en0' or 'en1', it would seem that for WiFi and USB based interfaces that it can be other values such as 'en2'
In the end it was quicker and easier to re-install OSX and this time the Intel port was identified as 'en0' and after applying the fix at Step-5c everything worked perfectly. So if you don't mind a re-install then that is probably the best option.

We did try deleting NetworkInterfaces.plist in /Library/Preferences/SystemConfiguration and re-booting, we tried removing the network devices in [System Preferences -> Network] and re-adding them , un-plugging cables and moving things around and eventually we were able to get the Intel port identified as 'en0' but even after trying all the remaining steps, iCloud would still not work. I suspect there are some other setup files that need deleting/changing. Like i said, in the-end, ten minutes spent re-installing OSX and completing Step-4 and the job was done.

it maybe possible by editing <BSDname> in the following file:-


But we didn't try this as we'd already wasted hours trying to fix it which is when we decided to re-install. If anybody does find out how to fix the lack of 'en0' then let me know and i'll update the guide.

Step-2 Summary: If using ethernet BSD name should be 'en0' or 'en1'

Step-3: Edit SMBios.plist and update Chimera Boot-loader

Make sure you have a unique Apple serial number, i think the latest version of Multibeast should take care of this during installation when it creates the SMBios.plist file, but as an added precaution i would recommend running Chameleon Wizard  and click on the 'SMBios' icon then click on 'open' and navigate to /Extra folder in the root of your startup disk and select the file SMBios.plist.

(OSX Raid uses will have to mount the two raid helper partition(s) to access the /Extra folders)

You can use one of the pre-made SMBioses if you know the correct one for your system (3,1 in my case) this will automatically fill-in a few non critical information tags that Multibeast leaves blank, however this is an optional and if your not sure just leave that alone and keep the one generated by Multibeast.

To change the serial number, click a few times on the two 'Random' buttons to generate a unique batch number and week of manufacture then click on 'Save'.

(OSX Raid users should also use 'save as' to save a copy onto the other helper partition(s)

If you are not already running Chimera 2.2.1+ then please download and install it. OSX Raid users will need to manually install Chimera by extracting the /usr/standalone/ i386 folder from the install package and use terminal commands to move the boot-loader files to the appropriate helper partitions.

Step-3 Summary: You must have a unique Serial No. and up to date boot-loader.

Step-4: Remove old iMessage Setup data

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 like me you have been trying to get iMessge to work for some time then the chances are that the setup data and plists are full of invalid data. So lets start with a clean slate and remove all the current iMessage related data and plists.

Ensure that you have ‘Show all Files’ or similar app for accessing hidden files and folders.
You can get Show all Files form the Terminal.
Enable ‘Show all Files’, start-up Finder and navigate to:-


Delete all files beginning with the following prefix:-

• Caches/
• Caches/

Now navigate to:-


Delete all files beginning with the following prefix:-


Now delete the folder:-


You can switch off 'Show all Files' now.

Step-5a: NV RAM - The Problem

On all real Apple MAC's, OSX stores some critical system variables and their contents in Non Volatile RAM rather than writing them to a config file or plist on your drive. The Apple NV RAM is bespoke hardware that is built into a MAC's System Board, as such PC Motherboards do not have it.

One of the most important variables normally stored in NV RAM is the SystemID UUID, as well as being a unique system identifier the value of the SystemID UUID is used as part of a crpto key for keeping content secure, this is an important factor of the Apple eco system and one which the iMessage system uses. If the iMessage uuid & session key is not saved in NV Ram then next time the system is powered off/rebooted it can be a different value resulting in iMessage login and activation problems.

There has been much work done in the community to try and resolve this problem and the latest version of Chameleon (Chimera) does include a fix that try's to maintain the SystemID UUID in OSX's nvram cache. But for reasons outside the scope of this guide it does not work for everybody, if this is the case for you then you must perform the following step.

Step-5b: NV RAM - The Solution

Hackingtsoh wizard xzenue has written a boot time module called FileNVRAM that simulates Apple's Non Volatile RAM through software and store's the names and values in a plist called nvram.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.plist in the /Extra Folder of your OSX startup drive.

This file will automatically get generated by FileNVRAM the first time it is initialised. By storing the variable names and values in a plist, FileNVRAM allows OSX to maintain these variables and values through power cycles and reboots. Further information is written to the simulated NV Ram by OSX such as brightness level and in iMessages case the current session key which is critical to iMessage working correctly.

Step-5c: NV RAM - Installing NVFileRAM

Download the attached file ‘’ and extract it, the contents are a folder called 'modules' which has a single file in it named 'FileNVRam.dynib' copy the ‘modules’ folder that you extracted form the attachment and place it in the ‘/Extra’ folder in the root of your startup drive.

Note: More recent versions of Multibeast now create the 'modules' folder in /Extra and place a file called 'Keylayout.dynib' in it, if you already have a 'modules' folder then just merge the contents of the attachment with the existing folder.

(Those using an OSX Raid will need to copy the modules folder to the /Extra folder on both raid helper partitions )

Now before we reboot i recommend running Disk Utility and repair permissions on your startup disk, this is optional but a worth while step.

That’s it, reboot your system . . .

Tips, Observations and Credit

If you installed Chimera at Step-3 of this guide then its best to stop the boot process the 1st time round and check that you have the correct version installed (just press the tab key to switch to text mode at the boot loader screen, the version will be displayed at the top of the screen) it needs to be 2.2 or later.

If all is well, let OSX load and try iMessage, hopefully it will now work.

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.

I've successfully used all of the above steps in various combinations to get iMessage working on OSX Mountain Lion 10.8.4/5 and Mavericks 10.9.0/1/2. Please post your success or fail stories here and if it did work for you please click on the 'Recommended' tab at the very top of this post to help others find it.

As I said at the start, most of this guide has been put together from various tips I found around the web and a lot of personal experimentation, my thanks to everyone who contributed - without the Hackingtosh community things would be very different, we should all be grateful for everyones hard work, without which we would not be able to run this great OS so well.

Special thanks to xzenue for creating the NVFileRAM fix.

Further notes for RAID Users
Updated: 04-03-2014

If you boot OSX from a software raid then unfortunately there is a problem with the way NVFileRAM works, because the boot loader has to be accessible outside of OSX (software raid can only work once kernel is up and running) the /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 and eventually times out and quits, so it is unable to update the info in the nvram plist.

The only way around this as far as I know is to clone the raid onto a stand alone HDD, modify the chameleon plist and install the boot loader so that the drive can boot on its own. Once booted from the stand alone HDD it is possible to install FileNVRAM in the /Extra folder and perform any additional steps required from the guide.

Once the new standalone HDD is booting ok, FileNVRAM should also be working and should have auto generated the nvram plist in /Extra, so go ahead and log in to iMessage, hopefully it is working now.

Once you have a working build you then have to re-clone the standalone HDD back to the raid and then copy the nvram-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.plist to each of the /Extra folders on the raid helper partitions and make sure you have NVFileRAM version 1.1.2 in the module folder.

Simply copying the nvram plist files on there own will not work, you have to clone the whole drive as well so i'm guessing there are some configuration files and plists within OSX and/or the user folder that are linked to the contents of FileNVRAM (system ID being the main candidate)

Once the re-cloned raid is working, FileNVRAM works in that it can read the plist from the helper partition and initialise the nv ram with its contents, thus iMessage will continue to work. However once OSX is loaded, NVFileRam it is unable to refresh the contents of the nv ram plist in /Extra as the raid helper partitions are no longer accessible (un-mounted) so if you ever get logged out of iMessage or your SystemID UUID is altered the plist can not get updated and you will have to do the whole process again.

Most raid users should be familiar with this procedure as it is the way most users set up a raid in the first place, but it is time consuming and there is always the possibility that something could go wrong during the cloning process and you could end up loosing your raid. Multiple TM & CCC backups are the solution to that fear, make sure you cover yourself for all possible out comes.

There must be a better way like updating some OSX files or plists with the Raid or SystemID uuid's, but as yet i have not found one, if anybody else has a better solution to resolve the raid issue with NVFileRAM please post , I have a raid 0 on my primary development system and i come against this problem all the time.

Update: I have reported this issue to the developers of NVFileRAM 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.

Guide Summary

In order or for iMessage to work on a Hackingtosh computer the following must be true.

  • You should have a valid credit card registered against your Apple ID - See Step 1
  • If using wired a network (ethernet) BSD name should be en0 or en1 - See Step 2
  • You must have a unique serial number and up-to-date boot loader - See Step 3
  • You should have NVFileRAM Version 1.1.2 in '/Extra/modules' - See Step - 5

Additional Information

Note: The version of FileNVRam.dynib included in the attachment of this guide is Version 1.1.2, the more investigative forum members may find a later version of FileNVRam.dynib floating around the internet - Version 1.1.3. It has been widely reported by many users, including myself that Version 1.1.3 does not work in all cases at least not yet. If the situation changes I will update this guide but for the moment I would recommend that you stick with Version 1.1.2 only try Version 1.1.3 if all else fails.

What else can I try ? Whilst this guide should work for the majority of users there are a few odd situations that can still cause iMessages to fail, a few users have reported success by using a real MAC to (re)initialise the Apple ID, I would suggest that you read through the rest of this thread - some forum members who the guide did not help have resolved the issue anther way and posted their findings.

Good Luck

Share this

Related Posts