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 youDO 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.
Symptoms:
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 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 any changes to the 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.
I believe the issue 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 validation checks thus triggering the contact Apple alert message and failure to receive a new token. In the past once the customer code was entered it would set a flag against the device in Apples database allowing your id's to pass that part of the validation check.
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 teh system type being used (either 13 or 17 digits). I suspect that the new validation checks implemented by Apple are now ensuring that the format of the MLB is correct and matches proper Apple formatting/validation.
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. I have plenty of real Mac MLB's to look at but information is scarce on the formatting of each component value.
Interesting side Note: New or refurbished Mac system boards do not have a OSX S/N burned into them. If Apple has to replace the system board on a faultily Mac the tech is supposed to run a ASD utility to generate the S/N from the MLB and burn it into the board. I am attempting to understand just how this utility works in the hope that it contains the look-up tables and correlations needed to understand how the component values of a MLB is made up.
As always when things go wrong ... 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. We have to try and find a way that can satisfy Apples validation and security without resorting to using cloned values or pirate methods 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.
自从换了clover，再也没登上去过iM和FT，估计我就在那幸运的黑名单中～
我也是打電話激活的。現在還能用。。。
别注销就好，不然～
目前大神现在也无解了～估计他们要休很长一段时间了
以前觉得clover优势很明显，可是现在变色龙越来越完善了，早上我还发了新版变色龙能使用imessage的模块文件……可是Clover至今没有好的解决方案
壕，友乎……