Русский / Russian English / Английский

Сейчас на форуме: johnniewalker, Adler, sss123 (+3 невидимых)
 · Начало · Статистика · Регистрация · Поиск · ПРАВИЛА ФОРУМА · Язык · RSS ·

 eXeL@B —› Крэки, обсуждения —› Анализ форматов [ч1. Внешний осмотр]
Посл.ответ Сообщение


Ранг: 103.3 (ветеран)
Статус: Участник

Создано: 18 ноября 2006 08:25 New!
Цитата · Личное сообщение · #1

Часть 1. Внешний осмотр.
Обсудим в первом приближении файло на операционном столе. Какие инструменты используете? Какие методики? Не углубляемся пока в полноценный реверс, в первой части только внешний осмотр!

Ветку создаю для тех, кто занимается реверсом / анализом (называйте как угодно) чужих файловых форматов с целью "поделиться знаниями и идеями". Надеюсь найдем что обсудить. Чтобы избежать флуда и оффтопа, от каждого автора прошу небольшого описания его "деятельности", его "инструментарий" ну и мессагу по теме, конечно.

Несколько лет занимаюсь разбором файловых форматов, специализируюсь на форматах специфических ИС. Инструментарий: WinHEX / 010 Editor, Filemon (далее Филемон) + собственный монитор (hook на WinAPI работе с файлами) и куча утилит, образующих swissknife.

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

Сходу выделю два направления:
1) анализ файлов, без хост-приложения
2) анализ файлов с хост-приложением

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

В независимости от направления необходимо оценить файло по следующим критериям:

Возможный контент. Собственно с ходу надо хотя бы немного понять что же хранится в этом файле ) Именно эти знания не раз еще пригодятся при анализе. Что же это? БД? Мультимедиа? Специфическая информация (картосновы к примеру)? Или же вообще это контейнер, который содержит самый разный контент?

Для начала советую не спешить и пробежаться по файлу каким-нибудь индентификатором (к примеру TrID), возможно и вообще не стоит заморачиваться и это обычный ZIP. Не забывайте что тот же TrID сканит по сигнатурам, у которых жестко указан offset. Используйте иные инструменты, чтобы поискать сигнатурки известных форматов внутри файла тоже, может быть это контейнер.

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

Упакованность. В случае наличия хост приложения можно оценить алгоритм упаковки, тем же PEiD + KANAL. Важно определить упакован ли весь файл и это container или же упакованы его элементы, но эти знания придут со временем (анализа конечно). Советую также оценить энтропию, по ней можно много чего сказать (тут поможет WinHEX / прочие утили).

В случае, если мы имеем дело с Deflate / LZO и прочим, то можно воспользоваться STUBS'ом (утиль, автора не помню, сам ее доводил потом до ума), которая является по сути брут-распаковщиком ряда алго. По результатам уже можно будет судить о некоторых моментах. А возможно вам этого и хватит =))

Зашифрованность. Опять же при наличии хост-приложения -> PEiD + KANAL. Правда есть много простых алго (SUB / ADD, XOR), которые любят использовать афтары: во-первых они быстрые, по сравнению с криптографией; во-вторых афтары (сцуки =) надеются на "безнаказанность". По этой теме думаю будет что обсудить.

Если мы имеем дело со строковой информацией, то однозначно в руки утилиту от UsAr'a (CryptoStringSearcher, далее CSS). Позволит оценить есть ли зашифрованные этими алгоритмами строки, да и вообще понять что у нас в файле со строками.

Более менее "с чем мы имеем дело" становится ясно. Это предварительный осмотр. Далее приходится углубляться.

P.S. Надеюсь ветка будет иметь продолжение. Я мог много чего не упомянуть, мне действительно интересно мнение отцов и остальных.

Ранг: 123.7 (ветеран)
Статус: Участник
1nn0$/100

Создано: 18 ноября 2006 14:42 New!
Цитата · Личное сообщение · #2

Занимаюсь анализом форматов полгода. (Ну как на работу устроился, так и пришлось)
Инструментарий: hiew, SomeBrains, Olly, Filemon, IDA (порой приходится выдерать из проги куски кода, такие как проверка CheckSum).
Занимался пока только анализом при наличии хост-приложения.

Методика:
Оценить что за прога. Если СУБД, то формат скорее всего такой: файл разбит на страницы (примерно по 0x1000 байт), в конце страницы таблица смещений. (Основано на личном опыте).
Создать пустой файл. Для чего? Чтобы откинуть мусор при парсинге. Не секрет, что большинство форматов (имеются в в виду громозкие офис-приложения) содержат информацию, которой можно принебречь при парсинге.
Создать небольшой файл с легко узнаваемыми данными. Проанализировать их положение в файле. Если данные не найдены есть смысл задуматься над зашифрованностью.
В случае зашифрованности, создать файл с совершенно другими данными, посмотреть изменилась ли структура, если нет, то скорее всего имееем дело лишь с шифрацией данных. Олю + IDA в руки. С шифрацией всего файла еще не сталкивался.
Создать еще один файл, чуть больше предыдущего и с другими, но также узнаваемыми данными. Проанализировать их расположение. Сделать предположение насчет общей структуры файла.
Создать большой файл. Проверить гипотезу.
Создать ооооочень большой файл. Проверить гипотезу. Если гипотеза верна, писать парсер. Проверить его на куче файлов. Править баги + представления о формате.

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

Ранг: 123.7 (ветеран)
Статус: Участник
1nn0$/100

Создано: 18 ноября 2006 14:43 New!
Цитата · Личное сообщение · #3

NaumLeNet, выложи плиз линки на проги указанные в твоем посте.

Ранг: 213.5 (наставник)
Статус: Участник
забанен

Создано: 18 ноября 2006 17:56 · Поправил: Demon666 New!
Цитата · Личное сообщение · #4

NaumLeNet пишет:
Если мы имеем дело со строковой информацией, то однозначно в руки утилиту от UsAr'a (CryptoStringSearcher, далее CSS). Позволит оценить есть ли зашифрованные этими алгоритмами строки, да и вообще понять что у нас в файле со строками.

Скачал, посмотрел, на первый взгляд кажется недоделанной, особенно алго – ИМХО.
На каком-то форуме видел, UsAr задавал вопрос, как улучить алгоритм поиска строк, но так и не получил на тот момент разумный ответ!?
UsAr
Если читаешь сие, то напиши здесь, какие планы на будущее в отношении CSS и поподробнее об …
Считаю, что CSS должен развиваться!
У самого, когда будет свободное время, тоже буду принимать активное участие в его развитии, тем более написан CSS на родном для меня языке программирования. ;)


Ранг: 103.3 (ветеран)
Статус: Участник

Создано: 18 ноября 2006 23:42 New!
Цитата · Личное сообщение · #5

Demon666
CSS действительно должен развиваться. Работает он довольно быстро, тем более asm (я написал аналог на delphi + fastmm лишь по той причине, что не хватает ряда опций и последняя версия 1.3 валится на больших файлах). Надеюсь UsAr слышит нас =) Хотя в топике про CSS я уже об этом упоминал не раз.

1nn0cent
Stuns - slil.ru/23429490
CSS - usar.pp.ru/CryptoStringsSearcher.1.3.rar
TrID - mark0.net/soft-trid-e.html

По поводу хост-приложения и файла. Реально облегчается задача, когда можно "генерировать" хост-приложением данные для исследования. Осложняется, когда хост-приложение умеет только читать файло - отсюда - набор данных всегда один. Если есть возможность выбрать то конечно же надо выбирать меньший набор.

Сенькс за ответ. На чем пишешь парсер обычно?

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

Последнее время часто вишу pattern, который назовем для краткости "Chunks". Т.е. это набор chunk'ов (блоков / записей / структур) и subchunk'ов разного назначения. Очень часто, каждый chunk сопровождается некоторой служебной информацией (имя + по совместительству сигнатура, метаданные и прочее), таблицей offset'ов (до след. чанка, до след. субчанка, до данных и т.д.). Подобную структуру можно наблюдать в формате PNG, в файлах игры WoW (World of Warcraft) и во многих других разношерстных системах.

Еще много всяких pattern'ов встречалось, долго описывать. Надеюсь кто-нибудь дополнит меня?

Ранг: 72.3 (постоянный)
Статус: Участник

Создано: 19 ноября 2006 01:28 New!
Цитата · Личное сообщение · #6

пока нет UsAr'а откомменчу. CSS по идеи должен перелится в более глобальный проект, но обстоятельства складываются так, что пока всё затормозилось, к сожалению...


Ранг: 103.3 (ветеран)
Статус: Участник

Создано: 19 ноября 2006 01:44 New!
Цитата · Личное сообщение · #7

sER
Можно поподробнее про глобальный проект? Пасширение кол-ва алго + встроенный брут по всему файлу / блокам? Реально интересно. Какие причины торможения, кстати?

Ранг: 66.8 (постоянный)
Статус: Участник

Создано: 19 ноября 2006 02:11 New!
Цитата · Личное сообщение · #8

NaumLeNet, Demon666
http://exelab.ru/f/index.php?action=vthread&forum=3&topic=6839

sER пишет:
CSS по идеи должен перелится в более глобальный проект, но обстоятельства складываются так, что пока всё затормозилось, к сожалению...

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

Ранг: 123.7 (ветеран)
Статус: Участник
1nn0$/100

Создано: 19 ноября 2006 02:13 New!
Цитата · Личное сообщение · #9

NaumLeNet, я ограничен требованиями конторы, поэтому MS C++ ну и ассемблерные вставки.
Поясню по поводу дерева с отрезками.
В файле БД лежит дерево. Лежит таким образом: маркер начала узла(МНУ), номер узла, длина данных, данные, маркер конца узла(МКУ). Вот собственно. Ну естественно дочерний узел выглядит так: МНУ, номер узла, МНДочернегоУ, ..., МКДочернегоУ, МКУ. Надеюсь понятно... Вот как можно облегчить исследование такой дряни? (Парсер-то я написал уже, просто интересно)
Да и вообще, можешь рассказать о возможностях других HEX редакторов. И как допустим пользоваться теми же шаблонами. То я кроме hiew ничего и не видел.


Ранг: 103.3 (ветеран)
Статус: Участник

Создано: 19 ноября 2006 02:49 New!
Цитата · Личное сообщение · #10

1nn0cent
Шаблоны облегчают понимание структуры. Один из вариантов анализа, когда ты с каждым шагом понимания структуры файла - правишь шаблон (выстраиваешь порядок данных, связи и прочее). Сразу же ты наглядно видешь "белые пятна", видешь полученную инфу (по сути небольшой парсер на правилах) и уже можешь ориентироваться дальше. Ну и возможность повторного и дальнейшего использования шаблонов - это гут. Если заказчику нужен просто мануал по формату (пром. шпионаж, нах =), то сопроводив его шаблоном ты облегчешь жизнь и себе и ему.

Если хочешь подробнее ознакомиться с шаблонами - попробуй 010 Editor, тем более тебе язык будет близок (там си-подобный).

По поводу твоего "дерева". Шаблоны реально могли бы упростить задачу, особенно в 010 Editor'e, там как раз результаты парса показываются в достаточно удобном представлении. Но вообще сложно сказать.

Ранг: 115.1 (ветеран)
Статус: Участник

Создано: 22 ноября 2006 21:18 New!
Цитата · Личное сообщение · #11

есть еще симпатичная утилита Structorian для просмотра/анализа форматов


Ранг: 103.3 (ветеран)
Статус: Участник

Создано: 22 ноября 2006 23:40 New!
Цитата · Личное сообщение · #12

__
www.yole.ru/projects/structorian/
Не плохая вещь. Порадовал си-подобный язык с рядом ООЧЕНЬ симпатичных фенек. Но сама среда и функционал - мимо =( У того же WinHEX'a будет поудобнее в разы. Спасибо за наводку.
 eXeL@B —› Крэки, обсуждения —› Анализ форматов [ч1. Внешний осмотр]

Видеокурс ВЗЛОМ