Файловый титбит. Учимся менять ресурсы игр на примере «Ядерного титбита»

Во мно­гих играх ресур­сы упа­кова­ны в спе­циаль­ный файл — игро­вой архив. Здесь могут лежать модели, тек­сту­ры, скрип­ты, ани­мация, зву­ки и про­чее. Некото­рые раз­работ­чики не запари­вают­ся и исполь­зуют ZIP, раз­ве что для минималь­ной мас­киров­ки меня­ют рас­ширение на какой‑нибудь про­изволь­ный набор букв.

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

Формат с кислотным привкусом

Се­год­ня про­дегус­тиру­ем «Ядер­ный тит­бит», игру 2003 года, соз­данную при учас­тии Дани Шепова­лова.

До­гадать­ся, какой из фай­лов в пап­ке игры — это архив с ресур­сами, мож­но, прос­то гля­нув на раз­меры. QUEST.ezd самый боль­шой и занима­ет 216 Мбайт. Это явно наш кли­ент. Откры­ваем его в HEX-редак­торе:

Обыч­но пер­вые четыре бай­та содер­жат сиг­натуру фор­мата. Здесь мы видим стро­ку ezd., что сов­пада­ет с рас­ширени­ем фай­ла. Зна­чит, это сиг­натура. Если нет явных про­тиво­речий, про­дол­жаем раз­бор с шагом в четыре бай­та. Струк­туры час­то вырав­нива­ются по INT32.

Сле­дующие четыре бай­та: 0x4D080000. Прог­рамма соб­рана для x86, поэто­му чис­ла записа­ны в обратном поряд­ке бай­тов. Таким обра­зом, 0x4D080000 интер­пре­тиру­ется как 0x0000084D, что в десятич­ной сис­теме рав­но 2125. Что это может быть? Воз­можно, заголо­вок архи­ва содер­жит чис­ло фай­лов. Две тысячи — впол­не адек­ватное чис­ло. Про­верим эту гипоте­зу поз­же.

Да­лее идет 0x3D750200, это декоди­рует­ся в чис­ло 161 085, что сос­тавля­ет 157 Кбайт. Это может быть раз­мер текущей струк­туры или сме­щение начала сле­дующей. Дей­стви­тель­но, по адре­су 161 085 закан­чива­ется спи­сок строк, похожих на име­на фай­лов.

Сле­дующий DWORD — 0xD69A820D, что экви­вален­тно 226 663 126. Это точ­но раз­мер фай­ла — 226 663 126 байт.

Опыт под­ска­зыва­ет, что на 16-м бай­те фай­ловый заголо­вок закан­чива­ется. Даль­ше сле­дуют стро­ки, переме­шан­ные с неиз­вес­тны­ми чис­лами. Ско­рее все­го, это мас­сив струк­тур, опи­сыва­ющих кон­крет­ные фай­лы. Поп­робу­ем опре­делить раз­мер и наз­начение всех полей.

Пер­вая струк­тура начина­ется с ASCII-строч­ки door_01.meat. Если раз­мер стро­ки заранее не ука­зан, зна­чит, она чита­ется до нулево­го бай­та. До начала сле­дующей стро­ки 18 байт. Рас­сто­яние меж­ду слу­чай­ными стро­ками не меня­ется, сле­дова­тель­но, это зна­чимые поля.

Срав­нивая пред­полага­емые струк­туры, замеча­ем пос­ле каж­дой стро­ки шесть неиз­менных зна­чений 0x000002000000. Счи­таем их кон­стан­той. Оста­ется понять наз­начение 12 изме­няемых бай­тов.

Что сра­зу бро­сает­ся в гла­за? Во‑пер­вых, чис­ло 161 085 сов­пада­ет со сме­щени­ем из фай­лового заголов­ка. Веро­ятно, это адрес с дан­ными пер­вого фай­ла. Сле­дующие два чис­ла могут быть раз­мером и кон­троль­ной сум­мой. Сме­щение вто­рого фай­ла — 163 654. Вычитая сме­щение пер­вого, получа­ем 2569. Зна­чит, это поле с раз­мером дан­ных.