Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
iMaster → Маленькие программы → Z archive Unpacker
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Консольный распаковщик архивов pac и exp игры Z и Z Expansion от 1996 - 1998 года. В качестве параметра указываем архив, получаем на выходе кучу файлов в текущей директории. Вот собственно и вся петрушка.
В Новостях был вопрос: "Зачем нужен распаковщик, если нет упаковщика?"
Ответ.
Где-то на просторах Интернета я обнаружил вот такую запись (цитата не точна и переведена с английского):
Каждый файл-ресурс Z запакован по алгоритму LZSS (из семейства LZ77), а затем архивы упакованы в группы по алгоритму .jmp2
Что это за алгоритм .Jmp2, неизвестно.
Итак, с помощью твоего, Antares, распаковщика (спасибо за него огромное!) я распаковал HEADFX.PAC (потому что он самый маленький 
), а затем упаковал по алгоритму LZSS файл HEADBIT0.DAT, полученый при распаковке. Итак, фрагмент этого файла, запакованного в LZSS:
00000000: FF 00 00 28 00 44 01 0D | 00 DD 2C F1 F0 80 03 20
00000010: EF F2 80 08 7A FC F4 0D | FC F4 12 0D 00 10 F1 F0
00000020: 5B 50 13 14 03 20 14 14 | 03 F0 23 04 DB C0 15 14
00000030: 03 90 16 14 03 60 17 B6 | 14 03 30 18 14 03 00 19
00000040: 14 03 D0 B6 53 04 A0 1A | 14 03 70 1B 14 03 40 AD
00000050: 1C 14 03 10 1D 14 03 E0 | 7B 04 B0 7D 1E 14 03 80
00000060: 1F 08 00 18 6F 01 AD 20 | 94 03 00 21 94 03 C0 A3
00000070: 04 80 95 22 94 04 23 9C | 04 24 A4 04 C3 04 80 D5
00000080: 25 94 04 26 9C 04 27 A4 | 04 27 10 FA 95 03 29 EC
00000090: 03 C0 2A 20 00 20 AA 2F | 01 2E FC 04 32 FC 04 36
000000A0: FC 04 3A D6 FC 04 3E 20 | A5 03 41 24 13 1C 1D E7
000000B0: 1F 1A 14 DC FF E1 FC 16 | 1D 1D FF 1B 1B 51 1A 1A
000000C0: 1B 1D 17 79 10 46 1F E3 | FA 14 1D 1C 1B 5B 10 3F
000000D0: 17 17 19 1A 1A 15 71 1F | E3 FA BF 1A 1B 19 18 19
000000E0: 1A 89 10 17 E7 17 1A 16 | 63 1F 77 1A 1B 16 15 37
000000F0: 15 15 16 B5 12 19 16 36 | 1F E4 F9 5B 19 18 DD 10Начало файла HEADFX.DAT, где и помещен HEADBIT0.DAT:
00000000: 00 00 00 00 FF 00 00 28 | 00 44 01 0D 00 BB 2C 41
00000010: 00 80 03 20 23 00 80 08 | 55 F5 00 0D 75 01 12 70
00000020: 00 10 A1 00 50 B5 13 74 | 02 20 14 74 02 F0 65 03
00000030: C0 B6 15 F4 03 90 16 74 | 04 60 17 F4 02 DA 30 18
00000040: F4 02 00 19 F4 03 D0 65 | 06 DB A0 1A F4 04 70 1B
00000050: 74 05 40 1C 6B F4 05 10 | 1D 74 06 E0 E5 08 B0 1E
00000060: 7D 74 07 80 1F 08 00 18 | 22 08 20 6B 74 0A 00 21
00000070: 74 0A C0 65 0B 80 22 53 | 75 0A 23 F5 0A 24 75 0B
00000080: 65 0D 80 25 54 75 0C 26 | F5 0C 27 75 0D 27 10 06
00000090: 93 0E B1 29 F4 0F C0 2A | F0 00 F0 01 B1 10 2E 55
000000A0: F5 10 32 75 11 36 F5 11 | 3A 75 12 3E 2F F0 10 93
000000B0: 10 41 74 13 1C 1D 1F 1A | 8F 14 10 00 BF 14 CC 15
000000C0: 16 1D 1D 1B FE 1B 51 1A | 1A 1B 1D 17 F0 0F 39 7F
000000D0: 17 EB 15 14 1D 1C E0 16 | F0 16 17 D1 17 19 10 17
000000E0: 15 5F 18 DC 15 20 17 19 | 8C 18 F0 19 C1 19 D0 19
000000F0: 1A 16 6F 17 9C 18 EB 1B | 16 15 00 1F 16 83 1C 19Видим очень много (почти все) одинакового. Разница, думаю, заключена в том, что файл HEADFX.DAT запакован еще раз этим .jmp2 алгоритмом. Осталось только узнать, что это за .jmp2 алгоритм такой и сделать упаковщик. Упаковщик я, в принципе, и сам могу написать, только вот узнать бы про .jmp2...
JMP2 это просто формат\контейнер для хранения файлов, как например RAR или ZIP, а упакован каждый файл по модифицированному алгоритму LZSS. Поэтому просто раздобыть LZSS упаковщик и применить его к файлам не получиться, его нужно модифицировать.
Спасибо! Все ясно. Можно тогда еще один вопрос? Первые четыре байта (00 00 00 00), я так понимаю, это результат контейнеризирования файлов? Потому как с них начинаются все .PAC файлы
Да, и если можно - какую-нибудь программу для объединения файлов по формату JMP2 
.
Первые четыре байта это просто резерв, начало файла идет после 4-ех нулей. Программы по объединению быть не может, так-как нет оригинального алгоритма упаковки. Это тоже самое что поместить в ZIP архив, файлы, сжатые по алгоритму RAR. Пока не будет полной двоичной совместимости все это бесполезно.
Спасибо еще раз! А как извлечь из .DAT файлов нераспакованные ресурсы?
PS. Извини за оффтоп
Они ни чем не упакованы, в них содержаться RAW данные. Тоесть изображения без палитр и заголовков.
Ох, извини, не из .DAT, а из .PAC. (Вот что значит не спать 2ое суток )
Тогда не понимаю вопроса. PAC это то же, что и EXP. Просто разные расширения. Или ты имеешь ввиду Z.pac в корне диска оригинального Z? Там находятся инсталяционные файлы. На кой нужен распаковщик, если они и так устанавливаются?
Да, я не так задал вопрос. PAC - это ведь контейнеры? Как вытащить оттуда файлы, не разжимая их? То есть получить на выходе нераспакованные файлы?
ЗЫ. Я тебя наверно уже вконец вывел из себя
Siberian GRemlin на oldgames вроде выкладывал ссылку на программу своего друга, которая позволяла просто извлечь файлы в нераспакованном виде. Ну а вообще берешь hex редактор и руками ковыряешь архив, довольно интересное и поучительное занятие 
. Заодно и разберешься как он устроен.
Спасибо!!!
Как я понял, в архиве указывается размер уже расжатых файлов, а как узнать размер упакованных - хз... Теперь до меня дошло, зачем нужна полная двоичная совместимость. Будем ковыряться...
Внимание, вопрос!
В архиве после имени файла идет 4 байта (00 00 00 00), потом 4 байта, назначение которых до меня не дошло, а потом 4 байта, которые означают размер файла. Так вот, что означают эти неизвестные для меня 4 байта?
А если еще подумать? 
. Наводящий вопрос - как распаковщик узнает, откуда ему брать данные для распаковки? Ответ на этот вопрос, даст ответ и на второй.
как узнать размер упакованных - хз...
Нет, я конечно понял, что эти байты означают адрес начала файла, не такой уж я и тупой. Иначе как бы до меня дошло, зачем нужна двоичная совместимость? Скорее так - каким образом они указывают на это начало, т. е. как они кодируют адрес? Поскольку я только первый раз пробую ковыряться в архиве, то прошу сильно ногами не пинать. А если еще учесть, что мне недавно исполнилось 15...
Возраст не имеет значения. Вопроса честно признаться не понял. Разложу по порядку.
- Под двоичной совместимостью понимается что два закодированных\сжатых файла должны на 100% быть идентичными. Если это условие не выполняется, алгоритм не годится и его нужно либо модифицировать либо переписывать.
- Архив JMP2 очень простой, помимо названия файла (макс. размер 8 байт), в нем существуют еще два поля: размер несжатого файла и смещение. Все.
- Размер сжатого файла определяется вычитанием из вышестоящего смещения, нижестоящего. Более подходящих слов сейчас не могу подобрать, но думаю смысл ясен.
Вот и вся структура архива, ничего там кроме содержимого самих файлов не кодируется, остальное математика на уровне 2 класса.
Antares, большое спасибо! Под "адресом начала файла" я и подразумевал смещение (которое, как я понимаю, отсчитывается не от начала архива, а от конца). Так что, в принципе, я разобрался еще пост назад . Только вот насчет смещения сомневался и запутался.
Распаковщик зетовских файлов я написал на коленке где-то за полгода до опубликованного тут. Если бы автор прочитал ззоне форум, то не изобретал велосипед. Хотя, ему тоже респект за работу. Я её не оспариваю.
Что касается самого формата, то там было много заморочек. Сначала я тупил и не понимал, что файлы сжаты т.к. заголовки lbm-файлов были похожи на какое-то расширение этого формата (сам lbm - контейнерный формат) и размер некоторых "сжатых" файлов был больше оригинала(!). Потом самой большой проблемой было узнать метод компрессии из офигенного количества оных, а потом разобраться в конкретной реализации и модификации.
Что касается фразы в переводе с английского: "Каждый файл-ресурс Z запакован по алгоритму LZSS (из семейства LZ77), а затем архивы упакованы в группы по алгоритму .jmp2" - это админ ззоне решил подправить то, как я описал формат, и получилось коряво.
Что касается запаковки. Применяемая модификация LZSS довольна распространена (особенно в кругах амиги, мака) и по запросу гугль выдаёт даже целые исходники. Не думаю, что авторы очень заморачивались в изменении устоявшегося метода запаковки. Да и вообще можно не запаковывать файлы, а ставить в признак запаковки отсутствие оной, что фактически приведёт к разряжению оригинального файла байтом "FF" через 8 байт (конечно, это уже не запаковка получится, но работать должно).
Кстати, на ззоне распаковщик с исходниками, так что читайте код на С - он эсперанто.
Да, так получилось, но есть одно существенное отличие, я выдрал алгоритм из игры, а не использовал чьих то исходников. То есть вся программа от начала до конца, написана мной.
Если бы я ранее обнаружил твой распаковщик, то конечно не стал бы писать свой, это очевидно. Для меня это просто очередное повышение опыта в разборе алгоритмов программ, это интересно. Сам же распаковщик почти не представляет интереса для большинства игроков.
Приятно, что на форуме начинают появляться люди разбирающиеся в программировании.
Разве я говорил, что передрал чужие исходники? Я тоже всё своими головой и ручками делал.
Исходники мне нужны были, чтобы уточнить, почему мой первоначальный вариант правильно распаковывает только начало файла. Просто в описалове алгоритма говорилось о смещении относительно скользящего окна, а оказалось, что в реализации - кольцевого буфера.
И я делал это тоже just for fun.
- Под двоичной совместимостью понимается что два закодированных\сжатых файла должны на 100% быть идентичными. Если это условие не выполняется, алгоритм не годится и его нужно либо модифицировать либо переписывать.
Не всегда. Знаю двух людей, которые разобрали формат видеороликов и написали свои кодировщики для них - у обоих файлы получаются отличные от оригинальных, при перегоне Игровой_Формат-Стандартный_Формат-Игровой_Формат, причём игра их отлично воспринимает и 100% совместимость. Понятное дело, в кодировании видеопотока есть где разгуляться.=)
Что касается запаковки. Применяемая модификация LZSS довольна распространена (особенно в кругах амиги, мака) и по запросу гугль выдаёт даже целые исходники.
А если попробовать запаковать по имеющейся модификации? Алгоритм распаковки ведь, если я правильно понимаю, тот же, и есть большая вероятность того, что игра может понять и такое сжатие.
Так google-и по "lzss.c". Должно много полезной инфы выдать.
Например: oku.edu.mie-u.ac.jp/~okumura/compression/lzss.c
Исходник запаковки LZSS у меня есть, более того, только что я сжал файлы, извлеченные из Main.exp (написал прогу, которая все сделал за меня ), осталось только поместить их в контейнер и запустить winz.exe.
Так в чем проблема? Я помню даже пример писал на ззоне. Сча отковыряю...
// --[DOOR.PAC]--
file_name: DOOR.PAC
sizeof(DOOR.PAC): 77 958 bytes
0x00: ubyte8 magic_number[4] = 0x00000000;
-0x03: ubyte8 file_id[4] = "JMP2";
-0x07: uint32 files_in_package = 0x0A // 10
struct packed_file_id
{
char file_name[12]; // dos_name = 8+'.'+3
uint32 unused; // 0x00000000
uint32 lzss_offset;
uint32 real_length;
};Эх, не понимаю я Сей, на VB кодю. Структуру JMP2 Antares объяснил мне самым подробнейшим образом, за что ему огромное спасибо. Так что сейчас забубеню.
Чтобы отправить ответ, вы должны войти или зарегистрироваться
iMaster → Маленькие программы → Z archive Unpacker
Форум работает на PunBB, при поддержке Informer Technologies, Inc