Hobbits 0.21 — визуализатор бинарных файлов для реверс-инжиниринга

Работает ли он с блоками битов переменной длины некратной 8? Можно ли проанализировать им файл ZIP, восстановив алгоритм распаковки? Есть ли готовые примеры такого разбора?

А точно что новость не про 1-го апреля ? Вот к примеру GIMP он что визуализирует не бинарные данные ?

Я несколько раз такие визуализаторы писал самостоятельно. Либо в консоль, либо PNM и xdg-open. Если упростят процесс готовым инструментом — прекрасно.

Но если биты не попадают на границу байт, получается громоздко. RLE я с трудом осилил, более сложное сжатие — нет. Если здесь есть готовое API с примерами — прекрасно. Например, shl, shr, rotl и rotr для массивов байт (или питоновских байтстрингов) произвольной длины.

Судя по «why/what» какой-то производитель чего-то сделал под себя и решил поделиться с миром.

Но зачем?

Zhbert

ник я не угадал

Лучше ли он, чем Kaitai IDE?

Интересная и полезная штука. Было бы круто, если бы для NSA’шной Ghidra ещё сделали плагин.

В руководстве пользователя такого ПО должен так же поставляться подробный рецепт содержащий состав, пропорции и график употребления веществ необходимых для подобного подхода к обратной разработке.

для подобного подхода к обратной разработке

Это о чём?

Но зачем?

We’d love contributions and resumes, but we’ll settle for bug reports and memes.

ник я не угадал

+1

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

Матрицу смотрел?

Хотя, может эта штука и про что-то ещё.

Я в этой теме не шарю

Зато честно =)

О, какой сильный набор решений. Почти как objdump.

Вот относительно наглядный пример про что я. Однако, мнение экспертов, как всегда бесценно.

Qt

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

Что-то я не пойму как это связано…

Правильное крипто на выходе даёт шум. Хорошее сжатие на выходе тоже будет давать что-то вполне шумоподобное.

Вроде бы авторы не предлагают открывать криптованные файлы и пыриться в них до просветления.

Посыл в том, что даже псевдослучайная маска применённая без соответствующей криптографии к одному и тому же шаблону даёт узнаваемую картинку. Для оператора == картинки original, and и or это разные картинки, а вот для человеческого глаза нет.

И? Имеется тулза, которая какими-то способами представляет содержимое файла в виде изображения. Для просмотра человеческим глазом.

В чём проблема «подобного подхода к обратной разработке»?

А если ему зашкваренный денувой файл подсунуть? Сколько оперативки нужно будет на такую визуализацию?

Сколько оперативки нужно будет на такую визуализацию?

Смотря как реализована работа с данными. Но на скрине визуализация для небольшого фрагмента в ~5kb. Для такого нужны «копейки» памяти.

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

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

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

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

Ну, надеяться на то, что взглянув на файл или его кусок показанный в виде «WxH, N-bit на пиксель» ВСЕГДА получится что-то эдакое УЗРЕТЬ было бы... гмм... глуповато.

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

Евгений Ваганыч, перелогиньтесь.

Ну, надеяться на то, что взглянув на файл или его кусок показанный в виде «WxH, N-bit на пиксель» ВСЕГДА получится что-то эдакое УЗРЕТЬ было бы… гмм… глуповато.

Можно попробовать подобрать эти самые W и H чем-то типа дискретной автокорреляционной функции. Кстати, у меня подозрение (могу ошибаться), что график в правой стороне скриншота — это она и есть.

Ага, ещё приделать туда cv и ml потом, дабы сервера не дешевели.

Можно попробовать подобрать эти самые W и H

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

Я один не понимаю, зачем это нужно? (не нужно)

Анализировать бинарные данные, не дизассемблируя раотающую с ними программу. Например, для извлечения ресурсов из игр. Сейчас уже намного менее актуально, чем лет 25 назад, так как большинство пользуются хорошо документированными чужими движками, а не пишут свои. Или расковыривать коммерческие БД, которые полагаются на security through obscurity. Опять-таки гораздо менее актуально, для новых баз, чем в прошлом.

зачем это нужно?

Хвастаться перед одноклассниками, например. Если еще заготовить гифку с «вирусом» за решеткой, то успех неизбежен.

А еще можно cat $file > /dev/dsp

В современных дистрибутивах pulseaudio не даст.

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

я понял. это пятна роршаха для программистов.

Я вообще не видел ни одной годной софтины подобного плана. как правило обещают много. а на деле пшик. может чтото пропустил?

будет время попробую, но чтото сомневаюсь.

http://kaitai.io/ смотрел? Говорят, прикручивали средства распаковки, но в примерах их нет, а ставить и экспериментировать нет времени. И средств описания блоков битов не выровненных на байт, по-прежнему, не нашёл.

Стоит поправить новость. Вчера выложили версию 0.22 :)

Побитная или побайтовая растеризация

Зашивать картинки с ЦП уже предлагали?

Гимп только растеризует, а это еще много чего. Ну понятно что инструменты разные.

Гимп только растеризует

Гимп не растеризирует, а редактирует растровые изображения. Растеризация - это превращение чего-либо в растр. Сабж поток битов отрисовывает в растре, векторные редакторы - вектор в растр могут превращать. А Гимп загружает уже готовый растр и редактирует его.

Прим. Формально у Гимпа есть загрузка SVG, т.е. он может растеризировать SVG. Раньше очень тормозил на такой операции, как сейчас - не знаю.

Прим.2 Попробовал: Гимп версии 2.10 растеризует SVG достаточно шустро.

посмотрю, спасибо. да, нет времени на самое вкусное.

вообще, с инструментом беда.

Кэп, это уже слишком.

Ну, надеяться на то, что взглянув на файл или его кусок показанный в виде «WxH, N-bit на пиксель» ВСЕГДА получится что-то эдакое УЗРЕТЬ было бы… гмм… глуповато.

Можно попробовать подобрать эти самые W и H чем-то типа дискретной автокорреляционной функции. Кстати, у меня подозрение (могу ошибаться), что график в правой стороне скриншота — это она и есть.

Насколько я могу судить, поэкспериментировав — да. График и таблица плагина Width Framer показывают вероятность, что файл имеет такой период в битах.

Вот только работает дико медленно, и считает неверно. Сложилось впечатление, что результаты предыдущих вычислений перемножаются с новыми и домножаются на что-то типа 10000. После нескольких попыток вся автокорреляция уходит в NaN.

P.S. Автор пообещал скоро поправить.

Вот только работает дико медленно

Значит толку мало от сабжа.

Кэп, это уже слишком.

сравнивать гимп с сабжем тоже «нифига себе» :)

Но это не ко мне!

А если так: GreyCat?

Ну «дико медленно» это как раз не повод для «толку мало». Тут же РМВ не нужно. Озадачил — отвлёкся — посмотрел. Более того, если она сравнения прогоняет не байтами, а битами, было бы странно, если бы оно работало быстро.

Вот то, что считает неверно — это уже хуже. Ждём обновлений.

Ну «дико медленно» это как раз не повод для «толку мало». Тут же РМВ не нужно. Озадачил — отвлёкся — посмотрел. Более того, если она сравнения прогоняет не байтами, а битами, было бы странно, если бы оно работало быстро.

Дико медленно работает отрисовка byte raster. От клика до реакции на него проходит 3-5 секунд. На 2-ГГц Селероне. Все остальные операции для файлов в десятки килобайт происходят мгновенно.

Вот то, что считает неверно — это уже хуже. Ждём обновлений.

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