Эта статья продолжает идею предыдущей "Как у меня получилось взломать и распаковать ресурсы старой игры для PSX" здесь я также попытаюсь с точки зрения "новичка в реверс-инжиниринге" описать ход мыслей и действий с помощью которых мне удалось "с нуля" разобраться в устройстве игрового архива.

Я рассчитываю, что она может быть полезна тем, кто боится открывать hex-редактор, думая, что это какая-то хакерская программа, надеюсь мне удастся показать, что даже уровня "продвинутого пользователя" и начальных навыков программирования может хватить для таких вот "вещей".

Часть Первая - Изучаем игру

Итак, перво-наперво нужно собрать информацию по игре, файлы которой мы решили “взломать”.

Представляю вашему вниманию Car Jacker, он же Crazy Drive Away, он же Car Boosting, и местами даже Car Jacker 2.

Игры были сделаны в 2004-2005 годах некой конторой Kozmogames Inc. на движке с пафосным названием e^N-gine.

Такое обилие личин объясняется, скорее всего тем, что в разных странах и у разных издателей игра выходила под разными названиями, видимо для того, чтобы геймеры не могли ничего про нее прочитать до момента покупки, и тем самым не передумали ее покупать.
Сами игры представляют из себя песочницы в стиле GTA с десятком миссий.

Скачать их всех можно по ссылке в интернет-архиве.(если вдруг кто-то захочет сам пользуясь моим руководством повторить взлом)

Приступаем к изучению самой игры, для этого открываем папку в которую она установилась. И вот что предстает нашему взору:

Сама игра весит менее 100мб из которых 90мб занимает файл data.pak, который и представляет собой главный и единственный игровой архив.

В файле config.ini глаза бросается вот такая строчка:
FontFile=textures\GUI\AGLettericaCondensedLight.dds

Тут мы видим относительный путь к файлу со шрифтами, но самого файла в папке с игрой нет, поэтому можно предположить что он хранится где-то внутри data.pak.
Попутно загуглим, что такое dds, оказывается это формат хранения текстур DirectX.

Отложим это пока в голове и откроем data.pak hex-редактором.

В самом начале файла нам предстаёт вот такая картина:

Первые несколько байт с какими-то данными, потом группа нулей, потом опять данные.
С одной стороны выглядит как типичный заголовок, где обычно сначала сигнатура или какое-то смещение, потом нули.

Но вот в чем проблема, первые байты это явно не сигнатура и не смещение, а скорее какая-то абракадабра.

Но отметим для себя, что наличие одинаковых байт “00”, идущих друг за другом говорит нам о том, что весь файл или хотя бы его часть - не сжаты.

На всякий случай, я пропустил архив через "Dragon UnPACKer" и парочку других перспективных универсальных игровых сканеров, на предмет открытых ресурсов, но ожидаемо - безуспешно.

Продолжаем листать data.pak в hex-редакторе дальше, а именно “перематываем” примерно на середину.

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

Но тогда почему универсальные игровые распаковщики не обнаружили те же файлы формата .dds, которые упоминались в конфиге?

Листаем дальше, в самый конец файла:

А вот это уже интересно! Последние 160кб файла занимает вот такая структура как на скриншоте.

Блоки равного размера содержащие что-то ОООЧЕНЬ похожее на текст , а остальная часть забита нулями.

Ощущение, что это текст, еще усиливает и то, что если присмотреться, то последовательность у “текста” на скриншоте отличается только четвертым символом с конца. Уж не пути ли это к файлам, с одинаковыми именами и расширениями, отличающимися лишь цифрой в конце?

Тогда получается что \ИИж - это расширение. А помните у нас в файле config.ini был путь  к какому-то файлу формата .dds?

Это не может быть совпадением, можно открыть таблицу ANSI(а точнее win-1251) и посмотреть, что нужно сделать с .dds чтобы оно превратилось в  \ИИж, но я поступил несколько иначе, создал текстовый файл и открыл его в том же hex-редакторе.

Редактор HxD в одном из окон показывает выделенные байты в разных системах счисления.

