FABIEN SANGLARD'S WEBSITE -------------------------- ABOUT RSS EMAIL TWITTER December 11, 2018 How the Dreamcast copy protection was defeated After I shipped the DOOM Black Book, I took some vacation…
HN Discussion: https://news.ycombinator.com/item?id=18654199
Posted by fafner
(karma: 1754)Post stats: Points: 128 - Comments: 50 - 2018-12-11T09:47:53Z
Article content:FABIEN SANGLARDʼS WEBSITE -------------------------- ABOUT RSS EMAIL TWITTER
December 11, 2018
How the Dreamcast copy protection was defeated
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.
First protection level: GD-ROM
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^. 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^ 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.
Booting from a GD-ROM: IP.BIN and 1ST_READ.BIN
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 DirectAudio^. Some games used WinCE^ 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^.
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.
Second protection level: Scrambler
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.
Give me my long sword, ho!
The mashed potatoes problem was solved when a Katana SDK (the official Sega SDK for the Dreamcast) was stolen^ 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.
Extracting a game from its GD-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"^ 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^ to complete^. The result was stored in a custom made format called ".gdi".
ikaruga.gdi 153 bytes
track01.bin 13,982,640 bytes
track02.bin 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^.
$ cat ikaruga.gdi 3
1 0 4 2352 track01.bin 0
2 5945 0 2352 track02.bin 0
3 45000 4 2352 track03.bin 0
Making a 1000 MiB GD-ROM fit inside a 700 MiB CD-ROM
To make the game fit on a 700 MiB CD-ROM, gameʼs assets were reworked. The ISO-9600 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-9600 is such a well-known format that simple python script (such as gditools.py) were written to explore the content of .gdi archives.
Packing and Distribution
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.
Response from SEGA and after-match
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.
^ Source: SEGA GD Workshop
^ Source: segaretro.org: GD-ROM
^ Source: Microsoft Announces Windows CE Toolkit for Dreamcast
^ Source: Dreamcast games utilising Windows CE
^ Source: IP.BIN and 1ST_READ.BIN
^ Source: Letʼs build a Sega Dreamcast game from scratch
^ Source: PC Serial Adaptor
^ Source: A more accurate and in-depth look at the Dreamcastʼs security
^ Source: Faster ways were designed latter, using the DCʼs broadband connector
^ Source: Dreamcast Myth: GD-ROM Storage Capacity
HackerNewsBot debug: Calculated post rank: 102 - Loop: 165 - Rank min: 100 - Author rank: 43