Поставьте на путь истинный
Автор
dragon-gor
, Aug 19 2007 17:35
Сообщений в теме: 10
#1
Отправлено 19 August 2007 - 17:35
Я не ламер.
Есть опыт с русной расспаковкой РЕ файлов, крякинге, не много знание АСМ`а.
Только не могу понять, как распаковываются игровые рессурсы.
Через HEX могу узнать насширение файла, вот тут и стопор.
Пользуюсь Олькой, снимаю дамп, только вот проюлема, она заточена на exe, dll, bin.
Какиму примудростями ВЫ пользуетесь?
Если не жалко - поделитесь, а лучше в портале появильсь бы хоть какие нибуть туторы.
Обратился с такой прозьбой на zoneofgames, так они меня просто послали (прежде это делать, я думаю, нужно узнать что человек умеет делать, а не сразу посылать на х...).
Если есть какие - нибуть туторы (жимательно свежие), я искреннее был бы благодарен.
Может я и буду полезен вам и в плане защиты ПО от любопытных, которые любят ковырять в чужих патчах и расспаковщиках.
Честно сказать, я не знал где создать топик, не ругайте - если что не так!!!
Есть опыт с русной расспаковкой РЕ файлов, крякинге, не много знание АСМ`а.
Только не могу понять, как распаковываются игровые рессурсы.
Через HEX могу узнать насширение файла, вот тут и стопор.
Пользуюсь Олькой, снимаю дамп, только вот проюлема, она заточена на exe, dll, bin.
Какиму примудростями ВЫ пользуетесь?
Если не жалко - поделитесь, а лучше в портале появильсь бы хоть какие нибуть туторы.
Обратился с такой прозьбой на zoneofgames, так они меня просто послали (прежде это делать, я думаю, нужно узнать что человек умеет делать, а не сразу посылать на х...).
Если есть какие - нибуть туторы (жимательно свежие), я искреннее был бы благодарен.
Может я и буду полезен вам и в плане защиты ПО от любопытных, которые любят ковырять в чужих патчах и расспаковщиках.
Честно сказать, я не знал где создать топик, не ругайте - если что не так!!!
#2
Отправлено 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
Там много описаний форматов к разным играм. Просто посмотри, как другие форматы устроены - тогда сразу сам будешь при раскопке прикидывать что да как (правда, там некоторые форматы некорректно описаны - могут быть ошибки, так что аккуратней если надумаешь писать распаковщик).
Здесь я, естественно, описал далеко не всё, а только самое основное.
Остальное - придёт с опытом.
Удачи.
Писал, правда как-то давно, такой вот мануал.
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
Отправлено 19 August 2007 - 22:44
койкакие статьи на сайте сетаки есть: http://extractor.ru/texts.phtml#1
а так вообще хватит и начального курса информатики, в частности "представление данных в ЭВМ"
соответственно умение видеть в хекс-редакторе эти данные..
знание языков и умение писать программы выдирающие эти данные (не копировать жэ их из редактора!?)
ну думаю ты всетаки знаеш как хранятся числа (1- 2- 3- 4-х байтные), что такое Big и Little Endian, а так жэ как хранятся компаненты цветов RGB в виде чисел (это я к тому если задумаеш графику ковырять)
ну для начала попробуй разобрать .bmp формат..
открой картанку в любом редакторе и попробуй найти в файле(в хекс редакторе) числа отвечающие за ширину, высоту, количество так называемых "байтов на пиксель" и вообще посмотри что там есть..
удачги !
а так вообще хватит и начального курса информатики, в частности "представление данных в ЭВМ"
соответственно умение видеть в хекс-редакторе эти данные..
знание языков и умение писать программы выдирающие эти данные (не копировать жэ их из редактора!?)
ну думаю ты всетаки знаеш как хранятся числа (1- 2- 3- 4-х байтные), что такое Big и Little Endian, а так жэ как хранятся компаненты цветов RGB в виде чисел (это я к тому если задумаеш графику ковырять)
ну для начала попробуй разобрать .bmp формат..
открой картанку в любом редакторе и попробуй найти в файле(в хекс редакторе) числа отвечающие за ширину, высоту, количество так называемых "байтов на пиксель" и вообще посмотри что там есть..
удачги !
#4
Отправлено 20 August 2007 - 17:52
Вот спасибо!!!
А то они говорят HEX в крайнем случае (zoneofgames). Я просто ковырял сталкера в хексе и не парился с распаковкой.
Почитаю статейки, думаю вопросы будут .
Ещё раз спасибо за отзыв!!!
А то они говорят HEX в крайнем случае (zoneofgames). Я просто ковырял сталкера в хексе и не парился с распаковкой.
Почитаю статейки, думаю вопросы будут .
Ещё раз спасибо за отзыв!!!
#5
Отправлено 26 August 2007 - 16:56
Сейчас скачиваю статьи с вашего сайта.
Вот появился вопрос:
Есть файл, архив med. Под хексом видно - файл Wav формата.
Из крякинга я представляю, что нудно найти начальную точку файла, снять дам и все будет ОК. Только, что то не получается. Может у меня другое представление вещей? Просто я взял расмотрел файлы НЕ ЗАПАКОВАННЫЕ и запакованные. Бывает много липы. В данном случае распаковываю музыку с L.A.Rush. В роде все просто, но дамп не пашет. Может не так снимаю? А вообще через Хекс дампы пашут (ладно там с олькой все понятно)? ИЛИ МНЕ ЧИТАТЬ СТАТЬИ? Правдо таких игрух нет, чтоб практиковаться
Вот появился вопрос:
Есть файл, архив med. Под хексом видно - файл Wav формата.
Из крякинга я представляю, что нудно найти начальную точку файла, снять дам и все будет ОК. Только, что то не получается. Может у меня другое представление вещей? Просто я взял расмотрел файлы НЕ ЗАПАКОВАННЫЕ и запакованные. Бывает много липы. В данном случае распаковываю музыку с L.A.Rush. В роде все просто, но дамп не пашет. Может не так снимаю? А вообще через Хекс дампы пашут (ладно там с олькой все понятно)? ИЛИ МНЕ ЧИТАТЬ СТАТЬИ? Правдо таких игрух нет, чтоб практиковаться
#6
Отправлено 28 August 2007 - 17:25
В начале идет сигнатура RIFF (Microsoft), что подтвердил GAP. Дальше размер файла, расшерение, смещение. Только вот даже при извлечении GAP`ом файл не проигрывается. Что нужно сделать?
Да, если снять дамп в WinHex - работать он будет? С Олькой так, загружаешь файл в ольку, смотришь где начинается ОЕР программы, ставишь бряк, запускаешь прогу, снимаешь дамп, импреком его прикручиваешь. Но это к РЕ файлам. Здесь что то подобное можно сделать, чтоб не писать паспаковщик?
Да, если снять дамп в WinHex - работать он будет? С Олькой так, загружаешь файл в ольку, смотришь где начинается ОЕР программы, ставишь бряк, запускаешь прогу, снимаешь дамп, импреком его прикручиваешь. Но это к РЕ файлам. Здесь что то подобное можно сделать, чтоб не писать паспаковщик?
#7
Отправлено 29 August 2007 - 03:41
dragon-gor!
RIFF - это контейнер. Т.е. там может, теоретически, храниться файл любого формата сжатый любым кодеком. Дамп памяти тебе, скорее всего, не поможет, потому что игра декодирует музыку блоками и тут же шлёт на звуковую карту.
RIFF - это контейнер. Т.е. там может, теоретически, храниться файл любого формата сжатый любым кодеком. Дамп памяти тебе, скорее всего, не поможет, потому что игра декодирует музыку блоками и тут же шлёт на звуковую карту.
#8
Отправлено 29 August 2007 - 12:36
Полная труба!!!
Посоветовали поэксперемтировать с BMP, чесно скалать, лажа какая то у меня получается. Размеры картинки так и не нашел
Даже взял существующий размер - перевел в НЕХ и поиском не нашел. По символике видно (вроде) где начало, но начало ли это? Статьи с сайта скачал, вот только проблема, уже 30, бейсик 17 лет назад знал (zx-spectrum), ASM знаю в ряде крякинга (где занопить, где собрать с/н, где джамп роменять, распаковать), но так ьакового программенга НЕТ, особенно в WinAPI. Вот и задаю такие вопросы. Мож, если не трудно, потренингуете, задание, а я вам буду писать мои действия
Посоветовали поэксперемтировать с BMP, чесно скалать, лажа какая то у меня получается. Размеры картинки так и не нашел
Даже взял существующий размер - перевел в НЕХ и поиском не нашел. По символике видно (вроде) где начало, но начало ли это? Статьи с сайта скачал, вот только проблема, уже 30, бейсик 17 лет назад знал (zx-spectrum), ASM знаю в ряде крякинга (где занопить, где собрать с/н, где джамп роменять, распаковать), но так ьакового программенга НЕТ, особенно в WinAPI. Вот и задаю такие вопросы. Мож, если не трудно, потренингуете, задание, а я вам буду писать мои действия
#9
Отправлено 13 July 2010 - 17:23
На самом деле в BMP ничего такого нет
Bitmap он на то и bitmap, что матрица цветов. Попробуй сделать рисунок в 1 пиксель и закрасить каким-нибудь цветом - вот это и будет матрица одного цвета. А их количество зависит от размеров рисунка) Которые задаются исключительно количеством рядов/столбцов в основной матрице
Bitmap он на то и bitmap, что матрица цветов. Попробуй сделать рисунок в 1 пиксель и закрасить каким-нибудь цветом - вот это и будет матрица одного цвета. А их количество зависит от размеров рисунка) Которые задаются исключительно количеством рядов/столбцов в основной матрице
#10
Отправлено 28 July 2011 - 20:02
Такой вопрос.
А можно как нибудь в отладчике перехватить момент, когда при загрузке игры все ресурсы уже распаковались в память и сбросить их на диск?
На какие API следует обратить внимание ?
Вот в отладчике обнаружил такие:
d3dx9_28.D3DXCreateTextureFromFileExA
d3dx9_28.D3DXCreateTextureFromFileExW
d3dx9_28.D3DXCreateTextureFromResourceExA
d3dx9_28.D3DXCreateTextureFromResourceExW
d3dx9_28.D3DXCreateTextureFromFileInMemoryEx
не знаю, правильно ли я на них обратил внимание или нет?
Они лежат в d3dx9_28.dll рядом с exe главным.
Как вообще происходит загрузка ресурсов в игру ?
Можно краткими тезисами обозначить принцип ?
P.S. То есть я к чему клоню:
Если игра распаковывает ресурсы для игры (простите за тавтологию ),
Значит в основном файле игры есть распаковщик который эти ресурсы распаковывает.
Так почему не воспользоваться уже готовым решением ?
Только проблема в том, как узнать момент когда ресурсы распаковались!
Короче сделать типа лоадера-распаковщика.
А можно как нибудь в отладчике перехватить момент, когда при загрузке игры все ресурсы уже распаковались в память и сбросить их на диск?
На какие API следует обратить внимание ?
Вот в отладчике обнаружил такие:
d3dx9_28.D3DXCreateTextureFromFileExA
d3dx9_28.D3DXCreateTextureFromFileExW
d3dx9_28.D3DXCreateTextureFromResourceExA
d3dx9_28.D3DXCreateTextureFromResourceExW
d3dx9_28.D3DXCreateTextureFromFileInMemoryEx
не знаю, правильно ли я на них обратил внимание или нет?
Они лежат в d3dx9_28.dll рядом с exe главным.
Как вообще происходит загрузка ресурсов в игру ?
Можно краткими тезисами обозначить принцип ?
P.S. То есть я к чему клоню:
Если игра распаковывает ресурсы для игры (простите за тавтологию ),
Значит в основном файле игры есть распаковщик который эти ресурсы распаковывает.
Так почему не воспользоваться уже готовым решением ?
Только проблема в том, как узнать момент когда ресурсы распаковались!
Короче сделать типа лоадера-распаковщика.
Сообщение отредактировал TEKTON: 28 July 2011 - 20:25
#11
Отправлено 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 файлов.
Наконец, третья грузит текстуру из памяти, т.е. где-то должно быть место, куда она распаковывается из игровых ресурсов.
Тут только проблема в том, что грузиться текстуры могут в видеопамять (откуда их потом сложно достать), а буфер для распаковки временный - т.е. после загрузки текстуры он уничтожается или перезаписывается следующей текстурой, так что нельзя будет дождаться загрузки игры и потом всё из памяти вытащить, т.к. в памяти к этому моменту уже ничего не будет.
Я не работал с DirectX, так что не могу что-то конкретное посоветовать - только общие вещи.
Судя по названиями функций (моё предположение):
d3dx9_28.D3DXCreateTextureFromFileExA и d3dx9_28.D3DXCreateTextureFromFileExW - грузят текстуры из файла
d3dx9_28.D3DXCreateTextureFromResourceExA, d3dx9_28.D3DXCreateTextureFromResourceExW - из ресурсов PE-файлов
d3dx9_28.D3DXCreateTextureFromFileInMemoryEx - из памяти
В первых двух функциях нужно просто перехватывать к каким файлам они обращаются - это и есть текстуры.
Со второй группой всё сложнее - это надо через какой-нибудь Resource Editor рыться в ресурсах .EXE или .DLL файлов.
Наконец, третья грузит текстуру из памяти, т.е. где-то должно быть место, куда она распаковывается из игровых ресурсов.
Тут только проблема в том, что грузиться текстуры могут в видеопамять (откуда их потом сложно достать), а буфер для распаковки временный - т.е. после загрузки текстуры он уничтожается или перезаписывается следующей текстурой, так что нельзя будет дождаться загрузки игры и потом всё из памяти вытащить, т.к. в памяти к этому моменту уже ничего не будет.