Перейти к содержимому


Внимание!

Это форум по извлечению ресурсов из игр: музыки, звуков, текстур, 3D-моделей...
Перед поиском ответов на форуме, рекомендуется ознакомиться с основным сайтом EXTRACTOR.ru!
[ Прочтите внимательно - правила создания тем и ответа в них ]
Все вопросы по запуску игр задавайте в другом месте: Установка и запуск игр.


Фотография

Поставьте на путь истинный


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 10

#1 dragon-gor

dragon-gor

    Младший сержант

  • Пользователи
  • 13 сообщений

Отправлено 19 August 2007 - 17:35

Я не ламер.
Есть опыт с русной расспаковкой РЕ файлов, крякинге, не много знание АСМ`а.

Только не могу понять, как распаковываются игровые рессурсы.
Через HEX могу узнать насширение файла, вот тут и стопор.
Пользуюсь Олькой, снимаю дамп, только вот проюлема, она заточена на exe, dll, bin.
Какиму примудростями ВЫ пользуетесь?
Если не жалко - поделитесь, а лучше в портале появильсь бы хоть какие нибуть туторы.
Обратился с такой прозьбой на zoneofgames, так они меня просто послали (прежде это делать, я думаю, нужно узнать что человек умеет делать, а не сразу посылать на х...).
Если есть какие - нибуть туторы (жимательно свежие), я искреннее был бы благодарен.

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

Честно сказать, я не знал где создать топик, не ругайте - если что не так!!! huh.gif

#2 [email protected]=-

[email protected]=-

    Полковник

  • Администраторы
  • 964 сообщений
  • Пол:Мужчина

Отправлено 19 August 2007 - 22:43

dragon-gor!
Писал, правда как-то давно, такой вот мануал.

BTW, если тебе на zoneofgames, даже какую-нибудь ссылку почитать не дали, а сразу послали - значит они просто пижоны. ИМХО.

В общем, этому научить сложно, если не сказать, невозможно. (*улыбается*)
Просто интуиция.

Обычно, алгоритм такой:

1) Берётся файл-архив, например archive.dat

2) Открывается каким-нибудь HEX-редактором

3) Смотрится его начало - если там есть что-то похожее на имена файлов - значит это FAT (File Allocation Table - таблица размещения файлов) архива.
Если в начале FAT'а нет - смотрим конец файла. Если и там нет - смотрим какой-нибудь файл в том же каталоге, например, с именем archive.<b>dir</b>, если и его нет - значит файл-архив зашифрован либо в нём хранятся только хэши (современные игры, типа Tomb Raider: Legend) от имён файлов, соответственно, будут проблемы. Иногда FAT хранится в .EXE файле (редко - в основном видел только в старых играх).

4) После этого смотришь сколько байт между двумя именами файлов.
Считаешь их количество. Обычно там должно быть:
- если файл записан как ASCIIZ, то там в конце будет \0 после имени файла, иногда под имя файлы резервируеться жёсткое количество байт (Doom - .WAD / Quake I & II, Half-Life I - .PAK)
- смещение начала файла от начала archive.dat (т.е. где файл начинается)
- размер файла (может не храниться, а только смещение: Syberia II - .SYB архивы)
- может быть ещё какая-нибудь информация (дата и время создания файла - .ASF от Silent Hill 2 и ещё где пары игр), флаг, отвечающий за использование сжатия и шифрования (.DAT в Resident Evil 3), CRC32 сумма может храниться и т.д. - короче, что только разработчикам в голову придёт

Важно: поля могут идти В ЛЮБОМ порядке (см. след. пункт).

5) После обнаружения FAT, обычно, нужно определить только три вещи:
- количество файлов (обычно оно предшествует FAT'у)

А для каждого файла в отдельности:
- имя файла
- размер этого файла
и/или
- смещение этого файла от начала archive.dat (т.е. где файл начинается)
(смещение может выравниваться - Resident Evil 3 - т.е. прочитанное смещение нужно выравнять, умножив на, скажем, 32 - т.е. каждый новый файл начинается с границы кратной 32-ум байтам) Ещё смещение может быть абсолютным - отсносительно начала архива archive.dat и относительным - относительно начала заголовка (тогда чтобы получить абсолютное смещение, нужно к смещению прибавить размер заголовка)

Если известно только смещение или только размер - то вторую величину придётся высчитывать вручную. Думаю, это не особенно сложно.
а) В случае если известен только размер файла, то тупо после FAT / заголовка обычно следует первый файл архива. Значит следующий будет начинаться с:
размер_заголовка + сумма(размеров всех файлов, что шли до него)
!!!ЭТО РАБОТАЕТ ТОЛЬКО ТОГДА, КОГДА НЕТ ВЫРАВНИВАНИЯ!!!
б) В случае, если известно только смещение, то тут размер файла получается как:
смещение_второго - смещение_первого
Для получения размера последнего файла отнимается от размера всего файла archive.dat.

Чтобы узнать, какое из обнаруженных полей отвечает за размер/смещение:
1) Обычно размер и смещение идут подряд
2) Обычно размер и смещение 4 байта каждое (DWORD / Long тип)
3) Что отвечает за смещение, а что за размер - очень просто узнать - берутся подозрительные 4 байта, считаются как число (не забываем их развернуть в зависимости о Little Endian / Big Endian формата). Пока что обозначим эти два числа как long1 и long2.
4) Теперь, что делаем - смещаемся на long1 - там должно быть начало файла, если его там нет, то пробуем сместиться на long2 - если и там нет, то в обоих смещениях осматриваем окрестности - если заголовок где-то недалеко, то, значит, смещение было относительное - осталось выяснить "относительно" чего (обычно заголовка архива archive.dat).
5) Теперь, пусть у нас long2 - это было смещение. Тогда величина long2+long1 - должна указывать на начала следующего файла за тем, который начинался с long2 (или на конец файла (что одно и то же), если файлы выравнены). То что long1 - не размер можно сразу определить, если это число больше размера архива archive.dat в целом.
Очень удобно искать смещение, если в архиве файлы не пожаты и известного формата - например все .WAV начинаются на 'RIFF' так что найти где начинается первый файл и второй - не составит особого труда.

Остальные поля заголовка (типа сигнатрура, размер архива, количество файлов и т.д.) - находятся методом "тыка" - т.е. просто тупо парсишь все файлы из FAT'а, пока они не кончатся (т.е. не пойдёт "мусор" - данные первого файла) и считаешь их количество. После этого ищешь в FAT'е или заголовке поле, где записан этот номер - это и есть количество файлов. Иногда, может указываться размер поля с FAT, но не количество файлов. Если так, и <i>записи фиксированной длинны</i>, то количество получить просто:
TotalFiles:=SizeOf(FAT) Div SizeOf(SingleFATRecored);
для Си:
TotalFiles = sizeof(FAT) / sizeof(SingleFATRecord);

Обычно размер хранится только для ASCIIZ строк-имён (Earth 2140 - .WD), тогда там где-то должна быть ещё таблица смещений на начала этих строк.

Вообще, изучи вот это: Xentax Wiki GRAFs
Там много описаний форматов к разным играм. Просто посмотри, как другие форматы устроены - тогда сразу сам будешь при раскопке прикидывать что да как (правда, там некоторые форматы некорректно описаны - могут быть ошибки, так что аккуратней если надумаешь писать распаковщик).

Здесь я, естественно, описал далеко не всё, а только самое основное.
Остальное - придёт с опытом.

Удачи.

#3 ghoul

ghoul

    Старший сержант

  • Пользователи
  • 45 сообщений

Отправлено 19 August 2007 - 22:44

койкакие статьи на сайте сетаки есть: http://extractor.ru/texts.phtml#1

а так вообще хватит и начального курса информатики, в частности "представление данных в ЭВМ" wink.gif

соответственно умение видеть в хекс-редакторе эти данные..

знание языков и умение писать программы выдирающие эти данные (не копировать жэ их из редактора!?)

ну думаю ты всетаки знаеш как хранятся числа (1- 2- 3- 4-х байтные), что такое Big и Little Endian, а так жэ как хранятся компаненты цветов RGB в виде чисел (это я к тому если задумаеш графику ковырять)

ну для начала попробуй разобрать .bmp формат..
открой картанку в любом редакторе и попробуй найти в файле(в хекс редакторе) числа отвечающие за ширину, высоту, количество так называемых "байтов на пиксель" и вообще посмотри что там есть..

удачги ! smile.gif

#4 dragon-gor

dragon-gor

    Младший сержант

  • Пользователи
  • 13 сообщений

Отправлено 20 August 2007 - 17:52

Вот спасибо!!!
А то они говорят HEX в крайнем случае (zoneofgames). Я просто ковырял сталкера в хексе и не парился с распаковкой.

Почитаю статейки, думаю вопросы будут smile.gif .

Ещё раз спасибо за отзыв!!! biggrin.gif

#5 dragon-gor

dragon-gor

    Младший сержант

  • Пользователи
  • 13 сообщений

Отправлено 26 August 2007 - 16:56

Сейчас скачиваю статьи с вашего сайта.
Вот появился вопрос:
Есть файл, архив med. Под хексом видно - файл Wav формата.
Из крякинга я представляю, что нудно найти начальную точку файла, снять дам и все будет ОК. Только, что то не получается. Может у меня другое представление вещей? Просто я взял расмотрел файлы НЕ ЗАПАКОВАННЫЕ и запакованные. Бывает много липы. В данном случае распаковываю музыку с L.A.Rush. В роде все просто, но дамп не пашет. Может не так снимаю? А вообще через Хекс дампы пашут (ладно там с олькой все понятно)? ИЛИ МНЕ ЧИТАТЬ СТАТЬИ? Правдо таких игрух нет, чтоб практиковаться sad.gif

#6 dragon-gor

dragon-gor

    Младший сержант

  • Пользователи
  • 13 сообщений

Отправлено 28 August 2007 - 17:25

В начале идет сигнатура RIFF (Microsoft), что подтвердил GAP. Дальше размер файла, расшерение, смещение. Только вот даже при извлечении GAP`ом файл не проигрывается. Что нужно сделать?
Да, если снять дамп в WinHex - работать он будет? С Олькой так, загружаешь файл в ольку, смотришь где начинается ОЕР программы, ставишь бряк, запускаешь прогу, снимаешь дамп, импреком его прикручиваешь. Но это к РЕ файлам. Здесь что то подобное можно сделать, чтоб не писать паспаковщик?

