LINUX.ORG.RU

Релиз Kaitai Struct v0.4

 , , , ,


2

3

Состоялся релиз v0.4 проекта Kaitai Struct — декларативного языка для описания форматов структур данных. Описание структуры составляется в виде файла .ksy (в простом YAML-подобном виде), а затем с помощью предлагаемого компилятора транслируется в исходный код парсинга (на данный момент поддерживаются C#, Java, JavaScript, Python, Ruby и предварительно — C++). Типичная сфера применения — разбор и импорт существующих бинарных форматов файлов (в том числе закрытых и проприетарных), сетевых пакетов (например, в составе IDS или систем мониторинга трафика) и т. п.

Кроме компилятора, в состав поставки входит визуализатор, с помощью которого удобно отлаживать разрабатываемое описание (особенно, если формат неизвестен и необходимо пробовать много разных гипотез), применяя его сразу к существующему файлу и наблюдая результат парсинга в виде дерева с подсветкой соответствующих элементам этого дерева мест в hex-дампе.

Инструментарий распространяется под GPLv3, используемые в компилируемом коде runtime-библиотеки — под MIT/Apache. Референсный компилятор написан на Scala, но существует версия для веба на JavaScript, работающая в браузере целиком на стороне клиента.

Из нововведений нового major-релиза можно отметить:

  • поддержку 2 новых целевых языков: полная поддержка C# и предварительная — C++ с STL;
  • полную поддержку JavaScript в runtime-библиотеке;
  • поддержку новых типов данных: числа с плавающей точкой и выделенные типы для массивов байт;
  • расширение встроенного языка выражений: добавлены операции для работы с массивами, преобразования типов данных, доступа к объекту потока и т. п.;
  • существенную переработку и унификацию runtime-библиотек всех поддерживаемых языков для приведения их всех к единому API (в рамках дозволенного правилами конкретных языков).

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

★★

Проверено: tailgunner ()
Последнее исправление: CYB3R (всего исправлений: 4)
Ответ на: комментарий от frob

А если взять какой-нибудь контейнер, хотя бы тот же CFB, то увидеть «FAT в файле» приятно, но дальше с ним надо что-то делать. Практически — показывать как из имеющегося дерева выбрать части и собрать из них другое дерево.

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

Первым версиям vsdump скоро 10 лет. Первым релизам libvisio — 6. Разбор как blackbox, никаких вопросов от MS.

Значит и здесь будет так же. Если политика MS - судиться только за патентные нарушения, а их тут нет - то все ок.

https://github.com/renyxa/re-lab/tree/master/colupatr

Спасибо, смотрю :)

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

А зачем?

Для удобства разбора. =)

Значит и здесь будет так же.

«Здесь» - это где? В случае выдирания куска кода?
Ни один адекватный проект такое не возьмёт — прямая дорога к проигранному делу в суде.

Спасибо, смотрю :)

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

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

Для удобства разбора. =)

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

Ни один адекватный проект такое не возьмёт — прямая дорога к проигранному делу в суде.

По обвинению в чем?

Я тут на самом деле посмотрел на OLEToy - практически впечатлился. На самом деле очень близко к тому, что делает визуализатор KS, но, разумеется, в куда более приятном интерфейсе. Нет желания как-то объединить усилия и, скажем, добавить туда поддержку форматов из KS? Или на основе этого сделать какой-то общий проект?

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

По обвинению в чем?

Очевидно, в нарушении копиратских прав.

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

Беглым гуглением нашлось: [1], [2].

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

А никто в здравом уме код на ассемблере напрямую брать не будет, а возьмут скорее всего выхлоп из hex-rays и допилят до более человекочитаемого состояния, чтобы его из C/C++ можно было нормально вызывать. Или просто перепишут из ассемблера на Си. Тогда будет трудно что-либо доказать. А так вообще, можно еще сделать т.н. https://en.wikipedia.org/wiki/Clean_room_design

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

Это не удобство разбора

Посмотрите с точки зрения визуализации — это оно самое и есть.

Для вышеупомянутого VSD в какой-то момент пришлось «ручками» проверять, что разобранные части составляют полный файл и ничего не пропущено. Оказалось, что кусок пропустил, но пользы от него не было. А вот для Freehand аналогичная проверка позволила понять с какой стороны распутывать мешанину. Впрочем для Freehand пришлось добавить выдачу графа зависимостей между записями, чтобы для уже разобранного формата импортёр написать. Иначе получалось «угадал все буквы, не смог прочитать слово.»

По обвинению в чем?

Нелицензированное использование кода?

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

OLEToy

Я думал добавить construct. Посмотрел внимательно и получилось, что придётся делать полуторную работу: формат не содержит средств для описания того как представлять данные. Так что получалось, что всё что можно выжать — вместо бинаря получить текст его разбора и этот текст по-новой разбирать, чтобы добавить визуализацию.
Ситуация была бы другой, если бы в конструкте уже было бы описано много всяких интересных форматов, тогда можно было бы объяснить себе зачем с этим связываться. Аналогичное «курица-или-яйцо?» применимо и к KS.

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

Кроме того, олетой — это «certified organic», росший как попало из состояния минимальных представлений о том чего можно сделать в GTK+, как это сделать «правильно», какие возможности нужны и во что всё это выльется.
Если бы начинал сейчас, то почти всё сделал бы по-другому =)

Так что вместо добавления KSY надо сесть, подумать над тем что полезно и чего не хватает, и переписать всё к чёртовой матери.
А так — прикрутить к олетой разбор файлов с использованием информации из KSY выглядит не слишком мудрёной задачей. Просто без добавленных хинтов для визуализатора результат будет невзрачный.

Остальные отговорки у меня стандартные: «я не программист» и «нет времени». Именно по этому ранее предложил помощь советом, если затеете делать «визуальный редактор».

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

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

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

Пара примеров того где дизассеблер может оказаться эффективнее (из офисно-графических миров)

Давайте будем честными хотя бы с самими собой: для таких выделенных алгоритмов дизассемблер и white box *всегда* будет на порядки эффективнее, чем гадание в black box. В случае, когда у тебя непонятный поток на первый взгляд рандомных бит, в котором ничего не ищется - пытаться угадать алгоритм, конечно, можно, и, как совершенно верно сказано - у некоторых даже получается - и это зачастую тянет на весьма серьезное исследование на год-два работы - но смысл?

OLEToy

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

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

Давайте будем честными

Давайте. Я всё своё сделал исключительно блэкбоксом. CPT и WPF — это те примеры где дизассемблирование может быть эффективнее. На порядки — это вряд ли. (Если речь идёт не про то, чтобы найти и выдрать нужные куски кода, а про восстановление алгоритма.) И причина в основном в том, что для разбора соответствующих частей сложно генерировать файлы.
Для CPT можно было бы пытаться зайти с обратной стороны — менять что-то в файле и смотреть как перекосит изображение в программе, но это означает повышенные требования к тому, кто будет открывать файлы в PhotoPaint.
А WPF назойливо пытается запихать дополнительный мусор в файл, поэтому для адекватного сравнения надо каждый раз начинать с пустого листа.

Ну и если всё пойдёт плохо, то от блэкбокса остаётся довольно много следов того, что это был блэкбокс.

но смысл?

Just for fun.

что-то добавить туда?

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

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

CPT и WPF — это те примеры где дизассемблирование может быть эффективнее. На порядки — это вряд ли. (Если речь идёт не про то, чтобы найти и выдрать нужные куски кода, а про восстановление алгоритма.)

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

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

Про gimp.ru, OLEToy и re-lab

Расскажите чуть подробнее о том, что это вообще такое и какой сейчас у этого статус? Я просто сейчас посмотрел поверхностно - вы и на LibreGraphics активно выступаете, и GSoC-поддержку получаете, и OLEToy, я смотрю, народ в целом активно использует и все такое. И цели у вас в целом-то весьма близки к тем, для чего мне бы хотелось KS применять :)

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