И вот что получилось в виде текста и в десятичной системе счисления.

.dds
2E 64 64 73 
46 100 100 115

\ИИж
5C C8 C8 E6
92 200 200 230

Я думаю вы уже догадались что произошло. Числовое значение каждого байта было умножено на 2.

Небольшой дисклеймер для “настоящих” программистов - не надо кричать сейчас в монитор, АЛЛО ЭТО БИТОВЫЙ СДВИГ и делать “рукалицо”. Мы же тут собрались ради тех, кто в программирование и реверс-инжиниринг пытается зайти с черного входа, так что про битовый сдвиг будет, но чуть позже.

Но есть небольшой нюанс.

Во-первых, умножение на 2 должно приводить к тому, что результат должен делиться на 2, а некоторый байты в файле на 2 не делятся.

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

Я эту проблему решил на интуитивном уровне, мне было очевидно что единственный способ “утрясти” проблему, сделать следующее: если результат умножения на два больше 255 - отнять от результата 255.

Это во-первых превратит четное после умножения число в нечетное, что не даст ему перекрыть ни одно из чисел до 128 умноженных на два, которые дали четный результат, а во-вторых при обратном декодировании, если вы встретили нечетное число, вы сразу поймете что это результат умножения на два, который превысил 255 и поймете что с ним сделать(добавить 255, а потом разделить на два).

Многие наверное скажут, блин чувак, ну ты офигел, как до такого можно дойти самому, это же какая-то "высшая математика".
Я могу частично с этим согласиться, и поэтому чуть ниже расскажу как можно было дойти до такого же решения без таких вот озарений.

Часть вторая - Пишем расшифровщик

Пришло время создать Proof-of-Concept расшифровщика.

Я свой писал на java. но тут чтобы легче читалось напишу на java-подобном псевдокоде.

File fileI = new File("data.pak");
byte [] fileBytes = Files.readAllBytes(fileI);
for (int i=0;i<fileBytes.length;i++) {
  if(!dividesByTwo(fileBytes[i]) fileBytes[i] = (fileBytes[i])+255)/2);
  else fileBytes[i]=fileBytes[i])/2;
}
File fileO = new File("data_dec.pak");
Files.write(fileO, fileBytes);

"Код" выше делает следующее: читает файл в массив байтов, потом проходит по этому массиву циклом и если байт не делится на 2, то прибавляет к нему 255 и делит на два, а если делится, то просто делит на два, а результат всего этого записывается в новый файл.

Теперь откроем в редакторе расшифрованный файл data_dec.pak и изучим его структуру.

Можно заметить что первые несколько байт архива, которые до этого были абракадаброй превратились в слово attack, но нас интересует конец файла, где, судя по всему, описана его структура.

Сравнив несколько блоков подряд, можно легко определить их структуру.

Первые 128 байтов из 140 - это текст, который содержит имя файла и виртуальный путь к нему.
Потом идет 4 блока по 4 байта, каждое из которых - число Int.
Первое число(выделено зеленым) - смещение относительно начала архива.
Второе число(выделено синим) - размер файла.
Третье число - всегда нули.
Четвертое число - тоже размер файла, оно всегда равно второму, по крайней мере для этого архива.

Первый файл называется
.\Animations\blackguy_with_bat\attack.ALF
Исходя из имени и пути к файлу, очевидно что это анимация атаки.
Смещение у него - 00 00 00 00 , т.е он начинается с самого начала архива, с первого байта.

Помните, когда мы открыли файл после расшифровки, в первых байтах было написано attack. Скорее всего формат этого файла с анимацией подразумевает, что в его начале хранится его имя.

Давайте перейдем по смещению 00 01 28 EC, т.е к концу первого файла архива, там мы видим слово fallback, что соответствует имени второго файла
.\Animations\blackguy_with_bat\fallback.ALF
Таким образом можно убедится, что все устроено так как мы и предположили.

А сейчас вернемся к тому второму альтернативному способу того как можно выяснить что делать с нечетными байтами.

