Jump to content

[Guide] AIO Guides For Hackintosh


607 posts in this topic

Recommended Posts

I´d like to contribute to the work done so far and let you know what I was able to figure out so far...

 

Before December 29th early in the morning (german time) it was enough to have a valid pair of MLB/ROM to sign on to iMessage an use the Service after that it stopped working for some of us though we´re still signed on (iMessage Preferences shows the Service to be activated). After this date we´re still able to log out an log into iMessage using a valid pair of MLB and ROM values but we´re not able to send or receive Messages at all. Again it logs in successfully but won´t send or receive any Messages even though it says the message was delivered...

 

I started to investigate on the issue and tried to figure out why my desktop machine was able to send and receive messages (iMessages and even SMS) where my Laptop and the mac I borrowed the ROM and MLB values from wasn't. Although all of them use the same ROM and MLB values only my Desktop PC was able to send and receive Messages. I logged out and back in on both of them (Laptop and MAC) and iMessage showed me to be logged in and activated but I was not able to send or receive any messages on this devices. I decided to run iMessageDebug on my working desktop and on the not working but signed in Laptop and MAC and discovered that SystemID and HardwareUUID where different on all of them. In a next step I disconnected the Laptop from the internet (Laptop is using Clover as bootloader) and changed SMUUID and SystemID to match the ones of my Desktop. After a reboot (still disconnected from Internet) it told me that the iCloudKeyChain has been deactivated. I checked all values with iMessageDebug and verified that ROM,MLB,System-ID and Hardware UUID do match my desktops values rebooted an connected the laptop to the network and iMessage worked again...

 

So my conclusion to this is, that apple started to associate ROM and MLB values with normally unique System-ID and Hardware UUID values and they do associate the first Hardware UUID and System-ID with the given ROM and MLB values which signs in to their services...

Yet again, it looks like Apple has tightened iMessage/FT validation checking so it might be necessary for those using cloned MLB/ROM values on multiple machines to take extra precautions against Apple blacklisting those values. I have been using genuine Mac IDs from my mac mini for over 6 months and it is still working for me as at the time of writing 1/1/2015. The new reports from users point to some type of system-id block when Apple's servers see more than one machine logged onto iMessage/FT with the same MLB/ROM but different system-id/PlatformUUID.

 

Recommendations

  • Consider generating unique MLB/ROM (with correct pattern/format) for your hacks and registering them by calling Apple Support
  • Cloning a Mac's MLB/ROM for your hack should only be done if you own the Mac whose MLB/ROM you are intending to use. Ideally, take MLB/ROM from an older Mac that has been “retired” from service
  • If you want to continue with cloned values on your hack, its prudent to take extra precautions to protect the "donor" Mac IDs from blacklisting caused by mismatches on your hack
  • Never share MLB/ROM values publicly
  • Try not to have more than one machine connected to the internet and logged into iMessage/FT at the same time (using the same MLB/ROM). If you want to connect both hack and Mac to the internet at the same time, make sure to logout of iMessage/FT on one of them.
  • To prevent Apple flagging ID mismatches, make the cloned system match the original Mac more closely - at a minimum, MLB/ROM & system-id.

Procedure

1. Run imessage_debug V2 on the real Mac to obtain system-id, MLB, ROM etc

2. Logout of iMessage & iCloud on hack

3. Disconnect from internet

4. Edit config.plist on hack so at a minimum you have matching the real Mac

     * MLB in RtVariables/config.plist

     * ROM in RtVariables/config.plist

     * CustomUUID in System Parameters/config.plist = System-ID of Mac, set inject system-id to true.

     * If cautious, change board-id and system serial in SMBIOS/config.plist to real Mac's value also

Note: changing ProductName/Mac Model to a different SMBIOS (eg to the same as the original Mac) may affect power management/sleep and other functions on the hack.

5. Run imessage_debug V2 on the hack to confirm new values

6. Reconnect internet

7. Login to iMessage and iCloud on hack

 

Finally, if your Mac's MLB/ROM is blacklisted, there is no need to panic if you are its rightful owner. Contact Apple Support - that is what they are there for :).

 

PS: Happy New Year 2015 to all fellow hackintoshers and even the Apple security guys who follow the IM forums :D:hysterical:.

  • Like 3
Link to comment
Share on other sites

 

 [...]

 

With regard to the risk in "sharing serials" - some common sense is required.  I own a Mac so I feel that it is morally OK to use its serials to activate iMessage on my own hacks and haven't encountered any problems.  I think @midi's recommendations are sensible -

  • don't publicly share your MLB/ROM or system serials
  • it's safe to use the same Mac's MLB/ROM on up to three hacks, even if these hacks use different SMBIOS and system serialsUse a unique system-id for each of your hacks eg you can generate a unique UUID with uuidgen in OSX terminal....
