406 replies to this topic

[rcork]

Nah, don't have it on my installation - and it doesn't use that data as people have faked the info properly and still no-go.

I think you're wrong on both statements. I'm not aware of any method of running a hack without FakeSMC. Also, there is a bunch of keys that FakeSMC doesn't have out of the box. If you want to see all the keys that are missing, enable debug mode in FakeSMC and then watch the Console for all the keys indexes that are requested by the OS but not present in FakeSMC.

[mike5065]

This issue is actually indicating to me that some very dramatic changes are coming. It's very exciting to me that computing is on the verge of such an evolution.

Care to elaborate? Are you alluding to the likes of OAuth, SAML, et al?

[p.H]

i changed the serialNO and hardware uuid of real mac，but it still did not work。。。。

I already did that before, same result.

[Donw35]

iMessage working here on my hack, just tested it

[Moonshine]

iMessage working here on my hack, just tested it

Have you tried logging out of iMessage and back in? (Not to be confused with quitting the application and re-launching it.) I dare you...

[Maniac10]

I regret doing it...

[Donw35]

Ah, ok, I have not logged out of iMessage on this machine since I upgraded it to 10.8, with that in mind, I prefer not to lose the iMessage functionality.

Boot loader
Chameleon 2.1svn (svn-r2030)

[p.H]

Ah, ok, I have not logged out of iMessage on this machine since I upgraded it to 10.8, with that in mind, I prefer not to lose the iMessage functionality.

Boot loader
Chameleon 2.1svn (svn-r2030)

If so, then you'd better watch out for it

[Donw35]

yeah, not a big deal if I lose it on this machine, I have a MBP if I need it but I am sure that if I logout I will not be able to log back in.

[ZackehSoul]

wat? Is that a thing now? Are you using some ancient DSMOS hack?

It's not required, just a preference.

I think you're wrong on both statements. I'm not aware of any method of running a hack without FakeSMC. Also, there is a bunch of keys that FakeSMC doesn't have out of the box. If you want to see all the keys that are missing, enable debug mode in FakeSMC and then watch the Console for all the keys indexes that are requested by the OS but not present in FakeSMC.

I'm correct on both accounts, I'm well aware of what I have installed on my machine. The second part of my post was regarding the missing keys, saying that people have added the missing ones manually and it still fails. Of course they may have done it wrongly, but I feel no reason to doubt them.

[fffeee]

I think you've misunderstood what rcork was saying about missing keys. I think he's referring to the fact that there are dozens(?) of values in the SMC that aren't documented or are otherwise unknown. When you enable debug logging you'll see several things OS X requests from the non-existent SMC that FakeSMC doesn't have an answer for. It seems unlikely that people are spamming the right data into undocumented and unknown values with any hope of success.

As for the other thing, since FakeSMC (or a DSMOS hack from days of yore) is actually required to run OS X on a system without an SMC, we're skeptical that you're not using it. Especially since it not only lets you used the signed binaries for things like Dock.app, but does a whole slew of other interesting things. Can you elaborate a bit more on your FakeSMC-less system?

[SS01]

Hmm.. We'd almost need to binpatch iMessage.. Maybe redirect the servers to someone else's site..

[LatinMcG]

maybe we can generate the id in a real mac and pass it to the hack plist or keychain ?

i think they did something to SMC to generate the id different.

[Pene]

Just some notes about iMessage:

As we found out some time ago (in the Clover thread on ProjectOsx) - iMessage trys to use the nvram vars MLB and ROM which are present on real Macs.
MLB is the Main Logic Board serial number (the value which is sometimes reported in profiler as the "Serial Number (processor tray)", not the "Serial Number (system)")
ROM is a value being read when booting from address 0xFFFFFF01, which is somehow related to MAC address. On some macs it is identical to the ethernet MAC address, on others to the firewire MAC address (without the two middle bytes, as the firewire MAC address is longer)

We can see those vars on real Macs by:
nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB; nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM

Long time ago, iMessage would not work with Clover (when it still worked with Chameleon), as MLB and ROM were being set to arbitary values (boot.efi read them from memory and set the nvram vars).
This problem never existed in Chameleon, as Chameleon would just return EFI_UNSUPPORTED, avoiding these vars from being set.
So, back then, in order to make iMessage work for Clover, we just deleted one of these vars, and then iMessage switched to the old authentication method (aka not using these vars, like it was for Chameleon). But this authentication method is now blocked.