#7 [email protected]=-

[email protected]=-

    Полковник

  • Администраторы
  • 964 сообщений
  • Пол:Мужчина

Отправлено 29 August 2007 - 03:41

dragon-gor!
RIFF - это контейнер. Т.е. там может, теоретически, храниться файл любого формата сжатый любым кодеком. Дамп памяти тебе, скорее всего, не поможет, потому что игра декодирует музыку блоками и тут же шлёт на звуковую карту.

#8 dragon-gor

dragon-gor

    Младший сержант

  • Пользователи
  • 13 сообщений

Отправлено 29 August 2007 - 12:36

Полная труба!!!
Посоветовали поэксперемтировать с BMP, чесно скалать, лажа какая то у меня получается. Размеры картинки так и не нашел sad.gif
Даже взял существующий размер - перевел в НЕХ и поиском не нашел. По символике видно (вроде) где начало, но начало ли это? Статьи с сайта скачал, вот только проблема, уже 30, бейсик 17 лет назад знал (zx-spectrum), ASM знаю в ряде крякинга (где занопить, где собрать с/н, где джамп роменять, распаковать), но так ьакового программенга НЕТ, особенно в WinAPI. Вот и задаю такие вопросы. Мож, если не трудно, потренингуете, задание, а я вам буду писать мои действия huh.gif

