Kaitai Struct 0.6

SWord

Забавно, кстати, я про этот проект не знал, спасибо! Чем-то по идеологии очень похоже на OLEToy - вы с ними не сотрудничали?

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

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

OLEToy вырос из нашего CDR Explorer (https://sk1project.net/modules.php?name=Products&product=cdrexplorer), который был классическим дампером. SWord - это следующая генерация, позволяющая разрабатывать in-place код.

Как я уже указывал выше, для отладки мы используем отдельное приложение

Насколько я понимаю, у вас чуть проще задача: по сути вся логика у вас строго только на Python, а где не хватает скорости - вы добавляете нативные модули на C, но опять же в основном используемые из Python?

Да. И более того, SWord создан для разработки только UniConvertor, поскольку он визуализирует модели форматов UniConvertor'а.

дытэктор мышкоюзера зашкалил

Не каждому суждено делать визуальный анализ в консоли :)

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

Или попробовать в SWord добавить поддержку большего числа поддерживаемых форматов (например, бинарники просматривать?) через внешние .ksy?

Или что-то еще? Например, я могу поковырять какие-нибудь еще недоделанные форматы, чтобы их потом добавить в sK1 / UniConvertor?

Миша, да можно попытаться. Особенно в реализации ksy описаний. Кстати, Inquisitor это же твой проект?

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

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

Интересная вещь, с одной стороны, казалось бы полная ерунда, такие вещи пишет каждый второй студент, с другой, с детства мечтал о таком процессе: скармливаешь компьютеру команды процессора (с размерами, таймингами), остальное железо, формат файла (скажем JPEG или видеокодек), второй формат файла (PNG или банально буфер на экране), а он уже сам рассчитывает оптимальный по памяти/скорости/кэшам алгоритм, и вот так за пол часа делается что угодно, от видеоплеера и браузера, до 3D RPG.

Ага - хотя я сейчас им уже несколько другие люди занимаются, а почти за последние n лет ничего толком туда не контрибьючу. Ну и, собственно, я наши похождения во время и после LTDL 2009 прекрасно помню :)

Та отож :) Как из прошлой жизни.

Расскажите немного о вот таком workflow, возможно ли анализировать формат сверху вниз, то есть например у меня есть сетевой пакет, я не знаю тип и размер полей, но знаю что следующий известный блок начинается с magic number. То есть, динамический размер чанка.

возможно ли анализировать формат сверху вниз

Обычно так и происходит. Собственно, все и заточено ровно под то, что сначала об очередном блоке ничего не известно, кроме, например, размера, а затем он обрастает типом, какими-то полями и т.д.

но знаю что следующий известный блок начинается с magic number

Вот конкретно так сложно на самом деле - KS не умеет обычно делать то, что делают «обычные» парсеры на основе всяких LR/LL/SLR и т.п. грамматик - т.е. «искать» какие-то образцы, бэктрекаться и т.д. Обычно бинарные форматы все равно устроены не так - они почти никогда не оперируют такими высокими материями - там все равно внутри размеры, смещения и т.д.

Зачастую, когда формат неизвестен, можно визуально найти в дампе то, что нужно и начинать с очень простой структуры типа

- size: 165
- size: 180
- size: 2073

а затем каждое из этих полей может начинать обрастать подтипом, какими-то процессингами и т.д.

Типа того :) Есть какие-то мысли, с чего бы такого можно было начать?

OLEToy вырос из нашего

Не надо грязи.

А бывают языки спецификации, на котором можно описать синтаксис C, C++, D, Java, PHP, Perl...

И потом на основании этого написать компилятор, который только на основании спецификации программу на этом языке скомпилирует.

Есть ли языки синтаксис, которых уже описан на таком языке спецификации?

OLEToy вырос из нашего

Не надо грязи.

У вас есть другие данные?

Haxe внезапно человечество уже придумало.

Бэкуса-Наура форма + yacc/Gnu bison?

Можно, но зачем?

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

Например в случае трёх целевых языков Си, Си++ и Java какую схему управления памятью будет подразумевать наш метаязык? Можно ручную, можно подсчёт ссылок, можно mark and sweep сборщик. В результате получим Си код который не работает без Boehm GC или Java с финализаторами по всему коду. Более того очевидно всё это ещё и будет работать по-разному и узкие места могут возникать в совершенно различных местах.

Тут речь всё же не о создании компилятора, а о том чтобы на основании программы описанной некоторым языком порождать эквивалентную по функциональнсти программу на целевом языке. Это то что делает Haxe.

Ну вот хотелось бы, такой «метакомпилятор», чтобы он знал, что бывает и malloc/free как на C и GC на D или Java, и чтобы всё умел..

А потом все эти спецификации языков можно будет как угодно скрещивать :-)

В какой-то степени язык выражений в kaitai как раз и есть такой метаязык.

Да, авторы его собственно и декларируют как DSL. Проект интересный, однако на мой взгляд использование YAML в качестве основы не самый удачный вариант, хотя, когда по работе мне потребовалось сделать нечто подобное сам его использовал, но для pet project'a я бы всё-таки построил грамматику и парсер под задачу вручную, уж больно тяжеловесен спек YAML. На самом деле исопльзуя scala можно было построить такую грамматику, которая являлась бы строгим подмножеством грамматики scala, тогда и парсер писать не надо.

Однако, по большому счёту, проект может спокойно набрать пользовательскую базу, а после этого в зависимости от наличия внятных сценариев использования того факта что валидный ksy это валидный yml, спокойно трансформировать язык как угодно, просто сделав генератор из старого формата в новый, что для декларативных языков не является особой проблемой.

поддержка побитового чтения

Вот теперь нужно

Вообще б да, им бы какой-нибудь синтаксис типа Spicy иметь - цены б не было.

Можно ли чтение юзертипов описывать в том же ksy чтобы не зависеть от

будет сгенерирован корректный import / include в предположении, что тип объявлен во внешнем файле)

?

Например, ue(v) и se(v) при реализации https://i.stack.imgur.com/2vi21.png обозначают https://en.wikipedia.org/wiki/Exponential-Golomb_coding и тут выбор между читаемостью и внешними зависимостями

Вот меня и интересует предлагаемый рабочий процесс, если к примеру у меня есть три пакета header-unknownpart-knownpart-checksum, в которых unknownpart имеет разный размер. Предположим, что я пока не обнаружил признак, по которому можно однозначно их различить (а может, я и не хочу их различать, а тупо пересылать дальше, меняя только known+checksum). Предлагается заводить по одному ksy файлу на каждый пакет?

Зачем? Заводишь сколько надо типов в одном файле и все.

Например, 9999? =)

Хоть 10000. Разрешаю.

Пример использования:

https://habrahabr.ru/post/281595/

Ты б еще древнее статью откопал :) там сейчас все в разы проще делается.

Приводи новый

ИМХО, когда рассказывают о новом софте, объяснить на пальцах что это, где может пригодится и как использовать - бесценно ;)

которая являлась бы строгим подмножеством грамматики scala, тогда и парсер писать не надо.

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

спокойно трансформировать язык как угодно, просто сделав генератор из старого формата в новый

Типа того. Предлагайте варианты.

Предлагается заводить по одному ksy файлу на каждый пакет?

Можно завести по типу на каждый пакет в одном и том же файле. Какие варианты-то? Вам надо по любому их как-то отличать и указывать для каждого вручную посчитанную длину или что-то такое. Сделайте что-то типа:

types:
  pkt1:
    seq:
      - id: header
        type: header
      - id: unknownpart
        size: 100500
      - id: knownpart
        type: knownpart
      - id: checksum
        type: u4
  pkt2:
    seq:
      - id: header
        type: header
      - id: unknownpart
        size: 1337
      - id: knownpart
        type: knownpart
      - id: checksum
        type: u4
# и т.д.

Дублирования на самом деле минимум, т.к. как раз сложные вещи - типы header и knownpart - описываются один раз.

Да вроде бы статья Накамуры не то, чтобы сильно устарела. Он же там в первой статье какие-то совсем банально-примитивные вещи показывает. Ну, «unknown» нынче можно вручную не писать, а так вроде бы все актуально. И консольным визуализатором можно новичков не пугать, а показывать сразу Web IDE.

У вас есть другие данные?

https://github.com/renyxa/re-lab/blob/master/oletoy/README

А не замахивался ли кто-то из KSY-сообщества на то, чтобы описать на нём двоичные форматы MS Office (те, что до появления OOXML)? Вот это была бы задача для истинного джедая (Спольски подтверждает).

Мсье, «вырос» не эквивалент «сделан из». OLEToy слеплен по образу и подобию CDR Explorer, с повторением архитектурных ошибок (ну или паттернов, кому как нравится). Собсно в докладе на LGM2012 Strba об этом и говорил. И ничего зазорного в этом нет - это опенсурс, мсье. Для того код и открыт, чтобы им пользовались.

Парсер CFB (он же OLE, который в основе всех этих форматов) у нас в целом есть. Описывать MS Office на самом деле не то, чтобы дико сложно, но весьма муторно - когда только официальная спецификация на 800-с-чем-то-там страниц.

Ога. А потом огребают проблемы с endianness, byte alignment, #pragma pack, сегфолты и непонятно откуда-то взявшиеся тормоза при обращении к структуре.

Руки надо просто выпрямлять. Или выбрать язык попроще. Благо, в наше время есть из чего.

все врерно,на 1 курсе института так и делают,а что дальше?
они начинают писать на джаваскрипте?

Ну кто на жс, кто на джаве, кто на плюсах... А тем некоторым, кто проникся, уже ничего не страшно.

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

А трансляция записывалась?

Собсно в докладе на LGM2012 Strba об этом и говорил.

Пруфцы будут или пёрнул в лужу и рад?

А писалку бинарного формата потом сложно запилить?

А трансляция записывалась?

Да. И даже видео уже готовы и выложены: https://fosdem.org/2017/schedule/event/om_kaitai/

А писалку бинарного формата потом сложно запилить?

Зависит от формата. Простую писалку я, надеюсь, мы таки скоро сделаем by popular demand. Более сложно сделать писалку, которая, скажем, по такому описанию:

seq:
  - id: len
    type: u4
  - id: str
    type: str
    size: len + 2
    # ...

умеет понимать, что поле len - зависимое от поля str, и когда в поле str будут класть, скажем, строчку «abcde», в поле len надо автоматом выставить длину строки минус 2, т.е. 3.

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