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> По-моему я не писал, что требуется куцый язык программирования. Описывая ожидаемые действия пользователя (того, который формирует парсер), ты описал куцый язык программирования. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uemqub7....@silver.lasgalen.net
