Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a Rot13-encoded string: "ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc". It seems to be the string that is supposed to make MacOS only run on certified systems, but it's obviously been reverse engineered and now it needs to be added to any Mac emulators to work.


VirtualBox supports two methods of operation:

(1) You supply this value in the "DeviceKey" config parameter

(2) Ensure the "GetKeyFromRealSMC" boolean config parameter is enabled (not sure if it is turned on by default or not). When enabled, VirtualBox retrieves the value from the SMC of your Mac.

Obviously method (2) only works if your host is a Mac. Apple doesn't supply a public API to retrieve this value, so VirtualBox has some code which runs inside a macOS kernel extension, and directly uses the SMC hardware registers to request it. [EDIT: Actually, turns out macOS does have an undocumented API for this – talk to AppleSMC using IOServiceGetMatchingService, IOConnectCallStructMethod, etc – and they use it, but they still fall back to direct hardware access if the API call fails, or if Windows/Linux/etc is the host OS and Apple hardware is detected.] VirtualBox already has a bunch of kexts needed to provide various features, and so this is just a bit more code in one of those kexts.

Option (2) is a lot of extra complexity compared to option (1), but has the advantage of being legally much cleaner. Option (2) only works on Apple hardware, and so by using option (2) Apple's license condition, of only virtualising macOS on Apple hardware, is automatically enforced.

Considering that VirtualBox is from Oracle, and as well as open source, they also sell it as a commercial product, you can understand why Oracle's lawyers want option (2).


I don't see why someone would opt for option 2 when virtualizing macOS on an Apple machine.


So my understanding – if you run VirtualBox on macOS, and you choose macOS as Guest OS type when creating your VM, it automatically turns GetKeyFromRealSMC on. That means you are using option (2) by default. You can always switch to option (1) instead if you want to, but if you are virtualising macOS-on-macOS, there is little reason to.

From reading the VirtualBox source code [0] – it also automatically enables GetKeyFromRealSMC if it detects Apple hardware, even if the host OS isn't macOS. So, if you install Windows on your Mac, and then create a macOS VM in VirtualBox, it will automatically select option (2) as well. (I think, they actually include the code to talk to the Apple SMC in their Windows and Linux kernel drivers too.)

(Note I haven't actually tried doing this myself, this is just what I gather from the source.)

[0] https://github.com/mdaniel/virtualbox-org-svn-vbox-trunk/blo...


> but if you are virtualising macOS-on-macOS, there is little reason to.

Not needing to run a kext just to retrieve a known hardcoded string seems like a very good reason.


You don't need to use a kext. You can instead use IOKit to talk to the AppleSMC driver over a Mach port. Works even without root: https://gist.github.com/vagelim/dd5be2802ecb097b81cf07711f6a...

VirtualBox has code to do the above. But it also has code in one of its kexts to do it by talking directly to the hardware, in case (for whatever reason) this API doesn't work; it tries IOKit first and then calls the kext as a fallback. And, the kext doesn't solely exist to talk to the SMC, it does a bunch of other things too. I'm not sure whether VirtualBox works without its kexts, but if it doesn't, it isn't because of this reason.

(When I wrote my original comment above, I didn't know you could do this through the IOKit API, although I've since edited that comment to mention it.)


Can't the emulator just patch out the code that checks for that string?


That would likely need to be built for every version of MacOS that's ever been made, it's easier to emulate the hardware and provide the key it's looking for. That part alone shouldn't violate any ToS or laws on it's own, as long as the key isn't provided by the emulator/vendor. That will still allow you to still virtualize MacOS on the actual hardware (as is required by the license of the OS) without having a hacky patch in place that could lead to crashes or failures to boot whenever an update is applied to the guest.

disclaimer: I am not a lawyer, this is not legal advice, etc.


It is illegal under the DMCA to circumvent an effective copy protection measure, or to traffic in devices intended primarily for such circumvention. The law sets a very, very low bar for what counts as "effective". Basically, if you get around any obstacle to unauthorized copying or use, or show others how to get around it, you have committed a felony. Everyone who has repeated the device key here has committed a felony.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: