After I shipped the DOOM Black Book, I took some vacation in Japan where I was able to play Ikaruga on a real arcade at Taito HEY in Akihabara. The experience reignited my interest in SEGA's ultimate video game console, the Dreamcast.

There is a lot of documentation available online which made the studying process easier than expected. Marcus Comstedt's excellent website which describes everything down to the GPU registers and Jockel's Let's build a Sega Dreamcast game from scratch are two excellent resources which will rapidly bring anyone up to date.

Studying the machine revealed the fascinating story of how hackers cracked the game copy protection early on and doomed SEGA's last hardware hopes.

On paper the SEGA Dreamcast's copy protection mechanism looked strong. Games shipped on a special medium called GD-ROM which only SEGA was able to manufacture. With the GD part standing for "Gigabyte Disc", its higher density brought the max capacity to 1 GiB, which was beyond what normal CD-ROM were able to provide (700 MiB).

A GD-ROM had the same physical dimensions as a CD-ROM but at the macro level it was made of two areas visible with naked eyes.

The first (dark) section was a low density, CD-ROM compatible, area holding up to 35 MiB. It contained a voiceover audio track reminding user that the content was intended for SEGA Dreamcast and not for a CD player^[1]. Developer also included a track with text files such as copyright and sometimes goodies such as artwork.

The (clear) high density section storing up to 984 MiB^[2] is where all the game's content was located. As far as hackers were concerned, it seemed there was no way to extract the game from its support and there was no way to burn it back for distribution either.

Before describing how pirates managed to copy games, we need to understand the boot sequence. The Dreamcast had no operating system. A common misconception is that it ran Windows CE but in fact Microsoft's OS was only an optional static library which Dreamcast developers could link against in order to use DirectX, DirectInput, and DirectSound^[3]. Some games used WinCE^[4] but many (like Ikaruga) did not. Regardless of what a developer used, a game was a fully-linked OS and a Dreamcast always booted in the same way.

Under normal usage, running an official game, a freshly powered up Dreamcast's BOOTROM started by loading the bootstrap from the GD-ROM to the RAM. Located in the last track on the GD-ROM and known in the community as "IP.BIN", the tiny program was in charge of displaying SEGA's license screen and ran two bootstrap level to setup the hardware registers, create the CPU stack, and initialize the VBR^[5].

More importantly, IP.BIN contained the name of the game executable. This name was looked up in the GD-ROM file-system and loaded in RAM at 0x8C010000 before execution was transfered there. Usually the filename of the game executable was "1ST_READ.BIN".


With the CPU jumping to 0x8C010000, the game started as intended.

The "foot in the door" came from a seemingly obscure capability of the Dreamcast to boot not from a GD-ROM but from a CD-ROM. Originally intended to add multimedia functions to music CDs, the functionality called "MIL-CD" was never used much, accounting for a mere seven karaoke applications.

SEGA engineers knew that MIL-CD booting could be used as an attack vector so they added a protection. When the console detected a CD-ROM, the BOOTROM loaded IP.BIN normally but scrambled 1ST_READ.BIN, seemingly at random. A valid executable was therefore turned into mashed potatoes which promptly crashed the console.
From there it looked like the console was safe. The Dreamcast was able to recognize a pirated game, corrupt the executable at load time, and defeated pirates.

The mashed potatoes problem was solved when a Katana SDK (the official Sega SDK for the Dreamcast) was stolen^[6] by the hacking team "Utopia" in late 1999. It turned out that the scrambler was nothing more than "security through obscurity". The SDK contained a reverse-scrambler which transformed a valid executable into reverse-mashed-potatoes so it would be valid again when loaded and scrambled by the Dreamcast when booting from a CD-ROM.

The stolen SDK was all pirates needed. With the ability to run code on the machine, the Dreamcast was re-purposed to act not as a game console but as a GD-ROM drive. The SDK's "Coder's Cable"^[7] allowed to connect the console to a PC and establish a physical connection. To trigger the console to dump the GD track content, a special executable was written, reverse-scrambled and burned onto a CD-ROM in order to output the whole 1 GiB via the console's serial port. It was an error prone process which took up to 18 hours^[8] to complete^[9]. The result was stored in a custom made format called ".gdi".

ikaruga.gdi            153 bytes
track01.bin     13,982,640 bytes
track02.raw      2,088,576 bytes
track03.bin  1,185,760,800 bytes

Trivia: You will notice that the total account for 1.2 GiB and not the 1.0 GiB mentioned earlier. This is because GD-ROM 2,352-byte sectors follow the "Red Book" format where 12 bytes are used for synchronization, 4 bytes for the header, 2048 bytes for the payload, and 288 bytes are for Error Detection Code/Error Correcting Code^[10].

$ cat ikaruga.gdi 
3
1     0 4 2352 track01.bin 0
2  5945 0 2352 track02.raw 0
3 45000 4 2352 track03.bin 0

To make the game fit on a 700 MiB CD-ROM, game's assets were reworked. The ISO-9660 file-system used on GD-ROM made it easy to down-sample/remove video sequences and musics. For most games however there was no need for such a complicated process since they did not use the whole 1 GiB space. For example, Treasure's Ikaruga was only 150 MiB and padded most of its content with zeros. In these cases, only adjusting the padding was enough.

In fact, ISO-9660 is such a well-known format that simple python scripts (such as gditools.py) were written to explore the content of .gdi archives.

The last two steps of the process were to reverse-scramble 1ST_READ.BIN and pack everything into a .cdi archive so DiscJuggler could burn the image on a CD-R. The result ran flawlessly on any vanilla Dreamcast without need for a modification chip.

SEGA quickly released a DC v2 which disabled MIL-CD altogether but unfortunately damage had been done. With revenues plummeting and the PS2 ogre coming out, developers abandoned the Dreamcast and SEGA retired from the hardware manufacturing business in order to focus on software.

Long-time Dreamcast explorer, "newchiefgaming", provided corrections for this article. They can be found here.

^	[ 1]	SEGA GD Workshop
^	[ 2]	segaretro.org: GD-ROM
^	[ 3]	Microsoft Announces Windows CE Toolkit for Dreamcast
^	[ 4]	Dreamcast games utilising Windows CE
^	[ 5]	IP.BIN and 1ST_READ.BIN
^	[ 6]	Let's build a Sega Dreamcast game from scratch
^	[ 7]	PC Serial Adaptor
^	[ 8]	A more accurate and in-depth look at the Dreamcast's security
^	[ 9]	Faster ways were designed latter, using the DC's broadband connector
^	[10]	Dreamcast Myth: GD-ROM Storage Capacity