#9 [email protected]@f

[email protected]@f

    Ефрейтор

  • Пользователи
  • 8 сообщений

Отправлено 13 July 2010 - 17:23

На самом деле в BMP ничего такого нет laugh.gif
Bitmap он на то и bitmap, что матрица цветов. Попробуй сделать рисунок в 1 пиксель и закрасить каким-нибудь цветом - вот это и будет матрица одного цвета. А их количество зависит от размеров рисунка) Которые задаются исключительно количеством рядов/столбцов в основной матрице wink.gif

#10 TEKTON

TEKTON

    Рядовой

  • Пользователи
  • 2 сообщений

Отправлено 28 July 2011 - 20:02

Такой вопрос.

А можно как нибудь в отладчике перехватить момент, когда при загрузке игры все ресурсы уже распаковались в память и сбросить их на диск?

На какие API следует обратить внимание ? ;)

Вот в отладчике обнаружил такие:

d3dx9_28.D3DXCreateTextureFromFileExA
d3dx9_28.D3DXCreateTextureFromFileExW
d3dx9_28.D3DXCreateTextureFromResourceExA
d3dx9_28.D3DXCreateTextureFromResourceExW
d3dx9_28.D3DXCreateTextureFromFileInMemoryEx
не знаю, правильно ли я на них обратил внимание или нет? :rolleyes:

