Блог unk1024 по поводу формата ресурсов в ПКМ ВМЛ:

..5 мая 2006 г.


Команда разработчиков мне не особо нравится, это мое личное.. Об остальном скажу побольше.
Они скрыли свой код ВМЛ, им дали (?) код К3. Не скажу, чтобы зависть, но нехорошо. Я тут сижу,
думаю, что это за формат SFFS, а они так просто.. Ну ладно, не буду забивать голову такими
вещами, вообще не люблю все эти вещи. Начнем, пожалуй.

У этой так называемой команды во главе с ALexusB (ничего не имею против) есть
свои раздумьки по поводу хранения ресурсов (в том числе и скриптов) в игре. Они
придумали (а может и не они?) такую систему: у них есть 7z-овский архив (причем
запароленый), из которого при запуске их утилиты разархивирования извлекаются
файлики, в том числе и файлы с ресурсами игры. Пароль не представляет особой сложности -
"slib_pasz" (нашел, просматривая, но не дебагингом, а глазами файлик setup_upd.exe -
та самая утилита). В итоге я сумел зайти WinRar'ом в этот архив. В нем я нашел ничего
такого, что смогло дать мне возможность открыть их код. Поэтому, задача состояла в том,
что мне самому необходимо расшифровать формат хранения ресурсов. Этим я и занялся.

Включив в WinAmp'е трэк System of a Down - Kill Rock'n'Roll, я принялся за работу.

�так, что я имею:
1. Достаточное знание C++.
2. Достаточное знакомство с различными форматами ресурсов.
3. Достаточное количество написанных программ-грабберов.
4. Файлик с ресурсами.

Это все, что мне необходимо. �так, за работу..

Сначала откроем файлик "stormex2.dll" (хранит сами ресурсы в зашифрованном виде)
и просмотрим его глазами.

Так, например, я нашел (как же не заметить такое?) в конце FAT-таблицу. Первая
структура ее, что пришла мне в голову, была следующей:

1. Размер строки с именем файла (включая каталоги) (тип: int).
2. Сама строка размером, указанным выше (тип: char []).
3. Размер самого файла (тип: int).
4. Нуль (тип: int).
5. Смещение от начала (тип: int).
6. Нуль (тип: int).

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

Перейдем к самому концу файла. В соответствии с предложенной мной структурой,
остаются лишние блоки данных размером в 24 байта. Я подумал, что это скорее всего
заголовок FAT, правда к нему надо было бы подобрать другое название =) Здесь я
предложил следующую структуру:

1. Количество файлов в FAT-таблице (тип: int).
2. Нуль (тип: int).
3. Смещение на начало FAT-таблицы от начала файла с ресурсами (тип: int).
4. Нуль (тип: int).
5. Размер FAT-таблицы (тип: int).
6. Нуль (тип: int).

Т.к. заголовок FAT расположен в конце, то читать файл нужно с конца. Следующий
этап заключается в том, является ли первый элемент - количеством файлов в
таблице. Это можно проверить, правда, погрешности в вычислении будут очень
большими. Для этого нужно взять размер FAT-таблицы и разделить его на
приблизительный размер структуры файловой информации.

Размер FAT-таблицы: 80EBh = 33003.
Приблизительный размер структуры файловой информации: 6 * sizeof (int) + ~30 = 54
Приблизительное количество файлов: 33003 / 54 = 611.

Выходит, что первый элемент не количество файлов в FAT-таблице. � тут до меня
только дошло. Я чисто случайно увидел смещение к началу ресурсов в DLL'ке. Оно
оказалось 3C00h. А это равняется как раз значению первого элемента. Значит,
вторая структура, предложенная мной, оказалось немного неправильной. Вот как
выглядит она точно:

1. Смещение на начало ресурсов (тип: int).
2. Нуль (тип: int).
3. Смещение на начало FAT-таблицы от начала файла с ресурсами (тип: int).
4. Нуль (тип: int).
5. Размер FAT-таблицы (тип: int).
6. Нуль (тип: int).

Теперь остается самое трудное - определить, каким образом шифруется содержимое
файлов в ресурсах. На этом я пока остановлюсь.

..6 мая 2006 г.


Пора вернуться к делу. Ничего нового не пришло в голову (и во сне тоже)..
Можно посчитать количество файлов в ресурсе. Для этого надо написать программку.

Через 10 мин была написана программка. Получилось, что количество файлов в
ресурсе достигает 691. Не очень много, но и не очень мало.

..7 мая 2006 г.


Ночью пришла мысль (а я прям как Кекуле из его случая с бензолом) о том, почему в
ресурсе файлики занимают менее 2 МБ? Я подумал, что применяется метод компрессии.
Осталось только проверить. Обычно компрессуют с помощью ZLib-библиотеки. Надо было
изучить DLL-ки, связанные с защитой. В "stormex2.dll" я ничего не нашел, но зато
оставался другой файлик - "stormext.dll". �... Действительно ZLib присутствовал в DLL
(это я увидел в списке используемых модулей, т.к. Delphi оставляет эту запись зачем-то).

Я уже был уверен в том, что дело близиться к завершению. Пришлось закачивать библиотеку
из �нтернета, т.к. я ее потерял у себя на винте =) Ну ладно, 400 кб никому не навредят.

Врубив в плэйлист System of a Down - Aerials, я переделал свою программку, добавил туда
метод декомпрессии, а также смастерил рекурсивную функцию для создания директорий.
Запустил...

О!.. Ура! Победа! Первый файлик "animals.c" декомпрессирован отлично. Далее пошли второй,
третий и, наконец, 691-ый. Моя мысля меня не подвела - все файлики лежали у меня в рабочей
директории. Дело, которое хотелось давно сделать, сделано. Можно закрываться.

Отправил файлик capitan_blood'у. Жду ответа.

а алексус знает?

Кроме нас никто.. Хотя сказать можно =) Какая теперь разница, скрипты то у нас =)

а они новые версие по другому перекодируют...

Вряд-ли.. Как они говорят остался один патч.. Но пока же мы не будем им говорить, ведь правда? =) Кстати, мы с тобой одного года рождения!

да, пока сохраняем тайну

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