Анализ ресурсов игры Wrath of Earth (возможность перевода)

Сегодня глядел в ресурсы. Почему-то не покидают мысли, что тексты лежат в n_norm.drv и они реально поджаты. Там в начале что-то наподобие таблицы-словаря. С картами никак, ни в каких вариантах RLE-сжатия, размеров и начальных смещений рисунок карты не появляется. Хотя есть вероятность, что признак повторителя лежит где-то в районе значения 10h. Кто-нибудь проверял по назначению все звуковые файлы. Я прогонял через Sound Forge все шаги *,fst - OK. Это нужно, чтобы полностью исключить попадание текстов в файл с явно звуковым расширением, который будет в игре использован не как звук, а как хранилище текста. Предлагаю аккуратными небольшими правками не в заголовочной таблице n_norm.drv попробовать проанализировать наличие текста.

 

В N_NORM.DRV (и в I_NORM.DRV тоже) текстов нет. Заменял эти файлы пустыми (состоящими из 00) - первый брифинг был на месте, а вылет из игры происходил позже, при загрузке карты.

 

Текста точно нет ни в *.FST, ни в *.SPC. Это можно проверить, просто запаковав WOE.RSC вообще без них. Текст первого брифинга при этом на месте, никуда не девается.
На сегодня точно известно, что текста нет в файлах:
список

A0 - первая заставка с логотипом;
A1 - первая часть интро (взлёт с Земли - открытие "портала");
A2 - вторая часть интро (вход в "портал"- титры с разработчиками);
A3 - ролик (взрыв на красной планете);
A4 - ролик (вылет катера из корабля, виден при начале новой игры);
A5 - четвёртая часть интро (подлёт к красной планете);
A6 - третья часть интро (вылет из "портала");
A8 - ролик (дым из руин пирамиды или купола на фоне голубого неба);
A9 - ролик (что-то типа катастрофы при посадке, вид из центра управления). Есть графические надписи, ролик нуждается в переводе!
C0-C3 - лицевая анимация, "говорящие головы";
F0-F5 - лицевая анимация, "говорящие головы";
M1 - картинка человека в серебристом скафандре на синем фоне, видна справа при выборе сложности игры;
WC - два скафандра, видны слева и справа при выборе пола персонажа;

00.DAT - неизвестно что, но подмена на забитый нулями файл первый брифинг не затрагивает;
DE - неизвестно что, но подмена на забитый нулями файл первый брифинг не затрагивает.

В 999 есть не текст, а графические надписи и изображения (подсказки, вызываемые Esc).

Скорее всего текст в картах.

 

Как я и говорил, в общем. Тем более, Фоллер в интервью упомянул некий скриптовый язык, что увеличивает шансы найти тексты именно в картах во много раз.
Только вот чем бы распаковать их...

 

Согласен, что в картах. Так намного проще редактировать уровни. Не надо пихать все в общий файл, менять потом указатели или еще доп. информацию. при изменении текстов. Также становится легко добавлять, переставлять уровни. На карте ассоциировано сразу: и NPC, и брифинги, и подписи объектов, название уровня. Кстати прикол. До 5 уровня в конце строки названия каждого из 1-4 уровней идут даты 07.03.2031, 22.03.2031, 12.03.2031, 02.03.2031. А потом дат нету.

Этим я сегодня максимально плотно занимаюсь. Перебираю все возможные параметры (смещение чтения в файле, ширина карты, высота карты) и варианты реализации алгоритмов типа RLE, не факт, что добьюсь успеха, но что-то смутно проскакивает например, если признаком повторителя считать все, что меньше 10h, больше или меньше этого числа все становится просто отвратным, а вот ближе к этому значению создается ощущения, что начинают проступать какие-то мелкие детали карт. Перебрать все сочетания RepeatByte, Map_W, Map_H, MapFileOffset, Increment будет довольно тяжело. Не успеваю зайти на абандонию и моби. Может ли кто-нибудь сейчас по быстрому глянуть и проверить. У меня ощущения, что упоминание про RLE-алгоритм я увидел именно там в сообщениях Фоллера. не могло же это у меня просто так возникнуть в голове.

