Описание форматов файлов, всевозможные ресурсы |
Добро пожаловать, гость ( Вход | Регистрация )
Описание форматов файлов, всевозможные ресурсы |
-=CHE@TER=- |
Jul 23 2006, 20:06
Сообщение
#1
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Итак, начнём.
Я тут увидел, что многие программы, которые я выкладываю на сайте - уже есть в XENTAX WIKI 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
Сообщение
#2
|
Незарегистрирован |
|
-=CHE@TER=- |
Dec 12 2007, 15:54
Сообщение
#3
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Нет конечно.
То что расширение совпадается совсем не означает, что и содержание тоже. |
Siberian GRemlin |
Dec 12 2007, 17:41
Сообщение
#4
|
Advanced Member Группа: CTPAX-X Сообщений: 533 Регистрация: 4-February 08 Пользователь №: 2 Спасибо сказали: 221 раз(а) |
Формат же разобран...
|
jTommy |
Dec 13 2007, 18:20
Сообщение
#5
|
Наблюдающий Группа: CTPAX-X Сообщений: 197 Регистрация: 4-February 08 Из: деревня Москва Пользователь №: 6 Спасибо сказали: 19 раз(а) |
Я тут увидел, что многие программы, которые я выкладываю на сайте - уже есть в XENTAX WIKI Grafs. Так программы или описания? Там вроде ссылки только на универсальные распаковщики (и очень редко на специализированные). Так что твои программы пригодятся на этом сайте. |
-=CHE@TER=- |
Dec 14 2007, 09:32
Сообщение
#6
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Так программы или описания? Там вроде ссылки только на универсальные распаковщики (и очень редко на специализированные). Так что твои программы пригодятся на этом сайте. Не прошло и года... (*улыбается*)Смысл был в том, что если описание формата известно, то распаковщик может написать, _практически_ каждый (ну, кто программировать хоть на чём-то умеет). Другое дело, что заходить туда и писать распаковщики по их описаниям форматов - как-то... не знаю, глупо что-ли? Хотя я ими (описаниями) пользовался действительно продуктивно только один раз - при написании Blood Rayne 2 POD Encoder Decoder (а то часто там ошибки или вообще к жизни не относятся - например для первой части игры Blood вообще не учитывается, что файлы и FAT архива могут шифроваться - кому интересно на сайте у Ken Silverman лежит утилита KBARF с исходными кодами на Си, которая расшифровывает и распаковывает архивы, но, как оказалось, у меня была версия где тело файлов не шифровалось, так что пришлось эту утилиту немного модифицировать). Для первого Blood правильное описание выглядит так: QUOTE char {4} - Header ('R', 'F', 'F', 0x1A) Сам алгоритм расшифровки (там XOR с меняющимся ключом) можно посмотреть в уже упомянутой программе KBARF.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 |
Siberian GRemlin |
Dec 14 2007, 16:27
Сообщение
#7
|
Advanced Member Группа: CTPAX-X Сообщений: 533 Регистрация: 4-February 08 Пользователь №: 2 Спасибо сказали: 221 раз(а) |
|
-=CHE@TER=- |
Dec 15 2007, 09:14
Сообщение
#8
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
|
Siberian GRemlin |
Dec 15 2007, 20:21
Сообщение
#9
|
Advanced Member Группа: CTPAX-X Сообщений: 533 Регистрация: 4-February 08 Пользователь №: 2 Спасибо сказали: 221 раз(а) |
Давай. Пригодится.
|
-=CHE@TER=- |
Dec 16 2007, 10:13
Сообщение
#10
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Блин, вру - и ни в одном глазу!
Поправил неточности в своём прошлом сообщении. Как различить, когда в архиве используется шифрование файлов, а когда нет - х.з. Видимо, это нужно те 16 байт смотреть... Думаю, они должны за это отвечать. |
-=CHE@TER=- |
Apr 6 2010, 16:47
Сообщение
#11
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Наверное тут будет самое место.
Очень подробное описание формата .TGA: tga_specs.pdf (64 Kb) Что интересно - прозрачность в 16 BPP (0 - есть, 1 - нет) не поддерживает ни PhotoShopt 7, ни XnView, даже PNGOut и тот, гад, в 16-ти цветовые переводит такие .TGA файлы. |
-=CHE@TER=- |
Sep 6 2014, 16:27
Сообщение
#12
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
- 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
Сообщение
#13
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Как различить, когда в архиве используется шифрование файлов, а когда нет - х.з. Разобрался до конца с форматом, поправил статью RFF Format и выслал изменения патчем для Ken Silverman. Он поправил свою утилиту на сайте, так что свою версию я из этой темы удалил. Нормальный распаковщик, поддерживающий шифрование (когда нужно) для таблицы размещения файлов и самих файлов можно, как и раньше, взять на его странице KBARF.Видимо, это нужно те 16 байт смотреть... Думаю, они должны за это отвечать. |
-=CHE@TER=- |
Jun 9 2018, 17:27
Сообщение
#14
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
На сайте про игру 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
Сообщение
#15
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Обновил программы. Для Total Overdose ещё раз переписал программу, чтобы она была по аналогии с той что для Alpha Prime (не буду никакие блоки пропускать). Выяснилось также, что в .NAZ архивах старый формат ZIP Data Description block (без сигнатуры) - что удивительно, так это то что даже родной WinZIP не понимает такие блоки, хотя в документации об этом прямо сказано (см. комментарии в исходных кодах к naztozip - я там детально описал что к чему), поэтому при глубоком тестировании архива, возможны сообщения об ошибках, хотя сами файлы распаковываются без каких-либо проблем или предупреждений. Вообще, интересно, чем разработчики в оригинале файлы упаковывали, потому что помимо этого мне также непонятно что это за байт 0x88 / 0x89 в extra field (как я уже писал, там должно быть минимум 4 байта - два на id и два на размер).
|
-=CHE@TER=- |
Mar 31 2019, 06:29
Сообщение
#16
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Если кто пользуется программой pngout, то знает, что если запустить её без параметров, то она покажет справку по использованию, где помимо всего прочего будет и такая строка:
QUOTE /mincodes# Workaround for buggy decoders. 1:Zlib 1.2.1 bug, 2:buggy mobiles Я как-то никогда не обращал на неё внимание. А тут, пару лет назад, начали в комментариях к перепаковщику архивов для Санитаров Подземелий жаловаться, что с новыми (перепакованными) файлами игра не работает и валится с ошибкой, даже если ничего не менять, а только распаковать и сразу же запаковать назад. Я сначала было убрал упаковку вообще, благо игра позволяла это сделать флагами в 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) Интересно, что версия 1.2.1 вышла 2003.11.17, а исправленная 2004.01.09 - казалось бы, интервал всего в два месяца, но насколько эта версия успела широко разойтись.... - 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 ... |
-=CHE@TER=- |
Mar 24 2020, 14:43
Сообщение
#17
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Понадобилось мне тут как-то создать длинный JPEG файл. Я знал, что там под ширину и высоту отводится 2 байта, поэтому более чем 65535x65535 (0xFFFF x 0xFFFF) там создать нельзя.
Но каково же было моё удивление, когда и 65535 у меня сделать не получилось - сохранил изображение в .BMP и попатался хоть чем-то сжать в .JPG, но всё что было под рукой отказывалось с таким файлом работать, причём ещё и без внятного сообщения об ошибке! Начал уменьшать высоту, пробуя после каждого уменьшения заново всунуть в JPEG и на 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. |
-=CHE@TER=- |
Sep 20 2022, 10:55
Сообщение
#18
|
Walter Sullivan Группа: Root Admin Сообщений: 1,355 Регистрация: 4-February 08 Пользователь №: 3 Спасибо сказали: 311 раз(а) |
Закрывая тему по игре Total Overdose - на сайте опять просили написать утилиту для упаковки.
Меня откровенно ломало это делать, но подумалось, что есть способ проще, т.к. формат, по сути, почти что .ZIP - возможно, игра его и поддерживает. Заглянул внутрь исполняемого файла игры TOD.EXE и сделал поиск ".zip" - нашёл такие строки (я здесь по строкам разбил, но это ASCIIZ строки, где каждая заканчивается нулём): CODE /uk_sounds.naz Как видите, к каждому .NAZ идёт в паре .ZIP (видимо, если .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 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). Спасибо сказали:
|
Упрощённая версия | Сейчас: 8th June 2024 - 06:53 |