XXXXX$ uuidgen
3851CC2B-218E-4907-B7A0-102D7CF1A221
  • IMHO, there is too much FUD (Fear, Uncertainty, Doubt) being spread on other forums about the use of MLB/ROM from Macs on hacks.  Yes, it will be a problem if the MLB/ROM is publically shared so multiple AppleIDs may login to iMessage/FT at the same time (using the same MLB/ROM) ---> the more likely Apple will notice ---> block the AppleIDs from using the publically shared MLB/ROM.  It is definitely NOT a problem if you own the Mac to which the MLB/ROM belongs and only use your own AppleID to login.  In anycase, you can remove any block placed on your AppleID by calling Apple Support if you are the legal registered owner of the Mac.

[...]

Fusion, I think you should remove the sharing thingy, I noticed that if you use the MLB+ROM frm an unused mac (I mean by that it doesn't use iM/FT) then it will work SINCE IT'S THE FIRST DEVICE WITH THOSE SERIALS TO ACTIVATE THE SERVICES, once the mac OR another hack with those serials tries to connect to those services, the serials are blocked instantly!!!!!!!!!!! I tried it with some working serials! and eve the real mac couldnt send messages, BUT IT CAN LOG IN!!!!!!!

Apple may do that! SO WHATCH YOUR SERIALS! OR GENERATE ONES ACCORDING TO THE PATTERN :)

Link to comment
Share on other sites

@midi,

 

Updated post #161 with link to post#377.

 

iMessage/FT still working for me on my hacks and real Mac Mini.  Also @griven & Kris404 have it working again after making sure system-id values are identical on all machines sharing MLB/ROM.  I have taken extra precautions as detailed in post#377 - I think the most important things are

  • Don't have both the real Mac and hack logged into iMessage/FT and connected to the internet at the same time, especially with different AppleIDs
  • Make the hack a much closer match to the Mac ie need not only MLB+ROM but MLB+ROM+system-id and maybe board-id and system serial.  If you want to be ultra cautious, make the output of imessage_debug between hack and mac identical....

Note: changing ProductName/Mac Model to a different SMBIOS (eg to the same as the original Mac) may affect power management/sleep and other functions on the hack.

_____________________________________________________________________________________________________

 

Update Jan 4th 2015

Thankfully, it appears that the system-id block may not be permanent....check your /var/log/system.log as mentioned by @PikeRAlpha here.

 

@Pavo reported iMessage/FT being restored on his real Mac after he changed the MLB/ROM and system-id on his hack and waiting for a few days.

 

Also iMessage/FT still working for me on both Mac and Hack using cloned values but I would still recommend caution not to login at the same time on both machines and use the procedure in post#377 above to avoid any ID mismatches....

Link to comment
Share on other sites

@Pavo reported iMessage/FT being restored on his real Mac after he changed the MLB/ROM and system-id on his hack and waiting for a few days.

 

 

Yep, same here. After 4 days my Macbook was unblocked. Before that, I could still log into iMessage but sending messages was just resulting in a "delivered" status, and the message was going nowhere.

 

You should receive the "Your Apple ID and phone number are now being used for iMessage and Facetime on a new Mac. If you recently signed into "Name of your real mac here"..." alert box on any other iDevice when it's unblocked.

Link to comment
Share on other sites

hmm, I got this one I opened iMessage (and had system.log on the side to see the progression):


Jan 4 12:12:40 midis-MacBook-Pro.local identityservicesd[598]: <IMMacNotificationCenterManager: 0x7fb7cbc37990>: Configuring notification center for identifier: com.apple.iChat topics: (
"com.apple.madrid"
)
Jan 4 12:12:40 midis-MacBook-Pro.local identityservicesd[598]: <IMMacNotificationCenterManager: 0x7fb7cbc37990>: NC Disabled: NO
Jan 4 12:12:40 midis-MacBook-Pro.local identityservicesd[598]: <IMMacNotificationCenterManager: 0x7fb7cbc37990>: DND Enabled: NO
Jan 4 12:12:40 midis-MacBook-Pro.local identityservicesd[598]: <IMMacNotificationCenterManager: 0x7fb7cbc37990>: Updating enabled: YES (Topics: (
"com.apple.madrid"
))
Jan 4 12:12:40 midis-MacBook-Pro.local com.apple.SecurityServer[54]: Session 100038 created
Jan 4 12:12:41 midis-MacBook-Pro.local logind[69]: -[SessionManager getClient:withRole:inAuditSession:]:241: ERROR: No session dictionary for audit session 100038
Jan 4 12:12:41 midis-MacBook-Pro.local logind[69]: _SMGetSessionAgent:73: ERROR: __SMGetClientForAuditSessionAgent failed 2
Jan 4 12:12:41 midis-MacBook-Pro.local IMRemoteURLConnectionAgent[2351]: SACShieldWindowShowing:925: ERROR: NULL response
Jan 4 12:12:41 midis-MacBook-Pro.local nsurlstoraged[701]: realpath() returned NULL for /var/root/Library/Caches/ocspd
Jan 4 12:12:41 midis-MacBook-Pro.local nsurlstoraged[701]: The read-connection to the DB=/var/root/Library/Caches/ocspd/Cache.db is NOT valid. Unable to determine schema version.
Jan 4 12:12:41 midis-MacBook-Pro.local nsurlstoraged[701]: realpath() returned NULL for /var/root/Library/Caches/ocspd
Jan 4 12:12:41 --- last message repeated 1 time ---
Jan 4 12:12:41 midis-MacBook-Pro.local nsurlstoraged[701]: ERROR: unable to determine file-system usage for FS-backed cache at /var/root/Library/Caches/ocspd/fsCachedData. Errno=13
Jan 4 12:12:41 midis-MacBook-Pro com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): The _DirtyJetsamMemoryLimit key is not available on this platform.
Jan 4 12:12:42 midis-MacBook-Pro.local identityservicesd[598]: [Warning] Warning, missing mailto:"DESTINATION EMAIL" in (null)
Jan 4 12:12:42 midis-MacBook-Pro.local identityservicesd[598]: [Warning] Warning, missing mailto:"MY EMAIL" in (null)
Jan 4 12:12:43 midis-MacBook-Pro com.apple.xpc.launchd[1] (com.apple.imdmessageservices.IMDMessageServicesAgent): The _DirtyJetsamMemoryLimit key is not available on this platform.
Jan 4 12:12:43 midis-MacBook-Pro com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): The _DirtyJetsamMemoryLimit key is not available on this platform.
Jan 4 12:13:39 midis-MacBook-Pro com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): The _DirtyJetsamMemoryLimit key is not available on this platform.

Update: it worked, I remade my config.plist and erased nvram and resetted iMessage. :)

Link to comment
Share on other sites

Hi,

I have Yosemite installed in a SSD drive (GUID partititon table), and Windows in a different hard drive.

How can I add Windows in Clover bootloader? Eventually I can reinstall Windows but not Yosemite.

(My mobo has a normal BIOS no UEFI)

Link to comment
Share on other sites

Yep, same here. After 4 days my Macbook was unblocked. Before that, I could still log into iMessage but sending messages was just resulting in a "delivered" status, and the message was going nowhere.

 

You should receive the "Your Apple ID and phone number are now being used for iMessage and Facetime on a new Mac. If you recently signed into "Name of your real mac here"..." alert box on any other iDevice when it's unblocked.

Just got that on my hack. But IM/FT never stopped working.

Using real mlb/ROM (no idea about the original Mac)

Link to comment
Share on other sites

Look at the guide I gave you, under Extras/Troubleshooting (Optional) > 3. it has everything you need to know, and yeah that guide you showed is ok.

I prepared the USB drive with Rufus

when I am in Clover I have "boot Microsoft EFI cdboot menu from WIN 7" and "boot Microsoft EFI mgrboot menu from WIN 7"

I press space bar I don't have "boot UEFI external from windows" and so I can't begin installation

Can anyone help?

Link to comment
Share on other sites

^^^^

+1

@carlocav,

 

Most likely your config.plist is set to hide bootx64.efi so you aren't seeing the correct entry in Clover's main menu.

 

As a workaround, copy bootmgfw.efi into /efi/microsoft/boot and delete or rename cdboot.efi (since not needed) so the EFI folder structure looks like below on your Windows USB installer....

 

post-846696-0-61590400-1419767386_thumb.

In troubleshooting step 3 of @avin7000's guide and my post#13, select Run bootmgfw.efi from the Microsoft EFI Boot Menu :).

  • Like 2
Link to comment
Share on other sites

So, this about OS X and UEFI Windows 8 on a legacy mode.

 

Today I accidentally discovered that Clover applies DSDT/config.plist to Windows also or may be I am wrong. I booted into windows with basic clover config and saw my screen resolution was not correct. And I did clover installation and booted, but now I see correct screen resolution.

 

So does clover has any influence on windows booting also? If yes, how do I boot into windows without DSDT/config.plist taking effect?

Link to comment
Share on other sites

Normally it shouldnt affect! For me, Clover injects the original dsdt to windows, check your settings, if it's really true that clover applies it to windows that would be awesome, I wish it could also inject SMBIOS of a real mac to use the startup app from apple :)

Link to comment
Share on other sites

So, this about OS X and UEFI Windows 8 on a legacy mode.

 

Today I accidentally discovered that Clover applies DSDT/config.plist to Windows also or may be I am wrong. I booted into windows with basic clover config and saw my screen resolution was not correct. And I did clover installation and booted, but now I see correct screen resolution.

 

So does clover has any influence on windows booting also? If yes, how do I boot into windows without DSDT/config.plist taking effect?

It does if you did a reboot, not a shutdown I guess. My old Asus N43SM does that quite often ( boot into windows first, then os x > nvidia gpu fires up although it was disabled in the dsdt, and if I do it in reverse order, nvidia gpu is gone from windows )

Link to comment
Share on other sites

 Share

×
×
  • Create New...