Не хочу показаться привередливым, но googlegroups слегка того, немёртвый. Примеры описанного в статье можно вполне поглядеть, например в comp.lang.python. Ну и, зная отношение гугла к своим проектам, как–то странно в 2016 на него завязываться. До кучи ещё всякая там приватность, анонимность, доступность почтового адреса кому угодно…

Тем не менее, присоединяюсь. Разобраться бы ещё как туда постить в ветки без гуглоинтерфейса… И да, официальный язык свежесозданного мейллиста, я так понимаю, английский?

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

Все остальное, что я видел, к сожалению, еще более странное. SF лепит кучу рекламы, Nabble, если его пытаешься использовать на hosted mailing list, требует посылать почту на какой-то уникальный для каждого лично служебный адрес (что делает очень неудобным посылку из почтового клиента). Librelist, пожалуй, еще более мертв с последними апдейтами в 2009. Все плохо ;)

Разобраться бы ещё как туда постить в ветки без гуглоинтерфейса

Reply с To или Cc на kaitai-struct@googlegroups.com

И да, официальный язык свежесозданного мейллиста, я так понимаю, английский?

Да.

GreyCat ★★
() автор топика

Между прочим, автор засветился с докладом на PHDays в этом году и скромничает. Если кому интересно,

Также, на Medium нашлась английская версия упоминавшейся выше статьи с хабра: «Reverse engineering visual novels 101»

Ещё и из новостей: пользователь ProtoH взялся реализовывать поддержку PHP7 для KS. Я считаю, страна должна знать своих героев. Ну и апплодирую за самоотверженность. :D

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

большой разницы

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

Расскажите чуть подробнее о том, что это вообще такое

gimp.ru — это http://gimp.ru, не знаю как правильно «позиционируется», надо у AP спросить.

re-lab — организованный AP проект по расколдовыванию всяких форматов в пользу свободного ПО. http://libregraphicsworld.org/blog/entry/re-lab-project-is-announced

OLEToy — основной инструмент для разбора и запоминания.

Офисные и офисоугодные форматы разбираются в OLEToy (кроме всяких древних эппловских — чем пользуется Alonso я не знаю) и реализуются в библиотеки вокруг librevenge в рамках DLP (Document Liberation Project). Так что GSoC — это со стороны TDF/DLP.
Всякое разное-другое попадает в gimp/krita и пр. или оседает до лучших времён.

LibreGraphics — хороший повод встретиться с друзьями.

и какой сейчас у этого статус?

Я вероятно не понимаю вопрос.

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

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

Да в том-то и дело, что «потенциальные неприятности» на самом деле почти не зависят от ассемблера. Можно (было) написать сколько угодно clean room implementation какого-нибудь LZW и все равно угодить под патенты Unisys. До 2027 года, если ты пишешь реализацию энкодера H.264 и название твоего проекта не - попадаешь под патенты MPEG LA.

Офисные и офисоугодные форматы разбираются в OLEToy (кроме всяких древних эппловских — чем пользуется Alonso я не знаю) и реализуются в библиотеки вокруг librevenge в рамках DLP (Document Liberation Project). Так что GSoC — это со стороны TDF/DLP.

Во! Спасибо за ссылки. Теперь вот смотрю на какие-то штуки вроде https://sourceforge.net/p/libwpd/librevenge/ci/master/tree/src/lib/RVNGOLEStr... и думаю, что:

  • что-то мне дико напоминает все эти очередные readU16 / writeU32
  • это все на самом деле же ведь можно превратить в декларативное описание - и использовать _и_ в OLEToy, _и_ в качестве библиотек

Я вероятно не понимаю вопрос.

