Версия для печати темы

Нажмите сюда для просмотра этой темы в оригинальном формате

CTPAX-X _ Статьи _ Описание форматов файлов

Автор: -=CHE@TER=- Jul 23 2006, 20:06

Итак, начнём.
Я тут увидел, что многие программы, которые я выкладываю на сайте - уже есть в http://wiki.xentax.com/index.php/GRAFs. Так что, я думаю, что имеет смысл делать распаковщики и выкладывать описания форматов, которых нет там. А то, как-то тупо получается - тут я выкладываю формат, который раскопал сам, в то время как он уже готовенький лежит там.

Ну, вот этого формата я там точно не видел:

QUOTE
Формат: .WD
Игра: Earth 2140

4 байта - количество файлов в архиве (обозначим их как TF)

далее следует блок описания такого формата:
4 байта - абсолютное смещение файла относительно начала архива
4 байта - размер файла
8 байт - зарезервированно - всегда 0-ли (в том архиве, который мне давал когда-то Siberian GRemlin для написания распаковщика - "FONT.WD")
4 байта - какая-то контрольная сумма - у всех файлов разная
4 байта - смещение имени файла в списке имён (NOfs) - см. дальше

Блок описания нужно повторить TF раз.

4 байта - размер списка имён

Затем идёт сам список имён файлов:
NAME1\0NAME2\0 и т.д.
т.е. просто TF штук ASCIIZ-строк друг за другом.

Если прочитать список имён в отдельную переменную-указатель, то через NOfs в качестве побайтового индекса, мы получим указатель на начало ASCIIZ-строки, с именем нужного нам файла.
Имя файла может содержать относительный путь, с использованием символа слэш "/" в качестве разделителя.

Автор: 9k1d Dec 12 2007, 13:20

не то? http://filext.com/file-extension/wd

Автор: -=CHE@TER=- Dec 12 2007, 15:54

QUOTE(9k1d @ Dec 12 2007, 01:20 PM) *
не то? http://filext.com/file-extension/wd
Нет конечно.
То что расширение совпадается совсем не означает, что и содержание тоже.

Автор: Siberian GRemlin Dec 12 2007, 17:41

Формат же разобран...

Автор: jTommy Dec 13 2007, 18:20

QUOTE(-=CHE@TER=- @ Jul 23 2006, 11:06 PM) *
Я тут увидел, что многие программы, которые я выкладываю на сайте - уже есть в http://wiki.xentax.com/index.php/GRAFs.
Так программы или описания? Там вроде ссылки только на универсальные распаковщики (и очень редко на специализированные). Так что твои программы пригодятся на этом сайте.

Автор: -=CHE@TER=- Dec 14 2007, 09:32

QUOTE(jTommy @ Dec 13 2007, 06:20 PM) *
Так программы или описания? Там вроде ссылки только на универсальные распаковщики (и очень редко на специализированные). Так что твои программы пригодятся на этом сайте.
Не прошло и года... (*улыбается*)
Смысл был в том, что если описание формата известно, то распаковщик может написать, _практически_ каждый (ну, кто программировать хоть на чём-то умеет). Другое дело, что заходить туда и писать распаковщики по их описаниям форматов - как-то... не знаю, глупо что-ли? Хотя я ими (описаниями) пользовался действительно продуктивно только один раз - при написании http://www.ctpax-x.org/?goto=files&show=23 (а то часто там ошибки или вообще к жизни не относятся - например для http://wiki.xentax.com/index.php/Blood вообще не учитывается, что файлы и FAT архива могут шифроваться - кому интересно на сайте у Ken Silverman лежит утилита http://www.advsys.net/ken/download.htm#slab6 с исходными кодами на Си, которая расшифровывает и распаковывает архивы, но, как оказалось, у меня была версия где тело файлов не шифровалось, так что пришлось эту утилиту немного модифицировать).

Для первого Blood правильное описание выглядит так:
QUOTE
char {4} - Header ('R', 'F', 'F', 0x1A)
uint16 {2} - version (0x2000 - no encryption; 0x0300, 0x0301 - encryption used)
uint16 {2} - unused1 (padding)
uint32 {4} - Directory Offset
uint32 {4} - Number Of Files
byte {16} - unused2 (padding)
byte {x} - Files data
Сам алгоритм расшифровки (там XOR с меняющимся ключом) можно посмотреть в уже упомянутой программе KBARF.

Автор: Siberian GRemlin Dec 14 2007, 16:27