В оглавлении архива нечетные байты встречаются только в смещениях, так как весь английский текст находится в первой половине таблицы ansi и всегда при умножении на два окажется в пределах 255.
Допустим мы не до конца декодировали архив,(пропусти все нечетные байты)
Для первых двух файлах в оглавлении текст у нас есть полностью, а вот смещения преобразованы только частично.
Вот что у нас бы получилось:
первый блок
имя:
.\Animations\blackguy_with_bat\attack.ALF
числа
00 00 00 00
00 01 28 D9 (D9 тут не декодирован так как это нечетное число 217)
00 01 28 D9
второй блок:
.\Animations\blackguy_with_bat\fallback.ALF
числа
00 01 28 D9
00 00 3F 2C (3F тут тоже не декодирован)
00 00 3F 2C

в любом случае 00 01 28 D9 выглядит вполне как 4 байтное число, и разумно было бы сходить посмотреть что там по этому смещению.

Попав на него мы видим что оказались в паре байт от слова  fallback, складываем в уме 2+2, понимаем что вместо 00 01 28 D9 мы должны были бы попасть на 00 01 28 EC.
Выходит, что EC (236) ,которое при умножении на два дает 472, должно как-то превратится в D9 (217). Ну и тут уже очевидно что разница между ними равна 255. И мы приходим к точно такому же решению, которое было описано выше. Вуаля!

Ладно, а теперь забудьте все, что я выше писал.

Несмотря на то, что мы смогли разобраться в том, как создатели движка\игры обфусцировали данные архива, для меня очевидно, что какой бы халтурой для сруба бабла, не была их игра, они бы никогда не стали в код движка вставлять какие-то прибавления и вычитания “255”. Во-первых это слишком ресурсоемко(слишком много дополнительных операций) во-вторых слишком криво с точки зрения программирования.

Ясно, что должен быть какой-то более низкоуровневый и простой способ проделать с байтами тоже самое, что мы тут выше делали с помощью прибавления 255 и деления на 2.
Недолгий гуглеж на тему того, какие способы делить и умножать на 2 применительно к байтам и битам существуют, выдал результат в виде Битового Сдвига.

Еще вот тут по ссылке есть онлайн инструмент чтобы поиграться с битовым сдвигом для разных чисел или можно использовать даже калькулятор windows переключив его в “режим программиста”.

Если лень ходить по ссылкам, то объясню вкратце, как это работает:

Возьмем два примера которые мы разбирали выше.
DEC 100
HEX 64
bit 01100100

Если применить сдвиг бит влево для 01100100, то получится 11001000, что в свою очередь равно 200 и эквивалентно умножению на два.,

Если же взять число
DEC 236
HEX EC
bit 11101100
то при сдвиге влево мы получим 11011001 что в свою очередь равно 217(D9)

В этом месте мне бы хотелось показать какой-то максимально красивый и короткий java-код, который бы ультимативно доказал превосходство и красоту битового сдвига над убожеством деления на 2 и прибавления 255, но java к огромному сожалению делает сдвиг совсем не так, как нам надо, она или увеличивает число до двух байт при сдвиге влево, либо если ее принудительно ограничить байтом - сжирает сдвинутые единицы заменяя их нулями. Поэтому код для реализации сдвига так, как нам надо, будет выглядеть в разы более монструозно, в виду запредельного количества костылей, чем код с делением и прибавлением 255.
Но говнокодить в java нам и не нужно, мы будем использовать kaitai(он наговнокодит все за нас).

Осталось разгадать последнюю загадку.

Так как оглавление архива расположено в его конце, для того чтобы создать полноценный распаковщик, нам нужно каким-то образом программно научится понимать, либо где расположено начало этого оглавления, либо его размер.

И тут стоит обратить внимание на самый-самый конец архива.

Дело в том, что последний блок оглавления заканчивается за 4 байта до конца архива.
В декодированной версии эти байты - 4F FD FF FF, в изначальной 9E FB FF FF.
Тут мне по правде говоря пришлось серьезно поломать голову. Помог встроенный в редактор "инспектор данных" и то, что я при написании распаковщика додумался вставить туда счетчик блоков в оглавлении.

В архиве было 1122 файла(блоков в оглавлении) и при выделении последних 4 байт в оригинальном data.pak, до декодирования, у меня глаз зацепился за это число.

Оказалось что последние 4 байта в файле не нужно подвергать декодированию, и они хранят ОТРИЦАТЕЛЬНОЕ значение количества блоков в оглавлении.

Таким образом вырисовывался алгоритм распаковки:

1. Прочитать последние 4 байта, получить количество(1122) файлов\блоков

2. Декодировать путем битового сдвига вправо весь остальной файл

3. Умножить число блоков на размер одного блока(1122 умножить на 144(байт в блоке)

4. Отступить от конца файла 4+(1122*144) байт

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

Часть третья - Kaitai

Во-первых, почему и зачем. Мне в каментах к прошлой статье написали :

Ну я и решил его попробовать.

Итак что такое Kaitai и зачем он нам нужен в данном случае:

1. Kaitai - декларативный язык описания структуры бинарных данных

2. Он позволяет в текстовом .ksy файле используя специальный синтаксис, описать структуру таких файлов, как например игровой архив описанный выше, в том числе с обфускацией и сжатием.

3. Такой .ksy файл может быть использован сам по себе, например в составе библиотеки с описанием всевозможных форматов или же его можно скомпилировать в классы(исходный код) какого-нибудь языка и использовать в своем проекте для работы с этими бинарными файлами.

Давайте же посмотрим, что я с помощью Kaitai смог сделать.

Для начала вынесем обфускаций данных за скобки и опишем уже декодированный формат.

Так проще разобраться в новом для себя языке, а сходу не было понятно, можно ли в рамках Kaitai реализовать битовый сдвиг(оказалось можно и очень легко), а декодирование можно было бы потом прикрутить уже сверху средствами java.

Вот что получилось в первой итерации:

meta:
  id: autothief_pak
  file-extension: pak
  application: CarJacker game
  endian: le
instances:
  toc_count:
    pos: _io.size - 4
    type: s4
  toc:
    pos: _io.size - 4 + toc_count * 144
    type: toc_record
    repeat: expr
    repeat-expr: -toc_count
types:
  toc_record:
    seq:
      - id: name
        type: strz
        encoding: ASCII
        size: 128
      - id: ofs_body
        type: u4
      - id: len_body
        type: u4
      - id: unk1
        type: u4
      - id: unk2
        type: u4
    instances:
      file_content:
        pos: ofs_body
        size: len_body

Опишу по порядку:
Первый блок “meta” вроде понятен сам по себе - набор обязательный полей, дающий понять структура какого именно файла описана ниже. 

Второй блок instances - это один из способов описание объектов. В данном случае я создал объект toc_count(количество записей в оглавлении), который находится на позиции “размер файла минус 4 байта” и типа s4 (Signed 4 bytes), а также объект toc, который находится по адресу “размер файла - 4 + кол-во записей умножить на 144”
При этом объект toc имеет повторяющийся тип toc_record, который описан ниже, с числом повторений равным переменной toc_count.

Дальше в блоке types идет описание единственного упомянутого мной "кастомного типа", который я упомянул - toc_record.

seq - второй(или первый) главный в kaitai способ описания объектов. В отличие от instances , которые могут иметь динамическое расположение и размер, данные внутри seq должны идти с начала, один за одним, и иметь фиксированный размер, наш toc_record как раз такой, если вы помните.

Итак, там у нас сначала name, строковое имя файла длиной 128 байт, z в конце strz в данном случае значит что 00 в конце строки можно обрезать.

Потом ofs_body - "смещение" файла в виде unsigned 4 bytes, такой же len_body - “размер файла” и два бесполезных числа.

Еще внутри каждой toc_record мы создаем в каком-то смысле “виртуальный” instance “file_content”, позиция и размер которого берется из значений самого toc_record.
Это и будет наш извлекаемый из архива файл.

Я сказал "виртуальный", потому что сам файл в архиве хранится отдельно от оглавления, но так как instances в Kaitai позволяют указывать любое расположение, то мы может как бы запихнуть ссылку на файл прямо в объект из оглавления.

Вроде бы на первый взгляд все получилось красиво. На языке Kaitai удалось минималистично и относительно понятно описать структуру игрового архива, игнорируя правда применяемое в нем кодирование путем битового сдвига.

На предварительно декодированном архиве этот .ksy файл работает как надо.

Но давайте попробуем реализовать еще и битовый сдвиг непосредственно силами Kaitai, оказывается он это может.

Для этого нужно по сути добавить одну вот такую строчку.
   process: ror(1) ( сдвиг на 1 бит вправо)

Но тут возникает проблема, куда не всунь в .ksy-файле выше этот process: ror(1) он работать не будет.

Два года назад компилятор просто валился с кучей разных стэк-трейсов, в зависимости от места инжекта процессинга, я назаводил багов, сейчас проверил, стэк-трейсов нет, зато есть красивые ошибки текстом, которые говорят, что "процессинг так не может".

Насколько я понял, проблема в том что process не умеет работать внутри instances , его смущает неопределенность размера данных которые нужно подвергнуть обработки.
Поэтому пришлось несколько “обезобразить” красивый и компактный файл, добавив в него дополнительный уровень seq (в самом верху), чтобы заработал процессинг.

Вот что получилось во второй итерации, теперь с битовым сдвигом и как следствие полным декодированием:

meta:
  id: autothief_pak
  file-extension: pak
  application: CarJacker game
  endian: le
seq:
  - id: body
    size: _io.size-4
    process: ror(1)
    type: pak_body
  - id: toc_count
    type: s4
types:
  pak_body:
    instances:
      toc:
        pos: _io.size + _root.toc_count * 144
        type: toc_record
        repeat: expr
        repeat-expr: -_root.toc_count
  toc_record:
    seq:
      - id: name
        type: strz
        encoding: ASCII
        size: 128
      - id: ofs_body
        type: u4
      - id: len_body
        type: u4
      - id: unk1
        type: u4
      - id: unk2
        type: u4
    instances:
      file_content:
        pos: ofs_body
        size: len_body		

Теперь структура файла такая:
В самом верху фиксированные seq-объекты body и toc_count. 

У объекта body размер “весь файл минус последние 4 байта” он имеет кастомный тип pak_body и к нему применен процессинг xor(1).
toc_count - это знаковый int(4 байта), который идет следом.
Ну а тип pak_body в свою очередь устроен точно так же как был устроен первый .ksy файл.

Получилось так что ради добавления процессинга, за который отвечает одна строка, файл пришлось усложнить и его размер вырос на 4 строки. Но хотя бы работает…

Теперь следующий этап. На основе этого .ksy файла мы с помощью компилятора kaitai сгенерируем java-классы. с помощью которых и будем работать с архивом(напишем красивый распаковщик)

Генерация происходит вот таким вот нехитрым образом из командной строки:
.\kaitai-struct-compiler.bat -t java autothief_pak.ksy

В результате у нас создается файл AutothiefPak.java размером 6кб, который мы добавляем в наш Java проект.

Чтобы этот класс заработал как надо, ему нужна библиотека kaitai-struct-runtime, которую в свою очередь можно добавить через maven или вручную.

В итоге для распаковки архива достаточно вот такого компактного кода:

public class Unpacker {
    public static void main(String[] args){
        AutothiefPak pack  = AutothiefPak.fromFile("data.pak"); //загружаем и сразу парсим файл в обьект AutothiefPak
        for (AutothiefPak.TocRecord file : pack.body().toc()){   //для каждой записи TocRecord внутри оглавления делаем следующее
          Path filePath = Paths.get(file.name()); //извлекаем путь
          Files.createDirectories(filePath.getParent()); // создаем директории под этот путь
          Files.write(filePath, file.fileContent()); // записываем содержимое массива байтов fileContent в файл по этому пути
        }
    }
}

И как результат работы программы, у нас на диске появляется 121 папка со 1122 файлами представляющие собой распакованные и декодированные ресурсы игры.

Спасибо за внимание, надеюсь этот пост сподвигнет кого-нибудь к собственным успешным исследованиям.