Заголовок ARZ: карта всього файла у 24 байтах

Нова задача

00 · Перетворити сім чисел на карту файла

Минулого разу ми прочитали перші чотири байти як header_word_0 = 2 і header_word_1 = 3. Тепер прочитаємо решту заголовка й знайдемо межі всіх великих секцій ARZ-X3. Вміст записів для цього не потрібен.

Спершу введемо запис (record). В ARZ це скомпільований DBR-запис — окремий набір даних, який може описувати предмет, уміння чи іншу сутність гри. Кожен запис має шлях (record path) — повну назву всередині бази. В ARZ-X3 є три синтетичні записи: records/example/dagger.dbr, records/example/shield.dbr і records/example/strike.dbr. Серед полів (field) першого є enabled = true і weight = 1.5: enabled та weight — назви полів, true і 1.5 — їхні значення.

1. розкласти 24 байти заголовка на сім окремих полів;
2. не плутати зміщення, розмір і кількість;
3. обчислити початок і кінець кожної секції;
4. помітити розрив, накладання або вихід за межі файла.

Спочатку межі полів

01 · Сім полів мають різну ширину й різні ролі

Поле — це домовлена ділянка байтів із власною шириною та роллю. Перші два поля займають по два байти. Наступні п’ять — по чотири. Разом їхні ширини складаються так:

Для перших двох полів використовуємо нейтральні структурні назви header_word_0 і header_word_1. Решту називаємо за їхньою роллю: record_table_offset, record_table_size, record_count, string_table_offset і string_table_size. У самому файлі збережено лише значення; назви допомагають розрізняти їх під час читання.

Перші чотири байти

02 · Два слова мають два різні контракти

Поточний офіційний інструмент запису створює пару (2, 3), але офіційні програми читання не сприймають її як поля magic і version. Вони працюють із двома окремими 16-бітовими словами.

Перше слово відхиляється, якщо воно менше за 2. Оскільки це перевірка нижньої межі, а не точної рівності, поле не є звичайним magic-значенням. У специфікації його спостережену роль названо ревізією сумісності формату. Це тлумачення поведінки, а не відновлена приватна назва поля.

Друге слово інструмент запису складає за допомогою бітових операцій, а програми читання перевіряють його біти окремо. Значення 3 означає 0x0001 | 0x0002, а не «версію три».

0x0001 сумісність шарів

У кожного наступного шару архіву цей біт має збігатися з першим шаром. Що саме означають стани 0 і 1, невідомо.

0x0002 контрольні суми ділянок

Коли біт установлено, досліджений шлях у коді гри обробляє останню 16-байтову завершальну секцію.

0xFFFC маска решти бітів

Ця маска охоплює решту чотирнадцяти бітових позицій; сама вона не є одним бітом можливостей. Поточний інструмент запису залишає ці позиції нульовими. Їхнє історичне чи майбутнє значення невідоме.

Якщо показати всі чотири байти як одне u32 LE, отримаємо 0x00030002, або десяткове 196610. Досліджений код гри не використовує це упаковане число як одну семантичну одиницю чи числову версію.

Число отримує роль

03 · Зміщення, розмір і кількість відповідають на різні запитання

Усі п’ять значень фізично записані однаково — як u32 LE. Різницю створює не вигляд байтів, а поле, у якому вони лежать. У назвах полів ці три ролі позначено як зміщення (offset), розмір (size) і кількість (count).

зміщення — де?

Відстань від початку файла до першого байта секції. Поля record_table_offset і string_table_offset.

розмір — скільки байтів?

Фізичний розмір секції в байтах. Поля record_table_size і string_table_size. У звичайному тексті цей розмір також можна назвати довжиною секції, але назви полів у заголовку використовують суфікс _size.

кількість — скільки елементів?

Кількість записів — і, відповідно, елементів таблиці. Поле record_count.

Формула кінця секції:end — перша позиція після секції.

Кількість не замінює розмір. Елементи таблиці записів мають змінну ширину, тому record_count = 3 не пояснює, скільки байтів займає таблиця. Для цього окремо збережено record_table_size = 120.

Дані та їхні координати

04 · У таблиці записів збережено межі кожного стисненого блока

У самому стисненому блоці не збережено шлях запису, стиснений розмір та розмір після розпакування. Ці значення збережено у відповідному елементі таблиці записів. Тому межі блока визначаємо за таблицею, а не за його вмістом.

В ARZ-X3 є три записи, тому між заголовком і таблицею лежать три стиснені блоки. Як працює стиснення, розберемо в наступній статті; тут достатньо знайти спільні межі цієї області.

Стиснені дані починаються одразу після 24-байтового заголовка, на позиції 0x18. Окремого поля з їхнім розміром немає. Їхній кінець збігається зі значенням record_table_offset = 0x9D — початком таблиці записів.

Трьом записам ARZ-X3 відповідають три 40-байтові елементи, разом 120 байтів. У цьому прикладі вони однакової ширини, бо мають однакову за довжиною вбудовану назву класу (class tag). Формат не гарантує цього для довільного файла, тому заголовок зберігає і record_count, і record_table_size.

Рядки за індексом

05 · У таблиці рядків кожен рядок має числовий індекс

В елементі таблиці записів замість самого шляху збережено лише його індекс у таблиці рядків — 0. Під цим індексом міститься повний шлях records/example/dagger.dbr. Там само під індексом 5 збережено назву поля enabled.

Тепер знайдемо межі цієї таблиці. Додаємо record_table_offset і record_table_size:

Поле string_table_offset також містить 0x115. Обидва значення приводять до тієї самої межі — між секціями немає прихованого проміжку.

Межі таблиці рядків:

Останні 16 байтів

06 · Чотири контрольні суми Adler-32 обчислюються для різних ділянок

Біт 0x0002 у header_word_1 позначає наявність завершальної секції з контрольними сумами (checksum footer). У поточному профілі вона лежить одразу після таблиці рядків; окремого зміщення для неї в заголовку немає. Adler-32 — це алгоритм контрольної суми, який перетворює ділянку байтів на одне 32-бітове значення. У секції зберігаються чотири такі значення у форматі u32 LE.

1. footer+0x00 — усі попередні дані

   Adler32(file[0x00..0x1D3))

   Збережене значення: 0x1B0F58FC.

   Охоплює остаточний заголовок і всі ділянки до завершальної секції.

2. footer+0x04 — таблиця рядків

   Adler32(file[0x115..0x1D3))

   Збережене значення: 0x254C3BAF.

   Охоплює рівно заявлені 190 байтів таблиці рядків.

3. footer+0x08 — стиснені дані записів

   Adler32(file[0x18..0x9D))

   Збережене значення: 0x9240095E.

   Охоплює три стиснені блоки без заголовка.

4. footer+0x0C — таблиця записів

   Adler32(file[0x9D..0x115))

   Збережене значення: 0x3BCC1200.

   Охоплює рівно заявлені 120 байтів таблиці записів.

Гра може послідовно завантажувати кілька шарів ARZ-архівів. Adler-32 працює поступово: його 32-бітовий стан можна продовжити на наступній ділянці байтів, а не починати обчислення спочатку. Тому офіційний інструмент запису, нативний завантажувач і незалежна сувора програма читання використовують ті самі значення завершальної секції за трьома різними контрактами:

спостережено під час запису — записує контрольні суми

Чотири значення збігаються з Adler-32 для показаних вище ділянок.

спостережено під час завантаження — бере початковий стан із файла

Під час завантаження чотири значення з першої завершальної секції копіюються до акумуляторів без повторного обчислення.

правило суворого читання — може звірити всі чотири

Незалежна програма читання може перерахувати суми й відхилити невідповідність. Це суворіше за перевірений шлях гри.

Для кожного наступного шару перший акумулятор продовжується на всіх байтах наступного файла, включно з його завершальною секцією. Інші три продовжуються лише на таблиці рядків, стислих даних записів і таблиці записів. У перевіреному шляху чотири збережені контрольні суми наступних шарів не звіряються окремо з перерахованими.

Карта має зійтися

07 · Перші три перевірки верхньорівневої карти

У перевіреному профілі збірки 24346246 з точною парою (2, 3) великі ділянки розташовані без проміжків. Значення із заголовка не варто приймати на віру: вони мають зійтися між собою й із повним розміром файла. Кожне додавання нижче виконується з перевіркою переповнення; переповнення означає некоректний результат.

1. таблиця не починається всередині заголовка

   record_table_offset ≥ 0x18
0x9D ≥ 0x18

2. таблиці торкаються без розриву

   record_table_offset + record_table_size = string_table_offset
0x9D + 0x78 = 0x115

3. завершальна секція закінчується разом із файлом

   string_table_offset + string_table_size + 16 = file_size
277 + 190 + 16 = 483

Уся картина

08 · Заголовок справді описав увесь ARZ-X3

Ми прочитали лише перші 24 байти, але вже знаємо, де лежить кожна велика секція та де файл повинен закінчитися.

Заголовок визначає межі великих секцій, але не координати окремого блока. Їх читаємо з відповідного елемента таблиці записів. Вміст LZ4-блока теж залишається стисненим. Проте тепер для кожного наступного кроку маємо точну ділянку файла.

Після читання

П’ять опорних думок

1. Заголовок перевіреного поточного профілю ARZ займає рівно 24 байти.
2. Два початкові слова мають поведінку сумісності й можливостей; п’ять полів описують секції.
3. Зміщення, розмір і кількість не взаємозамінні.
4. Кінець секції обчислюється як початок + розмір.
5. Чотири контрольні суми охоплюють окремі ділянки, але завантаження грою й сувора перевірка — різні контракти.