Всем здравствуйте. Вобщем прошло с того момента как я задался вопросом: "как же написать дизассемблер?". Я много раз начинал с нуля, читал мануалы, читал чужие исходники. Но я так и не смог остановиться на архитектуре дизассемблера, которой бы удовлетворил бы мои запросы. Я бы хотел спросить, тех кто уже писал свой дизассемблер, о том на какой именно архитек- туре они остановились и почему? Требования которые я выдвинул к дизассемблеру таковы: 1. Легкость сопровождение исходного кода. - Код был настолько должен быть понятным, что внесение изменений в него не должно вызывать никаких трудностей, как для автора, так и для другого человека 2. Легкость изменения инструкций и формата комманд процессора - Так как может возникнуть потребность изменить с i386 на другой процессор, к примеру ARM или какой нить другой 3. Обязана быть выходная структура - Касательно процессора i386 в ней могут находиться, флаги распознанных префиксов, опкод, регистры, идмнемоники ( т.к. мнемоника может иметь множество хекс-значений и надо знать смысл этой команды), смещени, непосредственные данные Прошу отозваться авторов таких программных кодов и не устраивать баталии, что моя архтиектура лучше, а вот другого товарища хуже. Спасибо за внимание
Может быть - несколько регрессивный вопрос, но зачем писать свой дизассемблер? Если вспомнить IDA, то он писался несколько лет, прежде чем стал что-то реальное/полезное собой представлять. Есть желание повторить этот путь? Теперь собственно по сути вопроса. Самым "правильным" подходом к решению такой задачи, IMHO, было бы создание упрощенного эмулятора выбранного процессора. Такой эмулятор мог бы фактически "выполнять" инструкции дизассемблируемого куска бинарных данных, выкладывая результаты своей работы в некий буфер. Таким образом, для x86 семейства задача сводится к построению дерева разбора всего набора инструкций выбранного процессора. При наличии удобоваримого варианта описания дерева, новый процессор можно было бы подключить просто создав еще один файл правил для парсера. Команды парсера могли бы выглядеть следующим образом: проанализируй биты с 0 по n входного потока даных, полученное значение используй как индекс в таблице переходов на следующее правило и так далее. В листьях дерева должны будут находиться дизассемблированные инструкции.
v_mirgorodsky Меня бы полностью устроила IDA, но я не могу воткнуть ее в свои проекты, возникает куча проблем(нет исходного кода, а имею ли я юридически на это право? и др.) До сих пор я использую движок от Ms-Rem, все бы хорошо, но исходный код уж жутко не понятный! Для чего нужно? В ридми к своему детищу Ms-Rem все кратко и верно описал, думаю мне его не переплюнуть по пояснению на фига нужен движок дизасма и потому я и не буду пытаться это делать. У меня в моей домашней практике, возникают задачи: 1. Анализ исходного кода, про анализировать, как то или иное чудо творит винда(помогает WinDBG) 2. Замена одной машинной команды на ряд других(Здесь помогает cadt плюсь свои мысли) 3. Хранить лог результата выполнение того или иного куска кода(OllyDebug и скрипты) есть и другие задачи, но мне лень писать их, да и сформулировать тоже надо уметь по поводу, ваших мыслей, я вас не совсем правильно понял. Могли бы вы раскрыть свои мысли по подробней?
здесь смотрел: http://www.winasm.net/forum/index.php?showtopic=1287 http://www.winasm.net/index.php?ind=downloads&op=entry_view&iden=143 ?
EvilsInterrupt Есть статья: "Using Code Normalization for Fighting Self-Mutating Malware". Раздел "3 Normalization Techniques". Подраздел "Instructions meta-representation" ИМХО у настоящего и полезного дизасмлера должна быть именно такая структура. Но я такие видел тока в теории. Кстати у Cifuentes тоже были такие идеи, и еще, ИМХО тока на таком движке можно реализовать настоящую кросс-дизассемблерность. Вобщем я свое ИМХО высказал. Пока и удачи! ЗЫ: http://portal.acm.org/ много че полезного надыбал, уже два дня там зависаю насчет новейших идей в реверсинге
Я тоже писал свой. Только за отсутствием математических знаний, не строил какие то сложные модели, основывал все на банальных if else, и понял насколько не удобно вот так "в лоб" отслеживать состояния системы. Багов куча была - просто потому, что я не выработал четкой линии поведения своей модели в ответ на входные данные(То есть ту же информацию об Imm операнде я мог по разному обрабатывать, в зависимости от того, есть ли еще операнды, и прочее..., в разных местах кода информация сохранялась по своему). Сейчас я пришел к выводу, что необходимо рисовать диаграмки будущего софта, тогда получается заранее определять и то, как система будет себя вести в отдельных ситуациях, и то, чего я вообще - то говоря, хочу. Фактически, после проекта я понял как я делать больше никогда не буду)) А так, вообще - была выходная структура, которая просто заполнялась по мере анализа. Сначала определялся префикс, потом по таблице опкодов бралась возможная инфа об операндах, Mod\RM... Дальше, если был mod\rm анализировалось наличие sib и так далее.
вдобавок, глючный. Из того, что пробовал, подошел только PVDasm h**p://pvdasm.reverse-engineering.net Исходник на С, относительно прост, корректно работал с моими наборами файлов (в отличие от cadt).
вот некоторые ошибки декодирования. Это не все, а только то, что обнаружилось в первые, так сказать, часы знакомства Не помню из какой это версии cadt, возможно уже их пофиксили.
Я писал об этом на крэклабе. Ms-rem ответил в духе : "сам дурак". После этого я скачал свежий билд - ничего не изменилось. Больше не интересовался. На память, не декодировался ни один опкод связанный с регистром CRx.
gazlan Мне он тоже не понравился, нет выходной структуры, а мне надо анализировать код, а не текст получать(для этого есть IDA).
Гм. Сам не пользовался, но если не нужен исходный код, только результат, то есть еще DLL от Vanja Fuckar. Сайт не помню. Народ хвалит.
Я для своего проекта использую OllyDASM. Он может дизассемблировать и ассемблировать команды, сбоев за год использования пока не было, за исключением неправильной обработки 2х префиксов, но это легко фиксится.
Чего мне не нравится в движке Ms-Rem: На примере простой команды. 1. к примеру есть машинная команда, полученная после mov eax,ebx для 32-режима. 2. И есть команда после mov ax,bx для 32-режима Сейчас п.1 != п.2 Но, Если перед п.2 поставить переобределение размера размера операнда, а есть такой префикс, то становится факт п.1 = п.2 Движок недает уловить одинаковые команды, путем идентификации размера, да я не спорю что можно посмотреть на наличие префикса, но куда проще было бы иметь идентификатор чем смотреть, а есть ли префикс. Чем проще? : Код при применении идентификтора размера операнда становится компактней и меньше по размеру! зы: Хоть кажется это и мелочью, но при анализе кода в автоматическом режиме уж очень становится острым вопрос сведение равнозначных команд в какую либо систему, чтобы на оснавании системы признаков строить код. Спасибо за Внимание, может я в чем-то и не прав. Удачи вам и жду нравоучений
