Re: смотрелка двоичных файлов со структурой
Sergey Spiridonov -> debian-russian@lists.debian.org @ Sun, 22 Mar 2015 17:29:15 +0100:
>> SS> Хочется именно специализированную программу.
>>
>> Мой опыт подсказывает, что задача, возлагаемая описанной программой на
>> юзера, сравнима по сложности с задачей написания парсера формата
>> средствами перлового или тиклового unpack.
SS> На юзера возлагается задача всего лишь запустить программу. Описания форматов
SS> программа уже должна иметь в своей базе данных.
SS> Дописывать и расширять базу данных нужно только для новых и нестандартных
SS> форматов.
SS> Более того, такая программа, по-моему, просто обязана быть частью
SS> дистрибутива.
SS> Хорошая аналогия - программа file.
SS> Ещё такая программа могла бы предоставлять удобный интрерфейс для
SS> реверс-инжиниринга бинарных форматов.
SS> Короче, удивлён что её нет.
Есть принципиальная разница между программой, которая уже знает форматы,
и программой, которую можно использовать для реверс-инжиниринга бинарных
форматов.
Первый случай решается по принципу UNIX way: берем file, смотрим, что он
сказал про формат, запускаем смотрелку этого формата. Всё есть в
дистрибутиве. Ключевые слова - file, которое ты уже знаешь, и mailcap.
Кажется, была и какая-то ориентированная на иксы программа, которая
объединяла функциональность.
Для выяснения, почему и это, скорее всего, плохая идея в общем случае,
могу порекомендовать поставить wireshark, запустить его и прикинуть
количество ТОЛЬКО СЕТЕВЫХ форматов, известных ему (он умеет по просьбе
юзера, а при наличии стандартного порта и самостоятельно,
интерпретировать данные как пакеты или поток различных сетевых
форматов). И понять, что к КАЖДОМУ нужно было приложить интеллект,
чтобы прочесть стандарт и проинтерпретировать структуру - она в бинарных
форматах в большинстве случаев существенно нелинейна.
Второй же случай - это задача на программирование. От того, что это
задача на программирование черного ящика, она легче не становится,
скорее наоборот. Поэтому дешевле всего оказывается короткий скрипт с
использованием unpack на перле или тикле, весь UI которого сводится к
выводу в stdout того, что он проинтерпретировал (лучше, наверное,
параллельно с дампом), а интерпретация написана в коде.
Цикл работы: написали интерпретатор, запустили, посмотрели на вывод,
подрихтовали интерпретатор, запустили, ...
Попытки навернуть на это гуй и куцый язык программирования делают
процесс существенно дороже, причем не столько для программиста оного
гуя, сколько для пользователя, он же программист парсера. Ему придется
бороться с куцым языком программирования в незнакомом гуе. Ну, к гую со
временем привыкнет (тот же xterm, в конце концов, тоже гуй), а куцый
язык программирования никуда не денется.
Reply to: