LINUX.ORG.RU

Kaitai Struct 0.7

 , ,


5

2

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

Предлагаемый комплект позволяет:

Версия 0.7 содержит масштабные изменения, в том числе:

  • Добавлена поддержка многофайловых проектов, теперь можно полноценно импортировать одни .ksy в другие с помощью meta/imports (в том числе будет работать доступ к атрибутам классов и т. п.);
  • Любые типы данных теперь можно объявить размером «до байта-терминатора» с помощью terminator (ранее так можно было делать только со строками), а в случае заранее заданного размера также можно «обрезать» отступы справа, если это нужно (pad-right).
  • Для пользовательских типов данных теперь можно указывать явно значение parent (и тем самым гибко регулировать формирование дерева объектов).
  • К типам и атрибутам теперь можно добавлять ссылку на пункты оригинальной документации формата с помощью doc-ref.
  • Существенно переработан процесс компиляции, который теперь делится на 3 этапа: парсинг YAML, прекомпиляция (единая для всех языков) и компиляция (индивидуальным компилятором конкретного целевого языка); это позволило упростить и сильно улучшить обработку ошибок — отныне все сообщения компилятора содержат указание на конкретное проблемное место; введено более 50 тестов, проверяющих сообщения на ошибочных входных ksy-файлах.
  • Генерируемый код теперь следит за тем, чтобы runtime-библиотека была совместимой версии и отказывается работать со слишком старой библиотекой.
  • Множество новшеств в языке выражений: type casting, строковые литералы в одинарных и двойных кавычках, новые методы преобразования типов.
  • Как всегда, исправлено несколько десятков ошибок, проведены оптимизации, внутренний рефакторинг компилятора и др.

Отдельно стоит отметить, что так как теперь можно подключать ksy-файлы как модули к своему проекту, начиная с версии 0.7 вместе с компилятором поставляется библиотека форматов (на момент релиза насчитывающая 60 штук), в том числе с такими распространенными структурами, как VLQ (wikipedia.org), ULEB128 и т. д.

>>> Подробности

★★

Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 5)
Ответ на: комментарий от ruzisufaka

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

Если речь про получение из позиции в файле ссылку на атрибут в структуре - то, боюсь, это все надо делать на стороне визуализатора. Кроме всего прочего, эта задача в общем случае вообще плохо решается, например потому, что одни и те же данные могут парситься несколько раз в разных объектах. Так что какой-то паллиатив типа «обойти все то дерево, что получилось до сих пор, составляя treeinterval-подобную структуру и затем lookup'ать в нее».

Я уж не говорю про традиционное, что заголовок парсим отдельно, а тело отдельно.

Эм, если речь про C-way'ное «заголовок = фиксированная структура, которую так удобно typecast'нуть», а «тело» - это все остальное, то, боюсь, KS (да, в общем, и никто, кроме неудачных реализаций на C) так не делает.

Вон, выше код вьюера

Окей, не вопрос. Как насчет перемещения куда-нибудь в GH issues, чтобы обсуждать протокол (я догадываюсь, что как минимум еще 1-2 человекам идея будет интересна)?

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

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

Может я не понял о чём вы... мой — делает.
Протокол/не протокол, а какой-то способ описать как показывать какой-то кусок данных было бы теоретически неплохо иметь. Но кажется мы всё это уже пообсуждали пару раз в анонсах предыдущих версий.

frob ★★★★★
()
Ответ на: комментарий от frob

Но кажется мы всё это уже пообсуждали пару раз в анонсах предыдущих версий.

Насколько я помню, тогда договорились до того, что у вас лично желания и времени добавлять поддержку KS нет, но вы не против, если ее напишет и пришлет кто-то извне (например, я). Я тогда туманно пообещал, что я попробую разобраться с OLE Toy - и, в итоге, так руки и не дошли :( - а потом появилась Web IDE, с живым мейнтейнером, и я решил целиком сосредоточиться на компиляторе.

Если сейчас есть желание и возможность попробовать действительно сформулировать рабочий протокол к такому вот «серверу парсинга» - давайте попробуем?

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

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

я js от слова совсем не знаю, а по f12 у меня список иксовых окон вызывается. но я вроде понял в чем беда - в старой версии firefox.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

Если F12 занята - то в Firefox - Tools / Web Developer / Web Console. Но если порешали - тогда все хорошо :)

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

Со временем свободным теперь только хуже стало.

Но главное, я не думаю, что имеет смысл тратить время на протоколы в целом и для вас на ОЛЕтой в частности. Вы движетесь в более-менее правильном направлении, гляделки у вас есть. Ну и отлично!

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

frob ★★★★★
()
Ответ на: комментарий от GreyCat

«give me a list of objects at root node»

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

ruzisufaka ★
()
14 июня 2017 г.
Ответ на: комментарий от GreyCat

GreyCat, вот ты как создатель сего, объясни мне - почему все эти тулзы для реверс-инженерига/описания структур сделаны через «назад»?

Почему, при использовании визуализатора я не могу выделить произвольное количество байт и жмякнуть капу - это структура, называется header. А потом внутри этой структуры - опять-же выделив несколько байт - описать собственно маджики/длины/прочий crc. И так-же дальше - вот еще 2 байта - recordid, 4 - его длинна, дальше - тело рекорда, повторяем до конца файла.

Почему обязательно надо в питон-стайле лабать портянки на yaml'e причем врукопашную?

LynxChaus ★
()
Ответ на: комментарий от LynxChaus

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

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

Есть, например, «плохой» пример в голове, как делать точно не стоит - это редактор структур в IDA, с его бесконечными «d» и «*» и подгонянием размеров в уме.

Почему обязательно надо в питон-стайле лабать портянки на yaml'e причем врукопашную?

Это не «портянки на YAML в питон-стайле», это просто дерево. Не нравится YAML - можно JSON, XML, C-style.

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

Да можно, наверное, но вопрос UI, востребованности и полезности этого. Так, чтобы всем понравилось - пока никто не сделал.

Ага, единственный пример от той-же иды у тебя «плохой». Всё остальное - еще хуже и с теми-же портянками.

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

Сейчас это перекладывается на того, кто пишет портянку. Можно же и спросить по мере создания - а куда это девать, от чего отсчитывать и сколько раз применять, какой тип/endianness/как показывать в визуализаторе.

Это не «портянки на YAML в питон-стайле», это просто дерево. Не нравится YAML - можно JSON, XML, C-style.

Для чего у нас мощные процессоры индустрия выпускает? Не нравиться писать эти портянки. Хоть на json хоть на c-style. Если уже начал писать, то проще писать сразу на целевом языке, т.к. получается двойная работа.

LynxChaus ★
()
Ответ на: комментарий от LynxChaus

Сейчас это перекладывается на того, кто пишет портянку. Можно же и спросить по мере создания - а куда это девать, от чего отсчитывать и сколько раз применять, какой тип/endianness/как показывать в визуализаторе.

Можно, только в итоге оказывается, что для создания очередного атрибута человеку нужно заполнить форму с десятком полей. Из всех которых будет заполнено только «size», которое в 95% случаев надо будет как раз стереть и заполнить поле «type».

Не нравиться

/me facepalms

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

Ну, кому как. Я на самом деле совершенно поддерживаю мысль о том, что показывать в IDE только текстовое (YAML) представление - неправильно, и что лучше бы показывать как раз дерево. После чего, наверное, можно подумать о том, как сделать эту потенциальную «форму добавления очередного атрибута с десятком полей» более человеко-пригодной и реализовать и ее тоже.

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

Можно, только в итоге оказывается, что для создания очередного атрибута человеку нужно заполнить форму с десятком полей. Из всех которых будет заполнено только «size», которое в 95% случаев надо будет как раз стереть и заполнить поле «type».

Еще раз и медленно - «выделить в визуализаторе». Выделил 2 байта - получил свой u2, выделил 4 - получил u4. Сложно выпадающую менюшку нарисовать «data type: u1/u2/u4/u8/float/string/new dataset» ?

Ну, кому как.

Мне - так. Вот смотрю в твой web-ide и понимаю, что я занимаюсь фигней. Глазами я структуру файла вижу, а вместо того, чтоб мне этот web-ide помогал - это я ему помогаю. Понимаешь мою мысль? Нахрена мне тогда IDE, если я пишу это всё ручками? Да и специфика есть - разбиралка формата пишется один раз, после чего обычно выкидывается вместе с форматом по прошествии энного времени. Переписывать на другой язык никто не будет, ибо незачем.

LynxChaus ★
()
Ответ на: комментарий от LynxChaus

Еще раз и медленно - «выделить в визуализаторе». Выделил 2 байта - получил свой u2, выделил 4 - получил u4. Сложно выпадающую менюшку нарисовать «data type: u1/u2/u4/u8/float/string/new dataset» ?

Хорошо, еще раз и медленно: выделение в визуализаторе дает только информацию о размере (и положении, что, впрочем, скорее мешает, чем помогает). Кроме размера у атрибута есть еще десяток параметров — да и размер часто не тот, что видно глазами, а на самом деле считается по какой-нибудь формуле. Из воздуха они не возьмутся, их так или иначе надо будет вводить, скорее всего еще и угадывая с n-ной попытки. Менюшку нарисовать можно (и в конечном счете скорее всего даже сделаем), но вот универсальным лекарством от всех болезней она не станет.

Мне - так. Вот смотрю в твой web-ide и понимаю, что я занимаюсь фигней. Глазами я структуру файла вижу, а вместо того, чтоб мне этот web-ide помогал - это я ему помогаю. Понимаешь мою мысль?

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

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

В природе точно существуют люди, у которых чуть больше уважения к своей работе.

GreyCat ★★
() автор топика
Ответ на: комментарий от GreyCat

Хорошо, еще раз и медленно: выделение в визуализаторе дает только информацию о размере (и положении, что, впрочем, скорее мешает, чем помогает).

Уже минимум 2 строчки писанины в минус.

Кроме размера у атрибута есть еще десяток параметров — да и размер часто не тот, что видно глазами, а на самом деле считается по какой-нибудь формуле. Из воздуха они не возьмутся, их так или иначе надо будет вводить, скорее всего еще и угадывая с n-ной попытки.

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

В природе точно существуют люди, у которых чуть больше уважения к своей работе.

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

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

Поэтому - среднее время жизни конвертора - 2-3 года, потом оно выкидывается вместе с железом.

LynxChaus ★
()
Ответ на: комментарий от LynxChaus

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

Возьмешься выписать все эти варианты? Я в целом могу создать два тикета в качестве предложения автору web IDE — один на отображение YAML в виде дерева объектов, а не текста, а другой — на такой вот визард создания новых атрибутов (по выделенному или как-то еще отмеченному). Но сильно хотелось бы расписать, как именно должно выглядеть окошко и продумать, как и что там задизайнить, чтобы какие-то типовые операции упрощать.

(про реальность)

Там, где я работал с железками и протоколами — железки все-таки mass market, выпускаются тиражами в десятки-сотни тысяч и живут лет эдак по 10-20.

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

К нам в чат, скажем, не так давно регулярно заходил человек, который, кажется, для каких-то то ли GPS-трекеров, то ли датчиков каких-то промышленных уже эдак штук 50 протоколов описал. Может, получится скооперироваться?

GreyCat ★★
() автор топика
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.