ArgVega

I have looked into ozmosis(haven't tried it), but I believe those values are only static for firmware that support nvram saving, I believe vmware efi and exe reset the nvram upon reboot. We could write a launch daemon to reset these setting upon reboot but it must execute on kernel boot up (not the case with vmware efi, it executes towards end of kernel). This is all based on elnono_ research of imessage: 'KLDBootstrap::~KLDBootstrap' calculates these five 17 bytes values based on hashes of: - IOPlatformUUID - IOPlatformSerialNumber - IODeviceTree:/chosen/boot-uuid - IODeviceTree:/options/4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM - IODeviceTree:/options/4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB each value is appended, in that order, on the gIOPlatformExternalData OSData object.....Those five values must be set when the kernel is started and MUST NOT change afterwards. http://www.insanelymac.com/forum/topic/294633-imessage-partially-broke-icloud-app-store-fully/?p=1981588 Hacking the vmware exe or efi would be great because we can set these values at the source, but I don't think it would be feasible. Donk tried to decode the efi64.rom but seems vmware has encoded it in a way that is not standard.

Hi All, Well I have made some progress with some scripts and hacks, but still cannot get the account to activate. Will to change the efi to (Chimera) to see if it allows activation of iMessage. If it does I will do an export of the hardware and nvram values to determine what's preventing the activation.. Here is where I have gotten to so far, sign in and enabled but iMessage still says inactive. I also did NOT receive a notification on my iPhone that the Mac was using the iMessage. What I am afraid of is it might require a legitimate apple serial in which case we are toast, because that would require us to have Macs ergo negating the need to have a VM OSX. If anyone has any ideas let me know.. @Donk: If you would check on your mac if your Mavericks guest (with iMessage working) has the same serial as your host?

Hi Donk, where you able to verify the same machine on Workstation? I wonder if it is something to do with the vmware injected hardware values from the local machine.

I was able to get iCloud find my iphone to recognize the VMware online with this vmx line, but yes iMessage is still broken. I think Donk is right, it must be something that needs to be injected into the NVRAM, if you use a different bootloader this works, but it breaks more than it fixes. Maybe it's the way VMware identifies it's hardware to the OSX. I get to log in to iMessage but get a message that says "error processing registration".

I know the VMX file has 2 lines that set the UUID, they are: uuid.bios and uuid.location. They are both hex values and there is an algorithm VMware uses to generate the machine UUID from these. They both seem to contribute to how the UUID of the machine is derived, I know when you move a machine it asks whether you want it to keep the same UUID or generate a new one. We might be able to play with these lines and see if this changes the UUID in NVRAM, I will check when I get home, but you are talking about the UUID in system profiler right? I think if you set uuid.location = "" (it might use the actual machines UUID), would you be able to verify this on your Mac Book Pro? EDIT: Maybe this can be fixed with a patch to the PlatformUUID.kext, to inject the correct UUID from the machine. Anyone have any knowledge with Kexts in order to write this? There used to be some for snow leopard but I doubt they inject the values in mountain lion, I think superhai wrote those

I think if we can manually patch the VM Ethernet IDs network values to spoof a Mac's "Ethernet" device to apple, such as ZackehSoul method: http://blog.zackehh.com/imessage-enabler-enabling-imessage-virtual-machines/ Along with this vmx patching by Donk we can achieve iMessage use in VMware while still preserving the stock VMware EFI and no longer breaking any of the machines features and stability. EDIT: If anyone has any knowledge of kext writing, there could be some sort of Ethernet "injector" written that resolves the Ethernet information to apple permitted hardware.

Try installing ps2 drivers for mouse and keyboard, and remove those lines I posted. See if that helps

We need more details to help you. What mouse are you using usb/ps2? What method did you use to install this? Did you add these to your vmx: keyboard.vusb.enable = "TRUE" mouse.vusb.enable = "TRUE" Did you install a ps2, kext?

I might be wrong, but OSX won't work on AMD without a patched kernel. You might ask donk, or try to search and see about AMD patching for Snow Leopard. Did you also add these into your VM: monitor.virtual_exec="hardware" monitor.virtual_mmu="software"

No problem mate Good luck on ur programming, remember to take snapshots of the machine b4 making any OS changes. Post here if you have any questions down the road

Hmm unless you made a backup of it b4 update, you might be screwed unless someone sends you their 10.6.3 vanilla kernel. In the guide you used for install, where there any loookouts for kexts that might cause kernel panics, that might have reappeared after update to 10.6.4? Have you tried asking in the guide website?

Try restoring last kernel that worked for your machine. Did you use a patched kernel or the standard vanilla one before this?

Refer to this post from MSok, he has more knowledge on this issue: http://www.insanelymac.com/forum/index.php...t&p=1513860

Did you follow the guide correctly? Type "cpus -z" to see what ur busratio should be, also did u do all the customizations like the tutorial said?

Haha thanks Donk, I wish though. You and MSoK are on a completely different level of understanding. That depends on wether you use/want the use of shared folders between your host and guest. It is supposed to be a a mapping to your host drive on the guest os as a shared folder. This is so you can access the data of the host computer, from the guest os, since darwin tools don't support drag and drop. If you want it removed so it doesn't place a shortcut on your desktop everytime it boots up, it involves removing a line from vmware-tools.sh. Let me know if you are interested and I can help you out.