[Перевод] Как взломали защиту от копирования консоли Sega Dreamcast

После выпуска книги DOOM Black Book я отправился в отпуск в Японию, где мне удалось поиграть в Ikaruga на настоящем аркадном автомате в игровом зале Taito HEY токийского квартала Акихабара. Этот опыт снова возродил во мне интерес к последней видеоигровой консоли SEGA — Dreamcast.

В сети можно найти множество документов, сильно облегчающих процесс изучения вопроса. Есть два превосходных ресурса, способных быстро ввести в курс дела любого: замечательный веб-сайт Маркуса Комштедта, на котором описывается всё, вплоть до регистров GPU, и ресурс пользователя Jockel «Давайте создадим игру для Sega Dreamcast с нуля».

При изучении машины я обнаружил восхитительную историю о том, как хакеры быстро взломали защиту копий игр и разрушили последние аппаратные надежды SEGA.

Первый уровень защиты: GD-ROM

На бумаге механизм защиты копий игр для SEGA Dreamcast выглядел очень сильным. Игры поставлялись на специальном носителе под названием GD-ROM, который могла производить только SEGA. GD расшифровывается как «Gigabyte Disc» («гигабайтный диск»), то есть его повышенная плотность записи обеспечивала максимальный объём в 1 ГБ, что было намного больше возможностей обычного CD-ROM (700 МБ).

GD-ROM имел те же физические размеры, что и CD-ROM, но на макроуровне он состоял из двух областей, различимых невооружённым глазом.

Первая (тёмная) зона — это совместимая с CD-ROM область низкой плотности, содержащая до 35 МБ. В ней содержалась голосовая аудиодорожка, напоминающая пользователю, что содержимое диска предназначено для SEGA Dreamcast, а не для CD-проигрывателя^[1]. Также разработчик добавлял туда дорожку с текстовыми файлами, например информацией об авторском праве, а иногда и промоматериалы, например, арты из игры.

Область высокой плотности (светлая) хранила до 984 МБ^[2] и на ней располагался весь контент игры.

Хакерам казалось невозможным извлечь игру с диска и прожечь её заново для распространения.

Загрузка с GD-ROM: IP.BIN и 1ST_READ.BIN

Прежде чем рассказывать о том, как пиратам удавалось копировать игры, нам нужно понять последовательность загрузки. У Dreamcast не было операционной системы. Есть популярное заблуждение о том, что в ней использовалась Windows CE, но на самом деле ОС Microsoft была всего лишь дополнительной статической библиотекой, которую разработчики Dreamcast могли подключать для использования DirectX, DirectInput и DirectSound^[3]. В некоторых играх WinCE использовалась^[4], но в большинстве (например в Ikaruga) она не применялась. Вне зависимости от того, что использовал разработчик, игра с полностью подключенной ОС и Dreamcast запускались всегда одинаково.

При обычном использовании и запуске официальной игры на только что включенной Dreamcast запускался BOOTROM, загружая с GD-ROM в ОЗУ программу начальной загрузки (bootstrap). Эта крошечная программа, расположенная на последней дорожке GD-ROM и известная сообществу под названием «IP.BIN», отображала лицензионный экран SEGA и выполняла два уровня начальной загрузки для настройки аппаратных регистров, создания стека ЦП и инициализации VBR^[5].

Более важно то, что IP.BIN содержал название исполняемого файла игры. Это название искалось в файловой системе GD-ROM и загружалось в ОЗУ по адресу 0x8C010000, после чего выполнение программы переносилось туда. Обычно исполняемый файл имел название «1ST_READ.BIN».

После того, как ЦП переходил по адресу 0x8C010000, игра запускалась, как и положено.

Второй уровень защиты: шифровальщик-скрэмблер

Теоретическая возможность взлома возникла благодаря казалось бы малозначимой способности Dreamcast загружаться не с GD-ROM, а с CD-ROM. Изначально этот функционал под названием «MIL-CD» задумывался для добавления в музыкальные CD мультимедийных функций, но практически не использовался, за исключением семи караоке-приложений.

Инженеры SEGA понимали, что загрузка MIL-CD может использоваться в качестве вектора атаки, поэтому добавили защиту. Когда консоль распознавала CD-ROM, то BOOTROM загружал IP.BIN обычным образом, но шифровал 1ST_READ.BIN, на первый взгляд случайным образом. Рабочий исполняемый файл превращался в хаотическую мешанину, которая приводила к зависанию консоли.

С такой точки зрения казалось, что консоль надёжно защищена. Dreamcast мог распознавать пиратскую копию игры, портить исполняемый файл в процессе загрузки и побеждать пиратов.

Подайте длинный меч мой!

Проблема с испорченным файлом была решена, когда в конце 1999 года командой хакеров «Utopia» был украден Katana SDK (официальный SDK Sega для Dreamcast)^[6]. Оказалось, что скрэмблер был ни чем иным, как реализацией принципа «security through obscurity». SDK содержал реверс-скрэмблер, который превращал правильный исполняемый файл в «обратную мешанину», которая снова становилась исполняемым файлом после загрузки и скрэмблинга консолью Dreamcast при загрузке с CD-ROM.

Извлечение игры с её GD-ROM

Украденный SDK — это всё, что было нужно пиратам. Благодаря возможности запуска кода на машине теперь Dreamcast можно было использовать не как игровую консоль, а как привод GD-ROM. «Кабель для кодера» из SDK ^[7] позволял подключить консоль к PC и установить физическое соединение. Для того, чтобы консоль могла создать дамп содержимого GD-дорожек, был написан специальный исполняемый файл. Затем его реверс-скрэмблировали и записали на CD-ROM, чтобы вывести весь 1 ГБ данных через последовательный порт консоли. Это был подверженный ошибкам процесс, занимавший до 18 часов^[8][9]. Результат сохранялся в специально созданном формате «.gdi».

ikaruga.gdi            153 байта track01.bin     13 982 640 байт track02.raw      2 088 576 байт track03.bin  1 185 760 800 байт

Интересный факт: можно заметить, что общий объём данных составляет не 1 ГБ, как говорилось выше, а 1,2 ГБ. Так получилось потому, что 2352-байтные сектора GD-ROM следуют формату «Red Book», в котором 12 байт используется для синхронизации, 4 байта для заголовка, 2048 байт для полезной нагрузки и 288 байт для 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

Как уместили 1000-мегабайтный GD-ROM на 700-мегабайтный CD-ROM

Чтобы уместить игру на 700-мегабайтный CD-ROM, перерабатывались ресурсы игры. Файловая система ISO-9660, используемая в GD-ROM, позволяла с лёгкостью изменять дискретизацию видеороликов и музыки, а также полностью их удалять. Однако для большинства игр такой сложный процесс не требовался, потому что они не занимали весь 1 ГБ. Например, Ikaruga компании Treasure занимала всего 150 МБ, а большая часть её контента была заполнена нулями. В подобных случаях достаточно было простого редактирования заполняющих данных.

На самом деле ISO-9660 — это такой известный формат, что для изучения содержимого архивов .gdi даже были написаны простые скрипты на Python (например gditools.py).

Упаковка и распространение

Последние два этапа процесса заключались в обратном скрэмблинге 1ST_READ.BIN и упаковке всей информации в архив .cdi, чтобы DiscJuggler мог записать образ на CD-R. Полученный результат без проблем работал на любой ванильной Dreamcast без необходимости чипа модификации.

Реакция SEGA и последствия

SEGA быстро выпустила вторую версию консоли DC с полностью отключенным MIL-CD, но ущерб уже был нанесён. После катастрофического падения доходов и выпуска конкурирующей PS2 разработчики забросили Dreamcast и SEGA ушла из разработки оборудования, целиком сосредоточившись на создании ПО.

Справочные материалы

[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