Имелось в виду: что из этих проектов в статусе «только экспериментируем» - ... - «используется в production в больших проектах», что из этого deprecated, какие задачи считаются условно закрытыми и работающими, а какие - актуальными? librevenge, я так понимаю, используется в LibreOffice? DLP в целом объединяет огромную когорту библиотек - в чем смысл - они их как-то пакуют, интегрируют и проталкивают в проекты скопом, или у него просто информационная роль? Те же самые вопросы про GIMP, Krita, MyPaint, Paint.NET - каким путем код попадает туда, кто координирует исследования?

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

gimp.ru — это http://gimp.ru, не знаю как правильно «позиционируется», надо у AP спросить.

Это что-то типа «узнавайте новости проекта из первых рук на родном языке».

Всякое разное-другое попадает в gimp/krita и пр. или оседает до лучших времён.

К сожалению, преимущественно в «и пр.», насколько мне известно.

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

Пара примеров того где дизассеблер может оказаться эффективнее (из офисно-графических миров) — PhotoPaint и парольная защита в не древних WordPerfect.

А история с шифрованием данных в лупах Recycle — это не сюда же?

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

По обвинению в чем?

Если внимательно почитать EULA, там можно встретить прямой запрет на дизассемблинг.

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

с шифрованием данных в лупах Recycle — это не сюда же?

Это было так давно, что уже не помню.

Если про всякое аудио говорить, то внутри YEP тоже есть сэмплы обычные (wav вроде) и в каком-то ямаховском формате. Ямаховский формат гораздо компактее, а внутри PSR места впритык. Значит делать только декодер практического смысла нет — нужен энкодер тоже. А У МЕНЯ ДАЖЕ PSR-а НЕТ! =)

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

какого-нибудь LZW и все равно угодить под патенты Unisys

Поэтому мне в какой-то момент стало интересно была ли у Shapeware лицензия на LZW или они просто для диплома переписали Бетховена задом наперёд. =)

что-то мне дико напоминает все эти очередные

В DLP на входе что-то, а на выходе — по выбору ODF или SVG (завёрнутый в XHTML для многостраничности).
librevenge появился, когда библиотек стало больше и Фридриху надоело копировать багфиксы в каждую из них. Тут-то он и вытащил общие куски в отдельную библиотеку.

можно превратить в декларативное описание

Можно. Но потом результат всё равно придётся транслировать ещё раз.
И в «декларативном» варианте наверняка где-то будет «а вот тут мы не будем заморачиваться и влепим вызов внешнего распаковщика».

«только экспериментируем» ... deprecated

Примерно вот так:
colupatr — «есть ошибки, которые лень исправлять».
Пользуется ли им кто-то кроме меня не знаю. Сделано под себя (гыгы) настолько, что были случаи, когда спустя какое-то время ковыряясь в дампе думал «а вот неплохо бы добавить функцию, чтоб нажал и УХ!», нажимал и оказывалось что сделал уже, просто успел забыть.

OLEToy — «какой баран так сделал??? ааа... это ж я...».
Используется в DLP когда надо что-нибудь расковырять/доковырять; некоторыми людьми в LibreOffice и Caligra, чтоб посмотреть чего в файле (с багзиллы, например); ранее упоминавшимися Yamaha-PSR-щиками (жалко их, но себя жальше).

colupatr/OLEToy ждут свободного времени, чтобы в них перетащили кое-какие интересные интерфейсные «находки», сделанные по совершенно другому поводу.

Роль у DLP «официальная/организационная». В принципе почти всё тоже самое можно было бы делать «группой заинтересованных лиц». Хотя, чтобы попасть в ООНовский комитет (или что это там у них) занимающийся вопросами digital preservation как индивидуалу, Фридриху видимо пришлось бы сначала стать звездой балета.

DLP-шные библиотеки используются в LO, куда они попадают практически автоматом, что для проекта TDF неудивительно.
Scribus и Caligra сами втыкают то, что им из всего этого надо. Инкскейперам приходится «помогать» (во всяком случае так было с libvisio и libcdr).
Поскольку это всё фильтры и есть консольные утилиты, то для использования в своём проекте можно даже просто нужный файл прогонять через внешнюю софтину и забирать обратно выхлоп.

