LINUX.ORG.RU

Как разобраться в формате файла? (было: Как заинструментировать код на Си)

 , , , ,


3

2

Пост обновлен, предыдущее название: «Как заинструментировать код на Си и понять что он делает? Реверсинг формата файла»


Вступление

Есть какой-то файл и я хочу понять его внутреннее устройство. В качестве примера, возмем файл формата PNG, так как он достаточно простой и хорошо документирован. Но далеко не все форматы хорошо документированы, поэтому полагаться только на документацию - нельзя.

Итак, у нас есть какой-то файл формата PNG - что с ним дальше можно сделать? Можно было бы взять готовую библиотеку для чтения данного формата (libpng), но она содержит более 100 000 строк кода, что крайне сложно для понимания.

Я предполагаю, что более наглядным для изучения будет разглядывать такие картинки:

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

К сожалению, не все форматы файлов так хорошо описаны, как описан формат PNG. Далеко не для всех форматов файлов есть такие картинки и тем более шаблоны для hex-редакторов. И я бы хотел делать такие картинки самостоятельно.


Идея

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

Само собой, для тестирования, нужно будет собрать некий тестовый датасет (набор png-файлов с разными разрешениями, режимами компрессии, битые файлы). Для этого было бы неплохо использовать утилиты из набора AFL для уменьшения датасета и уменьшения самих исходных данных: https://youtu.be/0dqL6vfPCek (фаззинг файла вместе с ffmpeg)

Вопрос: как бы заинструментировать имеющийся софт (программу, библиотеки), чтобы понять, что такое оно делает с файлом, что внутри и как его вообще читать? Да и вообще, что можно вытащить из подобной затеи?

Например, очень бы хотелось узнать:

  • Сигнатуру файла (\x89PNG в начале файла)
  • Структуру «чанков», что она представляет собой 4 поля: длинна, тип, данные, CRC32
  • Алгоритм расчета CRC32: какая часть данных считается, с заголовком или без, какой полином
  • Какая часть файла пожата zlib, какие части файла просто являются несжатыми массивами
  • Нарисовать какую-то диаграмму, где какой байт чему соответстует, вроде https://i.imgur.com/eLd44xQ.png или https://i.imgur.com/AwpmSxV.png

Я себе это представляю как-то так:

  1. Читаем кусочек файла и помечаем, что это наш файл (перехватываем read/fread, «отравляем» эти участки памяти)
  2. Ставим брейтпоинт на чтение памяти, логгируем, смотрим по map-файлу где мы это читали, желательно размотать стек
  3. По коду уже можно представить, читаем мы float или int16, находимся ли в структурке или еще где. Если мы внутри функции check_file_signature(), то это вообще очевидно. Можно пометить как ручками, так и чем-то вроде IDA.

Зачем? Это поможет в написании файлов-шаблонов для таких программ как https://ide.kaitai.io/ или 010 Editor. Конечно, в идеале запустить на входе PNG-файл, а на выходе получить KSY (формат описания файлов kaitai) или BT (формат для 010 Editor), но понятно, что идеальной документации не будет. Но я стремлюсь именно к этому.

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

Буду благодарен на статьи просто по инструментации сишного кода. Или не только сишного.


Референсы и идеи

  • https://github.com/AFLplusplus/AFLplusplus - отличное средство для фаззинга (пример фаззинга libpng: https://youtu.be/LsdDRat4S0U), но я не очень понимаю как это применить именно к описанию файла. А вот тулзы вроде afl-cmin - чистое золото
  • https://www.intel.com/content/www/us/en/developer/articles/tool/pin-a-dynamic-binary-instrumentation-tool.html - Intel PIN
  • Address Sanitizer or ASAN - можно попробовать поиграться с ним и залоггировать доступ к памяти
  • valgrind + lackey - очень многообещающе, но боюсь не осилить
  • Попробовать сделать доступ к страничке PROT_NONE, получить сегфолт, но непонятно как возвращать управление (сделал, но споткнулся на последнем пункте)


Последнее исправление: ruzisufaka (всего исправлений: 2)

Ответ на: комментарий от alysnix

может проще тупо почитать стандарт png, чем заниматься реверс инжинирингом?

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

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

https://ide.kaitai.io/

Ближе. Однако:

  1. Формат описания (KSY) писать все равно надо. И инструментация кода, как я думаю, помогла бы в этом. Мы же не знаем внутренности PNG.

  2. Лично я так и не смог заставить его работать, когда пытался последний раз (год назад). Оно постоянно сыпало ошибками и умирало. Задумка хорошая, язык не самый отвратительный, но пользоваться невозможно.

