Comments 12
Изумительно. Сигнатуру gzip в мемориз. И за offzip спасибо.
Боюсь, что стоит удалить из мемориза теперь, у zlib'а никогда не было сигнатуры, это потоковое сжатие без каких-то враппов для формата, а тем более magic'а по оффсету 0. Если автор пояснит почему наличие 78 9C гарантирует zlib (deflate?) — будет круто.
Oops, дико лоханулся и посыпаю головую пеплом. Конкретно у zlib'а 0x78 первым байтом (Compression Method and flags по RFC) идет в большинстве случаев. Во втором байте контроль первого + уровень компрессии.
Мои извинения автору и комментатору.
В итоге...
78 01 — No Compression/low
78 9C — Default Compression
78 DA — Best Compression
78 9C — Default Compression
78 DA — Best Compression
Мои извинения автору и комментатору.
Да, я тоже полез разбираться. Сразу для gzip, пусть будет: stackoverflow.com/questions/13112604/find-gzip-start-and-end
stackoverflow.com/questions/9050260/what-does-a-zlib-header-look-like
zlib magic headers
78 01 — No Compression/low
78 9C — Default Compression
78 DA — Best Compression
Разработчики bitsquid недавно начали публиковать серию статей про хранение данных:
А не было ли попыток этот процесс автоматизировать, создать некое подобие IDA Pro для работы с файлами неизвестных форматов?
Не слышал о таких, и думаю это невозможно. Существуют автоматические определители звуковых файлов, или архивов, как в этом случае. Но все они основаны на наличии стандартных заголовков, а это лишь меньшая часть работы с «неизвестными» форматами.
Полностью автоматически разобрать произвольный формат конечно же невозможно.
Но можно:
— сравнить несколько файлов предположительно одного типа и вычислить сигнатуру, поле содержащее размер файла, по полю с размером файла — endianness;
— посчитать энтропию, сообразить, что файл скорее всего запакован и попытаться найти упакованные фрагменты, как вы это сделали при помощи offzip;
— попытаться определить регулярные структуры (вектры, таблицы, и т.п.)
— автоматически сгенерировать дамперы, а для архивов — упаковщики/распаковщики;
— и, наконец, закончив автоматический анализ, дать возможность реверс-инженеру вручную обработать полученные данные. Примерно как в IDA Pro мы можем нажатием 'u' отменить интерпретацию какого-то фрагмента в качестве кода и пометить его, например, как строку.
Иными словами — автоматизировать рутину и объединить кучу утилит командной строки в одном интерфейсе.
Но можно:
— сравнить несколько файлов предположительно одного типа и вычислить сигнатуру, поле содержащее размер файла, по полю с размером файла — endianness;
— посчитать энтропию, сообразить, что файл скорее всего запакован и попытаться найти упакованные фрагменты, как вы это сделали при помощи offzip;
— попытаться определить регулярные структуры (вектры, таблицы, и т.п.)
— автоматически сгенерировать дамперы, а для архивов — упаковщики/распаковщики;
— и, наконец, закончив автоматический анализ, дать возможность реверс-инженеру вручную обработать полученные данные. Примерно как в IDA Pro мы можем нажатием 'u' отменить интерпретацию какого-то фрагмента в качестве кода и пометить его, например, как строку.
Иными словами — автоматизировать рутину и объединить кучу утилит командной строки в одном интерфейсе.
Сейчас посмотрел несколько последних проектов, такое ощущение, что ни разу не было никакой рутинной работы, всё время что-то новое.
Я допускаю, что можно сделать какую-то автоматизацию, но всё равно потом почти в каждом случае придется переделывать вручную, то есть мне кажется, количество ручной работы не уменьшится.
Я допускаю, что можно сделать какую-то автоматизацию, но всё равно потом почти в каждом случае придется переделывать вручную, то есть мне кажется, количество ручной работы не уменьшится.
www.synalysis.net
bitbucket.org/haypo/hachoir/wiki/Home
И еще Advanced hex editor и 010 умеют создавать структуры файлов.
bitbucket.org/haypo/hachoir/wiki/Home
И еще Advanced hex editor и 010 умеют создавать структуры файлов.
Sign up to leave a comment.
Разбор форматов: упакованные хешированные ресурсы