Comments 22
PS. Хотелось бы в конце статьи ссылки на источники с форматами и прочим.
изучить его контент напрямую
Так там были только картинки?
Первое что бросилось в глаза — расширение файлов NPK и LPK, что косвенно указывало на то, что это архивы.
Но вот этот момент как-то непонятен.
— Файлов меньше чем предполагаемых изображений на диске
— *PK — *package — пакет данных
Вывод: это собранные в один файл данные.
NPK… N??? PK = package = упаковка и т.д.…
Плюс минус такая логика
Также файлы с ресами у многих игр имеют похожие расширения. Например .mpq у близзардовских.
можно было исключить сразу всякие zip-related и прочие методы имеющие какие-то стандартные заголовки, так как ничего похожего на заголовок у сжатых данных не наблюдалось.
Встретились мне как-то обычные zip-файлы, но заголовки были оторваны и хранились скопом в отдельном файле. К счастью, это было на PC, и хитрецы не додумались спрятать unzip.dll, которая валялась в папке с приложением и наводила на определённые мысли.
Спасибо за статью!!!
Очень удобно для подобного анализа использовать kaitai.io
Помимо декларативного интерфейса поддерживает быстрое создание врапперров.
Плюс есть достаточное примеров.
Очень интересная статья, к сожалению, жаль, что как правило все такие статьи какие-то безсистемные и, не в обиду вам будет сказано, все как под копирку. "Открыл в HEX-редакторе, на глаз прикинул, что вот эта пара байт — длина, а здесь — смещение, поискал выбранную словно наугад последовательность байт в файле..." Я все жду, когда же наконец появится инструмент, или у кого-нибудь хотя бы идея, делать эти изыскания автоматически.
Например, как вы поняли, что в начале именно 4 + 2 + 2 + ...
байт? Почему не 2 + 2 + 4 + ...
? Или 8 + ...
? Или...? Ведь были же какие-то предпосылки, что разбор структуры файла начался именно с этих предположений. Затем вы искали какие-то общие части файла, по каким-то определенным смещениям (0x0400, 0x0800 и т.п.), догадались поискать паттерны (DF 10 00 00 00 09), причем определенного вида и определенный длины. Вам повезло, что формат оказался довольно простым и не зашифрованным.
Представьте, что появится инструмент, который проверит не один паттерн, выбранный на глаз, а с помощью алгоритма найдет, что нужно искать, где искать, и разметит структуру. Даже просто найти в файле блоки в виде "смещение + длина + данные" уже может упростить работу во многих случаях. Непонятно, почему ни один реверсер об этом еще не задумывался, или хотя бы не озвучивал в статьях такие мысли.
Мне кажется, это все можно автоматизировать, но вероятно тут нужен специалист по анализу данных/машинному обучению.
ну наверное да, вы правы, всегда сложно найти баланс между совсем уж детальным разжевыванием в стиле "как я понял что FF - это 255" и совсем кратким резюме "ну я тут открыл файл, понял что это не совсем стандартное LZSS , вот короче код для распаковки"
что до 4 + 2 + 2
то исторически в бинарных файлах числа записываются в кодировке Little Endian, т.е задом наперед
а самый типичная переменная для чисел - Integer, она занимает 4 байта и ее обычно хватает даже сейчас, и уж точно хватало в те годы.
чтобы было проще опишу на примере десятичных чисел.
у нас каждое число должно записываться 4 символами(байтами)
т.е 1 - это будет 0001
122 будет 0122
и так далее
при этом в бинарных данных при обратной записи это будет выглядеть как 1000 и 2210.
а сейчас представьте что вы открываете файл который выглядит как просто дикое нагромождение беспорядочного кода (так как применено сжатие)
т.е он выглядит вот так 82468762471641829764917846873264783216487632147386439812764
и вот посреди этой белиберды вы видите последовательность 100020004000
сразу первое что приходит в голову - это числа записанные в формате int
Я-то это понимаю, и думаю, многие понимают интуитивно. Вопрос, почему ни у кого, профессионально занимающегося реверс-инжирингом, не возникает мыслей как-то формализовать эти знания и описать принципы, которыми могли бы руководствоваться автоматические системы.
Скажем, очевидный пример — автоматически найти в файле повторяющиеся блоки данных и место, где хранится количество этих блоков (с учетом того, что количество для блока фиксированного размера может быть как записано явно — count
, так и в виде общего размера всех блоков — count * size_block
, а может в виде двух смещений, начала и конца?). Это конечно увлекательно читать, как автору приходит озарение, что вот эти 2/4 байта похожи на длину/количество, но гораздо интереснее было бы написать инструмент, сам ищущий эти закономерности в любом файле. Потому что такие поиски описываются чуть ли не в каждой статье по реверс-анализу незнакомого формата, и просто жалко видеть, как люди теряют часы, а то и дни, пытаясь угадать, где что лежит.
я бы хотел сервис по автоматизации написания статей, а то нервов и времени на статью уходит в разы больше, чем на реверс-инжиниринг, который в ней описан :)
Когда у кого-то "приходит мысль" - он пишет книгу и продает её. И сам становится классиком по теме. Вопрос только может ли он на этом заработать настолько чтобы это мотивировало на написание книги.
Я как реверсер тоже быстро дошёл до вопроса об автоматизации. Тоже удивился, что нет инструментов (из близкого — BinWalk), даже задавал вопрос о них здесь на Хабре. И в итоге сейчас пишу сам.
Ответ, почему такого инструмента нет, может быть очень простым — в реверсе нет денег, это чисто гиковская возня для хаков, модов игр и т.д. Иначе давно бы уже нейросети воссоздавали бы исходники по бинарнику, а инструменты типа Иды имели бы интерфейсы для людей, а не для инопланетян.
Как у меня получилось взломать и распаковать ресурсы старой игры для PSX