ruzisufaka
() автор топика
Последнее исправление: ruzisufaka (всего исправлений: 1)

прикольный вопрос!

в целом то, что ты хочешь, называется symbolic execution.

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

но некоторые соображения есть:

оптимизирующий компилятор – уже неплохое приближение к частичному вычислению (что уже половина дела). хитрый код на c++ я не раз читал, скомпилировав и дизассемблировав. убирает существенную часть абстракций. для rust, наверное, тоже будет работать.

есть всякие академические штуки, вроде frama-c. не думаю, что они справятся с реальным кодом.

ещё посмотри на fuzzing, например, afl – это такое динамическое восстановление control flow. у него неплохо получается «переоткрывать» бинарные форматы.

я этим уже давно не занимался – будет круто, если этот список дополнят.

anonymous
()

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

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)

Почему-то в PNG CRC32 не включает в себя длину, а полином такой же как в zip и gzip. Записана в чанке в формате big endian.

Например CRC32 от строки IEND получается 0xAE426082 и он совпадает с последними четырьмя байтами на скриншоте.

А разве в формате deflate нет своей контрольной суммы?

Xenius ★★★★★
()
Последнее исправление: Xenius (всего исправлений: 2)

В реале немного не так всё.

Раскрутить чтение файла, тем более на сишке - достаточно просто. На цепепе немного сложнее, но тоже реально.

Нужен какой-нибудь приличный декомпилятор и время. Берём софтину декомпилируем и ищем всякие open и read. Что-то будет относиться к чтению файла. Далее начиная с open ищем первое чтение, смотрим как читается заголовок. Ну и дальше кропотливо раскручиваем это всё. Если используются сторонние библиотеки - читаем доки на них, смотрим как они применяются для данных читаемых из файла. Ну и т.д. Дело в том, что отталкиваясь от файла, а не от кода, можно упустить огромное количество вещей, которые в исследуемом экземпляре не используются. А все возможные варианты файла заполучить может быть просто нереально. А если раскручивать код, то все варианты, флаги, метаданные потихоньку станут понятны и уже можно будет написать читалку которая будет читать любые файлы данного формата, даже те, которых у тебя не было.

Мне частенько приходится реверсить форматы файлов всяких мутных промышленных софтин написанных с какими-то понтами, велосипедами и потугами на вендорлок и всё такое.

Недавно реверсил формат HyperFile (*.FIC) из PCSoft’овского фреймворка WinDev. Такая типа недоБД проприетарная. Какое-то жалкое подобие SQLite но в которой можно делать поля-массивы, типа CREATE TABLE example(name CHAR(32),date DATETIME, reflectance[40] REAL32). Было забавно. Там вторичный заголовок, где хранятся названия, размеры и типы полей БД сначала сжимается нестандартной реализацией LZW, a потом перекрёстно ксорится 16-тибайтным ключом сделанным из французской фразы «Il serait plaisant qu’Annick se décide ŕ nous apporter des DooWaps» и начального 16-тибайтного seed. При этом, сами данные в файле не сжаты и не закодированы, но смещения и размеры полей без заголовка не получить. Нахера так делать, кроме как для лютого вендорлока - я не знаю. Зато теперь знаю что такое DooWaps. :)

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

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

оптимизирующий компилятор – уже неплохое приближение к частичному вычислению (что уже половина дела).

скомпилировав и дизассемблировав

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

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

В большинстве случаев реверс-инженеринг именно машинного кода будет проще и быстрее.

Именно так сейчас все и делают, если приложение проприетарное. Или в процессе реверсинга, или уже после него, пишется файл правил (к примеру, для 010 Editor) на столько, насколько это нужно исследователю. На этом документация обычно и заканчивается. Или просто выкусывается нужный кусок кода, пишется, а документация не пишется никогда.

Я же хотел бы получить полную, 100% документацию, пусть только для форматов, для которых существуют открытые реализации. Возможно, из таких вот выкушенных кусков кода.

Кстати, если нет проверки контрольной суммы - весьма эффективным может быть не анализ программы, а изменение самого файла и уже анализ результатов её работы па разных модификациях

В нашем примере есть некий my_png_reader без каких-либо защит, надо получить документацию (или хоть какое-то описание) формата PNG. Защит и проверок нет, можно патчить как угодно. Есть исходники. Вопрос - как?

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

А разве в формате deflate нет своей контрольной суммы?

Есть, это adler32, но на ряду с ним, внутри PNG используется еще и CRC32. Вот найти эти алгоритмы - это и есть задача. Ну и всякие настройки этих алгоритмов, вроде начальных значений или полиномов.

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

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

Иногда это большое преимущество. В том же PNG существует огромное количество расширений, чтение исходников libpng может быть крайне утомительным занятием. А вот если у тебя есть картинка вроде https://i.imgur.com/AwpmSxV.png с подписанными структурами - уже не так страшно и больно, уже можно написать свой диссектер и дальше наращивать функциональность по мере надобности.

Вот генератор таких картинок и хотелось бы заиметь. Пока что файлы открытые или почти открытые (всякие TTF-шрифты имеют внутри себя такой клубок расширений и легаси, что просто страшно). Опять же, даже для коммерческих редакторов, таких как 010 Editor, шаблоны бинарников порой крайне кривые (у меня на крохотном mp4 выжиралась вся память) или просто показывается заголовок и игнорируется 95% файла.

нестандартной реализацией LZW

Когда-то сам такое писал, когда пытался сделать GIF. Где-то обосрался и у меня постоянно падала Опера от моих картинок. Возможно эта нестандартная реализация - плод кривизны рук, а не вендорлок.

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

А разве в формате deflate нет своей контрольной суммы?

Есть, это adler32

Нет.

Где он тут https://www.rfc-editor.org/rfc/rfc1951?

Контрольные суммы есть в gzip и zip, которые являются контейнерами deflate.

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

Где он тут https://www.rfc-editor.org/rfc/rfc1951?

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

Я просто помню, что когда я генерил PNG своими руками, то внутри deflate мне приходилось считать adler32. А вот часть стандарта оно или нет - это я не знаю.

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

Как заинструментировать код на Си и понять что он делает? Реверсинг формата файла

В 90-х была програмка для реверсинга игр, которая работала так.
Меняем значение опции в игре, а программа в памяти производит поиск изменённых байт.

Нужно «порыть» inet, интересная тема.

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

В том же PNG существует огромное количество расширений, чтение исходников libpng может быть крайне утомительным занятием.

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

Возможно эта нестандартная реализация - плод кривизны рук, а не вендорлок.

Не, там всё пучком в смысле реализации, просто словарь например иначе организован, спецсимволы (dictionary reset и EOF) другие и т.п. Так что именно вендорлок, чтобы расковырять сходу не получилось.

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

Интересно такого рода программы помогут в реверсинге форматов данных?

Как-то мне знакомый админ сказал - «Вот этот школьник в пять минут может взломать любую игру».

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от Forum0888

Интересно такого рода программы помогут в реверсинге форматов данных?

Не очень, они для юных (и не очень) «хакеров» игр. :)

Вот этот школьник в пять минут может взломать любую игру

Вот именно! :)

dataman ★★★★★
()
Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от ruzisufaka

В PNG дефлейт используется внутри контейнера zlib, который добавляет небольшой оверхед. https://www.rfc-editor.org/rfc/rfc1950

То есть там есть и Adler32 от начального потока данных и контрольная сумма CRC32, по всей видимости, от уже сжатого потока данных, включая слово IDAT и всё после него, но исключая длину чанка.

Xenius ★★★★★
()
Последнее исправление: Xenius (всего исправлений: 2)
Ответ на: комментарий от nvl

Если есть исходники, то в чем проблема?

Их надо читать. Иногда очень много исходников. А хотелось бы понимать и для этого мне проще смотреть на картинки.

ruzisufaka
() автор топика

Допустим, у нас есть исходники и самой программы, и всех библиотек

Ну так возьми и прочитай их, зачем реверсить то что уже открыто?

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

Вопрос только как отслеживать данные в оперативной памяти, включая все копирования/распаковки.

посмотри на valgrind (не только memcheck, который по умолчанию вызывает команда valgrind, а все его возможности), или memory sanitizer, раз уж у тебя есть исходники.

предполагается, что исходники немного понятнее, чем чтение дизасма

по моему опыту это не так. ну и было бы тебе просто читать исходники – ты бы эту тему не создавал, правда?

а на тему дизасма – сейчас есть неплохие декомпиляторы, которые делают что-то более си-подобное, если в этом проблема. из бесплатного ghidra, из платного binaryninja и ida pro.

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

Чтобы решать задачу, нужно её сначала правильно поставить.

Найти/создать некий тулкит/фреймверк для описания форматов файлов. Попутно изобретя очередной универсальный язык для этого самого описания (должен быть одновременно декларативным и императивным). Потом конкурировать с kaitai, 010 editor, заработать миллионы долляров и построить прекрасную россию будущего.

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

Недавно реверсил формат

Такая типа недоБД проприетарная. Какое-то жалкое подобие SQLite

:)))

Может, ты и формат Borland Paradox реверсил? Вот такая документация (если её кто сподобился написать) была бы реально полезной для освобождения некоторых старых решений. Они на этом делались не для лютого вендорлока, а потому, что в середине 90-х реляционных альтернатив было не особо много, ну и по эффективности Paradox был неплохим решением, среди локальных СУБД пожалуй, что и лучшим.

P.S. На сорсфорже, правда, находилась некая pxlib

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

Может, ты и формат Borland Paradox реверсил?

Нет, просто не попадалось такого. А что, есть много старых данных в этом формате, и экспортировать нечем?

Мне этот HyperFile пришлось ковырнуть исключительно потому что есть актуальный, безальтернативный (пока что, хе-хе ;)) софт, который постоянно производит эти файлы в количестве в рутинном производственном процессе (рецептуры цветов производимых предприятием артикулов из имеющихся на данный момент пигментов), а родная экспортировалка HyperFile для WinDev мало того, что платная (идёт в составе SDK который недёшев и да вряд ли сейчас его нам продадут вообще), так ещё и 100500 кнопок в ней надо мышью нажать, чтобы собственно экспортировать данные в что-то удобоваримое. Даже если купить SDK, то это не работа будет а классическое постоянное мышевозение виндовое. Да и на все точки, где это файло требуется постоянно открывать, не накупишься. Ну вот и пришлось сделать чтобы наш софт этот HyperFile нативно открывал без каких-либо сторонних библиотек или там ODBC драйверов.

Ну так вот, если файлы постоянно не создаются в процессе чем-то уникальным и незаменимым и речь просто о замене софта который их использует, то проще и разумнее все старые данные один раз отконвертировать какой-нибудь борландовской конвертилкой/дампилкой в читаемый формат и потом в тот же SQLite, например, а замену софту на Парадоксе сделать уже с новым форматом.

Stanson ★★★★★
()

Нашел это:

Очень вдохновляет, хотя ничего и непонятно. По всей видимости мне надо сделать еще один tool для valgrind. Как я понял, вся нужная инфраструктура уже есть внутри этого pmem, мне бы только для своих целей его заюзать - вот тут наверное у меня квалификации и не хватит.

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

Вроде бы то, я попробую чуть позже переосмыслить и переписать первый пост.

Пока же вот мои размышления в 3 часа ночи о том, как жить дальше:

  • Для начала залезть в процесс (LD_PRELOAD? Valgrind? my_cool_instrumentation.h + my_cool_lib.a?)
  • Найти в процессе интересующий файл (Подменить собой read/fread?)
  • Если не нашли, просканировать всю аллоцированную память, поискать кусочки исследуемого файла (вдруг файл как-то кусочками подгружался и я его пропустил?). Героически побороться с чем-то похожим на ASLR, чтобы адреса не прыгали.
  • Перехватить обращение к этой памяти (или изобрести свой malloc, повесить обработчик исключений на себя и при каждом эксепшене что-то самостоятельно делать, или заюзать валгринд?)
  • Как-то размотать стек, узнать где мы находимся, как зовут текущую функцию, номер строки в файле исходников (читать рядом лежащий dwarf?)

Вроде бы ничего больше для счастья и не надо. Ну, по крайней мере пока. К примеру, надо будет конечно найти не только обращения вида databuf[123], но и somestruct.some_field и как-то их различать, а на самодельном аллокаторе с эксепшенами это будет непросто.

Пока же это больше фантазии в 3 часа ночи и последствия просмотра чего-то вроде https://youtu.be/lLEcbXidK2o

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

Найти/создать некий тулкит/фреймверк для описания форматов файлов.

https://github.com/kaitai-io/kaitai_struct

Основная идея заключается в том, что конкретный формат описывается 
в языке Kaitai Struct только один раз, а затем может быть 
скомпилирован с помощью kscисходных файлов на одном из 
поддерживаемых языков программирования. Эти модули будут включать 
в себя сгенерированный код для парсера, который сможет читать 
описанную структуру данных из файла/потока и предоставлять к ней 
доступ с помощью красивого, простого для понимания API.

Уже поддержанные форматы:
https://github.com/kaitai-io/kaitai_struct_formats
http://formats.kaitai.io/

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

@Forum0888

С какой целью вы с таким упорством постите в узкие технические темы выхлоп из поисковика? Серьёзно полагаете, что все кругом — идиоты и кроме вас погуглить никто не справится?

По постам понятно что в теме вы ни ухом ни рылом. И не только в этой. Скор набиваете? Жаждете быть причастным?

Отвечать и пререкаться здесь не надо — просто сделайте форуму одолжение и перестаньте отвечать в темы, в которых не разбираетесь толком. Спасибо.

anonymous
()

Пока пошел по простому пути: https://stackoverflow.com/questions/8415747/how-to-implement-deterministic-malloc - изобретаю свой «маллок» и в перспективе буду загружаться через LD_PRELOAD https://stackoverflow.com/questions/6083337/overriding-malloc-using-the-ld-preload-mechanism (спасибо авторам, а то про calloc и ему подобные я уже забыть успел)

ASLR победил двумя заклинаниями:

echo 0 > /proc/sys/kernel/randomize_va_space
gcc -no_pie
ruzisufaka
() автор топика
Ответ на: комментарий от ruzisufaka

присоединяюсь к @buddhist:

ты, видимо, сам не придумал, что ты хочешь делать и зачем.

пока были следующие варианты:

  • система описания бинарных форматов – тебе правильно предложили kaitai struct, 010 editor templates и пр.

  • динамическая инструментация i/o в программе – тебя ткнули в valgrind

  • вывод формата по control flow – я и @mittorn предложили смотреть, как это делают фаззеры, типа afl

соберись с силами и придумай, чем занимаешься.

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

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

Как из flow control выковырять нужную информацию я представляю слабо, потому скорее динамическая инструментация IO, но в valgrind из коробки этого нету, зато сам valgrind является отличным фреймверком для написания таких штук, как я понимаю. Там даже в репозиториях есть что-то похожее на задуманное, но датированное 2005-м годом с подписью «постоянно падает».

Так как инструментированный код в лучшем случае может дать нам адрес кода и адрес файла, куда было обращение, то лог будет выглядеть примерно так:

IP:0x80000034 at 0x827364
IP:0x80000489 at 0x569387
IP:0x80002394 at 0x345877
IP:0x80002394 at 0x938432

Первый адрес можно скормить addr2line и получить имя файла и строку (можно ли получить столбец - не разобрался). Его же можно скормить дизассемблеру и получить тип данных (uint16_t, uint64_t, float) и его размер. Еще при логгировании адреса можно попробовать писать стектрейс, чтобы понять откуда был высокоуровневый вызов (в то вдруг там самодельный слой IO и мы только его залоггируем?). Второй адрес - это смещение в файле. Вот в общем-то и все, все наши данные, которые мы можем наковырять. Или нет? Если я ошибаюсь, напишите!

Это уже кое-что, как мне пока думается, отличная отправная точка для работы, но подобный лог - очень сильно далек от kaitai и 010 editor. Чтобы его засунуть в эти программы, надо будет изобретать какой-то конвертор. Какой именно - непонятно. Очевидно, что нужно будет двигать секции, возможно делать несколько уровней выделения, чтобы это было хоть как-то полезно. Да и будет ли это вообще хоть сколько-нибудь полезным - я не знаю. Поэтому все это пока на стадии пруф-оф-концепт.

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

Kaitai я так и не смог заставить работать, а шаблоны под 010 editor я даже писал.

Девлог:

Сделал хелловорлд со своим маллоком (выделяю память через mmap), своими правами, и своим обработчиком сегфолтов. Столкнулся с проблемой, что отловить обращение к памяти я могу (получить сегфолт), но что делать дальше - непонятно. Очевидное решение, дать странице памяти нужные права и вернуться из обработчика, но как отнять права на следующем шаге?

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

А если я не хочу быть реверсером, а просто хочу узнать о строении файлов?

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

Поэтому я решил заинструментировать код.

Оказывается, есть даже почти готовый семпл: https://valgrind.org/docs/manual/lk-manual.html

Впрочем, я все еще боюсь трогать valgrind (писать к нему свой тул) и попробую теперь поискать со встроенным в компилятор адресс-санитайзером.

ruzisufaka
() автор топика