If now we set these values (before OSX loads) to logical values, the error message when trying to log in changes to the following message:
"Your Apple ID can't be used to set up iMessages at this time." You can see this exact message here: http://support.apple.com/kb/HT5419

By the way, this is the same message that I get also on my (real) MacBook3,1 when trying to sign in to iMessage (ML is not officially supported on that computer).
That message also persisted on the real MacBook3,1 even when I changed SMBIOS data and serials to MacBookPro3,1 (which is supported by ML), so there's obviously something else missing.

On the MacBook3,1 it should have been easier to achieve this, as it doesn't use FakeSMC, and probably has most values set correctly (definitely more than on a Hack).

MacBook3,1 and MacBookPro3,1 are also the same generation. Same EFI version, same chipset, same CPU (Apple just decided not to support ML on the MacBook3,1 probably due to not wanting to support the X3100 gfx, as that's the only real difference between the two).

So just to make it clear, setting that ROM and MLB changes something, and makes iMessage on Hackintosh to behave like it does on unsupported Macs (e.g. MacBook3,1), but it is not enough to solve the problem. There is something else we haven't found out yet.

Edit: some clarifications

[juanerson]

Hi folks. I am absolutely agree with you guys about some missing and/or bad configured KEYS in FakeSMC. But I don´t know, maybe is also related to the known of Geekbench checking about "iMac9,1 (Hackintosh)" instead of "iMac (Early 2009)", for example.

[rcork]

Just some notes about iMessage:

As we found out some time ago (in the Clover thread on ProjectOsx) - iMessage trys to use the nvram vars MLB and ROM which are present on real Macs.
MLB is the Main Logic Board serial number (the value which is sometimes reported in profiler as the "Serial Number (processor tray)", not the "Serial Number (system)")
ROM is a value being read when booting from address 0xFFFFFF01, which is somehow related to MAC address. On some macs it is identical to the ethernet MAC address, on others to the firewire MAC address (without the two middle bytes, as the firewire MAC address is longer)

we can see those vars on real Macs by:
nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB; nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM

So far, to make iMessage work for Clover we would just delete one of these vars, and then iMessage would switch to the old authentication method (aka not using these vars, like it was for Chameleon), which is now blocked.

If we set these values (before OSX loads) to logical values, the error message when trying to log in changes to something like:
Your Apple ID can't be used to set up iMessages at this time. Click Contact Support from the dialog.

By the way, this is the same message that I get also on my (real) MacBook3,1 when trying to sign in to iMessage (ML is not officially supported on that computer).
That message also persisted on the real MacBook3,1 even when I changed SMBIOS data and serials to MacBookPro3,1 (which is supported by ML), so there's obviously something else missing.

So just to make it clear, setting that ROM and MLB changes something, and makes iMessage on Hackintosh to behave like it does on unsupported Macs (e.g. MacBook3,1), but it is not enough to solve the problem. There is something else we haven't found out yet.

This sounds interesting. I'm using Chameleon, not Clover. Does anyone know of a way to inject nvram variables in Chameleon. If so, i can try using the values from my rMBP and see what i get.

[Pene]

You can try to set them after OS booted, by:
sudo nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB=....
But from my experiments, it didn't have the proper effect, as the error message changed for me only when I set them before booting.

Also, I tried that already (before booting) with (hopefully) real values. No go. As I wrote above, I even tried injecting MacBookPro3,1 values on my MacBook3,1. Didn't help either.
There is something else missing.

[flux84]

As mentioned, setting those nvram values after being booted, even if you restart imagent, doesn't seem to have any effect.

If there is a way to get Chameleon/Chimera to set nvram values on boot, I have a real MacPro3,1 running ML to get values from to match my MacPro3,1 Hack to.

[fffeee]

possibly relevant:

• NVRAM support @ http://forum.voodoop...pouubtg0r42a12v

couple of threads about "SystemID" may be related as well.

thank you, @Pene for dropping some science on this thread today!

[eep357]

description from man page:

The nvram command allows manipulation of firmware NVRAM variables. It can be used to get or set a variable.  It can also be  usedto print all of the variables or set a list of variables from a file.Changes to NVRAM variables are only  saved  by  clean  restart  or  shutdown.

In  principle,  name  can  be  any  string.   In practice, not all strings will be accepted.  New World machines can create new variablesas desired.  Some variables require administrator privilege to get or set.

 The given value must  match  the  data  type  required  for  name. Binary data can be set using the %xx notation, where xx is the hex value of the byte.  The type for new variables  is  always  binary data.