The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  вход/выход  слежка  RSS
"Релиз системы разбора произвольных бинарных файлов Kaitai St..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +1 +/
Сообщение от opennews (??) on 09-Авг-16, 23:39 
Поле четырёх месяцев разработки доступен релиз инструментария хKaitai Struct 0.4 (http://kaitai.io/) - языка для описания форматов сериализации произвольных бинарных структур данных. Идея Kaitai Struct заключается в том, что формат данных описывается с помощью простого декларативного языка на основе YAML, а затем это описание можно скомпилировать в готовый код парсера на любом из поддерживаемых языков. Для облегчения отладки предлагается визуализатор, в котором можно наблюдать, как сериализованная в файле структура раскладывается в дерево взаимосвязанных объектов в соответствии с описанием.


Основные новшества (https://github.com/kaitai-io/kaitai_struct_compiler/blob/6fd...):

-  Поддержка новых целевых языков: полностью поддерживается C#, предварительно поддерживается C++ (на основе стандартной библиотеки STL).
-  Поддержка новых типов данных: типы с плавающей точкой IEEE 754 (одинарной и двойной точности) и выделенный тип для массивов байт
-  Новые возможности языка выражений: методы для обращения к первому и последнему элементам массива, методы преобразования строк в числа, возможность обращения к объекту-потоку (например, для получения размера потока и позиционирования относительно конца структуры)
-  Новые возможности препроцессинга обрабатываемых буферов: XOR с ключом переменной длины
-  Стандартизация API всех runtime-библиотек и приведение их к единому виду (насколько это можно, с соблюдением традиций каждого из целевых языков)
-  Полная реализация API runtime-библиотеки JavaScript (в том числе поддержка 64-битных целых через аппроксимацию в double)


На сайте проекта также доступен компилятор (http://kaitai.io/repl/), работающий в браузере (в комплекте с несколькими примерами описаний форматов) - а также растущая библиотека (https://github.com/kaitai-io/kaitai_struct_formats) примеров описаний распространенных форматов.

URL: http://kaitai.io/
Новость: http://www.opennet.ru/opennews/art.shtml?num=44937

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от Аноним (??) on 09-Авг-16, 23:39 
А это для чего вообще?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +2 +/
Сообщение от A.Stahl (ok) on 09-Авг-16, 23:47 
Для создания парсеров.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +4 +/
Сообщение от kai3341 (ok) on 10-Авг-16, 09:50 
Допустим, Вы столкнулись с исследованием работы какого-то бинарного говна^W формата. Например, я сталкиваюсь с исследованием бинарного протокола обмена данными. Так вот, собственный парсер на этапе исследования можно не писать, а задействовать этот проект.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

9. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от GreyCat (ok) on 10-Авг-16, 13:05 
Да, в общем, и дальше, уже после исследования можно не писать - для этого проект и делался - просто сгенерировать из описания и использовать как есть.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от dq0s4y71 (ok) on 10-Авг-16, 13:19 
Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат уже известен и нужно быстро сделать парсер для него. Приходилось делать нечто подобное для парсинга сообщений CAN, только выхлоп у меня был на Си...

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

11. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +1 +/
Сообщение от GreyCat (ok) on 10-Авг-16, 13:22 
> Ну, для _исследования_ форматов есть WireShark, а эта штука нужна, когда формат
> уже известен и нужно быстро сделать парсер для него. Приходилось делать
> нечто подобное для парсинга сообщений CAN, только выхлоп у меня был
> на Си...

Именно что _исследовать_ с помощью WireShark очень и очень неудобно. Писать и отлаживать диссекторы для неизвестных форматов там тяжко (даже если речь о lua). В KS же - проверка любой гипотезы - это единицы секунд. Поправил какой-нибудь типа данных с u4be на u2le, перезагрузил визуализатор - вуаля.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

6. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +2 +/
Сообщение от Аноним (??) on 10-Авг-16, 10:18 
Это супер тема! Очень удобно, например, при разборе BLOB-ов проприетарщиков.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +2 +/
Сообщение от Аноним (??) on 10-Авг-16, 11:45 
Тема конечно супер... при условии наличия готового описания интересующего формата.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +1 +/
Сообщение от Аноним (??) on 10-Авг-16, 12:43 
Конечно вы правы, но кто ж вам эту инфу даст?
Поэтому и приходится заниматься реверс инжинирингом, но в этом же и интерес!
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

12. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +1 +/
Сообщение от dq0s4y71 (ok) on 10-Авг-16, 13:25 
1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора в пакете данных?

2) Что оно может, чего не может, например, protocol buffers?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +1 +/
Сообщение от GreyCat (ok) on 10-Авг-16, 13:27 
> 1) Понимает ли эта штука форматы, изменяющиеся в зависимости, например, от идентификатора
> в пакете данных?

Конечно.

> 2) Что оно может, чего не может, например, protocol buffers?

