Добрый день.

Я планирую написать небольшой дизассемблер + gui, с подключением плагинов через dll. Это велосипед, но всё таки хотелось бы иметь свой дизасм, который я смогу при желании править.

Составляя диздок, наткнулся на спорные моменты, которые вы возможно поможете мне решить.

1. основная проблема: как хранить исследуемую базу, учитывая что должны поддерживаться стат. браузинг и браузинг памяти (при отладке), с сохранением имён локаций и возможно др. метаданных.
у меня 2 варианта:
1а. на каждый байт свой дескриптор, (т.е. описывает код,данные,др) идеально для стат. браузера, но при браузинге памяти как-то cложно т.к. памяти может занять очень много
1б. на каждый регион памяти свой дескриптор, идеально для браузинга памяти, для стат. бр. но при больших регионах. При маленьких регионах опять сложность: (попробуйте например в ida создать мегабайт однотипных оч. маленьких структур)

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

решено

2. на чём писать? определённые наработки есть и на C и на Pascal, пытаюсь решить к чему-то одному это привести.
штука довольно узкопрофильная, тут думаю не так важно на чём. ядро планирую в виде dll (msvc или delphi/fpc), gui либо delphi/fpc, либо qt, кросплатформенность мне не нужна, поэтому тут пока остановился на delphi, т.к. gui контролы пишутся очень легко и быстро. если у кого есть опыт создания виджетов в qt, просветите насколько это проще/сложнее чем delphi.

решено.

| Сообщение посчитали полезным:

vden пишет:
т.к. памяти может занять очень много
Сколько для Вас много? Начинающим кодером тоже этого боялся, старался всё экономить - да не стОит себя ограничивать! Мой дизасм, например, после распознавания всех ф-ций ноутпада и укладывания данных в структуры весит в памяти всего 8 мб с небольшим. Для каждой инструкции своя структура, структуры укладываются в блоки, блоки в блоки функций, функции в мапе.

vden пишет:
на каждый байт свой дескриптор
Если Вы не помечтать сюда пришли, а имеете реальный план, то должны знать, что лучший стиль - данные и код хранить в разных структурах. То, что в иде видно - это всего лишь видно. Что происходит внутри, когда Вы нажимаете на C, D, или U?...

vden пишет:
на чём писать? определённые наработки есть и на C и на Pascal, пытаюсь решить к чему-то одному это привести.
Есть наработки на C - оставьте Паскаль! Замучаетесь на Паскале то и дело преобразовывать из DWORD в DWORD* в MOD_RM_SIB*, обратно и так далее...

-----
IZ.RU

| Сообщение посчитали полезным:

Это принципиально создавать свой движек дизасма, почему не заюзать существующие ?

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

DenCoder пишет:
Сколько для Вас много?
учитываем, что в базе храниться виртуальная память (т.е. секции так, как они будут замаппены [win или др.]-loader'ом). до 500 мб я считаю нормально.
Например если по дескриптору на байт, то файл с общим вирт. размером 100 мб x 4 байта/дескриптор = уже 400 мб, а если ещё сделать дамп модулей из памяти и сохр. его в базе, будет немало

Регионом я называю участок памяти от VA0 до VA1 который содержит однородные данные.

Если описывать "explored"-регионы структурами, то Size = VirtSize + (StrucCount * SizeOf(Struc)), тут уже размер в основном зависит от размера структур и их количества + размер вирт. памяти. Структура грубо говоря декларирует начало,конец региона, что содержит: код/дата. Лейблы локаций в расчёт не берутся, их удобнее хранить в хешированном списке.
Если регионы будут "длинными", то их будет не много, соотв. и размер небольшой. Но если много "коротких" регионов, размер будет увеличиваться значительно.
Вот в чём дилемма.

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

DenCoder пишет:
Что происходит внутри, когда Вы нажимаете на C, D, или U?
хм, иду не реверсил))

BoRoV пишет:
Это принципиально создавать свой движек дизасма, почему не заюзать существующие ?
дело в том, что я хочу сделать немного больше чем просто дизасм, например отслеживание потока кода/данных, особенно в нестандартных exe, учитывание перекрывающихся переменных, вывод данных при помощи отдельных back-end'ов, идей много. Возможно я упустил что-то уже такое opensource, буду рад ссылкам, не считая Olly

| Сообщение посчитали полезным:

vden почему всё скомпилено без рантайма ? И почему не дизасмит ?

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

