История изменений

Я реверсил некоторые форматы игр, правда до3Dшной эпохи, поделюсь соображениями.

Обычно нужен только мозг и hex редактор - смотришь на байтики, мозг сам видит закономерности и повторяющиеся структуры. Видишь повторяющиеся структуры, смотришь чем они различаются, становится понятно что они есть. Для поиска различных bitmap данных (несжатые картинки, текстуры, карты высот и т.д.) помогает открыть бинарник в gimp с типом файла = raw (остаётся подобрать ширину). Можно действовать и обратно - зная данные искать их в файле (например, у юнита 2600 здоровья и 300 брони, ищем эти числа рядом, находим таблицу с типами юнитов). В DOS играх таким способом, если не было компрессии, явной обфускации или куски данных не были зашиты в код, там можно расковырять всё.

Если ресурсы игры лежат в одном файле непонятного формата, на 99% в начале его будет к-во ресурсов, а потом таблица ресурсов содержащее как минимум смещение и размер (часто также название, что сильно помогает) для каждого - пишем распаковывалку за десять минут, смотрим на отдельные файлы. Натравливаем file, strings. С неизвестными смотрим на размер: файлы одного размера это сигнал, файлы красивого размера большой степени двойки (65536, 131072, 196608) скорее всего битовые карты, т.е. текстуры, спрайты, карты высот, изображения для миникарты и т.д. (в данном случае с большой вероятностью 256x256 картинки с палитрой, 16битным либо прозрачность+палитра, RGB цветом соответственно). Не забываем про палитру, 66304 байт например это 256x256 картинка + 256*3 палитра. Бывают свои хитрые форматы*. Над неизвестными файлами начинаем медитировать начиная с самого маленького.

Если не получается, берём в руки отладчик. На первом уровне не нужно даже знать ассемблер, ставим breakpoint на DOS прерывание чтения файла (а можно ещё проще, запустить dosbox под ktrace или systrace (или как там это в linux)), и смотрим какого размера блоки читаются → уже имеем представление о структуре файла. На самый крайний случай оставляем дизассемблер - я лично им реверсил только алгоритмы декомпрессии.

Насчёт более поздних игр (windows и cdrom эпоха) могу сказать что байты экономить перестали, зато стали экономить время разработчиков, поэтому форматы упростились - с большой вероятностью можно встретить широко известные форматы (tga, bmp, gif для текстур, wav, pcm и всякие древние кодеки, file о них знает а mplayer даже играет, zlib и zip компрессия, plaintext и т.д.). Не имел дела с 3D, нужно вспомнить какие в то время были популярны форматы для моделей и анимации - что-нибудь типа формата из первокваки который изучен вдоль и поперёк. Если формат моделей свой, берём hex редактор, и вперёд - для статичных моделей ничего принципиально нового изобрести нельзя, будет что-то типа: [число вершин][x y z]{* число вершин}[число треугольников][n1 n2 n3]{* число треугольников}, координаты скорее всего во float, вариации включают формат вершины - x y z, x y z w, наличие нормали, текстурных координат и т.д. Как хранят анимацию честно говоря не знаю - наверное набор вершин множится для каждого keyframe + данные о последовательности keyframe и таймингах.

Ещё можешь посмотреть http://rewiki.regengedanken.de/wiki/Main_Page - там примеры форматов игр, возможно какая-нибудь документация и ссылки на инструменты.

Если разберёшь формат, напиши лучше сначала библиотеку для его разбора - будет чище, проще, и если ты не осилишь последователям будет откуда продолжить. За совет Unity или Unreal я бы в лицо плюнул, естественно нужно брать свободный движок (ogre/irrlicht/osg например, см. openmw) - ремейк хорошей игры обязан быть полностью свободным, а проприетарный крап ничем не лучше оригинального глюкалова в dosbox или wine.

* Так просто в качестве примера, в commandos текстуры хранились интересно. Точно правда уже не помню. Цвет хранился в несжатом виде, 1байт/пиксель + палитра, а прозрачность, которой было всего 3 уровня (прозрачно/непрозрачно/полупрозрачно) была RLE сжата, и всё это было перемешано. Типа [непрозначно * 3 пикселя][цвет][цвет][цвет][полупрозрачно * 2 пикселя][цвет][цвет][прозрачно * 3 пикселя](для прозрачных цвет не хранился)х[непрозрачно * 3 пикселя][цвет][цвет][цвет] и т.д. Чтобы понять это тоже было достаточно помедитировать в hex редактор.

Я реверсил некоторые форматы игр, правда до3Dшной эпохи, поделюсь соображениями.

Обычно нужен только мозг и hex редактор - смотришь на байтики, мозг сам видит закономерности и повторяющиеся структуры. Видишь повторяющиеся структуры, смотришь чем они различаются, становится понятно что они есть. Для поиска различных bitmap данных (несжатые картинки, текстуры, карты высот и т.д.) помогает открыть бинарник в gimp с типом файла = raw (остаётся подобрать ширину). Можно действовать и обратно - зная данные искать их в файле (например, у юнита 2600 здоровья и 300 брони, ищем эти числа рядом, находим таблицу с типами юнитов). В DOS играх таким способом, если не было компрессии, явной обфускации или куски данных не были зашиты в код, там можно расковырять всё.

Если ресурсы игры лежат в одном файле непонятного формата, на 99% в начале его будет к-во ресурсов, а потом таблица ресурсов содержащее как минимум смещение и размер (часто также название, что сильно помогает) для каждого - пишем распаковывалку за десять минут, смотрим на отдельные файлы. Натравливаем file, strings. С неизвестными смотрим на размер: файлы одного размера это сигнал, файлы красивого размера большой степени двойки (65536, 131072, 196608) скорее всего битовые карты, т.е. текстуры, спрайты, карты высот, изображения для миникарты и т.д. (в данном случае с большой вероятностью 256x256 картинки с палитрой, 16битным либо прозрачность+палитра, RGB цветом соответственно). Не забываем про палитру, 66304 байт например это 256x256 картинка + 256*3 палитра. Бывают свои хитрые форматы*. Над неизвестными файлами начинаем медитировать начиная с самого маленького.

Если не получается, берём в руки отладчик. На первом уровне не нужно даже знать ассемблер, ставим breakpoint на DOS прерывание чтения файла (а можно ещё проще, запустить dosbox под ktrace или systrace (или как там это в linux)), и смотрим какого размера блоки читаются → уже имеем представление о структуре файла. На самый крайний случай оставляем дизассемблер - я лично им реверсил только алгоритмы декомпрессии.

Насчёт более поздних игр (windows и cdrom эпоха) могу сказать что байты экономить перестали, зато стали экономить время разработчиков, поэтому форматы упростились - с большой вероятностью можно встретить широко известные форматы (tga, bmp, gif для текстур, wav, pcm и всякие древние кодеки, file о них знает а mplayer даже играет, zlib и zip компрессия, plaintext и т.д.). Не имел дела с 3D, нужно вспомнить какие в то время были популярны форматы для моделей и анимации - что-нибудь типа формата из первокваки который изучен вдоль и поперёк. Если формат моделей свой, берём hex редактор, и вперёд - для статичных моделей ничего принципиально нового изобрести нельзя, будет что-то типа: [число вершин][x y z]{* число вершин}[число треугольников][n1 n2 n3]{* число треугольников}, координаты скорее всего во float, вариации включают формат вершины - x y z, x y z w, наличие нормали, текстурных координат и т.д. Как хранят анимацию честно говоря не знаю - наверное набор вершин множится для каждого keyframe + данные о последовательности keyframe и таймингах.

Ещё можешь посмотреть http://rewiki.regengedanken.de/wiki/Main_Page - там примеры форматов игр, возможно какая-нибудь документация и ссылки на инструменты.

Если разберёшь формат, напиши лучше сначала библиотеку для его разбора - будет чище, проще, и если ты не осилишь последователям будет откуда продолжить. За совет Unity или Unreal я бы в лицо плюнул, естественно нужно брать свободный движок (ogre/irrlicht/osg например, см. openmw) - ремейк хорошей игры обязан быть полностью свободным, а проприетарный крап ничем не лучше оригинального глюкалова в dosbox или wine.

* Так просто в качестве примера, в commandos текстуры хранились интересно. Точно правда уже не помню. Цвет хранился в несжатом виде, 1байт/пиксель + палитра, а прозрачность, которой было всего 3 уровня (прозрачно/непрозрачно/полупрозрачно) была RLE сжата, и всё это было перемешано. Типа [непрозначно * 3 пикселя][цвет][цвет][цвет][полупрозрачно * 2 пикселя][цвет][цвет][прозрачно * 3 пикселя](для прозрачных цвет не хранился)х[непрозрачно * 3 пикселя][цвет][цвет][цвет] и т.д.

