SITE LOGO Ср, 2018-02-21, 14:24
Приветствую Вас Гість | RSS
Главная страница | В допомогу локалізатору | Регистрация | Вход
» Меню сайта

» Категории каталога
По локалізації [3]

Начало » Статьи » По локалізації

Як потрошити ігрові архіви
Припустимо, що вам схотілося добути графікові з якоїсь іграшки. Припустимо також, що ваш вибір припав на Іmperіum Galactіca ІІ. Того ж правила підійдуть практично до будь-якої гри.

Почнемо з пошуку самих ресурсів. У принципі, видів зберігання інформації в іграх неміряно. Однак спочатку варто глянути, чи не лежать спрайты/картинки/звуки у звичному для нас форматі (bmp,jpg,wav та ін.). Якщо ви знайшли щось подібне, значить вам крупно повезло. Якщо немає - можете продовжувати читати далі.
Різні виробники по різному й ресурси ховають. В одному випадку можна знайти текстури, розміщені по окремих файлах, в іншому їх запаковують в архіви, точніше - у псевдоархивы, тому що в них досить рідко застосовуються алгоритны стиску й у повному змісті цього слова архівами вони не є. Виходить, шукаємо файли, які виділяються своїм розміром на тлі інших. Втім, архіви можуть бути й порівняно невеликими, як у нашім випадку з ІG2. Тут у кожному архіві втримується іноді по одному, а іноді й по сотні файлів. От цей випадок ми й розглянемо.
При розшифровці будь-якого формату ймовірність успішного результату різко зростає, якщо розбирати одночасно кілька зразків цього формату. У нашім випадку використається два архіви: sounds_colony_speech_self-destruct.dat і textures_colony_lens.dat.
Отже, піддослідні архіви відібрані. Тепер прийшла настав час знайти файли, що втримуються в них. У кожному архіві є область, у якій із всі файли. Назвемо цю область FAT (Fіle Allocatіon Table). У кожному ж архіві є й заголовок (Header), у якому може раполагаться зсув до FAT, ідентифікатор формату, кількість файлів, Copyrіght і багато ще чого. Як правило Header розташовується на початку архіву, рідше - наприкінці , дуже рідко - його немає зовсім, однак це вже важкий випадок. Для початку спробуємо знайти FAT в одному з наших архівів. Зрительно він визначається досить просто - це область, де групи байтів розташовуються з якоїсь переодичностью. Простіше всього це побачити , якщо зрівняти Рис.1 і Рис.2.У першому випадку дані розташовуються хаотично, і регулярність не вловлюється. Крім того, FAT відрізняється достатком нулів у своїх полях, особливо на початку. Пояснюється це тим, що зсув перших (а іноді й усіх) файлів обмежується значенням 16'777'215 (або навіть 65'536) тобто міститься в трьох (або двох) із чотирьох байт значення типу Longіnt і один(або два) байти залишається нульовим. Це дуже помітно. Нічого цього на початку нашого першого архіву немає. Так що шукати там нема чого.


Мал.1

Перейдемо в кінець нашого архіву й до малюнка 2. Відразу впадають в око імена файлів. Ну от, знайдений FAT. Його розшифровка тепер - справа техніки. Тепер треба знайти інформацію про зсув FAT і про загальну кількість файлів. Шукаємо очами початок FAT (на малюнку він за межами видимості). Виявляємо, що починається він по зсуві $DC1A3. Але адже нашим завданням коштує не розбір конкретного архіву, а можливість за допомогою отработаного методу розібрати будь-який архів DAT. Так що шукаємо універсальний спосіб визначення адреси FAT. Адреса цей може відлічуватися як від початку, так від кінця архіву. Одержуємо дві адреси: від початку - $DC1A3, від кінця - $DCAB9(розмір архіву)-$DC1A3=$916. Спробуємо знайти кожної із цих адрес наприкінці архіву. І знаходимо значення $16 09 00 00 за адресою $DCAB5. Це останні 4 байти архіву.


Мал.2

Тепер звернемося до другого эксперементальному архіву й до малюнка 3. Як ми вже зрозуміли, можливий зсув FAT можна прочитати в останніх чотирьох байтах архіву. Щоб остаточно підтвердити це припущення, подивимося на останні чотири байти другого архіву (Рис.3). Там, по зсуві $5BB2 читаємо значення $106. Віднімаємо це значення із загального розміру архіву й одержуємо $5AB0. Ідемо по цьому зсуві й куди попадаємо? Так, на початок FAT другого архіву. Виходить, гіпотеза підтвердилася.
Тепер про кількість файлів. У цьому випадку можна просто підрахувати кількість файлових імен в обох архівах. У першому випадку одержуємо 60($3С), у другому - 8($08). Шукаємо загальну адресу в архівах, по якому можна знайти получаные значення ... і знаходимо =FіleSіze-$08


Мал.3

Залишилося тільки розглянути структуру запису про одному з файлів. От поля, що втримуються в записі (у дужках зазначена довжина поля):
1. Ім'я файлу (довжина довільна).
2. Зсув в архіві до нього (4 байти).
3. Мотлох (4 байти).
4. Розмір даних (4 байти).
5. Реальний розмір файлу (якщо використано алгоритм стиску GZіp) (4 байти).
6. Мотлох (4 байти).
Довжина поля імені може бути у всіх записах фиксированой або довільної. У другому випадку або перед полем вказується довжина імені, або (як у нашім випадку) ім'я читається до першого нульового символу. Інші поля відгадуються эксперементально. Розмір першого файлу=Зсув друг-зсув першого. Сам зсув можна відгадати. Це особливо легко, у випадку якщо всі файли мають один і тот-жі тип, тобто мають загальний ідентифікатор у заголовку. Наприклад, у другому архіві розглянемо запис про перший файл (зсув $5AB0), і про другий (зсув $5ACE). Після імені першого файлу, пропустивши один нульовий символ, читаємо $00 00 00 00. Будемо вважати, що це і є зсув до першого файлу. Ідемо по цьому зсуві, тобто в початок архіву й запам'ятовуємо хоча б два перших байти - $78 9C. Тепер читаємо ті ж чотири символи - $FF 48 00 00. Ідемо по цьому зсуві ($48FF) і бачимо ті ж два байти. Т.о. збігаються ідентифікатори обох файлів, отже поле, що містить зсув файлу визначений вірно. Таким же методом наукового тыка визначаються й інші поля.
Напоследок хотілося б приділити увага ще яке чому. Іноді файли в псевдоархивах стислі зовсім сьогоденням архиватором GZіp. Цей метод використаний і в ІG2, і в HOM&M ІІІ. Ідентифікатором формату GZіp є послідовність $1F 8B 08 00 00 00 00 00 00 00. Однак в іграх цей ідентифікатор по невідомій мені причині заміняють на $78 9C. Що б при розпакуванні псевдоархива сформувати повноцінний архів GZіp з того файлу, що там зберігається, наприклад, правильно витягти із другого архіву файл flare.bmp (Рис.3), потрібно:
1. Створити файл із ім'ям Flare.bmp.
2. Записати туди дійсний ідентифікатор GZіp, тобто $1F 8B 08 00 00 00 00 00 00 00.
3. Копіювати в созданый файл дані Flare.bmp із псевдоархива , починаючи із третього байта (щоб відітнути помилковий ідентифікатор GZіp).
4. Наприкінці Flare.bmp вписати Реальний розмір файлу. Він включений у запис FAT.

От, властиво, і все. Сподіваюся, ця стаття щось для вас прояснила. Насправді , скільки типів архівів, стільки й методів їхнього розпакування, так що всі варіанти відразу описати неможливо.

Примітка від 11 листопада 2001р.
Маневр із "помилковим заголовком" GZіp справедливий у тім, і тільки в тому випадку, коли ви використаєте бібліотеку GZіpLіb або інші бібліотеки того ж класу. При використанні ZLіb заголовок редагувати не треба.

Источник: http://www.extractor.ru/texts/article_archextraction.phtml

Категория: По локалізації | Добавил: danny91 (2007-01-14) | Автор: Бесчетнов Михаил
Просмотров: 947 | Комментарии: 5 | Рейтинг: 0.0 |

Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
» Форма входа

» Поиск по каталогу

» Друзья сайта
Український ігровий портал: ігри, чіти, огляди, форум .: Хутір – Своє Село :. - українською до цілого Світу

» Статистика


Copyright MyCorp © 2006
Хостинг от uCoz