Pull to refresh

Comments 22

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

Так там были только картинки?
95% диска — картинки, так как это просто диск с доп-материалами. были еще модели(около 5 штук примерно) и буквально пара файлов фоновой музыки в формате типа midi. но так как принцип хранения всего этого был один и тот же, и сам я все это начал именно из-за картинок, то я не стал разбирать вообще все файлы диска, вроде как технически — интересных моментов там не было, а статья и так вышла слишком большой.
Спасибо. Интересно.
Первое что бросилось в глаза — расширение файлов NPK и LPK, что косвенно указывало на то, что это архивы.

Но вот этот момент как-то непонятен.
— Скорее всего файлы достаточно тяжелые
— Файлов меньше чем предполагаемых изображений на диске
— *PK — *package — пакет данных
Вывод: это собранные в один файл данные.

NPK… N??? PK = package = упаковка и т.д.…
Плюс минус такая логика

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), даже задавал вопрос о них здесь на Хабре. И в итоге сейчас пишу сам.
Ответ, почему такого инструмента нет, может быть очень простым — в реверсе нет денег, это чисто гиковская возня для хаков, модов игр и т.д. Иначе давно бы уже нейросети воссоздавали бы исходники по бинарнику, а инструменты типа Иды имели бы интерфейсы для людей, а не для инопланетян.

Only those users with full accounts are able to leave comments. Log in, please.

Articles