За редким исключением DLP код библиотек не проталкивает: не хотите брать — не берите.
Заинтересованные проекты про DLP знают. Представители (или «лица близкие к») предположительно всех потенциальных СПО-шных «потребителей» бывают на LGM.

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

libmspub/libpagemaker наверное самые «пассивные» из того где есть чего ещё поразбирать.

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

В «экспериментальных» libemfplus и ковыряние формата InDesign. В «заглохших» PNG с добавками от fireworks (или что там это было) — Критовцы заинтересовались, а потом куда-то сдулись; и вышеупомянутые CPT/парольная защита для WPF — нет времени этим заниматься.

Есть ещё «ткнул в файл из хулиганских побуждений, что-то нашёл, добавил как есть». Оно не deprecated, просто всем плевать =)

кто координирует

Никто, да и зачем?

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

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

…а как вы себе представляете (будущих?) пользователей KS?

…1. Те, кому надо встроить поддержку какого-то формата в свой софт…
…2. Те, кому нужен удобный инструмент для реверс-инжиниринга неизвестного формата…

Уже высказывался, но наверное невнятно, попробую развить мысль:

Первой группе KS не нужен. Совсем. Для того чтобы разработчик пришёл ради одного (или нескольких) форматов, результат работы KS должен быть, как минимум, не хуже и не сложнее в использовании, чем уже существующие решения. Что не сходится с действительностью:

  • Удобство использования

    Библиотеки, грубо говоря, предоставляют готовый результат: «подставляй канвас, я тебе туда нарисую». К тому же, в биндингах для отдельных либ часто реализованы дополнительные абстракции, подстраивающие высокоуровневый интерфейс под возможности конкретного языка. Сгенерированный же KS парсер даёт лишь доступ к набору полуфабрикатов. Нужно понимать, что значат все эти блоки, затем написать прослойку для выкладывания оных в правильном порядке в нужное место.

  • Документация

    Тут, думаю, очевидно: К библиотечным функциям, как правило, есть мануалы, примеры и копипастбище на stack overflow.

    В случае KS — курить .ksy–файл до просветления, читать про формат, разбираться.

  • Покрытие отдельно взятого формата и множества форматов в целом

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

    Зато есть готовые libarchive, ffmpeg/libav, imagemagick/graphicsmagick, и т.д. и т.п.

Получается, у категории «разработчиков» нет никакой мотивации даже задумываться об использовании KS. Если, допустим, формат эксклюзивный и никем ещё не ковырялся, это уже переводит разработчика в категорию «реверсеров». Да и то, ещё надо найти решимость заморачиваться с KS, когда можно просто описать формат привычным для разработчика ЯП и использовать эту наработку. Про то, что разработчику вообще не нужен компилятор, только сам сгенерированный парсер — уже говорил.

Далее, «реверсеры». Те, кто ковыряют неизвестный формат и хотели бы облегчить себе жизнь. Им нужно наглядное представление бинарника(ов) и возможность тут же добавлять описания структур, проверять гипотезы. Пока что, в любимый инструмент KS просто так не добавить, опять же, придётся писать некую прослойку. Нужно как–то обновлять описание — сейчас для этого приходится дёргать компилятор, затем перезагружать скрипт. Даже среди скриптуемых хексредакторов — кто поддерживает перезагрузку отдельных скриптов/диссекторов «на лету»? Даже родной ksv приходится перезапускать. :)

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

…и что такое «поддержка кучи форматов»?…

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

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

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

Это ваша мотивация для разработки KS. Ну ладно, я в общем–то по сути вопроса абсолютно согласен, пусть будет наша. Остаётся самая малость — убедить тех, кому KS может быть полезен, собственно, его использовать.

Если делать для себя, а не для пользователей, получается как–то так.

Quote
()
Ответ на: комментарий от AP

Если внимательно почитать EULA, там можно встретить прямой запрет на дизассемблинг.

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

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

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

кто поддерживает перезагрузку отдельных скриптов/диссекторов «на лету»?

OLEToy поддерживает. Форматы лежат в отдельных питоньих файлах, которые запросто перезагружаются. Разбираемый файл тоже можно или перечитать или распарсить заново: бывает удобно, чтобы быстро посмотреть чего меняется — заменил файл на новую версию, перечитал, заметил разницу.

(Для различий проявляющихся локально имеется что-то вроде хекс-диффа, но тут уж как повезёт.)

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

Библиотеки, грубо говоря, предоставляют готовый результат: «подставляй канвас, я тебе туда нарисую»

Вы почему-то все зацикливаетесь на каких-то очень простых применениях типа «библиотека работы с картинками, которая умеет распаковать и нарисовать на канвас». Да, такие есть. Но некоторым вполне себе нужен более развесистый и многоуровневый интерфейс. Посмотрите, например, [link=https://github.com/wvanbergen/chunky_png]чем сейчас модно работать с png в Ruby[/link]. По сути - ровно все то же, что получается в результате компиляции png.ksy - те же блоки, те же аксессоры к ним, формат расшифровки каждого типа блока и т.д. Если нужно написать в свой веб-сервис какую-нибудь штуку, которая анализирует метаданные в загружаемых png, поменять палитру или там, скажем, добавить прозрачность - самое то.

Кроме того, мир отнюдь не ограничивается картинками. Задача библиотеки, которая читает форматы elf / pe / mach-o в каком-нибудь типовом дизассемблере - именно читать эти форматы, там с этими «полуфабрикатами» вполне себе работа и идет. Задача софта, который работает с MIDI - работать с MIDI-сообщениями, все равно придется изучать их структуру, что туда можно и что нельзя пихать. Если софт разбирает очередной заковыристый формат тэга в медиафайле - то все равно придется смотреть на структура тэга, подгонять под него UI и т.д. Если софт разбирает сетевые протоколы - ему тоже не нужно прыгать выше головы и пытаться в них вычислить что-то сверхособенное - нужно просто парсить пакеты.

Есть куча задач, где библиотека парсинга делает собственно парсинг, а не какие-то дополнительные высокоуровневые функции.

Документация

Сложно спорить, но .ksy как раз и задумывался как формализованная документация. Чтобы не нужно было писать все эти километровые портянки текста с таблицами вида «а вот здесь у нас такой-то бит, а здесь у нас адреса релокейшенов, а здесь сами релокейшены».

Зато есть готовые libarchive, ffmpeg/libav, imagemagick/graphicsmagick, и т.д. и т.п.

Зато есть куча областей, кроме графики, где готового либо нет, либо мало, либо оно такое, что лучше б не было ;)

Даже родной ksv приходится перезапускать. :)

О да, это ужас, надо нажать аж целых 3 клавиши - «q», «вверх» и «Enter». Впрочем, это хорошая идея, надо сделать reload .ksy без перезапуска.

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

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

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

На самом деле - кому как. Я на конференциях и воркшопах, где выступал, сколько-то общался именно с такими ребятами - подходили, спрашивали. Многим интересно, но почти все сразу же говорят, что не готовы в своих чудо-программах на миллион форматов вот так вот все бросать и переделывать на новый лад. Плюс 80% таких программ пишется на C++, поддержка которого в KS до сих пор [link=http://kaitai.io/ci]не проходит все тесты[/link].

Им точно так же дико неудобно таскать и запускать компилятор на каждый чих

И как же они, бедные, живут, когда им приходится для своей программы на C++ таскать и запускать компилятор C++ на каждый чих? А на C# или Java - там аж целая цепочка инструментов - да еще и IDE обычно «таскают»...

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

Я на самом деле не очень понял, что такое «на лету», применительно, скажем, к 010 или Hexinator. В Hexinator, вон, вообще все редактирование исключительно через визуальный редактор, результат обновляется фактически в рилтайме.

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

Как сделано в олетой...

Допустим возимся с каким-то форматом. И всё что у нас пока есть — при обнаружении в начале файла сигнатуры «PupkinSuperFormat», запускаем «parse» из модуля «wtf.py».

Открываем образец файла в этом формате, олетой его «распарсит». Поскольку знаем мы мало, то допустим нарисует «кустик» из файла с «заголовком» и «данными» в качестве веток.
Смотрим мы на это и видим, что данные смахивают на TLV. Правим wtf.py, говорим олетой «перезагрузи wtf, распарсь файл заново» и получаем обновлённый результат без перезапуска. Если знали больше и у нас уже какое-то дерево имелось, то заодно развернёт нужные ветки, чтобы поместить нас более-менее туда где были до этого.

Применительно к KSY было бы что-то вроде «перечитай KSY...» в случае интерпретатора или перекомпилируй/перечитай.

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

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

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

Если внимательно почитать EULA, там можно встретить прямой запрет на дизассемблинг.

Зависит от законов конкретной страны. Вот например http://consumer.stormway.ru/legal_ru.htm https://reverseengineering.stackexchange.com/questions/60/is-reverse-engineer...

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

Вообще, собственно, если уж говорить про EULA - то следует начинать с того, что в 99% из них, где есть фраза про дизассемблирование, она звучит как-то так:

You may not: [...] reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;

Т.е. дизассемблирование всегда будет идти рука об руку с любым другим методом реверс-инжиниринга, в том числе сколько угодно clean room и black box.

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

Возьмите gitter, он цепляется к проекту на github, имеет стандартный набор приложений (десктопные под онтопик и два оффтопика + мобильные под android/iOS). Не требует дополнительной регистрации, аутентификация через github.

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

состояние дерева и позицию в нем, адаптируя его под новое дерево,

В gtk это довольно просто делается — получить path до выделенного элемента в дереве, запомнить, потом развернуть дерево до элемента с таким path.

Если дерево серьёзно поменялось — развернёт столько сколько сможет. Довольно часто изменения — это разбор деталей в конкретном элементе или разбор с добавлением следующих элементов в родителя. Так что попадаешь куда надо или близко к тому.

Перемещаться в дереве к элементу с совпадающим с запомненным ранее смещением... может и нужно в каких-то случаях, но сходу ничего где это было бы важно не придумывается.
Хотя сам по себе простой доступ к информации о том каково смещение элементов от начала файла и/или ещё какой-то «ключевой» точки может быть полезным довольно часто, например, если в файле есть что-то вроде ToC оперирующего смещениями (или одни структуры ссылаются на другие используя смещения, а не какие-нибудь названия/индексы) — чтобы реализовать возможность перемещаться туда-сюда между структурами.

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

Т.е. дизассемблирование всегда будет идти рука об руку с любым другим методом реверс-инжиниринга, в том числе сколько угодно clean room и black box.

Использование «продукта» для создания файлов EULA как правило не ограничивает.
Получающиеся файлы принадлежат пользователю.
С файлами почти* всегда можно делать что угодно.

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

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

С дизассемблированием такой номер не пройдёт.

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

Возьмите gitter, он цепляется к проекту на github, имеет стандартный набор приложений (десктопные под онтопик и два оффтопика + мобильные под android/iOS).

Я, пожалуй, толком ничего хорошего про него сказать не могу. Протокол - полузакрытый, проприетарный и нестандартный. Набор «приложений» - тоже полузакрытый и де факто там раздают просто дистрибутив webkit на ~80 мегабайт, открывающий заранее прошитый URL. Чем это отличается от просто держать открытой вкладку в браузере - непонятно.

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

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

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

С дизассемблированием air gap примерно такой же - «мне прислал этот код мой товарищ из Европы/России, на территории которой это легально».

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

примерно такой же

Похоже к общему знаменателю мы по этому поводу не придём. Предлагаю юридическую сторону вопроса закрыть.

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