[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: смотрелка двоичных файлов со структурой



Привет

On 22/03/15 22:50, Artem Chuprina wrote:

> Есть принципиальная разница между программой, которая уже знает форматы,
> и программой, которую можно использовать для реверс-инжиниринга бинарных
> форматов.

Скорее это просто дальнейшее развитие просмотрщика. Для
реверс-инжиниринга всё равно нужен просмотрщик, хотя это может быть и
простой pritf.

> Первый случай решается по принципу UNIX way: берем file, смотрим, что он
> сказал про формат, запускаем смотрелку этого формата.  Всё есть в
> дистрибутиве.  

Речь идёт не о смотрелке различных форматов. Смотрелка это нечто другое.
Например, какая смотрелка у ZIP? Squeeze? Unzip -v? Это не то что
требуется. Нужен именно просмотр бинарной структуры файла.
А таких утилит в дистрибутиве нет.

> Для выяснения, почему и это, скорее всего, плохая идея в общем случае,
> могу порекомендовать поставить wireshark, запустить его и прикинуть
> количество ТОЛЬКО СЕТЕВЫХ форматов, известных ему (он умеет по просьбе

Речь шла не про сетевые форматы, а про файлы, но почему бы и нет?

> юзера, а при наличии стандартного порта и самостоятельно,
> интерпретировать данные как пакеты или поток различных сетевых
> форматов).  И понять, что к КАЖДОМУ нужно было приложить интеллект,
> чтобы прочесть стандарт и проинтерпретировать структуру - она в бинарных
> форматах в большинстве случаев существенно нелинейна.

Понятно, что в некоторых форматах есть логика и для правильного и
полного прочтения некоторых из них понадобится даже немного
попрограммировать. Но даже если показывать хотя бы то что можно показать
без логики, это уже будет полезная вещь. Для сложных форматов
потребуется либо встроенный интерпретатор (можно и перл, почему нет),
либо интрерфейс для внешних программ-плугинов.

> Второй же случай - это задача на программирование.
> Поэтому дешевле всего оказывается короткий скрипт с
> использованием unpack на перле или тикле, весь UI которого сводится к
> выводу в stdout того, что он проинтерпретировал (лучше, наверное,
> параллельно с дампом), а интерпретация написана в коде.

Язык не принципиален, конечно, перл так перл. Хотя, на мой взгляд лучше
что-то компактное, что можно освоить за короткий срок. Или приделать
возможность запускать внешние команды, которые будут показывать это
потом в просмотрщике.

> Цикл работы: написали интерпретатор, запустили, посмотрели на вывод,
> подрихтовали интерпретатор, запустили, ...

Идея с описанной утилитой - сохранить результат этой работы и
предоставить более-менее стандартный интерфейс в приемлемом для других
людей виде.

> Попытки навернуть на это гуй и куцый язык программирования

По-моему я не писал, что требуется куцый язык программирования.
-- 
Сергей



Reply to: