Jump to content
Welcome to InsanelyMac Forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

About ElCoyote_

  • Rank
    InsanelyMac Protégé
  1. Hi everyone, I am not sure you should be using the latest 8.0.1 darwin.iso (unless you have VMW 12, maybe). On VMW 11.1.2, applying the latest darwin iso made the OSX 10.11.0 crash VMW, As a result, I stayed with the bundled iso from my install. For the record, both of my 10.10.5 and 10.11.0 VM were created from a clone of my 10.9.5 VM over last week-end. - The 10.10.5 was created by booting an ISO of 10.10.5 (I couldn't use the app store to create a 10.10 VM since El-Capitan had already been released). - The 10.11.0 VM was created by updating from the App Store straight from 10.9.5. I'm running VMW 11.1.2 on Linux (RHEL) with the latyest 2.0.6 unlocked. This allows for testing stuff on snapshot'able VM's instead of busting my only physical OSX box (a MBP). Regards,
  2. Hi Dave, Thank you so much a thousand times for these unlockers. I stayed on workstation 10.x until yesterday (Aug 23rd) when I found the 2.x family of your unlocker. Thanks a ton. I have since then updated to workstation 11.1.2 and all of the VM's are running happily. One thing I noticed is that vmware (the product) SIGSEV's (I'm on Linux RHEL6) when I try to 'edit' the configuration of an OSX VM. Strace'ing the process shows a call trace similar to this: read(29, 0x7fd60a2e2030, 7) = -1 EAGAIN (Resource temporarily unavailable) gettid() = 19983 poll([{fd=29, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout) fstat(29, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 fcntl(29, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- geteuid() = 1502 gettid() = 19983 write(2, "/build/mts/release/bora-2780323/bora/lib/string/str.c:211 Buffer too small\n", 75) = 75 write(2, "/build/mts/release/bora-2780323/bora/lib/string/str.c:211 Buffer too small\n", 75) = 75 write(2, "/build/mts/release/bora-2780323/bora/lib/string/str.c:211 Buffer too small\n", 75) = 75 write(2, "Panic loop\n", 11) = 11 exit_group(1) = ? +++ exited with 1 +++ I wonder if anyone has seen something like this on Linux.. Vince
  3. Yes, you' re right. I thought it would work because the results of osx-system.sh within the Guest were the same as on my Real Mac but I hadn' t verified iMessage. I used the identification of my Real MBP (along with the Serial Number, the hardware type, etc..) and it' s still not signing in.. (although it seems to take longer to verify that information). Kind regards,
  4. Hi, SMBIOS.use12CharSerialNumber = "TRUE" did the trick for me on VMWare Workstation 10.0.1 for my OSX Mountain Lion VM.. Thank you so much, Regards, ElCoyote
  5. I Used v1.1.1 to unlock 9.0.2 on both Linux (RHEL) and Windows. No issues to report so far.
  6. Hello, Both of my 10.6.8 and 10.7.5 VMs work fine with VM 9.0.1 under Linux. Did you upgrade the VM's virtual hardware to the latest version after upgrading to VM 9.0.1? That does help most of the time... Regards,
  7. @Donk: No problem at all, take your time and all the best with the work. I'm not too fluent into ASM, opcodes or hexadecimal readings but you can count on me in testing whatever you need when you'll be ready. Thanks,
  8. Please also remember to upgrade the virtual hardware to the latest version (Fusion 5 or Workstation 9) for best results. On Linux I'm still on 8.0.4 but on native MBP (10.7.5) with Fusion 5.0.1 and your unlocker allowed me to upgrade my Lion VM (10.7.3) to the latest patches (10.7.5) without any issue. Note that I had upgraded the virtual hardware prior to applying the VM's OSX patches.. @Donk: Did you have a chance to take a look at darkmas' patch for Linux? I have not yet researched the issue either but that could maybe explain the differences I saw between choices for non-shared VMs and shared VMs... Thank you once again for this great tool and for including the source too.
  9. No such luck, I'm afraid. I tried both libs but to no avail: # [..snip..] Patching /usr/lib/vmware/lib/libvmacore.so/libvmacore.so File mapped @0x2b6117bf7000 length 9037800 # [..snip..] Patching /usr/lib/vmware/lib/libvmomi.so/libvmomi.so File mapped @0x2aaabcbf6000 length 5379472 #
  10. Hello Donk. Thanks for the quick reply.. here's a pmap of vmware-hostd on my machine with the relevant parts: # pmap 14141|grep lib/vmware 14141: /usr/lib/vmware/bin/vmware-hostd -a /etc/vmware/hostd/config.xml 0000000000400000 48080K r-x-- /usr/lib/vmware/bin/vmware-hostd 00000000034f3000 9536K r---- /usr/lib/vmware/bin/vmware-hostd 0000000003e43000 1108K rw--- /usr/lib/vmware/bin/vmware-hostd 00002aaab3649000 1356K r-x-- /usr/lib/vmware/lib/libcrypto.so.0.9.8/libcrypto.so.0.9.8 00002aaab379c000 1024K ----- /usr/lib/vmware/lib/libcrypto.so.0.9.8/libcrypto.so.0.9.8 00002aaab389c000 148K rw--- /usr/lib/vmware/lib/libcrypto.so.0.9.8/libcrypto.so.0.9.8 00002aaab38c5000 292K r-x-- /usr/lib/vmware/lib/libssl.so.0.9.8/libssl.so.0.9.8 00002aaab390e000 1020K ----- /usr/lib/vmware/lib/libssl.so.0.9.8/libssl.so.0.9.8 00002aaab3a0d000 28K rw--- /usr/lib/vmware/lib/libssl.so.0.9.8/libssl.so.0.9.8 00002b576df0d000 8140K r-x-- /usr/lib/vmware/lib/libvmacore.so/libvmacore.so 00002b576e700000 2048K ----- /usr/lib/vmware/lib/libvmacore.so/libvmacore.so 00002b576e900000 600K r---- /usr/lib/vmware/lib/libvmacore.so/libvmacore.so 00002b576e996000 80K rw--- /usr/lib/vmware/lib/libvmacore.so/libvmacore.so 00002b576e9b7000 4836K r-x-- /usr/lib/vmware/lib/libvmomi.so/libvmomi.so 00002b576ee70000 2048K ----- /usr/lib/vmware/lib/libvmomi.so/libvmomi.so 00002b576f070000 392K r---- /usr/lib/vmware/lib/libvmomi.so/libvmomi.so 00002b576f0d2000 24K rw--- /usr/lib/vmware/lib/libvmomi.so/libvmomi.so 00002b576f5ea000 548K r-x-- /usr/lib/vmware/lib/libnfc-types.so/libnfc-types.so 00002b576f673000 2048K ----- /usr/lib/vmware/lib/libnfc-types.so/libnfc-types.so 00002b576f873000 72K r---- /usr/lib/vmware/lib/libnfc-types.so/libnfc-types.so 00002b576f885000 16K rw--- /usr/lib/vmware/lib/libnfc-types.so/libnfc-types.so 00002b576f88d000 9388K r--s- /usr/lib/vmware/icu/icudt44l.dat I found tracks of darwin-* in libvmacore.so only.. # strings -a /usr/lib/vmware/bin/vmware-hostd |grep libv.*\.so libvmacore.so libvmomi.so # strings -a /usr/lib/vmware/lib/libvmacore.so/libvmacore.so |grep -i darwin GuestOS_IsDarwin darwin darwin-64 darwin10 darwin10-64 darwin11 darwin11-64 @&!*@*@(button.guestDarwin9)Mac OS X Server 10.5 @&!*@*@(button.guestDarwin9_64)Mac OS X Server 10.5 64-bit @&!*@*@(button.guestDarwin10)Mac OS X Server 10.6 @&!*@*@(button.guestDarwin10_64)Mac OS X Server 10.6 64-bit @&!*@*@(button.guestDarwin11)Mac OS X Server 10.7 @&!*@*@(button.guestDarwin11_64)Mac OS X Server 10.7 64-bit # strings -a /usr/lib/vmware/lib/libvmomi.so/libvmomi.so |grep -i darwin #
  11. @Donk: obviously it's not as simple as before, I tried the following patch and it didn't make any difference.. although it appeared to patch vmware-hostd just fine: [....] Patching /usr/lib/vmware/bin/vmware-hostd File mapped @0x2afd25203000 length 60149488 Found SRVR @ 0x2afd278198eb Found SRVR @ 0x2afd27819983 Found SRVR @ 0x2afd27819994 Found SRVR @ 0x2afd278199a7 Found SRVR @ 0x2afd2781f6ea Found SRVR @ 0x2afd2781f708 Found SRVR @ 0x2afd2781f9d2 [....] =================================================================== RCS file: RCS/Unlocker.cpp,v retrieving revision 1.1 diff -c -r1.1 Unlocker.cpp *** Unlocker.cpp 2012/05/11 14:42:44 1.1 --- Unlocker.cpp 2012/05/11 14:49:56 *************** *** 79,84 **** --- 79,85 ---- char const vmx_stats[] = "vmware-vmx-stats"; char const vmwarebase[] = "libvmwarebase.so.0"; char const install_path[] = "/usr/lib/vmware/"; + char const vmx_hostd[] = "vmware-hostd"; char const vmx_path[] = "bin/"; char const vmwarebase_path[] = "lib/libvmwarebase.so.0/"; #endif /* __ESXi__ || __linux__ */ *************** *** 656,661 **** --- 657,665 ---- workPath.assign(vmwarebasePath); workPath.append(&vmwarebase[0], sizeof vmwarebase - 1U); patch_one(workPath, 0); // ignore error + workPath.assign(vmxPath); + workPath.append(&vmx_hostd[0], sizeof vmx_hostd - 1U); + patch_one(workPath, 1); #endif /* _WIN32 || __linux__ */ #ifdef _WIN32 if (vmxPath64.empty()) { What do you think?
  12. @Donk: I love your work, btw! And thank you so much for the source too, it's really nice to have that and rare enough to mention. About the issue, I agree it's 'comsetic', although if you edit the Shared VM's configuration, the OS type will change to 'Other-32' and render the machine unbootable (at least on Linux). To work around this issue, I've made my MacOSX Shared .vmx files immutable on Linux but it would be a 'nice to have' if this could get fixed. Please don't hesitate to contact me if you would like help in testing this out. I'm surprised that ESXi doesn't exhibit this issue, perhaps this is because it's using a different Client.. Many Thanks once again,
  13. @donk: Thank you very much for this 1.1.0 release. I had VM8.0.3 on Linux working fine with 1.0.2 and SL10.6.8 & L10.7.3. I uninstalled 1.0.2 and re-ran the 1.1.0 installer. No issue to report so far. One thing I'd like to mention, though, is this: - When I open my MacOSX VMs (not Shared), they show up correctly as 'MacOSX 10.x 64bit'. - However, if I 'share' the VMs so I can access them through a remote VMWare Workstation, they show up as 'Other 32bit' even though the .vmx stills bears 'darwin-64'.. That is, until I attempt to edit the VM's config and -then- it changes to other-32. Perhaps this is because another binary needs to be patched.. (/usr/lib/vmware/bin/vmware-hostd, maybe) On my Linux box, vmware-hostd bears references to OSX but they don't show up when VMware Workstation is used as a remote client. # strings -a /usr/lib/vmware/bin/vmware-hostd|grep -i darwin GuestOS_IsDarwin _ZN3Vim2Vm17GuestOsDescriptor31GUESTOSFAMILY_DARWINGUESTFAMILYE _ZN3Vim2Vm17GuestOsDescriptor34GUESTOSIDENTIFIER_DARWIN11_64GUESTE _ZN3Vim2Vm17GuestOsDescriptor29GUESTOSIDENTIFIER_DARWINGUESTE _ZN3Vim2Vm17GuestOsDescriptor31GUESTOSIDENTIFIER_DARWIN64GUESTE _ZN3Vim2Vm17GuestOsDescriptor31GUESTOSIDENTIFIER_DARWIN10GUESTE _ZN3Vim2Vm17GuestOsDescriptor31GUESTOSIDENTIFIER_DARWIN11GUESTE _ZN3Vim2Vm17GuestOsDescriptor34GUESTOSIDENTIFIER_DARWIN10_64GUESTE darwinGuest *darwin64Guest darwin10Guest *darwin10_64Guest darwin11Guest *darwin11_64Guest darwin darwin-64 darwin10 darwin10-64 darwin11 darwin11-64 darwinGuestFamily biosIsGOSDarwin isolation.bios.IsGOS.Darwin @&!*@*@(msg.gostable.family.darwin)Apple Mac OS X @&!*@*@(msg.gostable8.guest.darwin11)Mac OS X 10.7 @&!*@*@(msg.gostable8.guest.darwin11-64)Mac OS X 10.7 64-bit @&!*@*@(msg.gostable8.guest.darwin10)Mac OS X Server 10.6 @&!*@*@(msg.gostable8.guest.darwin10-64)Mac OS X Server 10.6 64-bit @&!*@*@(msg.gostable8.guest.darwin)Mac OS X Server 10.5 @&!*@*@(msg.gostable8.guest.darwin-64)Mac OS X Server 10.5 64-bit
  14. Hello all, Thank you so much for this unlocker (and thanks for sharing the code, btw). I used unlock-all-v102.zip. I'm using this to non-reg some GPL software under OSX (my only OSX hardware doesn't have the ressources to do that). I've used successfully the Linux version under RHEL5 x86_64 to patch VMware Worksation 8.0.1. One thing that I noticed is that 'Apple Mac OSX' is only available as a choice if the VM is not shared. Once the VM is shared it's not a choice in the Linux GUI anymore. Not that I really care but my OSX 10.7.2 VM only works when 'non-shared' and stops working if I 'share' it through VM8's integrated VMware server. PS: If you'd like me to test out new code, then please feel free to contact me Thanks again, Regards, V. (on a 64gb Dell T5400) I forgot: When used in the 'Shared VM' mode, the OSX kernel with 'panic' with a register dump. When used as a private VM, it works just fine. BTW 10.6.8 works fine in all cases too.