How to hacked the copy protection console Sega Dreamcast

After the release of the DOOM Black Book, I went on vacation to Japan, where I managed to play Ikaruga on a real arcade machine in the Taito HEY game room in Tokyo’s Akihabara district. This experience again revived my interest in the latest video game console SEGA - Dreamcast.

The network can find a lot of documents, greatly facilitating the process of studying the issue. There are two excellent resources that can quickly enter the ropes all: a wonderful web site Marcus Komshtedta, which describes everything up until the GPU registers, and user resource Jockel «Let's make a game for the Sega Dreamcast from scratch" .

While studying the car, I discovered a delightful story about how hackers quickly cracked the copy protection of games and destroyed the latest SEGA hardware hopes.

Level One: GD-ROM

On paper, the copy protection mechanism for the SEGA Dreamcast looked very strong. Games were delivered on a special carrier called GD-ROM, which could only be produced by SEGA. GD stands for “Gigabyte Disc” (“gigabyte disk”), that is, its increased recording density provided the maximum amount of 1 GB, which was much more than the capabilities of a regular CD-ROM (700 MB).



GD-ROM had the same physical dimensions as the CD-ROM, but at the macro level it consisted of two areas distinguishable to the naked eye.

The first (dark) zone is a low-density CD-ROM compatible area containing up to 35 MB. It contained a voice track that reminds the user that the contents of the disc are intended for the SEGA Dreamcast, and not for the CD player ^[1] . Also, the developer added a track with text files, such as copyright information, and sometimes promotional materials, such as art from the game.

The area of ​​high density (light) stored up to 984 MB ^[2] and all the game content was located on it.

Hackers seemed impossible to extract the game from the disk and burn it again for distribution.

Booting from GD-ROM: IP.BIN and 1ST_READ.BIN

Before we talk about how the pirates managed to copy games, we need to understand the boot sequence. Dreamcast did not have an operating system. There is a popular misconception that it used Windows CE, but in fact, Microsoft's operating system was just an extra static library that Dreamcast developers could plug in to use DirectX, DirectInput, and DirectSound ^[3] . In some games, WinCE was used ^[4] , but in the majority (for example, in Ikaruga) it was not used. Regardless of what the developer used, the game with a fully connected OS and the Dreamcast always ran the same way.

Under normal use and launch of the official game on the Dreamcast that was just started, BOOTROM was launched, loading the bootstrap program from GD-ROM into RAM. This tiny program, located on the last track of GD-ROM and known to the community as “IP.BIN”, displayed the licensed SEGA screen and performed two levels of bootstrap for setting up hardware registers, creating a CPU stack and initializing VBR ^[5] .

More importantly, IP.BIN contained the name of the game executable file. This name was searched in the GD-ROM file system and loaded into RAM at 0x8C010000, after which the execution of the program was transferred there. Usually the executable file had the name "1ST_READ.BIN".


After the CPU went to the address 0x8C010000, the game was launched, as it should be.

Second level of protection: encryptor-scrambler

The theoretical possibility of hacking arose due to the seemingly unimportant ability of the Dreamcast to boot not from GD-ROM, but from a CD-ROM. Initially, this functionality called “MIL-CD” was conceived for adding multimedia functions to music CDs, but was practically not used, with the exception of seven karaoke applications.

SEGA engineers understood that the MIL-CD download could be used as an attack vector, so they added protection. When the console recognized the CD-ROM, BOOTROM downloaded IP.BIN in the usual way, but encrypted 1ST_READ.BIN, at first glance, at random. The working executable file turned into a chaotic jumble that caused the console to hang.


From this point of view, it seemed that the console was reliably protected. Dreamcast could recognize a pirated copy of the game, spoil the executable file during the download process and defeat the pirates.

Give me my long sword!

The problem with the corrupted file was solved when, at the end of 1999, the Utopia hacker team stole Katana SDK (the official Sega SDK for the Dreamcast) ^[6] . It turned out that the scrambler was nothing more than the implementation of the principle of "security through obscurity". The SDK contained a reverse-scrambler, which turned the correct executable file into a “reverse jumble”, which again became an executable file after loading and scrambling with the Dreamcast console when booting from a CD-ROM.

Extracting the game from its GD-ROM

A stolen SDK is all the pirates needed. Thanks to the ability to run the code on the machine, the Dreamcast could now be used not as a game console, but as a GD-ROM drive. The “cable for the encoder” from the SDK ^[7] allowed connecting the console to the PC and establishing a physical connection. In order for the console to create a dump of the contents of the GD-tracks, a special executable file was written. Then it was reverse-scrambled and burned onto a CD-ROM in order to output the entire 1 GB of data through the serial port of the console. It was an error-prone process that took up to 18 hours ^{[8] [9]} . The result was saved in a specially created format ".gdi".

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

Interesting fact : you can see that the total amount of data is not 1 GB, as mentioned above, but 1.2 GB. This happened because the 2352-byte GD-ROM sectors follow the “Red Book” format, in which 12 bytes are used for synchronization, 4 bytes for the header, 2048 bytes for the payload and 288 bytes for the 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

How to fit the 1000-megabyte GD-ROM on the 700-megabyte CD-ROM

To accommodate the game on a 700-megabyte CD-ROM, game resources were processed. The ISO-9660 file system used in GD-ROM made it easy to change the discretization of videos and music, as well as completely remove them. However, for most games such a complex process was not required, because they did not occupy the entire 1 GB. For example, Treasure's Ikaruga occupied only 150 MB, and most of its content was filled with zeros. In such cases, simple editing of the fill data was sufficient.

In fact, ISO-9660 is such a well-known format that simple Python scripts (for example, gditools.py ) were even written to examine the contents of the .gdi archives .

Packaging and distribution

The last two stages of the process consisted of reverse scrambling 1ST_READ.BIN and packing all the information into the .cdi archive so that DiscJuggler could burn the image to a CD-R. The result obtained without any problems worked on any vanilla Dreamcast without the need for a chip modification.

SEGA reaction and consequences

SEGA quickly released a second version of the DC console with the MIL-CD completely disabled, but the damage was already done. After a catastrophic drop in revenues and the release of a competing PS2, the developers abandoned the Dreamcast and SEGA withdrew from the development of hardware, concentrating entirely on software development.

Reference materials

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