Мне не нравится, что, байты E0h, 90h стоят всегда в начале, как будто это и есть размер карты. Но цена деления сектора я это точно знаю всегда 40h (кстати, карта 004 как раз отличается этим первые два байта не 00h 40h, а 05h С0h и сегодня я ее прошел, в сейве сейчас посмотрю изменение координат). Но я прошел уже 5 уровней с детальным изучением координат карты и нигде не было превышения значений 8192 (даже на той карте 004 было под 8000), вплотную один раз было ~8100. но превышения никогда не было. Это говорит о том, что размер карт 128х128, а цена одного сектора равна 40h. Возможно E0h, 90h как-то участвуют в RLE-алгоритме как признаки повторителя, или диапазон признаков повторителя. Нужно проверять правками затирая именно эти самые первый байты карт, тогда мы больше поймем про архитектуру карт. распакуем карты, примерно будем знать где тексты. Скорее всего они в самом конце файла карты. Там обратите внимание как-то пестро идут байты. Признаком текстов даже сжатых является частое повторение пробелов, обрывов строки, как бы они не были закодированы без сжатия или со сжатием.

Vladimir 777, ты упоминал про относительный анализ кодировок. Вероятность того, что тексты несжаты уже полностью исключена полным прогонов всех вариантов гаммирования или же такая вероятность еще остается? Я просто не вижу смысла сжимать текст, его конечно довольно много в игре, но не настолько много. И потом, не забываем, что эти люди не особо ужимались с памятью, поскольку "замутили" свою EMS. У них кроме карт ничего не зажато вообще, ни растры текстур, ни звук. Зачем же зажимать тогда текст? Для уровня "профессионалов" 1995 г. достаточно было его загаммировать или еще мощнее - закодировать по таблице байт в байт. Пример - в прошлом году осенью A.P.$lasH легко нашел многобайтовый гаммирующий ключ, которым прошивались строки всех текстов в игре Terminator: Future Shock и это тоже был 1995 г., и это был откровенно недружественный шаг по защите текстов от изменения. А автором игры была довольно именитая компания, а не маленький коллектив программистов, только начинающих себя в подобном бизнесе.

И еще, а почему бы нам не попробовать вариант со сравнением сейвов. Может это даст какие-то данные для понимания архитектуры карт.

 

Меня всегда пугает это красивое слово - "гаммирующий". Там, пардон, фуфел был школьный - то ли ксорили, то ли отнимали, я уже не помню, где там эта тема?

Нашёл текст в памяти, сравнил с ресурсом и порядок. Здесь же явное сжатие, причём тексты я тоже в памяти вижу, а вот чтобы до них добраться, нужно брать Soft-Ice и смотреть.

Что касается параноидальной защиты - я прямо сейчас разбираю Prehistorik (тяжело идёт всё остальное, поэтому переключился). Так вот, вы будете смеяться, но там:

1. Загрузчик в COM-файле, который подчитывает куски кода из другого файла на диске и формирует в памяти EXE, который сжат LZEXE.
2. Четыре ресурсника, в которых ресурсы выборочно сжаты LZ, а сжаты или нет - это в EXE указывается, а не во флагах самого потока.
3. Спрайты и уровни ДОПОЛНИТЕЛЬНО, после разжатия LZ оказываются сжатыми в RLE.

И как с этим было справиться без Soft-Ice, лично я совершенно не представляю.

Так что странных извращенцев уже тогда, в 1990 году хватало

 

Вот отыскал.
http://www.old-games.ru/forum/showthread.php?p=921062#post921062

Только что глянул уровень 5 (по идее это карта 004). Но на этом уровне цена одного сектора в координатных единицах все равно равна 64 (40h). Тогда я опять не могу понять, что это за числа в начале большинства карт 00 40 E0 90.

 

Я говорил, что в WOE.RSC нет текста в кодировке, сохраняющей алфавитную последовательность букв. Т.е. если в кодировке за A будет следовать не B, а, к примеру, F, а за F не G, а K, и такое будет встречаться повсеместно - относительный поиск ничего не найдёт. Но это не наш случай (когда такой бардак в кодировке, то бардак и в шрифте), просто сжаты тексты.

Кстати файл 999 скорее всего сжат тем же способом, что и карты. Если глянуть на распределение символов (такая функция есть в Hex Workshop, в WinHex это называется "анализ файла" и представляет результат в наглядном виде графика) в файле, то мы увидим всё те же пики на 00h, 40h, 80h и С0h. И в конце файла будет 00 FF, как в картах.

Назначение содержимого 999 более-менее известно, может попытаться найти какое-нибудь изображение (спрайты выстрелов?) и, зная как оно должно выглядеть в игре, уже его пытаться разжать?

 

В сейве идут первые байты файла карты начиная со смещения 16h. В среднем сейв это 25-35 кБт. Т.е. какой-то изменяемый слой карты точно сохраняется. Другие слои неизменны: освещение, физ факторы, текстуры.

---------- Сообщение добавлено в 14:17 ---------- Предыдущее сообщение размещено в 14:14 ----------

Как гипотеза.
Скорее всего это связано с признаками повторителя.
Или например повторители это диапазоны (дикий вариант)
00h - 00h+10h
40h - 40h+10h
E0h - E0h+10h
90h - 90h+10h
А если поменять 90h и E0h, то результат должен быть вроде как идентичным.

Но смущает карта 004.
в ней так
05 C0 E0 90
Кстати С0h - это признак повторителя в pcx.

 

Было там про RLE:

Но он же говорит не про карты, а про спрайты. А "credits.bin and endgame.bin", которые он назвал сжатыми вообще не сжаты же?

 

Проанализировал сейвы и карты. Самый первый уровень. Сохранение выполнено в самый первый момент появления на уровне. Один шаг на восток и снова сохранение. Правда, перед этим появился противник и второй сейв удлинился на несколько десятков байт. Но постоянная часть точно есть. И эта часть совпадает с картой уровня 000 (у сейва в начале небольшой заголовочек 22 байта). Сегодня я не успел определить точную границу окончания постоянной части в сейве. Это очень сильно поможет разобраться с картами. Это где-то между смещениями 4000h и 5000h. Кстати, 80h*80h=4000h

---------- Сообщение добавлено в 21:31 ---------- Предыдущее сообщение размещено в 21:14 ----------

Текстуры в BMP идут не совсем стройно как я думал. Т.е. только прямой однобайтовой адресацией текстур на картах не обойтись. Тогда в каждой карте должна быть таблица перевода двух- или четырех байтовых идентификаторов текстур. Это позволяет легко совмещать текстуры из различных уровней, сильно разнесенных по номерам в игре между собой. Я думал, что имелась прямая однобайтовая адресация + смещение по текстурам от уровня к уровню. Оказалось не так. Кстати, многие текстуры используются для анимации, они всегда идут последовательно друг за другом.

Про RLE Фоллер говорил только в отношение раcтровой графики. Но карты также можно зажать. По сути карта это несжатый квадратный растр из секторов, в которых указаны например номера текстур. Почему бы не сжать это. Допустим 128х128х10 слоев = 163 кБт при однобайтовой адресации для слоев номеров текстур и величин физ. параметров, стоп, а карты имеют размеры по 250-350 кБт. Может действительно нет сжатия? Просмотр байтов карты 000 на ширине 128 без RLE представляет собой белый шум точек при любых смещениях от начала файла.

Сегодня глянул в IDA Pro файл woe.exe. Там очень мало инфы. Даже строк предельно мало. Хотя может Ида неправильно его раскрыла, но ошибок не было. Про запаковку я не знаю, есть она в ехе или нет. Короче, адресация команд и данных там двух байтовая. Это значит, что четырехбайтовые указатели маловероятны, хотя я наподобие их тоже видел в одном из файлов. Значит в заголовке карты (там примерно первые 28 байт почти одинаковы у всех карт) указатели (а скорее размеры!) двухбайтовые.

 

а идею сделать резидент который будет менять текст на переведенный прямо в памяти кто-нить рассматривал?.
а вообще, недавно ковырял ресурсы win-игры одной, так там без OllyDbg вообще бы ничего не понял, м.б. и тут каким-нить Turbo Debugger стоит пройтись..

 

Нашел место окончания постоянной части в сейвах. 000044A5h (сейвы карты 000). Также я взял первый уровень, первый момент появления на карте, шаг на восток и сохранение. Заголовок FD FD FD… из сейва обрезан (это просто кодированная строка имени сейва). После этого начало куска из сейва совпадало с началом карты 00 40 E0 90.
Размер постоянной части в сейве равен 17574 Бт. Приделав шапку сейва и загрузив уровень, я получил вылет. На этом все. Что-то у меня бензин кончается по поводу возможности перевода этой игры. Тут все нереально запаковано. Что за стиль программирования был у Фоллера, я такого еще не видел.