без рантайма - просто такой выбор, +линкует моментально (это кстати в делфи плюс))

как такового дизасма сейчас нет, можно нажать D, выбрать code i386 (это дизасмит 1 инструкцию, никакого анализа сейчас нет, пока я не определюсь с оптимальным хранением данных)

UPD: сейчас это больше похоже на WinHex, но если сделать соответствующие datahandler'ы и загрузчики, то можно отображать практически что угодно: ресурсы, диалоги...

| Сообщение посчитали полезным:

vden
если уж делать, сразу скрипт систему продумай, чтобы доступ был к структурам дизасма

и чтобы имена давать можно было функциям/переменным/структурам итп, комменты

ИМХО: Посмотри как в ида сделано, в общем. иначе писать кроме как для своег экспиренса смысла нет.
все равно все на иде сидят

| Сообщение посчитали полезным:

vden пишет:
учитываем, что в базе храниться виртуальная память (т.е. секции так, как они будут замаппены [win или др.]-loader'ом). до 500 мб
vden пишет:
файл с общим вирт. размером 100 мб
Где Вы видели такие? Интересуют-то только секции кода и данных, инициализированных и неинициализированных. Зачем Вам по-крайней мере кучи, например? Если дизасм способен определить, где выделяется виртуальная память, где удаляется и сколько раз, то не значит, что надо обязательно всё то же самое проделывать. Хотя, воля Ваша...

BoRoV пишет:
Это принципиально создавать свой движек дизасма, почему не заюзать существующие ?
Писать на чьём-то движке - это:
только тратить время на разбор ошибок, подгон кода под свой стиль, добавление своих полей в структуры и отладка всевозможных несогласовок! Хотя, все в разной степени упёрты настойчивы, может и что-то выгорит. Только это исходник должен быть идеальный, а таких я не встречал...

И потом - на свои-то грабли приятнее наступать, чем на чужие

vden пишет:
никакого анализа сейчас нет, пока я не определюсь с оптимальным хранением данных
Определяйтесь. Всё на самом деле намного проще...

Дошло вроде. Вы хотите подгрузить все dll и их заодно проанализировать? У меня сделано так, имеется потенциальная возможность анализа подгруженных dll, но зачем всё в оперативке держать? Когда надо - базу dll можно подгрузить. Со 100 мб всё-таки перегнули, столько не будет Чаще всего размер всего образа с всеми образами подгруженных dll, даже если это 1C, (упс - она и правда жрёт до хрена ) не превысит 40 МБ. Исключение может быть в случае 1С (порядка 127 МБ в папке + наверное, 50 мб системных)...

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

Rustem пишет:
и чтобы имена давать можно было функциям/переменным/структурам итп, комменты
Легко можно также прикрутить, добавив мапу соответствия. Главное - функционал, это основа основ, интерфейс - уже для удобства пользователя, которое нафиг не надо, если нет основы.

-----
IZ.RU

| Сообщение посчитали полезным:

Rustem пишет:
если уж делать, сразу скрипт систему продумай
скрипты это хорошая идея

DenCoder пишет:
Где Вы видели такоие?
Согласен это редкость, но бывает. Ещё года 4 назад, игра "черепашки ниндзя" образ минимум 85 мб, после распаковки 5 мб, но вирт. память использовалась протектором, то ли для антидампа, сейчас не помню. Игры с solidshield если не ошибаюсь, тоже объёмные. А вообще размер взят как "большой", т.е. на практике действительно будет меньше

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

DenCoder пишет:
Всё на самом деле намного проще...
не хочу спорить. попробуйте следующее, откройте в ida небольшой файл размером около 100 кб как бинарный и сделайте его массивом структур во весь размер файла

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

естественно не держать всю базу в памяти. маппинг.


Freeware Ida меня практически во всём устраивает, но есть неудобства, которые в своём дизасме я бы мог избежать. Например у структуры можно сделать базовое смещение (при чём переменное в различных участках кода), так чтобы если есть обращение [eax-4], было ясно что это длина строки. Т.е. смысл максимум автоматизации реверсинга, где это возможно.

| Сообщение посчитали полезным:

DenCoder пишет:
Замучаетесь на Паскале то и дело преобразовывать из DWORD в DWORD* в MOD_RM_SIB*, обратно и так далее...
А в Си не надо что ли преобразовывать? Из всего, что видел только в php ниче не надо делать, там тебе еще и жопу вытрут.

ЗЫ А вообще вопрос ТС мне тоже интересен, правда больше в плане самомодификации кода. Дебажим файл, а он раскриптовывает код ниже, как быстро базу актуализировать и синхронизировать отображаемые данные.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным: _ruzmaz_

DenCoder пишет:
DWORD в DWORD* в MOD_RM_SIB*
кстати в паскале можно сделать record с инлайн функциями, который выдаст op/mod/rm/s/i/b (аналог битовой структуры C, или же в fpc есть битовые структуры, наверно больше вопрос лени и кодингскилла)

| Сообщение посчитали полезным:

Дизасм корявый.


А должно так.


ЗЫ. И скопировать нельзя.

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

PE_Kill пишет:
А в Си не надо что ли преобразовывать?
В Си это проще )))

vden пишет:
откройте в ida небольшой файл размером около 100 кб как бинарный и сделайте его массивом структур во весь размер файла
ну зачем такой изврат - не пойму... Добавлять новые переменные надо по мере обращения к ним. В сложных случаях проводить бэк-трейс реверс анализ. Значение регистра или переменной в каком-то блоке зависит от другого значения или переменной - находим по референсам блок, изменяющий это значение, инструкцию. Если в инструкции регистр или переменная зависит также от еще значений, также ищем блок, инструкцию... и т.д. рекурсивно. По мере нахождения строим дерево, вершины которого будут решениями и укладываются в список. При нахождении инструкций вроде lea ecx, [edx + ecx * 4], определяем диапазон ecx и ставим тип "таблица" или "массив". lea ecx, [edx + disp] - имеем дело либо со структурой, где база - edx, либо указателем на массив или строку в одной из структур массива объектов структуры. И т.д.

vden пишет:
количество чанков в функции становится большим, скорость доступа к базе резко снижается
Каким образом, если есть блоки инструкций и структуры инструкций связаны между собой указателями? Не заметил что-то...

BoRoV пишет:
А должно так.
декодирование ModRMSib не реализовано, пока, видимо или не вызывается... сами скобки-то готовы )))
05 сложно декодировать? ))

помогу немного

алгоритм декодирования ModR/M_SIB сверху вниз
UPD. То есть слева значения этого поля, справа маска, по которой проверяем. Проверка начинается сверху вниз, шаг за шагом. Первое, что TRUE - и есть правильный вариант декодирования.

vden пишет:
смысл максимум автоматизации реверсинга, где это возможно
И я за это.

-----
IZ.RU

| Сообщение посчитали полезным:

DenCoder пишет:
декодирование ModRMSib не реализовано, пока, видимо или не вызывается... сами скобки-то готовы )))
Не, это скорей всего неверно используется дизасм двиг. Как видно он быд настроен на х64 файлы.

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

BoRoV пишет:
Дизасм корявый

DenCoder пишет:
помогу немного

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

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

BoRoV пишет:
ЗЫ. И скопировать нельзя.
Контрол на который всё выводится - самописный, читает данные через API дизасма, копирования сейчас просто нет. Там если внимательно посмотреть можно ещё 100 багов найти.

| Сообщение посчитали полезным:

BoRoV пишет:
неверно используется дизасм двиг
Ах, так двиг не собственный? А я здесь распинаюсь...

-----
IZ.RU

| Сообщение посчитали полезным:

DenCoder пишет:
Ах, так двиг не собственный? А я здесь распинаюсь...
Двиг если и будет собственный (скорее всего будет нужен), то всё я думаю можно взять здесь http://ref.x86asm.net/
Я пока вижу смысл только в 2х двигах: intel x86/64 и ARM

| Сообщение посчитали полезным: DenCoder

vden пишет:
Я пока вижу смысл только в 2х двигах: intel x86/64 и ARM
Да ты хоть один до ума доведи, тогда другие будет намного проще довешивать.

ЗЫ. Т.Г.Ш. на иконке понравился

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

vden пишет:
Двиг если и будет собственный
Потом сложно будет dll, юзающую двиг подстраивать под свой. Такой эксперимент уже был... Дело Ваше!

За ссылку, кстати, спасибо! Может, пригодится...

UPD. Кстати, не запостил бы сюда и может, еще долго бы и не увидел, что алгоритм(таблицу) можно упростить



-----
IZ.RU

| Сообщение посчитали полезным:

vden пишет:
Возможно я упустил что-то уже такое opensource
Ну, неоднократно были попытки создать опенсорс аналог иды, всех я не знаю, но вот одна из них http://lida.sourceforge.net/

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

Только сейчас мысль дозрела добавить к дизасму блоки структур UNDEFINED_STRUCT, и карту для них для ускорения доступа. Только опять же на каждый байт излишне делать такие структуры! По мере распознавания функций(FUNC_MAP) и данных(VAR_MAP, STRING_MAP) блоки будут биться на части.

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



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



Ладно, все знают, что нет такой инструкции Пусть будет



Такой же тенденцией страдает и мой дизасм. Но я предлагаю добавить структуру ADJACENT_INSTRUCTION (смежная инструкция).

struct ADJACENT_INSTRUCTION
{
BYTE Disp; //смещение относительно оригинала (в пределах длины инструкции-оригинала)
INSTRUCTION* pCmd;
ADJACENT_INSTRUCTION* pNext;//очень редко может быть еще одна смежная, но всё же
};

struct INSTRUCTION_LIST
{
INSTRUCTION* pCmd;
INSTRUCTION_LIST* pPrev;
INSTRUCTION_LIST* pNext;
ADJACENT_INSTRUCTION* pAdjacent;//В обычных условиях просто NULL
};

..................

-----
IZ.RU

| Сообщение посчитали полезным:

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

Windows_2000_source_code\private\windbg64\debugger\em\ia64dis.cpp

Кстати там написано, что дизасм юзает интеловский дизасм из библиотеки disem.dll. Может пригодится.

| Сообщение посчитали полезным:

DenCoder пишет:
излишне делать такие структуры это меня и беспокоит

DenCoder в твоём примере прыжок в середину инструкции и обычный дельта-трюк для получения eip.

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

Usulgurt. Спасибо за участие. В исходниках винды действительно много интересного. Если говорить о дизасме, то сейчас по x32/x64 выбор есть Distorm, BeaEngine, Mediana, дизасм из Bochs, дизасм из VirtualBox. Голова кружиться, что брать и адаптировать или написать свой.

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

| Сообщение посчитали полезным:

Кстати, ещё вопрос как вы считаете макс. 65536 типов данных в одной базе будет достаточно или избыточно?

Anterior, Posterior lines реально нужны? Или достаточно коментов.

| Сообщение посчитали полезным:

vden пишет:
Спасибо за участие.

Кстати есть ещё такой крутой дизасм как beye там тоже открытые исходники для х32 и х64.

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

Если что выкладывай сюда xml описывающий данные для отображения в dizasme, народ чтонить добавит.

| Сообщение посчитали полезным:

vden пишет:
потому что дизасм сам не может "понять" что это бред а не код
В проведённых экспериментах, когда и нет явных прыжков, а используются непосредственные операнды размером 4 байта, выявлено, что для юзермода что пробовать дизасмить строку, что дизасмить данные - огромный процент около 90% что в числе 5 инструкций будет запрещенная для юзермода, и процент поменьше, около 10, что будет прыжок или кол за пределы кодовой секции или образа вообще. Для этого у меня предусмотрены пока 3 константы:



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

vden пишет:
Кстати, ещё вопрос как вы считаете макс. 65536 типов данных в одной базе будет достаточно или избыточно?
Не понимаю, о чём Вы. Вы знаете, что такое динамические структуры данных?

vden пишет:
Anterior, Posterior lines реально нужны? Или достаточно коментов.
Видели Ida 5.5 в режиме графа? Нужны они там?

-----
IZ.RU

| Сообщение посчитали полезным:

Usulgurt
Вот примеры инструкций для теста:
mediana/files/tests.bin

-----
EnJoy!

| Сообщение посчитали полезным:

Usulgurt пишет:
Вплоть до криптоинструкций
AES что ль? Написано всё.

-----
IZ.RU

| Сообщение посчитали полезным:

DenCoder пишет:
В Си это проще )))
Чем? Друдновыговариваемой директивой? Если руки не из жопы растут, то сложность 1 в 1, за исключением битовых полей.

-----
Yann Tiersen best and do not fuck

| Сообщение посчитали полезным:

PE_Kill пишет:
сложность 1 в 1
Хорошо, возможно по дельфи я даже не троечник Но как тогда будет на дельфи выглядеть аналог ниже?



-----
IZ.RU

| Сообщение посчитали полезным: