Re: смотрелка двоичных файлов со структурой
Sergey Spiridonov -> debian-russian@lists.debian.org @ Tue, 24 Mar 2015 11:11:45 +0100:
>> Есть принципиальная разница между программой, которая уже знает форматы,
>> и программой, которую можно использовать для реверс-инжиниринга бинарных
>> форматов.
SS> Скорее это просто дальнейшее развитие просмотрщика. Для
SS> реверс-инжиниринга всё равно нужен просмотрщик, хотя это может быть и
SS> простой pritf.
Во-во. Простой printf.
>> Первый случай решается по принципу UNIX way: берем file, смотрим, что он
>> сказал про формат, запускаем смотрелку этого формата. Всё есть в
>> дистрибутиве.
SS> Речь идёт не о смотрелке различных форматов. Смотрелка это нечто другое.
SS> Например, какая смотрелка у ZIP? Squeeze? Unzip -v? Это не то что
SS> требуется. Нужен именно просмотр бинарной структуры файла.
SS> А таких утилит в дистрибутиве нет.
Так. Давай с самого начала. КОМУ и ЗАЧЕМ ИМЕННО нужен просмотр
БИНАРНОЙ СТРУКТУРЫ zip? Ну, кроме человека, который пытается исправить
баг в unzip - тут понятно.
>> Для выяснения, почему и это, скорее всего, плохая идея в общем случае,
>> могу порекомендовать поставить wireshark, запустить его и прикинуть
>> количество ТОЛЬКО СЕТЕВЫХ форматов, известных ему (он умеет по просьбе
SS> Речь шла не про сетевые форматы, а про файлы, но почему бы и нет?
Скинь награбленный поток в файл, будет файл.
>> юзера, а при наличии стандартного порта и самостоятельно,
>> интерпретировать данные как пакеты или поток различных сетевых
>> форматов). И понять, что к КАЖДОМУ нужно было приложить интеллект,
>> чтобы прочесть стандарт и проинтерпретировать структуру - она в бинарных
>> форматах в большинстве случаев существенно нелинейна.
SS> Понятно, что в некоторых форматах есть логика и для правильного и
SS> полного прочтения некоторых из них понадобится даже немного
SS> попрограммировать. Но даже если показывать хотя бы то что можно показать
SS> без логики, это уже будет полезная вещь.
Use case, пожалуйста. В подробностях, с полной конкретикой, от РЕАЛЬНОЙ
задачи. Вот конкретный файл (можно фрагмент файла), мы хотим сказать
программе про него то-то и то-то (КОНКРЕТНО), хотим увидеть то-то и
то-то (КОНКРЕТНО).
А то пока твои вопросы удается проинтерпретировать только как "а почему
в дистрибутиве нет прекрасной гуевой программы, которая делает непонятно
зачем нужную сложную фигню?" Потому и нет, что непонятно, зачем.
SS> Для сложных форматов
SS> потребуется либо встроенный интерпретатор (можно и перл, почему нет),
SS> либо интрерфейс для внешних программ-плугинов.
>> Второй же случай - это задача на программирование.
>> Поэтому дешевле всего оказывается короткий скрипт с
>> использованием unpack на перле или тикле, весь UI которого сводится к
>> выводу в stdout того, что он проинтерпретировал (лучше, наверное,
>> параллельно с дампом), а интерпретация написана в коде.
SS> Язык не принципиален, конечно, перл так перл. Хотя, на мой взгляд лучше
SS> что-то компактное, что можно освоить за короткий срок.
В рамках sysread/unpack/printf перл можно освоить за час.
SS> Или приделать возможность запускать внешние команды, которые будут
SS> показывать это потом в просмотрщике.
Еще пять минут уйдет на освоение system.
>> Цикл работы: написали интерпретатор, запустили, посмотрели на вывод,
>> подрихтовали интерпретатор, запустили, ...
SS> Идея с описанной утилитой - сохранить результат этой работы и
SS> предоставить более-менее стандартный интерфейс в приемлемом для других
SS> людей виде.
В смысле, умный программист формирует парсер бинарной структуры (или
описание ее для парсера, написанного другим программистом - это задачи
одного уровня сложности), а потом садится юзер, указывает программе
файл, каким-то чудом догадывается, откуда взять парсер, указывает и его
тоже, и программа показывает проинтерпретированное содержимое оного
файла оному юзеру?
Тогда скорее не перл, а tcl/Tk. unpack там такой же, а быстро написать
гуй на tcl/Tk удобнее.
Надо понимать, что задача написать парсер, задача описать структуру
более-менее универсальному парсеру, и задача отобразить более-менее
произвольную (конкретную) структуру (уже после парсера) понятным
человеку образом - задачи одного уровня сложности, и намекают на
использование Тьюринг-полного языка программирования.
Упростить задачу отображения можно только сильно сузив класс
отображаемых структур. Тот же wireshark те же известные ему сетевые
форматы отображает не структурой, а текстовой записью. Элементы
структуры там минимальны - он умеет различать запрос и ответ, может
быть, умеет различить два запроса. Но не умеет, например, связать запрос
с ответом именно на этот запрос - как в случае, предусмотренном на
уровне протокола в IMAP, так и в случае SMTP pipeline.
А ты ставишь задачу в общем виде. У нее не может быть работоспособного
частного решения.
>> Попытки навернуть на это гуй и куцый язык программирования
SS> По-моему я не писал, что требуется куцый язык программирования.
Описывая ожидаемые действия пользователя (того, который формирует
парсер), ты описал куцый язык программирования.
Reply to: