Потом будет язык описания протоколов. Годно! Очень Годно. Это Lex и Yacc....

помню этой хренью пытался разобрать данные из iwreq. Ниасилил.

Прикольная штука, я что-то похожее навелосипедил для разбора OpenFlow

Он уже умеет работать со сжатыми данными? Или только парсит несжатые заголовки?

нужная вещь, но ide у меня не работает. я так понимаю оно на js и Co. хотя б на java для десктопа б написали.

помню этой хренью пытался разобрать данные из iwreq. Ниасилил.

А что именно не получилось?

Он уже умеет работать со сжатыми данными?

Вроде б около года как умеет.

нужная вещь, но ide у меня не работает.

А как именно не работает, можете показать / рассказать?

я так понимаю оно на js и Co.

Технически - на TypeScript и Scala.js. Но компилируется все в итоге в JavaScript, да.

хотя б на java для десктопа б написали.

На Java тоже есть, внезапно. И консольная есть. И вообще еще много чего есть ;)

А как именно не работает, можете показать / рассказать?

ну серый экран и ничего не происходит. ни кнопок ничего.

На Java тоже есть, внезапно. И консольная есть. И вообще еще много чего есть ;)

ну я бегло, по тому что тут было в новостях, посмотрю попозже что там есть.

Он уже умеет работать со сжатыми данными?

Вроде б около года как умеет.

Примеры есть? В официальных примерах на ZIP, RAR, LZH, GIF, PNG я ничего такого не нашёл (с полгода назад).

ну серый экран и ничего не происходит. ни кнопок ничего.

В браузере сейчас обычно есть JavaScript-консоль (открывается по F12) - если какие-то ошибки сыпятся, то, как правило, там видно. Можете посмотреть и прислать? Браузер, кстати, какой?

Примеры есть?

https://github.com/kaitai-io/kaitai_struct_formats/blob/aac5217e3c53ab6765ebf...

В официальных примерах на ZIP, RAR, LZH, GIF, PNG я ничего такого не нашёл (с полгода назад).

Оно там вроде бы и не нужно. Как бы цели написать произвольный декомпрессор нет.

Оно там вроде бы и не нужно. Как бы цели написать произвольный декомпрессор нет.

А я бы с радостью сжал какой-то файл дефлейтом (картинку, текст) и разглядывал бы, во что оно превратилось, с подсветочкой по байтикам и битикам. Или не про то сказка?

А я бы с радостью сжал какой-то файл дефлейтом (картинку, текст) и разглядывал бы, во что оно превратилось, с подсветочкой по байтикам и битикам. Или не про то сказка?

Это сейчас даже можно сделать - благо теперь unaligned bits есть. Посмотреть вполне даже получится, только с практической точки зрения это все относительно неинтересно. KS на каждый чих генерирует отдельную структуру, соответственно, все эти блоки-ссылки, которые в алгоритме нормального компрессора-декомпрессора появляются в памяти один раз мелькнув в регистре, осядут в памяти каждый отдельной здоровой структурой.

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

Т.е. с учебной точки зрения (или с точки зрения отладки алгоритмов сжатия), наверное, полезно, а с практической точки зрения - проще вызвать готовый алгоритм.

с практической точки зрения - проще вызвать готовый алгоритм

Со своей практической точки зрения, я хочу получить раскрашенный хекс-дамп вроде https://i.stack.imgur.com/8f1oP.png, тыкать в поля, видеть их названия и значения в десятичном виде, иметь возможность перейти по оффсету (абсолютному или от границы структуры, в зависимости от формата), получить какие-то простые вычисления (прибавить к оффсету размер структуры + выдрать из какого-то массива нужный элемент). Зачем? Мне надоело красить вот такие скриншоты руками или писать утильки для рисования, а на практике это очень даже полезно и помогает восприятию.

https://github.com/kaitai-io/kaitai_struct_formats/blob/aac5217e3c53ab6765ebf...

Спасибо.

Оно там вроде бы и не нужно. Как бы цели написать произвольный декомпрессор нет.

А как ещё можно парсить формат, все важные данные внутри которого сжаты? Можно, конечно, дать на выходе блоб, пускай мучаются с ним, как хотят. Но когда ставится задача распарсить, обычно этого недостаточно.

Пример. Есть непонятный формат рисунков из старой игры. Предположительно, RLE-сжатие, но детали неясны. Нужно получить картинку в PPM. Поможет ли тут Kaitai Struct, или его хватит только на несжатый заголовок? Распакованный рисунок для одного из файлов имеется.

Второй пример. Есть непонятный формат анимации из той же игры. Первый кадр закодирован RLE как выше, последующие, предположительно, используют дельта-кодирование. Нужно получить набор кадров в PPM. Поможет ли Kaitai Struct? Распакованные кадры одного из файлов имеются.

Третий пример, абстрактный. Есть непонятный формат кодирования двумерных изображений, деталей которого авторы не раскрывают, но известно, что для распаковки используют Boost. Может ли Kaitai Struct чем-то помочь здесь для преобразования его в PPM?

Хочется странного

А может ли сабж оказаться полезным при разборе не файла, а сетевого потока, где начало осмысленной порции данных не обязательно находится в начале пакета, и его надо быстро искать по неким маркерам? Или, может, более-менее универсальный парсер таких данных можно сделать как расширение к KS?..

Хотел сегодня пощупать визуализатором (https://github.com/kaitai-io/kaitai_struct_visualizer) RIFF wav файл в отладочных целях. Нужно было понять в чем проблема. Сунулся, а этот визуализатор на руби. И предлагается погружаться в чудный мир фанов этого языка, качать его рантайм, пакетный менеджер, ставить, настраивать... Подумал я, да и плюнул на этот пионерский полуфабрикат с зоопарком язычков.

А на нём можно описать какой-нибудь интерфейс для плагинов (таблицы с указателями на функции и т.д.)?

С подключаемыми модулями выглядит гораздо интереснее.

010 Editor

я хочу получить раскрашенный хекс-дамп [...]

Чем web IDE сейчас отличается от того, что вы описали? По-моему, оно делает все это и многое другое уже сейчас.

Пример. Есть непонятный формат рисунков из старой игры. [...] Нужно получить картинку в PPM.
Второй пример. [...] Нужно получить набор кадров в PPM.
Третий пример, абстрактный. [...] Может ли Kaitai Struct чем-то помочь здесь для преобразования его в PPM?

Все три примера плюс-минус одинаковы и упираются в то, что нужно угадать неизвестный алгоритм компрессии/кодирования, а не разбирать какую-то структуру. Структуры-то по сути и нет: вам никогда не понадобится раскладывать в памяти этот поток на классы/структуры, алгоритм в реальной жизни будет stateful и будет выдавать поток байт на выходе, а не структуру.

Угадывать алгоритм декомпресии с помощью KS можно, но относительно неэффективно - хотя бы потому, что смотреть захочется не на промежуточные структуры, а на конечный результат. Поэтому для игр, например - в 99.9% случаев проще взять дизассемблер/декомпилятор и выдрать этот алгоритм из кода, а не угадывать. Для каких-то более специфичных штук типа реверсинга алгоритмов, зашитых в железках - скорее всего экспериментировать с кодом на императивном языке тоже будет эффективнее.

А может ли сабж оказаться полезным при разборе не файла, а сетевого потока, где начало осмысленной порции данных не обязательно находится в начале пакета, и его надо быстро искать по неким маркерам?

Открываете поток, описываете алгоритм поиска маркера кадра / sync bits / whatever (если поток более-менее адекватный типа MPEG / Ogg / т.п. - как правило, это очень просто), затем вызываете KS на каждый найденный маркер.

Если есть желание более тесной интеграции, можно придумать в KaitaiStream какие-то методы для поиска маркеров - welcome, давайте думать вместе?

А на нём можно описать какой-нибудь интерфейс для плагинов (таблицы с указателями на функции и т.д.)?

Поясните чуть более подробно, что имеется в виду? Прямо сейчас по сути возможность подключать произвольные внешние классы есть через opaque types.

нужно угадать неизвестный алгоритм компрессии/кодирования, а не разбирать какую-то структуру. Структуры-то по сути и нет

Этот поток имеет определённую структуру. Для RLE это что-то вроде «волшебное число-длина повторяемого фрагмента-число повторений-повторяемый фрагмент». Для LZ — «ссылка-длина». И так далее. Самое интересное начинается, если за сжатым блобом идёт очередной заголовок с параметрами следующего блоба.

экспериментировать с кодом на императивном языке ... будет эффективнее

Тогда в каких случаях KS эффективнее императивного языка?

Этот поток имеет определённую структуру.

Это не структура в понимании того, что ее нет смысла укладывать в какой-то struct / class и иметь к ней API. Никому в голову не придет построить из этого в памяти дерево объектов и потом долго этим гордиться. Все алгоритмы в реальной жизни, которые будут с этим работать, будут производить преобразование на лету: поток→поток, все.

Тогда в каких случаях KS эффективнее императивного языка?

В случаях, когда нам таки надо делать не преобразование, а построить модель данных в виде графа объектов, с которыми потом будут уже работать алгоритмы. С теми же картинками / анимациями - это задача парсинга внешнего контейнерного формата, когда мы получаем более-менее аккуратный массив кадров, каждый кадр со своей метаинформацией (всякие там ширина/высота/смещения/горячие зоны/палитры, etc) и картинкой (которую можно раскодировать в битмап, если это нужно, вызвав соответствующий алгоритм декомпрессии).

GreyCat, Цветовая разметка дампа - полезная фича. Сабж могут использовать не только для генерации кода, но и для изучения форматов.

Можно примеры форматов анимации и архивов, когда известен алгоритм распаковки, но требуется реверсить метаинформацию? Или когда метаинформацию можно для чего-то использовать без расшифровки блобов?

получаем более-менее аккуратный массив кадров

Достаточно часто есть небольшое число ключевых кадров, а все остальные привязаны к предыдущим. Чтобы получить один, надо распаковать несколько десятков, если не сотен.

Допустим, есть некая программа, которая подгружает плагины, хранящиеся в виде динамических библиотек. В манифесте плагина указано имя функции инициализации. Программа во время запуска вызывает её и передаёт указатель на структуру, которая содержит что-то вроде этого:

struct ApiTable {
    void (*SomeApiMethod1)(SomeType);
    int  (*SomeApiMethod2)(SomeOtherType);
}

Можно примеры форматов анимации и архивов, когда известен алгоритм распаковки, но требуется реверсить метаинформацию? Или когда метаинформацию можно для чего-то использовать без расшифровки блобов?

Мир, внезапно, не ограничивается картинками и анимацией. Мы в целом изначально использовали KS для реверсинга протоколов аквариумных контроллеров. Железка - залитая компаундом бескорпусная микросхема, прошивку вытаскивать очень дорого. Протокол угадывается статистическим анализом нескольких тысяч пакетов.

Есть куча примеров реверсинга файлов с логами, базами данных, файловыми контейнерами, байткодом и тучей всего, где угадывание структуры вполне возможно и адекватно, а шифрование блобов или отсутствует, или вполне себе стандартное.

Как вы себе представляете вызов C API/ABI из, скажем, JS-машины в браузере, да или даже из JVM, выполняющейся на какой-нибудь смарткарте?

KS позволяет обращаться к коду на целевом языке. В коде на целевом языке (если это конкретно взятый C++, скажем), никто не мешает сделать dlopen / LoadLibrary и вызывать какие угодно функции оттуда, а затем, если это нужно, результат передать обратно на допарсинг в KS.

Алсо, см. https://github.com/kaitai-io/kaitai_struct/issues/51

Чем web IDE сейчас отличается от того, что вы описали? По-моему, оно делает все это и многое другое уже сейчас.

Во-первых, оно мне с радостью сообщает, что мой браузер устарел, хотя я его поставил меньше месяца назад. Во-вторых - это веб со всей моей неприязнью к нему. А в третьих - где там посмотреть на сам дефлейт? В предлагаемом зип-семпле я не увидел данных. Производит впечатление чего-то очень глючного и неюзабельного.

нет смысла укладывать в какой-то struct / class и иметь к ней API. Никому в голову не придет построить из этого в памяти дерево объектов и потом долго этим гордиться. Все алгоритмы в реальной жизни, которые будут с этим работать, будут производить преобразование на лету: поток→поток, все

Т.е. перед нами скорее парсер/десериализатор, нежели инструмент для разбора непонятных бинарников? Потому что описание из заголовка наводит мысли о реверсинге. Если это так, то может изменить формулировку?

Состоялся релиз Kaitai Struct 0.7 — языка и набора программ, предназначенных для описания и разбора всевозможных бинарных форматов (например, сетевых пакетов, файлов с изображениями/аудио/видео, баз данных, архивов, контейнеров и т. д.).

Можно примеры форматов анимации и архивов,

Мир, внезапно, не ограничивается картинками и анимацией.

Если бы их не было в первом посте, вопрос не возник бы :)

Расшифровка проприетарных форматов — дело нужное. Но так уж вышло, что интересующие меня форматы описывают зависимости от 2 параметров на равномерной сетке и используют сжатие. Поэтому я их назвал «картинками».

Во-первых, оно мне с радостью сообщает, что мой браузер устарел, хотя я его поставил меньше месяца назад.

Т.е. оно совсем не работает? Можно чуть больше подробностей, какие-то сообщения об ошибках?

А в третьих - где там посмотреть на сам дефлейт? В предлагаемом зип-семпле я не увидел данных.

Что значит - «посмотреть на дефлейт»? Если вам интересен результат и дальнейшая работе по разбору того, что получится - process: zlib - и вперед. Если интересен процесс разбора deflate-потока на группы бит - то в теории можно описать все это на ksy: unaligned bit integers есть, условные конструкции есть, коллекции есть. С точки зрения обучения тому, как работает LZ и Huffman - наверное, даже познавательно.

Т.е. перед нами скорее парсер/десериализатор, нежели инструмент для разбора непонятных бинарников? Потому что описание из заголовка наводит мысли о реверсинге. Если это так, то может изменить формулировку?

Вы не поверите, но зачастую народ применяет наш скромный «парсер/десериализатор» вполне успешно именно для «разбора непонятных бинарников», «реверсинга», форензика, анализов малвари и еще много чего.

Расшифровка проприетарных форматов — дело нужное. Но так уж вышло, что интересующие меня форматы описывают зависимости от 2 параметров на равномерной сетке и используют сжатие. Поэтому я их назвал «картинками».

Из того, что я вижу - в современном мире «компрессия» и «бинарные форматы» чем дальше, тем больше разделяются. Если раньше примерно каждая первая игрушка придумывала свой собственный формат сжатия картинок с переподвывертом, то сейчас народ в лучшем случае придумает свой контейнерный формат, а картинки будут сжаты JPEG / PNG / S3TC. Единственное, где есть еще какое-то разнообразие - это модели, но там все как раз прекрасно разбирается в структуры.

Когда говорят про медиа, в 99% случаев народ интересует метаинформация, а не битмапы или кадры потока как таковые - т.к. именно с метаинформацией гигантский бардак и шатание, 100500 несовместимых друг с другом вариаций EXIF / IPTC / XMP и т.п.

Цветовая разметка дампа - полезная фича

Да она вроде бы есть - и в web IDE, и в консоли (субъективно - в консоли реально удобная, которая показывает именно древовидность структуры).

Так и запишем. Для анализа легаси-архивов непригоден. Обидно.

Mileage - он такой, всегда varies. Кому пригоден, кому нет. Вот сейчас вы чем пользуетесь? Я так понимаю, если не подглядывать в код (хотя зачем в ситуации с играми не подглядывать? если уж дата-файлы есть - то и код скорее всего тоже доступен) - то гипотезы алгоритмов декомпрессии проще всего проверять какими-нибудь прототипами скриптиков на Python/Ruby/Perl/PHP?

Надо засовывать библиотеку в дизассемблер и вдумчиво смотреть.

Ну вот собственно о чем и речь.

Т.е. оно совсем не работает? Можно чуть больше подробностей, какие-то сообщения об ошибках?

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

Что значит - «посмотреть на дефлейт»? Если вам интересен результат и дальнейшая работе по разбору того, что получится - process: zlib - и вперед. Если интересен процесс разбора deflate-потока на группы бит - то в теории можно описать все это на ksy: unaligned bit integers есть, условные конструкции есть, коллекции есть. С точки зрения обучения тому, как работает LZ и Huffman - наверное, даже познавательно.

Как работает Хаффман, семейство алгоритмов Лемпеля-Зива или устроен контейнер zip-файлов я прекрасно знаю. К сожалению, когда я учился, разноцветных хекс-дампов не было. Но тема эта не обучении или познавательности, а о некотором творении, которое могло бы это прочитать и представить в каком-то визуальном виде. Что я хочу видеть: заголовки zip-контейнера (с разными цветами, хинтами, в некоторых случаях размер битового поля, если такое применимо), потом некий кусок, скажем, синенького цвета «а это у нас кусок дефлейта», на который можно клацнуть и увидеть заголовок (если есть). кнопку «распаковать в отдельный стрим» и скажем зелененький кусок «а это у нас кусок хаффмана, тут деревья, а тут чуть дальше светлозеленым - это сами пути по этому дереву». Конечно, это мое виденье, оно может быть не совсем корректным, быть можно кто-то сразу захочет видеть ЛЗ-структуру поверх хаффмана сразу. И вот тыкая на кусочки данных Хаффмана, я хочу подсветку значений из дерева Хаффмана и подсветку байтиков в распакованном потоке.

Нет, я не прошу «зделойте мне». Просто если я увижу что-то такое, красивое, с помпонами и драконами, то я точно буду знать, что стоит инвестировать свое время в изучение этих всяких «ksy: unaligned bit integers», что с таким инструментом реально можно сделать что-то съедобное (если к тому времени этот файл будет читаемым, а не превратится в мешанину нечитаемых костылей). А то средств описания форматов существует великое множество, если я не ошибаюсь, вы сами в одной из лекций показывали XML-based чудо, от внешнего вида которого опускаются руки.

Вы не поверите, но зачастую народ применяет наш скромный «парсер/десериализатор» вполне успешно именно для «разбора непонятных бинарников», «реверсинга», форензика, анализов малвари и еще много чего.

Вы не поверите, но и при помощи топора можно отремонтировать телевизор, но... Несколько неудобно. Вот товарищ рядом со своим легаси-форматом тоже пришел к такому выводу.

Единственное, где есть еще какое-то разнообразие - это модели, но там все как раз прекрасно разбирается в структуры

Возможно вы являетесь богом реверсинга, что одного взгляда на хекс-дамп достаточно для разбора формата. Это очень круто, напишите туториал об этом.

У самого было много раз так, что пока в чем-то не разбираешься, то судорожно ищешь инфу, все говорят «да эт просто», а ты бьешься головой об стену и не понимаешь куда идти дальше, клянешься всем вокруг и самому себе написать книгу об этом, а когда всеже осиляешь - уже и не знаешь о чем писать, ведь «да эт просто».

то гипотезы алгоритмов декомпрессии проще всего проверять какими-нибудь прототипами скриптиков на Python/Ruby/Perl/PHP?

А если именно их и надоело писать? Я рассматрива(л) эту тулзу как средство избавления от этого.

Вот за это и многое другое, я и ненавижу «веб-технологии».

Ну, то есть сообщения об ошибках вы показывать не хотите (или хотя бы явно сказать, что все настолько плохо, что их нет, например), проще устроить истерику и обвинить во всех грехах «веб-технологии». Окей.

У web IDE совершенно адекватный автор, который весьма бодро реагирует на баг-репорты и уж тем более на такие критичные, когда все сломалось и не работает.

Нет, я не прошу «зделойте мне».

Из вышеописанного 70-80%, как мне кажется, есть прямо сейчас, с точностью до названий кнопочек и цветовой гаммы. Остальные 20-30% заключаются в том, что надо описать deflate stream и, если это нужно, подключить к нераспакованному массиву байтов body в zip-файле. Насколько я помню, там все уложится в 3-4 типа - сам блок с признаком, тело uncompressed блока, тело compressed блока, возможно еще отдельно префиксы вынести. А, еще bindump'а нет, есть только hexdump - но и это можно сделать.

В целом хорошо, принял, идея годная. Если кто-нибудь не сделает до меня - как-нибудь сделаю.

то я точно буду знать, что стоит инвестировать свое время в изучение этих всяких

Ознакомиться с базовыми понятиями в KS, по-моему, занимает минут 15. Мы уже общаемся тут сильно дольше.

А то средств описания форматов существует великое множество,

Прямых аналогов KS я на данный момент не знаю.

Есть множество реализаций чего-нибудь внутри конкретных языков (Construct, Preon, BinData, bitstruct, BinPAC и т.п.) - они все, соответственно, сильно проще KS, привязанные к конкретному языку и, за редкими исключениями, интерпретируемые (=медленные). Ни о каких разноцветных хекс-дампах тут речи не идет, строить дампы некому, если только сам не засучишь рукава и не сделаешь дампер.

Есть куча «продвинутых хекс-едиторов» (вроде 010 или Hexinator) - но они, соответственно, исключительно на «посмотреть» (да и то, это самое «посмотреть» функционально там весьма убогое).

Есть n-ное количество мертворожденных / академических проектов вроде DataScript, BitBlaze, PacketTypes, Tupni, PADS и т.д. Как правило умирают, как только авторы написали статью и кончились деньги по гранту.

если я не ошибаюсь, вы сами в одной из лекций показывали XML-based чудо, от внешнего вида которого опускаются руки.

О как %) А можно чуть поподробнее? Я какие-то лекции вел?

У самого было много раз так, что пока в чем-то не разбираешься, то судорожно ищешь инфу, все говорят «да эт просто»

Я вроде бы нигде не говорил, что это «просто» или «быстро». Любые разбирательства требуют определенных знаний предметной области, практик из аналогичных решений, а еще тучи времени, чтобы перепробовать кучу гипотез. Главная польза от KS - ускорять этот самый процесс опробования гипотез.

А если именно их и надоело писать? Я рассматрива(л) эту тулзу как средство избавления от этого.

Еще раз: KS построит дерево объектов (в алгоритмах сжатия это будут всякие префиксы, группы, ссылки, литералы и т.д.) - а дальше-то что? Вам, вероятно, нужно смотреть на результат разжатия, а не просто на дерево объектов. А результат получается из дерева после применения какого-то алгоритма обхода этого дерева. Его все равно писать.

Ну, то есть сообщения об ошибках вы показывать не хотите (или хотя бы явно сказать, что все настолько плохо, что их нет, например), проще устроить истерику и обвинить во всех грехах «веб-технологии».

Когда падает приложение на сишке, все исчезает и мы видим «сегментейшен фаулт». Когда падает приложение на педоне или жаве, то мы видим 2 страницы бектрейса. Когда падает приложение на «веб-технологиях», я понятия не имею где искать ошибку (в ИЕ4 выскакивало окошко), было ли это так задумано и вообще, а может мне сменить браузер/ос/страну для начала? Про желтый баннер сказано. Возможно, что так оно и должно быть.

У web IDE совершенно адекватный автор, который весьма бодро реагирует на баг-репорты и уж тем более на такие критичные, когда все сломалось и не работает.

Единственное, что я могу сделать - записать видео, как я это вижу. А дальше сами думайте, все сломалось или «так и задумано».

Насколько я помню, там все уложится в 3-4 типа - сам блок с признаком, тело uncompressed блока, тело compressed блока, возможно еще отдельно префиксы вынести.

Так сделай, покажи свое кси-кунфу. Потому что автору такие вещи легко даются, а для меня - китайская грамота.

А, еще bindump'а нет, есть только hexdump - но и это можно сделать.

Не проблема, я сам сделаю, если есть какой-то интерфейс до внешнего визуализатора, который бы рисовал хекс/дек/окта/бин-дамп, через который можно было бы как-то скормить готовую расскраску, то было бы вообще прекрасно. Я знаю, что как-то у вас это реализовано, но я не копался в реализации. Там независимое приложение и протокол «раскрашивания» между ними, или библиотека и обязательно внедрение в приложение? Если протокола нет, но мысль кажется интересной, то можем обсудить. Это мне интересно.

Есть куча «продвинутых хекс-едиторов» (вроде 010 или Hexinator) - но они, соответственно, исключительно на «посмотреть» (да и то, это самое «посмотреть» функционально там весьма убогое).

Вот Хексинатор видел только по рекламе, за него не скажу, а вот 010 штука очень даже годная, с простым языком описания, с возможностью условий/вывода ошибок/расскраски. Одна из крутых фишек в том, что в комплекте репозитарий пользовательских темплейтов. Нашел его, когда надо было разобрать достаточно распространенный, но плоходокументированный формат. Интерфейс, конечно, мог бы быть и получше, но меня эта штука почти всем устраивает. И да, еще раз хочу сказать спасибо за тот обзор хекс-редакторов, что вы однажды устроили.

О как %) А можно чуть поподробнее? Я какие-то лекции вел?

На ютубе есть лекция по сабжу. Если не вы, то кто-то явно из приближенных вел.

Вам, вероятно, нужно смотреть на результат разжатия, а не просто на дерево объектов. А результат получается из дерева после применения какого-то алгоритма обхода этого дерева. Его все равно писать.

Ну как минимум, я хочу видеть все эти деревья, дальше я сам решу, что с этим делать.

И очень хочется не «вызвать внешний распаковщик дефлейта», а именно средство, которое пробежится по разобранным структурам и само распакует

Когда падает приложение на «веб-технологиях», я понятия не имею где искать ошибку

Step 1 (с которого я бы начинал вообще любой баг-репорт): описать среду, в которой вы это запускаете. Для веба, очевидно, это в первую очередь ОС, браузер, какой-то набор настроек браузера, который может быть критичным (ну, не знаю, может быть у вас весь JavaScript жестко заблокирован, или стоит какой-нибудь плагин, который запрещает загрузку чего-либо из каких-нибудь непроверенных источников).

Step 2. Если это все-таки более-менее современный браузер, то нажать F12 (открыть консоль), увидеть там «две страницы бектрейса» и скопировать его. В идеале - еще сходить во вкладку типа «Network», посмотреть, есть ли ошибки загрузки файлов там (например, не знаю, злой провайдер почему-то решил заблокировать загрузку чего-нибудь), если есть - то тоже скопировать URL и коды ошибок.

Даже если шаг 2 даст вообще ничего - это уже тоже тема для разговора. Я знаю, что у Тамаша есть, например, специальная отладочная версия, увешанная всяким логгингом - от пришлет URL, можно будет попробовать диагностировать с ней.

Так сделай, покажи свое кси-кунфу.

Я уже согласился :) Проблема в том, что у меня есть час-два в день максимум на этот проект, и того, что можно сделать как-то на порядки больше, чем того, что успеваю.

Не проблема, я сам сделаю, если есть какой-то интерфейс до внешнего визуализатора, который бы рисовал хекс/дек/окта/бин-дамп, через который можно было бы как-то скормить готовую расскраску, то было бы вообще прекрасно. Я знаю, что как-то у вас это реализовано, но я не копался в реализации. Там независимое приложение и протокол «раскрашивания» между ними, или библиотека и обязательно внедрение в приложение? Если протокола нет, но мысль кажется интересной, то можем обсудить. Это мне интересно.

Все 3 существующих на данный момент визуализатора реализованы по одному и тому же принципу:

• Вызывается ksc с флагом --debug, ksy компилируется в java/js/rb-файл
• Файл подгружается в рабочую среду визуализатора как код (в случае Java - еще и компилируется java->class, в случае JS - подгружается в отдельный jail)
• Делается вызов полученного парсера, на вход подается конкретный файл.
• На выходе получаем:
  • дерево объектов (которое можно обходить средствами reflection языка и/или с помощью debug info, сгенерированных --debug)
  • map'ы и массивы с информацией о том, где именно в потоке расположен тот или иной атрибут конкретного объекта (генерируются тоже только с --debug)
• Визуализатор рисует дерево, рисует хексдамп(ы), отмечает в нем (них), где расположены интересующие атрибуты.

Такой подход позволяет использовать один и тот же компилятор по сути и для работы, и для отладки.

Можете теперь более подробно пояснить, где предполагалось иметь «протокол раскрашивания»?

На ютубе есть лекция по сабжу. Если не вы, то кто-то явно из приближенных вел.

https://www.youtube.com/watch?v=bV3malGzVRo - это? Это не лекция, это весьма поверхностно-обзорный доклад с PHDays, где самому KS посвящено минут 10 по сути. Просто было еще n-ное количество воркшопов (большой русскоязычный на ZN и штуки 3-4 англоязычных поменьше) - но там если у кого что не работало - мы как раз на месте разбирали.

или стоит какой-нибудь плагин, который запрещает загрузку чего-либо из каких-нибудь непроверенных источников

В общем, писать багрепорты для веба - не имеет смысла. Что и требовалось доказать.

Можете теперь более подробно пояснить, где предполагалось иметь «протокол раскрашивания»?

Конечно. В предложенной схеме надо, если я правильно понимаю, каждый раз перекомпилировать модель, потом перечитывать файл/перезапускать парсер. Может ли произойти такое, что где-то тут будет сегфолт? Так как в процессе разбора неизбежны ошибки, попыток написать разборщик будет много, а терять окошко хексдампа очень бы не хотелось (например, у нас состояние памяти текущего процесса). Еще один аспект, если я правильно понимаю, то разобрать NTFS раздел будет непросто, ведь мы же не сможем засосать в память пару терабайт, да к тому же сделать из этого всего объекты? Наш процесс разрастется и привет ООМ-киллеру.

Но это мои предположения, надеюсь я ошибаюсь.

Мне бы хотелось все это делать из некоторого внешнего процесса. Это одновременно позволило бы изолироваться от возможных ошибок/проблем, вместе с тем не зависеть от конкретного парсера.

Теперь к практике. Вот есть у меня примерно такой биндамп:

open(d,$ARGV[0]) || die "Usage: $0 filename, error '$!'";
my($of,$l,$cu,$bu,$bt,$bb)=(0,4,0);
while(1){my $by=getc(d);last if not defined $by;
$bu.=($cu?" ":"").unpack("B8",$by);$bb=unpack("C",$by);$bt.=$bb<32||$bb>127?'.':$by;$cu++;
if($cu==$l){printf("%.8x: %s | %s\n",$of,$bu,$bt);$bu=$bt="";$of+=$l;$cu=0;}
}
if($cu){printf("%.8x: %s%s | %s\n",$of,$bu," "x(9*($l-$cu)),$bt);}

На разработку этого ушли миллионы человекочасов, данный вьюер обладает нужной функциональностью, но вот не умеет раскрашивать то, что он показывает. Как добавить нужную функциональность?

Самое простое решение, это слушать сокет, ожидать команды вида «оффсет:бит, размер, цвет», сложить это уже в какую-то внутреннюю мапу (как мне удобно, а то может и не складывать, если данных слишком много, то можно ограничиться только размерами текущего окна, если оно есть), при дисконнекте или команде «коммит» начинаем отрисовку/перерисовку. Так как возможен скроллинг или изменение данных (при просмотре памяти), то протокол лучше сделать двунаправленным.

В принципе, можно навелосипедить что-то свое, просто у нас будет некий «адаптер» между парсерами и моим крутым и биндампером, протокол будет проприетарным по принципу «больше никому не нужен». Может быть я просто загоняюсь и это вообще как-то стандартизировать не стоит, но в этот момент можно подумать о других, уже написанных вьюерах.

https://www.youtube.com/watch?v=bV3malGzVRo - это? Это не лекция, это весьма поверхностно-обзорный доклад с PHDays, где самому KS посвящено минут 10 по сути.

Да, оно. Мне оно было полезно, хотя я лишний раз убедился в ненужности KS. Особенно понравился пример с XML.

В предложенной схеме надо, если я правильно понимаю, каждый раз перекомпилировать модель, потом перечитывать файл/перезапускать парсер.

Так точно. Разве что «перечитывать файл» не обязательно, можно использовать тот же поток.

Может ли произойти такое, что где-то тут будет сегфолт?

Не должен. Может быть exception - в режиме с --debug.

Еще один аспект, если я правильно понимаю, то разобрать NTFS раздел будет непросто, ведь мы же не сможем засосать в память пару терабайт, да к тому же сделать из этого всего объекты? Наш процесс разрастется и привет ООМ-киллеру.

Для этого есть lazy parsing. До тех пор, пока к определенным объектам не обратишься - они не зачитываются и не появляются в памяти.

Так как возможен скроллинг или изменение данных (при просмотре памяти), то протокол лучше сделать двунаправленным.

В целом идея понятна и, наверное, разумна - т.е. хочется отделить некий engine, работающий с данными и собственно визуализацию. До сих пор все визуализаторы объединяли это внутри себя.

Здесь есть n-ное количество подводных камней:

• потоков может быть много; например, до какого-то момент мы работали с «внешним» потоком (контейнером и сжатыми данными), а затем мы добрались до собственно данных, разжали их и получили «внутренний» поток, в котором, в свою очередь, может быть своя структура и объекты;
• действительно нужен двунаправленный протокол, нельзя просто так взять и отдать развернутое дерево целиком (в том числе оно может быть бесконечным, например) - нужны запросы за определенными узлами и ответы на них;
• нужно уметь передавать все поддерживаемые типы данных; их не так много, в целом в рамки какого-нибудь JSON при желании укладывается;
• и вьювер, и «parsing engine» должны иметь доступ к одному и тому же конкретному файлу - надо придумать, как это обеспечивать; раз уж коммуникация через сокет - то хочется и сетевой прозрачности;

Может быть я просто загоняюсь и это вообще как-то стандартизировать не стоит, но в этот момент можно подумать о других, уже написанных вьюерах

Вы хоть один вьювер можете назвать, который делает выделение полей в хекс-дампе и кому это будет интересно? Я знаю ровно один - Okteta. Раз в год пытаюсь им писать какие-то письма и предложения сотрудничать - в ответ - тишина.

Для этого есть lazy parsing. До тех пор, пока к определенным объектам не обратишься - они не зачитываются и не появляются в памяти.

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

потоков может быть много; например, до какого-то момент мы работали с «внешним» потоком (контейнером и сжатыми данными), а затем мы добрались до собственно данных, разжали их и получили «внутренний» поток, в котором, в свою очередь, может быть своя структура и объекты;

Не считаю это подводным камнем, а вполне естественным. Даже более, визуализатор может суб-стрим накладывать на основной. Это в принципе сделать не сложно, нужно только указывать позицию в «родительском» потоке. Я уж не говорю про традиционное, что заголовок парсим отдельно, а тело отдельно.

нельзя просто так взять и отдать развернутое дерево целиком (в том числе оно может быть бесконечным, например) - нужны запросы за определенными узлами и ответы на них;

Меня на данный момент интересует планарное представление «кто есть кто».

Вы хоть один вьювер можете назвать, который делает выделение полей в хекс-дампе и кому это будет интересно?

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