QUOTE(-=CHE@TER=- @ Dec 14 2007, 04:32 PM) *
у меня была версия где тело файлов не шифровалось, так что пришлось эту утилиту немного модифицировать).

А ты её выкладывал?

Автор: -=CHE@TER=- Dec 15 2007, 09:14

QUOTE(Siberian GRemlin @ Dec 14 2007, 04:27 PM) *
А ты её выкладывал?
Изменённую утилиту? Нет. Я же чисто для себя менял - извлечь .MID файлы и сравнить с творчеством группы "Климбатика". Тебе надо что-ли? В смысле - выложить? Только оно на Си.

Автор: Siberian GRemlin Dec 15 2007, 20:21

Давай. Пригодится.

Автор: -=CHE@TER=- Dec 16 2007, 10:13

Блин, вру - и ни в одном глазу!
Поправил неточности в своём прошлом сообщении.

Как различить, когда в архиве используется шифрование файлов, а когда нет - х.з.
Видимо, это нужно те 16 байт смотреть... Думаю, они должны за это отвечать.

Автор: -=CHE@TER=- Apr 6 2010, 16:47

Наверное тут будет самое место.
Очень подробное описание формата .TGA: https://web.archive.org/web/20090206013618/http://tfcduke.developpez.com/tutoriel/format/tga/fichiers/tga_specs.pdf (64 Kb)
Что интересно - прозрачность в 16 BPP (0 - есть, 1 - нет) не поддерживает ни PhotoShopt 7, ни XnView, даже PNGOut и тот, гад, в 16-ти цветовые переводит такие .TGA файлы.

Автор: -=CHE@TER=- Sep 6 2014, 16:27

- Ancient chinese secret!
© Lo Wang, Shadow Warrior (1997)

Не могу пройти мимо и не упомянуть формат коллекций изображений .LIB из игры Blade & Sword (см. соответствующую тему на Extractor.ru).

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

Итак, действующие лица в порядке появления (поля из заголовка lep-файла):
Width, Height, Width_Add, Height_Add - типа DWORD (находятся в начале заголовка);
Crypted, Width_Idx, Height_Idx - типа BYTE (находятся в самом конце заголовка);
Div_List - массив DWORD из 10 элементов (от 0 до 9, прописан в исполняемом файле игры).

А теперь представляю вам главного персонажа (барабанная дробь) - Её Величество Технология Особого Китайского Шифрования!

CODE
if (lep_head.Crypted) {
  lep_head.Width  = (lep_head.Width  / Div_List[lep_head.Width_Idx ]) + lep_head.Width_Add;
  lep_head.Height = (lep_head.Height / Div_List[lep_head.Height_Idx]) + lep_head.Height_Add;
}

Автор: -=CHE@TER=- Nov 1 2016, 15:50

QUOTE(-=CHE@TER=- @ Dec 16 2007, 10:13) *
Как различить, когда в архиве используется шифрование файлов, а когда нет - х.з.
Видимо, это нужно те 16 байт смотреть... Думаю, они должны за это отвечать.
Разобрался до конца с форматом, поправил статью http://www.shikadi.net/moddingwiki/RFF_Format и выслал изменения патчем для Ken Silverman. Он поправил свою утилиту на сайте, так что свою версию я из этой темы удалил. Нормальный распаковщик, поддерживающий шифрование (когда нужно) для таблицы размещения файлов и самих файлов можно, как и раньше, взять на его странице http://www.advsys.net/ken/download.htm#slab6.

Автор: -=CHE@TER=- Jun 9 2018, 17:27

На сайте про игру Total Overdose спрашивали, так что взялся я её посмотреть.
Пока ковырял архивы .NAZ, вдруг, понял, что мне это что-то напоминает.
И точно, выяснилось, что там, как оказалось, обычный .ZIP в котором сигнатуру изменили и имена файлов пошифровали, плюс поменяли местами 4 поля в структуре перетащив их из начала в конец. Интересно что под отладчиком local .ZIP headers игра, вообще, не расшифровывает - похоже они забиты мусором, хотя размер и совпадает с тем что должно быть, так что приходится при конвертировании их восстанавливать вручную.
Сделал конвертер в .ZIP отбросив поле с непонятными данными (по спецификации .ZIP там не менее 4 байт должно быть на одно поле, а тут 1 байт), так что не пугайтесь, что после конвертирования архив слегка похудеет.
Ещё вспомнил что у нас есть конвертер архивов Alpha Prime в .ZIP - тоже поглядел что там и сделал конвертер.
Оба конвертера теперь будут с открытыми исходными кодами.
И если конвертер для Alpha Prime от Xplorer'а я могу спокойно заменить (без исходных кодов, плюс антивирус у меня почему-то на него ругается), то jTommy написал GUI распаковщик для Total Overdose и я не знаю - стоит его заменять или оставить в архиве.

С одной стороны меня просто жаба давит в архив 4 Кб добавлять ещё 30 Кб старой программы.
С другой стороны опять начнутся стоны, что старая программа работала, а новая непонятно как (ибо работу с консолью осилить не могут).
Что думаете?

P.S. Ни разу не хочу принизить огромный вклад Xplorer'а в общее дело - он молодец, но я за открытые исходные коды и не понимаю, если честно, чего там прятать - я про эту игрушку, вообще, только благодаря этому конвертеру и узнал. Даже про Total Overdose и то больше слышал.
Вообще, Xplorer как-то странно программы писал. Ну, т.е. он делал какие-то вещи, которые, вроде, ничем обоснованы не были. Ну, ок, допустим, ты не хочешь, выкладывать исходные коды, потому что программа написана как попало и тебе за код стыдно (или ещё там чего). Ладно. Но зачем её шифровать (UPX, плюс стёртые заголовки, возможно ещё что-то)? Там же ни копирайтов нет, ни даже сообщений об ошибках. Чего там реально прятать было? Что кто-то подсмотрит алгоритм и выдаст конвертер за свой? Так, опять же, копирайтов нет - и так кто угодно авторство присвоить может. В общем, есть отдельные моменты которые мне непонятны и объяснить я их не могу.
P.P.S. И, jTommy тоже, кстати, молодец, но он, видимо, не работал с .ZIP до этого, поэтому не сообразил что там архив или сообразил, но ему распаковщик проще написать было, чем заморачиваться с конвертированием.

Автор: -=CHE@TER=- Jul 14 2018, 16:49

Обновил программы. Для Total Overdose ещё раз переписал программу, чтобы она была по аналогии с той что для Alpha Prime (не буду никакие блоки пропускать). Выяснилось также, что в .NAZ архивах старый формат ZIP Data Description block (без сигнатуры) - что удивительно, так это то что даже родной WinZIP не понимает такие блоки, хотя в документации об этом прямо сказано (см. комментарии в исходных кодах к naztozip - я там детально описал что к чему), поэтому при глубоком тестировании архива, возможны сообщения об ошибках, хотя сами файлы распаковываются без каких-либо проблем или предупреждений. Вообще, интересно, чем разработчики в оригинале файлы упаковывали, потому что помимо этого мне также непонятно что это за байт 0x88 / 0x89 в extra field (как я уже писал, там должно быть минимум 4 байта - два на id и два на размер).

Автор: -=CHE@TER=- Mar 31 2019, 06:29

Если кто пользуется программой http://www.forum.ctpax-x.org/index.php?showtopic=96#entry1377, то знает, что если запустить её без параметров, то она покажет справку по использованию, где помимо всего прочего будет и такая строка:

QUOTE
/mincodes# Workaround for buggy decoders. 1:Zlib 1.2.1 bug, 2:buggy mobiles
Я как-то никогда не обращал на неё внимание. А тут, пару лет назад, начали в комментариях к перепаковщику архивов для http://www.ctpax-x.org/?goto=files&show=118 жаловаться, что с новыми (перепакованными) файлами игра не работает и валится с ошибкой, даже если ничего не менять, а только распаковать и сразу же запаковать назад. Я сначала было убрал упаковку вообще, благо игра позволяла это сделать флагами в TOC/FAT архива, но потом, всё же, попробовал её вернуть. Проблема была в том, что я всегда использовал последнюю версию zlib. Здраво решив, что здесь что-то не так, я поглядел исполняемый файл игры и, увидев там строчку "zlib 1.2.1", взял эту же версию библиотеки после чего файлы стали получаться один в один как в игре. Поставив проверку в исходных кодах чтобы не использовали другие версии zlib я благополучно об этом и забыл.
Но, на всякий случай, если кто-то будет изменять другие игры и игра невоспринимает ничего кроме сжатых данных, а при перепаковке возникает ошибка - посмотрите не использует ли игра zlib версии 1.2.1.
Если коротко, то из-за ошибки в 1.2.1 сжатые файлы можно распаковать другими версиями, но вот сама 1.2.1 может распаковать только то, что сжато ей же или, как в pngout, программами которые могут эту ошибку эмулировать. Ещё, как вариант, можно попробовать заменить код zlib, если он в отдельном .DLL файле.
Цитата из zlib/ChangeLog (1.2.1.1 - это версия следующая сразу за 1.2.1):
CODE
Changes in 1.2.1.1 (9 January 2004)
...
- Fix a big fat bug in inftrees.c that prevented decoding valid
  dynamic blocks with only literals and no distance codes --
  Thanks to "Hot Emu" for the bug report and sample file
...
Интересно, что версия 1.2.1 вышла 2003.11.17, а исправленная 2004.01.09 - казалось бы, интервал всего в два месяца, но насколько эта версия успела широко разойтись.

Автор: -=CHE@TER=- Mar 24 2020, 14:43

Понадобилось мне тут как-то создать длинный JPEG файл. Я знал, что там под ширину и высоту отводится 2 байта, поэтому более чем 65535x65535 (0xFFFF x 0xFFFF) там создать нельзя.
Но каково же было моё удивление, когда и 65535 у меня сделать не получилось - сохранил изображение в .BMP и попатался хоть чем-то сжать в .JPG, но всё что было под рукой отказывалось с таким файлом работать, причём ещё и без внятного сообщения об ошибке!
Начал уменьшать высоту, пробуя после каждого уменьшения заново всунуть в JPEG и на 65500 изображение наконец-то упаковалось.
Пошёл https://www.google.com/search?q=jpeg+65535+65500. Релевантной информации очень немного, даже стандарт на JPEG и Wikipedia пишут о 65535, так что самое внятное объяснение, которое удалось найти, выглядит так:

QUOTE
Symptom
A job fails with the error "Maximum supported image dimension is 65500 pixels(JPEG standard).."

Cause
This is caused by a combination of preview DPI setting and the height or width of the output file. The maximum pixel height/width of a JPEG is 65535 or 2^16-1. Many software implementations reduce this slightly to 65500 including libjpeg and libjpeg-turbo. This is a limitation of the JPEG standard.

Resolution
Error: JPEG Compression failed: Maximum supported image dimension is 65500 pixels(JPEG standard)..

This is due to the preview file that is created regardless of input file type. The maximum allowed is a combination in the preview settings of your workflow of the DPI setting and the output size of your job. For example: if your preview DPI is set to 100 the max height/width would be 655" as 100x655=65500.

This can be resolved by:
* disabling the preview on the workflow
* reducing the DPI so the preview image does not exceed 65500 pixels
* selecting a fixed preview size from the dropdown.
© https://communities.efi.com/s/article/Error-JPEG-Compression-failed?language=en_US#Resolution.

Автор: -=CHE@TER=- Sep 20 2022, 10:55

Закрывая тему по игре Total Overdose - на сайте опять просили написать утилиту для упаковки.
Меня откровенно ломало это делать, но подумалось, что есть способ проще, т.к. формат, по сути, почти что .ZIP - возможно, игра его и поддерживает.
Заглянул внутрь исполняемого файла игры TOD.EXE и сделал поиск ".zip" - нашёл такие строки (я здесь по строкам разбил, но это ASCIIZ строки, где каждая заканчивается нулём):

CODE
/uk_sounds.naz
/uk_sounds.zip
/it_sounds.naz
/it_sounds.zip
/de_sounds.naz
/de_sounds.zip
/fr_sounds.naz
/fr_sounds.zip
/es_sounds.naz
/es_sounds.zip
Как видите, к каждому .NAZ идёт в паре .ZIP (видимо, если .NAZ не найден). Остальные архивы я нашёл внутри исполняемого файла одной строкой (это одна строка, с запятыми и пробелами):
CODE
blocks.naz, sounds.naz, videos00.naz, videos01.naz
Что как бы говорит о том, что новые .NAZ файлы создавать бесполезно, т.к. игра не ищет по маске *.NAZ, а работает строго только с именами упомянутыми выше.
И тут меня осенило, что, возможно, функция открывающая архивы одна, где внутри, уже по типу файла, определяет как его открывать: как .NAZ или как .ZIP.
Тогда я сделал следующее:
1. Дешифровал все архивы .NAZ в .ZIP при помощи утилиты nastozip.
2. Убрал во временный каталог все оригинальные .NAZ файлы.
3. Переименовал все полученные .ZIP архивы в .NAZ (просто раширение сменил).
4. Запустил игру и... всё заработало будто так и было. Даже новую игру начал - никаких ошибок.
Всё, конечно, не тестировал, но, подозреваю, что проблем быть не должно.
Мораль сей басни такова: вот так лень победила желание что-то делать (конвертер из .ZIP обратно в .NAZ).