Как последнюю попытку, стоит попробовать следующее. Собственно, карты нам нужно изучать, чтобы понять, где лежат тексты. Если бы найти байт в байт хотя бы первые буквы брифинга, то можно сильно «раскрутить» кодировку или сжатие текста. Но это очень долго искать. Разве что делать заливки по 10-20 байт выборочных участков и потом запускать и всегда включать новую игру. Но наверное всегда будут вылеты или зависания.

 

A.P.$lasH, ради интереса погонял её в DosBox Debugger. И действительно- меню, оружия и т.п. лежат прям в памяти. А вот текстов брифингов что-то я не увидел (пробовал на 1 м уровне естессно), останавливал её и до брифинга, и во время и после - не нашёл. искал я только в основной памяти, но драйвера всяких EMS мы же всё равно отключаем.
а ты именно их находил?

 

Символы хранятся в памяти в той же кодировке, что и основные тексты игры. Здесь я просто добавил 0x41, поэтому не так красиво, как могло бы быть, но понять можно.

 

В смысле это стандартная ASCII с выброшенными первыми 64 символами ?

WERTA, решение проблемы поиска местонахождения текстов - самоочевидно и следует вот из этого:

Если есть указатели на фонты, значит их адреса есть в подпрограммах печати текста. Ищем эти подпрограммы, затем ставим на них бряки в любом отладчике и запускаем на выполнение - вуаля ! в стеке у нас есть адрес следующий за вызвавшим подпрограмму печати символа. Таким образом раскручиваем код до печати строк. И получаем знание, где и в каком виде они хранятся.

 

A.P.$lasH, я тоже в этой кодировке смотрел, но ёмоё, брифинги-то оказались в EMS (я теперь тоже сделал дамп побольше и увидел их), хоть драйвер EMS мы и отключаем (иначе не запускается). странное дело, но значит игра обращается к ems как-то не через драйвер (логично)..
с одной стороны это препятствие, если кто-то всё же решит делать переводчик-резидент..
с другой - маленькое подспорье если кто-то решит таки её дебажить - нужно будет как-то искать как она загружает данные в EMS.. хотя м.б. это тоже препядствие..

 

Zolimax, там самопальная система расширенной памяти, Фоллер в интервью говорил.

 

Вот это прочитать: LIM EMS. Всё реализуется аппаратно.

 

В формате записей псевдоархива RSC как раз смущает регулярность в поведении второй (непонятной) четверки байтов. Это и не смещение, и не размер, а тогда что это. Возможно, это связано с размещением в EMS. Может это кодирующие 4 байта? Но мы знаем что многие ресурсы не закодированы, хотя бы тот же звук. А еще после имен файлов, после разделительного нуля 00h идут последовательности каких-то байтов. Скорее всего, это просто остатки от не обнулённых при инициализации строк. В Си-программировании обязательно самому нужно инициализировать переменные и, особенно, массивы. Фоллер писал про полный игнор четвёрки этих загадочных байтов.

Кто-нибудь сталкивался с простыми алгоритмами запаковки текстов? Если тут имеется RLE-сжатие для растров, массива секторов карт, спрайтов, то для текста RLE не подойдёт. Оно неэффективно будет сжимать, поскольку в тексте мало повторяющихся последовательностей. Даже если есть какое-то сжатие, пусть даже со словарем, то прибавлением 41h (декодировкой) мы должны были бы увидеть хотя бы словарик в карте 000. Но этого не было. Кстати если есть алгоритм сжатия с реализацией подстановки слов или частей слов по индексу из словарика, то перевод принципиально невозможен.

У меня ощущение, что карты дополнительно закодированы каким-то ключом. Имеется смысл этот ключ разместить в заголовочной таблице RSC. Я сегодня поупражнялся с этим вариантом с картой 000, но ничего так и не получил. Т.е.
сначала декодирую, ожидаю получить кодировку (00h, 01h, 02h,...). затем декодирую эту кодировку в (41h, 42h, 43h,...). Но ничего не проявляется. В который раз как об стенку - результата нет.