Они лежат в d3dx9_28.dll рядом с exe главным.
Как вообще происходит загрузка ресурсов в игру ? ;)
Можно краткими тезисами обозначить принцип ? ;)

P.S. То есть я к чему клоню:
Если игра распаковывает ресурсы для игры (простите за тавтологию :P ),
Значит в основном файле игры есть распаковщик который эти ресурсы распаковывает.
Так почему не воспользоваться уже готовым решением ?
Только проблема в том, как узнать момент когда ресурсы распаковались!
Короче сделать типа лоадера-распаковщика.

Сообщение отредактировал TEKTON: 28 July 2011 - 20:25


#11 [email protected]=-

[email protected]=-

    Полковник

  • Администраторы
  • 964 сообщений
  • Пол:Мужчина

Отправлено 31 July 2011 - 04:11

d3dx9_28.dll - это библиотека 9-го DirectX и к игре она не имеет никакого отношения (игра её использует разве что).

Я не работал с DirectX, так что не могу что-то конкретное посоветовать - только общие вещи.

Судя по названиями функций (моё предположение):
d3dx9_28.D3DXCreateTextureFromFileExA и d3dx9_28.D3DXCreateTextureFromFileExW - грузят текстуры из файла
d3dx9_28.D3DXCreateTextureFromResourceExA, d3dx9_28.D3DXCreateTextureFromResourceExW - из ресурсов PE-файлов
d3dx9_28.D3DXCreateTextureFromFileInMemoryEx - из памяти

В первых двух функциях нужно просто перехватывать к каким файлам они обращаются - это и есть текстуры.
Со второй группой всё сложнее - это надо через какой-нибудь Resource Editor рыться в ресурсах .EXE или .DLL файлов.
Наконец, третья грузит текстуру из памяти, т.е. где-то должно быть место, куда она распаковывается из игровых ресурсов.
Тут только проблема в том, что грузиться текстуры могут в видеопамять (откуда их потом сложно достать), а буфер для распаковки временный - т.е. после загрузки текстуры он уничтожается или перезаписывается следующей текстурой, так что нельзя будет дождаться загрузки игры и потом всё из памяти вытащить, т.к. в памяти к этому моменту уже ничего не будет.