Fun fact: macOS used to encrypt its system applications as a form of copy protection on Intel machines, using encryption keys that were read from the System Management Controller chip on the board.
They don't do that any more on Apple Silicon machines, and the entire OS is free to download from their CDN, completely unencrypted. Still, though, the SMC on M1 machines (which is now part of the M1 chip itself, and completely different from the one on Intel boxes) continues to hold those very same keys, and they're still "secret" and omitted when you enumerate them. macOS no longer even reads them, but you can dump them with the debug tooling I wrote for Asahi Linux a few weeks ago.
more context for other ppl reading: colloquially known as "the haiku" it is a way to force an exploiter to violate copyright law in order to disseminate a method to boot the system on unauthorized hardware
That sounds like the old days, when game cartridges needed to have code that would cause a Sega or Nintendo trademark to appear. The courts did not provide trademark/copyright protection for access control codes.
>We hold that when there is no other method of access to the computer that is known or readily available to rival cartridge manufacturers, the use of the initialization code by a rival does not violate the [Lanham Trademark] Act even though that use triggers a misleading trademark display.
I seem to remember a similar case for the Gameboy ROM that needed to contain an image of the Nintendo trademark to boot, but couldn't find a good online reference. Lexmark tried to pull a similar stunt by claiming the ROM code in their cartridge chips was executable code in a secret language, but courts again said it was an access control code first, and thus functional not creative.
Correct with the Gameboy. In fact, that is literally all the very small ROM (256 bytes) in the Gameboy does: Display the logo from the cartridge and then compare it with the one in the ROM (makes it seem even tinier).
If the comparison fails, the logo was still displayed scrolling down and making the bing sound, but the Gameboy now just halts. Everyone who had one in their youth knows the black block scrolling down with no cartridge inserted, and various variants of corrupted logos if contact was bad or the cartridge broken.
This also means the Gameboy has no “OS” whatsoever, it’s all done by the games. But the system is too simple to need one anyway.
That’s also why it’s so good for writing your first emulator.
This case is amazing. Not only did they decide it was not trademark violation, they blamed the trademark holders for putting their competitors in a position where they had to use the trademark in order to compete.
The world was a lot more reasonable before the DMCA.
Another fun wrinkle is that as part of that suit, Sega engineer Takeshi Nagashima also produced two cartridges with different methods of bypassing the screen "using standard components, at a total extra cost of approximately fifty cents". They offered to let Accolade's counsel examine the cartridges, but only on the condition that Accolade's engineers couldn't see them. This convinced the district court that the code triggering the screen was "nonfunctional", but the Ninth Circuit disagreed.
My guess is that these methods involved some modchip-style tomfoolery like reset glitching or forcing values onto the bus, and could have been defeated by Sega in a future revision of the console.
The Game Boy definitely does do that, as a sibling comment also mentions, though I don't remember there being a case about it. My recollection from long ago is that when you turn on the Game Boy with no cartridge inserted, there's just a black box where the Nintendo logo normally is. There's a well-known similar Nintendo case but it involved the NES, and there was a later one with Sony over the Playstation BIOS.
But yes, the courts (or at least the 9th Circuit) have looked down on these attempts to use copyright and trademark as methods of preventing access. Of course now they have DMCA anticircumvention provisions to help out instead anyhow.
IIRC, the reimplementing version did something like, display the trademark so it could run at all, and then on the next screen (when the game runs), say “not really, but we had to display that so this could run”.
The Gameboy use a very similar system to make it harder to create cartridges not sanctioned by Apple. The cartridge would have to provide the Nintendo logo and the system would check it and then display it (there actually is a TOC/TOU vulnerability there that lets you display something other than the logo on startup). Because the cartridge had to provide the logo, not being licensed by Nintendo meant doing a copyright violation.
Wait, does that mean that if someone wrote the drivers you could make an ARM hackintosh or VM without needing any special measures? Still an EULA violation, but zero friction and zero technical impediments?
Yes, I already run the native build of macOS in a bespoke hypervisor for experimentation purposes (most of the hardware is passed through), and macOS already has a VM-specific ARM kernel that in principle doesn't even require any proprietary CPU features and would run on any ARM machine (the native one wouldn't, it needs custom Apple instructions). I'm pretty sure someone already tried the macOS vmkernel on QEMU/KVM on another ARM box and it boots to a shell. I think it even has virtio support and there's a QEMU Guest Agent built into macOS these days (yes, really).
There's just one catch. The desktop environment requires GPU acceleration to even start, and your two options are emulating the proprietary Apple GPU, or emulating the paravirtualized Metal GPU they developed for VMs. Neither is likely to be particularly easy... it's why I tell people to not expect to be able to run a macOS VM on Linux on an M1 Mac, unless they want to write a whole Metal implementation. A plain kernel in single user mode? Sure. macOS desktop? Good luck :-).
For macOS on macOS on Apple hardware, Apple have their paravirt GPU support on both sides so it basically "just works" with minimal work from the third-party hypervisors that build on those frameworks.
> The desktop environment requires GPU acceleration to even start, and your two options are emulating the proprietary Apple GPU, or emulating the paravirtualized Metal GPU they developed for VMs.
That basically enforces in hardware what has always been the commercial position of OSX: open kernel, closed (and ruthlessly guarded) desktop libraries.
Could you pass the GPU (and all attendant hardware) transparently through Linux into a macOS VM, a bit like PCI passthrough (IIRC) is used for Windows VMs?
....hmm, now I think about that I realize it wouldn't have many non-tinkering oriented use cases. Right now I can only think of out-of-band firewalling.
It's... complicated. And yeah, at that point, it wouldn't have many use cases.
The hypervisor I wrote for research purposes passes through all the hardware (except the UART), which is easier than trying to do it on top of Linux. But it also doesn't try to be a secure hypervisor or anything like that (it would be trivial for the guest to take over).
The commpage had a different message that came from the DSMOS kernel extension which implemented the encryption stuff.
Your karma check for today:
There once was was a user that whined
his existing OS was so blind,
he'd do better to pirate
an OS that ran great
but found his hardware declined.
Please don't steal Mac OS!
Really, that's way uncool.
(C) Apple Computer, Inc.
The ARM builds don't have DSMOS.kext, so I imagine the commpage message is gone.
They don't do that any more on Apple Silicon machines, and the entire OS is free to download from their CDN, completely unencrypted. Still, though, the SMC on M1 machines (which is now part of the M1 chip itself, and completely different from the one on Intel boxes) continues to hold those very same keys, and they're still "secret" and omitted when you enumerate them. macOS no longer even reads them, but you can dump them with the debug tooling I wrote for Asahi Linux a few weeks ago.