Я реверсил некоторые форматы игр, правда до3Dшной эпохи, поделюсь соображениями.

Обычно нужен только мозг и hex редактор - смотришь на байтики, мозг сам видит закономерности и повторяющиеся структуры. Видишь повторяющиеся структуры, смотришь чем они различаются, становится понятно что они есть. Для поиска различных bitmap данных (несжатые картинки, текстуры, карты высот и т.д.) помогает открыть бинарник в gimp с типом файла = raw (остаётся подобрать ширину). Можно действовать и обратно - зная данные искать их в файле (например, у юнита 2600 здоровья и 300 брони, ищем эти числа рядом, находим таблицу с типами юнитов). В DOS играх таким способом, если не было компрессии, явной обфускации или куски данных не были зашиты в код, там можно расковырять всё.

Если ресурсы игры лежат в одном файле непонятного формата, на 99% в начале его будет к-во ресурсов, а потом таблица ресурсов содержащее как минимум смещение и размер (часто также название, что сильно помогает) для каждого - пишем распаковывалку за десять минут, смотрим на отдельные файлы. Натравливаем file, strings. С неизвестными смотрим на размер: файлы одного размера это сигнал, файлы красивого размера большой степени двойки (65536, 131072, 196608) скорее всего битовые карты, т.е. текстуры, спрайты, карты высот, изображения для миникарты и т.д. (в данном случае с большой вероятностью 256x256 картинки с палитрой, 16битным либо прозрачность+палитра, RGB цветом соответственно). Не забываем про палитру, 66304 байт например это 256x256 картинка + 256*3 палитра. Бывают свои хитрые форматы*. Над неизвестными файлами начинаем медитировать начиная с самого маленького.

Если не получается, берём в руки отладчик. На первом уровне не нужно даже знать ассемблер, ставим breakpoint на DOS прерывание чтения файла (а можно ещё проще, запустить dosbox под ktrace или systrace (или как там это в linux)), и смотрим какого размера блоки читаются → уже имеем представление о структуре файла. На самый крайний случай оставляем дизассемблер - я лично им реверсил только алгоритмы декомпрессии.

Насчёт более поздних игр (windows и cdrom эпоха) могу сказать что байты экономить перестали, зато стали экономить время разработчиков, поэтому форматы упростились - с большой вероятностью можно встретить широко известные форматы (tga, bmp, gif для текстур, wav, pcm и всякие древние кодеки, file о них знает а mplayer даже играет, zlib и zip компрессия, plaintext и т.д.). Не имел дела с 3D, нужно вспомнить какие в то время были популярны форматы для моделей и анимации - что-нибудь типа формата из первокваки который изучен вдоль и поперёк. Если формат моделей свой, берём hex редактор, и вперёд - для статичных моделей ничего принципиально нового изобрести нельзя, будет что-то типа: [число вершин][x y z]{* число вершин}[число треугольников][n1 n2 n3]{* число треугольников}, координаты скорее всего во float, вариации включают формат вершины - x y z, x y z w, наличие нормали, текстурных координат и т.д. Как хранят анимацию честно говоря не знаю - наверное набор вершин множится для каждого keyframe + данные о последовательности keyframe и таймингах.

Ещё можешь посмотреть http://rewiki.regengedanken.de/wiki/Main_Page - там примеры форматов игр, возможно какая-нибудь документация и ссылки на инструменты.

Если разберёшь формат, напиши лучше сначала библиотеку для его разбора - будет чище, проще, и если ты не осилишь последователям будет откуда продолжить. За совет Unity или Unreal я бы в лицо плюнул, естественно нужно брать свободный движок (ogre/irrlicht/osg например, см. openmw) - ремейк хорошей игры обязан быть полностью свободным, а проприетарный крап ничем не лучше оригинального глюкалова в dosbox или wine.

* Так просто в качестве прима, в commandos текстуры хранились интересно. Точно правда уже не помню. Цвет хранился в несжатом виде, 1байт/пиксель + палитра, а прозрачность, которой было всего 3 уровня (прозрачно/непрозрачно/полупрозрачно) была RLE сжата, и всё это было перемешано. Типа [непрозначно * 3 пикселя][цвет][цвет][цвет][полупрозрачно * 2 пикселя][цвет][цвет][прозрачно * 3 пикселя](для прозрачных цвет не хранился)х[непрозрачно * 3 пикселя][цвет][цвет][цвет] и т.д.