The DMG boot ROM fits into the top 0x100 bytes. To protect it from being snooped, the last instruction shuts off the boot ROM by flipping a register that can’t be flipped back, mapping the top 0x100 back to the cartridge (and allowing the cartridges interrupt vectors to be installed.) So, there is no jump to 0x100 at any point; they just fit the DMG boots ROM perfectly into 0x100 bytes and control flow leaves bootstrap right as PC hits 0x100.

This simple security mechanism was extremely effective, and lead to the DMG BIOS being undumped until relatively recently, when it was dumped by imaging the ROM directly and via fault injection to skip the last instruction.

The fact that it was undumped until recently makes me want to understand this more. Can you ELI5?

In only 0x100 bytes of ROM that is so simple, there’s unlikely to be too many software bugs that allow dumping. Decapping a chip and imaging it isn’t cheap either. The hardware mechanism for locking the boot ROM may be hard to figure out without having the boot ROM already. And given how simple and effective the hardware mechanism is, it, too, is unlikely to have any obvious flaws to exploit.

So they didn’t exploit flaws, they just tried to work around the protection.

Even though the Gameboy is relatively slow (~4.7 Mhz processor IIRC) it’s still not going to be easy to hit exactly at the right time to be able to perform your fault injection.

The protection is simple enough to be effective. If you did it with a modern manufacturing process it’d probably be quite difficult to be able to image the bits directly...

Nowadays, for say Nintendo Switch, you are more likely to see keys and firmware data dumped via early boot exploits or privilege escalation.

There's a description of the particular fault injection used for the Gameboy Color here: https://www.its.caltech.edu/~costis/sgb_hack/

Fault injection is a method to cause microprocessors to execute instructions "incorrectly" by manipulating external factors (clock frequency, input power, etc). Getting the CPU to fail to write to a memory address, or flipping the truth of a comparison instruction, and other "glitches" can influence execution of security-sensitive code and ultimately undermine security mechanisms.

The original Gameboy ROM was dumped by physically de-capping the chip and reading out the bits: https://dot-matrix-game.blogspot.com/2014/01/boot-roms.html

That was a super insightful read!

tl;dr For the SGB, they quadrupled the clock speed briefly to glitch over the one instruction responsible for mapping out the ROM.

For the CGB, they halted the clock, drained the voltage to randomize the instruction counter, then used a NOP slide that led to their payload.

In my mind, "network play" refers to playing multiplayer games over a network, which this isn't? This is about playing a Game Boy game on an emulator that is running on a server somewhere, which sounds very much like "Cloud gaming" to me.

I think "cloud gaming" was pretty accurate:

https://en.wikipedia.org/wiki/Cloud_gaming

... given the "client" in this case was just telnet and the game was "running" on another machine "in the cloud" [1]?

1. like literally on alibaba, amirite?!

Probably because the lower addresses are for the interrupt vector table.

No. Execution actually starts at 0x0 like most architectures, but the boot loader fits in the first 256 bytes, so after the last instruction executes, execution continues on at 0x100