Сейчас на форуме: bartolomeo, -Sanchez-, morgot (+3 невидимых) |
eXeL@B —› Софт, инструменты —› Дизасм. |
. 1 . 2 . 3 . 4 . >> |
Посл.ответ | Сообщение |
|
Создано: 24 октября 2016 12:21 · Поправил: difexacaw · Личное сообщение · #1 Здрасте. Необходим быстрый, очень быстрый дизассемблер x86. Должен уметь определить длину инструкции и размер адресуемой памяти(eg: inc dword [eax] -> 4байта). Есть множество всяких разных, но обычно они весьма толстые, либо не поддерживают определение размера данных. Свой делать пока нет времени. Нужен если не с этой фичей, то хотя бы дизасм длин. Тот который я юзаю не профайл. ----- vx |
|
Создано: 24 октября 2016 12:26 · Личное сообщение · #2 |
|
Создано: 24 октября 2016 12:28 · Личное сообщение · #3 |
|
Создано: 24 октября 2016 12:49 · Личное сообщение · #4 |
|
Создано: 24 октября 2016 14:35 · Личное сообщение · #5 у меня только сорцы. вот атач по описанию очень подхоже на то что вы ищите: Hacker Disassembler Engine 32 v0.28 [2009.03.09] --- Небольшой дизассемблерный движок, предназначенный для анализа x86-32 кода. HDE определяет длину команды, префиксы, байты ModR/M и SIB, опкод, значения immediate, и др. HDE может пригодиться тебе, например, при написании распаковщиков, расшифровщиков, вирусов исполняемых файлов, когда простого дизассемблера длин недостаточно, а большой дизассемблер тащить тяжело. В дистрибутиве имеются скомпилированные объектные файлы разных форматов, заголовочные файлы и исходники на ассемблере. поддержка FPU, MMX, SSE, SSE2, SSE3, 3DNow! инструкций высокая скорость и маленький размер (~1500 байт) базонезависимый и не привязанный ни к какой ОС код совместимость с различными средами программирования b5e7_24.10.2016_EXELAB.rU.tgz - Hacker Disassembler Engine 0.28.rar | Сообщение посчитали полезным: ajax, difexacaw |
|
Создано: 24 октября 2016 15:21 · Личное сообщение · #6 |
|
Создано: 24 октября 2016 15:40 · Личное сообщение · #7 Veliant Это единственный способ затестить любой дизасм длин, так как делает это безошибочно на основе железячных фич. Но суть не в этом. У меня текущий прожект(DBI) это динамический трассировщик, тоесть это тулз, которая берёт под дебаг всё приложение, каждая инструкция трассируется, но этот способ трассировки промежуточный, это не эмуляция и не железячный трейс. Затыка по скорости образовалась с именно с дизасмом. Раньше это мне было не нужно, для иных задач юзались мощные моторы, типо BEA-disasm. Но в данном случае каждая инструкция важна, если дизасм использует депак таблиц для раскодировки(это не вынесено в инит) или использует циклы(итерации) - такое не годится, это сразу зарубает профайл. script_kidis Гляну спс. ----- vx |
|
Создано: 24 октября 2016 15:44 · Поправил: Veliant · Личное сообщение · #8 |
|
Создано: 24 октября 2016 15:47 · Поправил: difexacaw · Личное сообщение · #9 Veliant Не профайл и слишком толст, требует того, что называется развёртыванием приложения. Фактически задача и есть запилить более быстрый и мощный тулз. ----- vx | Сообщение посчитали полезным: neshta |
|
Создано: 24 октября 2016 16:47 · Личное сообщение · #10 |
|
Создано: 24 октября 2016 18:34 · Поправил: Isaev · Личное сообщение · #11 |
|
Создано: 24 октября 2016 18:43 · Личное сообщение · #12 difexacaw пишет: Это единственный способ затестить любой дизасм длин, так как делает это безошибочно на основе железячных фич XED из pin так тестировался. Capstone годный двиг в плане фиксов, хотя толстоват, 800кб для x64-86 онли, такой размер не всегда приемлем, например в драйвер уже не запихнуть, с модификациями будет работать, только слишком избыточно. |
|
Создано: 24 октября 2016 20:50 · Поправил: difexacaw · Личное сообщение · #13 script_kidis Затестил, этот мотор робит шустрее Virxasm(эталонный) в 12 раз, в данный момент дизасмит рандом буфер, фейла не обнаружено Но он не может определять ничего, кроме длины и MRM. UniSoft Судя по коду это не годится, во первых классы всякие, а это принципиально не профайл ибо толстое, вот например: Code:
Какие то хэши и синтаксис, наверно генерит мнемоники. Не годится. Isaev Там собрано всё подряд, тот же Bea. Есть dizahex, компактный и с таблицами, но он поставляется в сишном виде и пока нет чем собрать что бы потестить. Добавлено спустя 10 минут neshta Трассировка с использованием текущего дизасма даёт профайл в 12 раз медленее прямого исполнения, но virxasm это мутирующий мотор и не для сабжевой задачи предназначен(таблицы генерятся в динамике). Можно прикинуть какой профайл даст выше приведённый двигатель(будет использоваться так же кэш инструкций). Невозможно что бы какой то толстый тулз типо пина дал такую скорость ----- vx |
|
Создано: 24 октября 2016 21:28 · Личное сообщение · #14 difexacaw пишет: Невозможно что бы какой то толстый тулз типо пина дал такую скорость Да, это бесспорно, у иногда пользуюсь биндом pina, годится лишь для проверки какой то идеи, но итоговый тул пишется уже вне этой среды, ибо чрезмерно толст и завязан на плюсах, то есть из другого языка могу вызвать какие то функции, но на лету не смогу адаптировать, ибо все прибито к архитектуре тула, хотя, как трейсер очень даже не плох, если без разнице размер с прочими OOP. Capstone редко используют в динамике, обычно используется в статике, здесь он хорош или в генерации шелкода из за ассемблера на его базе, ибо достаточно легок и прост в использовании, но для динамики негоден из за толстоты, классы можно выкинуть, но сильно легче не станет, было 800кб станет 700-650кб, такое по понятным причинам никуда не годится. HDE устарел, по крайне мере авторский вариант, не поддерживает современные камни с новыми инструкциями, те же AVX идут лесом, хотя они не особо часто и нужны. |
|
Создано: 24 октября 2016 21:38 · Личное сообщение · #15 neshta Обработка не поддерживаемых диасмом инструкций не существенна, так например тот же virxasm не поддерживает simd. При этот запускается итерация хардверного трейса(TF). Такие операции не частые и не особо сказываются на профайле. Помимо длины нужно определить размер адресуемого блока. Обычно моторы могут только длину и мрм, либо могут всё(Bea), но медленны. Размер блока необходим для обработки изменяющегося кода(апдейтить кэш инструкций при обнаружении записи в код) и поиска строк. ----- vx |
|
Создано: 24 октября 2016 21:48 · Личное сообщение · #16 difexacaw пишет: Помимо длины нужно определить размер адресуемого блока Зачастую это все, что требуется от движка. Тем более в большинстве случаев набор инструкций очень ограничен, а неизвестные инструкции можно откинуть, ибо размер можно высчитать относительно известных инструкций, адресация известных инструкций мы же знаем, стало быть не проблема рассчитать неизвестные. Подумаешь будет блок с неизвестными, если не стоит задача полной эмуляции, то зачастую на подобные инструкции забивают кол, а промежуточные данные берут из регистров ежели они конечно важны. Сейчас сильно в моде проход анализатора и генерация кода под определенный случай, только это сложные и статичные системы. Скиньте сурсы dizahex если нет никаких зависимостей, то соберу, огрызок компиля есть. |
|
Создано: 24 октября 2016 21:58 · Личное сообщение · #17 neshta За неимением мотора для определения размера блока, реализовано следующим образом. Допускается наличие в инструкции MRM и соответственно адресации, формируется описатель для вычисления эффективного адреса. Далее выполняется проход по регистрам, вычисление из каждого адреса и валидация этого адреса. Из за частых промахов не профайл, поэтому реализована карта памяти двумя способами(хуки на аллокатор и мониторинг рабочего набора - это позволяет сделать нт) и проверка указателя быстра, но всё равно такой вероятностный подход не гуд. Двиг в аттаче, нет трафа на скачку компиля c8ec_24.10.2016_EXELAB.rU.tgz - Dizahex.rar ----- vx |
|
Создано: 24 октября 2016 22:15 · Личное сообщение · #18 difexacaw пишет: но всё равно такой вероятностный подход не гуд В таком случае пилить свой дизасм, ибо не знаю публичного и достаточно вменяемого. | Сообщение посчитали полезным: difexacaw |
|
Создано: 24 октября 2016 22:23 · Личное сообщение · #19 |
|
Создано: 24 октября 2016 22:25 · Личное сообщение · #20 |
|
Создано: 24 октября 2016 22:30 · Поправил: difexacaw · Личное сообщение · #21 neshta В этом и смысл темы. Всё что мощное по функционалу медленно, а упёрлось всё именно в профайл. По этой причине пришлось запилить модель кэша, но получилось в таком случае проблемка с памятью, этот механизм требует её очень много. На диаграмке показано. 7123_24.10.2016_EXELAB.rU.tgz - ICT.png ----- vx |
|
Создано: 24 октября 2016 22:39 · Личное сообщение · #22 difexacaw пишет: Всё что мощное по функционалу медленно, а упёрлось всё именно в профайл В свое время тоже искал двиг, но лучшее из публичого это xed и capstone, но для данное задачи непригодно от слова совсем, а остальное либо устарело на поколения камня или же вообще какой то мусор, правда dynamorio я не разбирал, хз, какой там двиг, ибо хватило взгляда на код, чтобы отпало желание копаться в недрах говнокода. Может что то и есть, хз, но не встречал, хотя искал долго, ибо много задач зависит от качества движка, pin меня не устраивает по некоторым критериям, в которые не входил скорость с размером, это ладно, но переписывать движок ради какой то задачи это уже на грани зла. Добавлено спустя 10 минут difexacaw пишет: По этой причине пришлось запилить модель кэша Арифметическое сжатие пробовали? Подобные таблицы должны хорошо сжиматься. |
|
Создано: 24 октября 2016 22:58 · Личное сообщение · #23 neshta dynamorio это шедевр, там масштабный ресерч нэйтива с коментами и запил костылей. > Подобные таблицы должны хорошо сжиматься. Не применимо, так как этот механизм и нужен что бы ускорить раскодировку. Там прямые ссылки только, индексация и битовые синхронизации, по другому никак не сделать. Потестил(линкуется с /nodefaultlib) dizahex, в результате в 30 раз быстрее чем virxasm, соответственно получше гораздо чем hde ----- vx |
|
Создано: 24 октября 2016 23:03 · Личное сообщение · #24 difexacaw пишет: Не применимо, так как этот механизм и нужен что бы ускорить раскодировку В каком то из камней подобная реализация, но сам камень увы не помню помню лишь что алго вполне публичный, хоть и защищен патентом. difexacaw пишет: гораздо чем hde HDE был днищем даже на момент своего создания, скорость не очень и ко всему прочему устарел даже на момент своего создания. Добавлено спустя 7 минут Остается допилить лучший вариант, то бишь самый быстрый и не прожорливый, добавить новые инструкции думаю не проблема. Вряд ли найдется готовый двиг, ибо повсеместно по проектам ходят древние ископаемые без какой либо модификации, сам сейчас ище библиотеку для хуков без порчи кодосекции, варианты есть, но там куча зависимостей и огрызком собрать совсем не вариант. |
|
Создано: 25 октября 2016 08:16 · Поправил: VodoleY · Личное сообщение · #25 |
|
Создано: 25 октября 2016 09:44 · Личное сообщение · #26 neshta Для хуков лучше моего мотора(x86) не существует в природе. Тонны всего мусора берут просто пару первых инструкций. В принципе для трассировки можно и не использовать вообще определение длины инструкций, что даст самый высокий профайл. Но на это запилен весь остальной функционал(маркеры кода/данных етц). Так что если делать только мотор для быстрого трейса, то должно быть достаточно раскодировки MRM(это маленькая процедурка). Если для определения длины есть более менее норм движки, то со второй задачей(определение размера данных) совсем напряг, ничего нет. VodoleY Слияние кода это не задача дизасма длин, но всё же интересно было бы посмотреть. ----- vx |
|
Создано: 26 октября 2016 04:13 · Личное сообщение · #27 |
|
Создано: 26 октября 2016 07:51 · Личное сообщение · #28 neshta Обычно с хуками на 64 проблемы из за релатив адресации. Но такая проблема возникает только если использовать тупо копирование нескольких инструкций и в таком варианте задача не разрешима. Код(процедура) это единое целое и только как целое она может изменяться. Для этого необходимо её пересобрать полностью - описать графом и сбилдеть в буфер. ----- vx |
|
Создано: 26 октября 2016 10:27 · Поправил: VodoleY · Личное сообщение · #29 difexacaw пишет: VodoleY Слияние кода это не задача дизасма длин, но всё же интересно было бы посмотреть. ДА ЧТО ВЫ ГОВОРИТЕ??? каким образом тогда происходит внедрение кода в произвольное место проги? читайте мануалы.. гдето с 90 года начиная.. рекомендую журнальчик эллектронный.. Инфектед воис.. выходил когдато такой. ЗЫ.. собственно дизасм длин нужен всего для 2ух вещей.. 1. для валидного инлайна кода (в случаее борова.. он там был около 300 байт вроде) 2. для эспрес анализа точек входа и прыжков.. (для подмены адреса) вобщем это чисто вирусная технология.. в старых вирусах.. только дизасм длин и оставляли, чтоб не тащить за собой полный дизасм ----- Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме.... |
|
Создано: 26 октября 2016 13:53 · Поправил: difexacaw · Личное сообщение · #30 VodoleY Перетираемый код целиком куда то переносится, Всегда при патче проходится дизасмом длин по началу кода для выделения границы инструкции и места необходимого для записи новой, стаб потом возвращает управление в исходный код. Это изначально не верный подход, если встретиться относительное ветвление(или RIP), то выполнить патч не получится. > он там был около 300 байт вроде Хотелось бы глянуть. 28c5_26.10.2016_EXELAB.rU.tgz - Gpp.rar Добавлено спустя 18 минут neshta Посмотрел сурц fde64, там множество манипуляций 8-мибитовыми регистрами. Видемо автор не имеет представления про оптимизацию, использование 8/16 бит операций не профайл, особенно для x64. Добавлено спустя 4 часа 30 минут В 5 раз скорость меньше, по сравнению с прямым исполнением при использовании dizahex(без кэширования и с повторной раскодировкой MRM) ----- vx |
. 1 . 2 . 3 . 4 . >> |
eXeL@B —› Софт, инструменты —› Дизасм. |
Эта тема закрыта. Ответы больше не принимаются. |