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, 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 ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.