Разбирать произвольные существующие бинарные форматы - например, те же gif, png, mp3, ogg, avi, iso9660, fat32, elf, zip и т.д.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от dq0s4y71 (ok) on 10-Авг-16, 13:40 
То есть с ним идёт ещё какая-то библиотека существующих форматов?
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +3 +/
Сообщение от GreyCat (ok) on 10-Авг-16, 13:42 
> То есть с ним идёт ещё какая-то библиотека существующих форматов?

Библиотека - в смысле коллекции примеров .ksy-описаний форматов - конечно идет - https://github.com/kaitai-io/kaitai_struct_formats

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от dq0s4y71 (ok) on 10-Авг-16, 14:09 
Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня интересовало, какие преимущества здесь даёт ваша программа.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +3 +/
Сообщение от GreyCat (ok) on 10-Авг-16, 14:18 
> Ну, protocol buffers, насколько я понимаю, тоже может такие форматы разбирать, меня
> интересовало, какие преимущества здесь даёт ваша программа.

В традиционном виде использования - на самом деле скорее _не_ может. Protobuf в норме описывает не формат сериализации, а саму структуру данных - а формат сериализации при этом будет такой, как удобно protobuf'у. В том числе это означает что по умолчанию формат protobuf - самоописываемый, как JSON / BSON / ASN.1 DER/CER - т.е. получателю не надо знать формат, чтобы понять синтаксис. Перед каждым полем все равно будет идти префикс, который указывает тип поля и тем самым определяет, как его читать/писать, сколько оно байт будет занимать в потоке и т.д.

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от dq0s4y71 (ok) on 10-Авг-16, 14:37 
ок, спасибо.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

28. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от nuclight (??) on 11-Авг-16, 21:09 
Нет, тут немножко в кучу смешалось. Формат protobuf - не самоописываемый. Формат protobuf из приведенного списка эквивалентен ASN.1 - для того, чтобы полноценно пропарсить бинарное сообщение, получателю необходимо иметь описание формата - несмотря на то, что типы и длины в потоке указаны, имен там нет. Упрощенный пример - пришли в пакете два числа, строка, массив из трех чисел? Что это такое, что куда? Вы заранее не знаете, если не согласовать это в парсере - именно за этим компилятор protobuf-языка

Действительно полностью самоописываемым будет JSON (и, например, какая-нибудь вариация XML-схемы, где договорились об указании имен, но это таки согласовать придется опять) - в нем имеются не только типы данных, но и названия этих переменных. Вот такие данные получатель уже сможет пропарсить, не имея заранее описания синтаксиса/схемы (зачем? подумайте, например, о проблеме апгрейда между версияи - убирание старых полей, добавление новых).

Но если нужен бинарный эквивалент JSON, в наше время следует смотреть не на BSON, а на (исправление допущенных ошибок проектирования в) CBOR - он стандартизирован в RFC 7049, очень прост и для парсеров на Си, полностью совместим по модели данных с JSON, расширяем - стандартизирован уже и ряд расширений к нему (например компрессия повторяющихся имен), и кучу имплементаций под все  языки на http://cbor.io/ уже наклепали.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

29. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от GreyCat (ok) on 12-Авг-16, 11:03 
JSON вида {"msg": ["foo", 1, 5, 7, [-1.5, -0.5]]} тоже не будет самоописываемым, если работа с msg проводится с помощью массива констант типа такого:

const ENTITY_NAME = 0
const ENTITY_COORDS = 4

и, соответственно, обращение через json.msg[ENTITY_COORDS] = [-1.5, -0.5].

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

19. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от anonkz on 10-Авг-16, 16:20 
quickbms же есть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +1 +/
Сообщение от GreyCat (ok) on 10-Авг-16, 21:13 
Есть. Только там не столько описание формата, сколько просто скриптовый язык для выполнения конкретной задачи (как правило - извлечения контента из архива). Скомпилировать это самое описание для BMS в какой-нибудь другой язык и использовать из своей программы - малореально.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

23. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от jacob on 11-Авг-16, 08:46 
Кажется избыточным в описании формата везде писать "id" и "type". Вместо какого-нибудь
seq:
  - id: src_port
    type: u2
  - id: dst_port
    type: u2

Можно было бы писать просто:

seq:
  - src_port: u2
  - dst_port: u2

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

25. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от GreyCat (ok) on 11-Авг-16, 09:14 
> Кажется избыточным в описании формата везде писать "id" и "type".

Давайте усложним задачу :) Как тогда предлагаете описывать поля типа таких:

      - id: frame_times
        type: f4
        repeat: expr
        repeat-expr: num_frames
        if: group != 0

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

26. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от jacob on 11-Авг-16, 09:35 
>> Кажется избыточным в описании формата везде писать "id" и "type".
> Давайте усложним задачу :) Как тогда предлагаете описывать поля типа таких:
>       - id: frame_times
>         type: f4
>         repeat: expr
>         repeat-expr: num_frames
>         if: group != 0

В ваших примерах на гитхабе большинство полей идет именно как id и type. Так может, добавить частный случай, чтобы сократить писанину?

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от GreyCat (ok) on 11-Авг-16, 18:09 
Во-первых, вы предлагаете очень странную вещь. То есть, представьте, как это будет читаться хотя бы человеческим глазом:

- id: u2
- id: blah
  type: strz
  terminator: 0xd
- terminator: u4

Сравните это с текущей, куда более однородной, на мой взгляд, записью:

- id: id
  type: u2
- id: blah
  type: strz
  terminator: 0xd
- id: terminator
  type: u4

На самом деле тут задано три атрибута с идентификаторами "id", "blah" и "terminator". В описание поля всего одна key-value пара, то мы считаем идентификатором - key, а типом - value. Если больше одной - то, внезапно, все по-другому - они обрабатываются как полноценные key-value пары описания атрибута.

Вообще, предполагалось, что это формат разметки, а не полноценный язык программирования с кучей syntactic sugar, который людям придется еще надо отдельно изучать. "Много способов сделать одно и то же" не хочется поощрять. Это здорово упрощает создание дополнительных инструментов - визуализаторов, визуальных редакторов, отладчиков и т.д. Мне сделать исключения в компиляторе, разумеется, несложно - но это же исключение придется делать всем и везде. Оно того стоит?

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

22. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от lk on 11-Авг-16, 07:19 
Где картинки визуализатора?

А то без него на construct смахивает.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от GreyCat (ok) on 11-Авг-16, 09:11 
Вот у этого товарища в статье картинок было сколько-то - https://habrahabr.ru/post/281595/

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

30. "Релиз системы разбора произвольных бинарных файлов Kaitai St..."  +/
Сообщение от lk on 12-Авг-16, 14:45 
Картинка визуализатора там одна. Впрочем и её достаточно -- "консольный".

Не понимаю разницу с конструктом.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру