Hacker News Digest

Автор, энтузиаст исследования игровых файлов, взялся за анализ Splinter Cell (2002) в поисках вырезанного контента, столкнувшись с загадочным форматом .lin, остававшимся нерасшифрованным 20 лет. Игра, разработанная Ubisoft на Unreal Engine 2, имеет файловую структуру с разделенными картами, где каждый уровень состоит из нескольких .lin-файлов. Автор предположил, что common.lin содержит общие данные для оптимизации размера, подобно shared.map в Halo.

Анализ hex-редактором показал, что файлы содержат zlib-сжатые блоки с форматом {размер_распакованных_данных, размер_сжатых_данных, zlib_блок}. Инструмент для распаковки успешно извлек 64КБ данные, включающие четыре 32-битных целых числа, вероятно, связанные с размерами кэша текстур и буферов вершин. Основная секция содержит ссылки на игровые ресурсы, такие как \menu\menu.unr и \1_1_0Tbilisi.unr, что указывает на структуру, аналогичную Unreal Engine.

• Обсуждение охватывает широкий спектр тем: от форматов файлов и их обратной разработки до влияния на разработку игр и оптимизации.
• Участники обсуждают, как разработчики игр используют формат .lin для оптимизации загрузки уровней, и как это влияет на разработку игр.
• Также обсуждается, какие инструменты и подходы используются для обратной разработки форматов файлов.
• Участники делятся опытом и советами о том, как начать изучать неизвестные бинарные форматы.
• Обсуждаются также влияние этих практик на разработку игр и на то, как разработчики игр должны балансировать между оптимизацией и читаемостью кода.

В задаче Google CTF 2025 webz исследуется уязвимость в патче Google-zlib, который увеличивает размер таблицы Хаффмана и убирает проверки на переполнение. Это позволяет обойти защиту от oversubscription и incomplete set, что ведёт к использованию неинициализированной памяти в таблице.

Уязвимость проявляется в функции inflate_fast, где неверно построенная таблица Хаффмана приводит к чтению за пределами буфера или использованию мусорных данных. Это позволяет перезаписать указатели и выполнить код, манипулируя сжатыми данными. Эксплуатация требует точного контроля над структурой Deflate-блока для управления содержимым таблицы.

• Обсуждается уязвимость в модифицированной версии zlib, созданной специально для CTF-задачи Google, а не в основной библиотеке.
• Участники отмечают сложность и искусственный характер задач Google CTF, но предлагают ресурсы для обучения и тренировки.
• Проводятся параллели между этой уязвимостью и ранее обнаруженной уязвимостью в WebP.
• Подчёркивается, что ошибку можно быстро найти с помощью фаззинга, без необходимости привлечения ИИ.
• Уточняется, что заголовок исходной статьи содержал пометку "[CTF]", указывающую на соревновательный контекст.

FlateView — это инструмент для анализа и визуализации сжатых данных, особенно полезный при работе с алгоритмами сжатия, такими как DEFLATE. Он позволяет разработчикам и исследователям изучать структуру сжатых потоков, выявлять паттерны и оптимизировать производительность сжатия. Например, можно увидеть, как повторяющиеся последовательности байтов заменяются ссылками, что помогает понять эффективность алгоритма.

Инструмент поддерживает различные форматы, включая gzip и PNG, и предоставляет детализированное представление данных, такое как длина блоков, типы кодирования и статистика. Это особенно ценно для отладки проблем со сжатием или для обучения принципам работы компрессии. Практическое применение включает улучшение алгоритмов сжатия в собственных проектах или анализ существующих файлов на предмет избыточности.

• Критика недостаточной визуализации динамических блоков и таблиц Хаффмана в gzip/deflate, отсутствие пояснений к параметрам и символам.
• Запросы на улучшение: добавление легенды для цветов, объяснение формата backreference (например, "x4<-135"), поддержка многоблочных текстов.
• Обсуждение технических проблем: несоответствие подсчёта байтов, отсутствие паддинга, предложения по визуализации Brotli и zopfli.
• Упомянуты альтернативные инструменты для визуализации deflate, отмечена сложность кодирования динамических таблиц Хаффмана.
• Шуточные комментарии о тестовых данных (Bee Movie script) и замечания об опечатках в названиях (zlib vs Z-Lib).

Перестаньте пихать PNG в игры

PNG — хорош для обмена, но плох для текстур: нет мипмапов, кубемапов, premultiplied-альфы и GPU-сжатия (BCn).
При загрузке приходится распаковывать и тратно пересжимать — тормоза и лишняя память.

Что делать
Используйте KTX2 или DDS: заголовок + готовые GPU-данные, можно сжать ещё zlib/lz4.
Для мобильных — Basis Universal, транскодит под нужный формат на лету.

Экспорт
В редакторе кнопки нет; берите готовый open-source-конвертер Zex или пишите свой.

• Нет готового OSS-инструмента, который за один вызов делает мипмапы → BC/ASTC → KTX2+zstd для всех типов текстур.
• Все крупные движки решают это собственным импорт-пайплайном; остальные катят свои скрипты вокруг Compressonator, DirectXTex или старых ISPC-библиотек.
• GPU-ускорение есть только в закрытых NVIDIA/AMD утилитах и части шейдеров Compressonator; открытых «одним бином» всё равно нет.
• Для веба и мобилок часто берут PNG/JPG и конвертят уже на клиенте, жертвуя RAM/бандвидсом; Basis Universal/KTX2 пока единственный разумный компромисс.
• Нейро-компрессия обещает «всё заменить», но пока не в продакшене; старые палитровые форматы в GPU никто не хочет возвращать.