Здрасте.

Необходим быстрый, очень быстрый дизассемблер x86. Должен уметь определить длину инструкции и размер адресуемой памяти(eg: inc dword [eax] -> 4байта).

Есть множество всяких разных, но обычно они весьма толстые, либо не поддерживают определение размера данных. Свой делать пока нет времени.

Нужен если не с этой фичей, то хотя бы дизасм длин. Тот который я юзаю не профайл.

-----
vx

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

Hacker Disassembler Engine Ы?

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

script_kidis

Забыл добавить что хотелось бы не просто ссылки на название, ибо их сотни, а уже опробованный вариант, так как каждый тестить не реал.

-----
vx

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

difexacaw на форуме есть тема по наиболее популярным с описаниями от тех, кто пробовал

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh

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

у меня только сорцы.
вот атач по описанию очень подхоже на то что вы ищите:
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

RLDE, который на фолтах?

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

Veliant

Это единственный способ затестить любой дизасм длин, так как делает это безошибочно на основе железячных фич. Но суть не в этом. У меня текущий прожект(DBI) это динамический трассировщик, тоесть это тулз, которая берёт под дебаг всё приложение, каждая инструкция трассируется, но этот способ трассировки промежуточный, это не эмуляция и не железячный трейс. Затыка по скорости образовалась с именно с дизасмом. Раньше это мне было не нужно, для иных задач юзались мощные моторы, типо BEA-disasm. Но в данном случае каждая инструкция важна, если дизасм использует депак таблиц для раскодировки(это не вынесено в инит) или использует циклы(итерации) - такое не годится, это сразу зарубает профайл.

script_kidis

Гляну спс.

-----
vx

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

Инструмент PIN Tool не пробовал? Позволяет трейсить с довольно большой скоростью

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

Veliant

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

-----
vx

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

http://www.capstone-engine.org/

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

лентяи, написал же есть тема: --> Link <--

-----
z+Dw7uLu5+jqLCDq7vLu8PvpIPHs7uMh

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

difexacaw пишет: Это единственный способ затестить любой дизасм длин, так как делает это безошибочно на основе железячных фич

XED из pin так тестировался. Capstone годный двиг в плане фиксов, хотя толстоват, 800кб для x64-86 онли, такой размер не всегда приемлем, например в драйвер уже не запихнуть, с модификациями будет работать, только слишком избыточно.

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

script_kidis

Затестил, этот мотор робит шустрее Virxasm(эталонный) в 12 раз, в данный момент дизасмит рандом буфер, фейла не обнаружено
Но он не может определять ничего, кроме длины и MRM.

UniSoft
Судя по коду это не годится, во первых классы всякие, а это принципиально не профайл ибо толстое, вот например:

Какие то хэши и синтаксис, наверно генерит мнемоники. Не годится.

Isaev

Там собрано всё подряд, тот же Bea.

Есть dizahex, компактный и с таблицами, но он поставляется в сишном виде и пока нет чем собрать что бы потестить.

Добавлено спустя 10 минут
neshta

Трассировка с использованием текущего дизасма даёт профайл в 12 раз медленее прямого исполнения, но virxasm это мутирующий мотор и не для сабжевой задачи предназначен(таблицы генерятся в динамике). Можно прикинуть какой профайл даст выше приведённый двигатель(будет использоваться так же кэш инструкций). Невозможно что бы какой то толстый тулз типо пина дал такую скорость

-----
vx

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

difexacaw пишет: Невозможно что бы какой то толстый тулз типо пина дал такую скорость

Да, это бесспорно, у иногда пользуюсь биндом pina, годится лишь для проверки какой то идеи, но итоговый тул пишется уже вне этой среды, ибо чрезмерно толст и завязан на плюсах, то есть из другого языка могу вызвать какие то функции, но на лету не смогу адаптировать, ибо все прибито к архитектуре тула, хотя, как трейсер очень даже не плох, если без разнице размер с прочими OOP.
Capstone редко используют в динамике, обычно используется в статике, здесь он хорош или в генерации шелкода из за ассемблера на его базе, ибо достаточно легок и прост в использовании, но для динамики негоден из за толстоты, классы можно выкинуть, но сильно легче не станет, было 800кб станет 700-650кб, такое по понятным причинам никуда не годится. HDE устарел, по крайне мере авторский вариант, не поддерживает современные камни с новыми инструкциями, те же AVX идут лесом, хотя они не особо часто и нужны.

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

neshta

Обработка не поддерживаемых диасмом инструкций не существенна, так например тот же virxasm не поддерживает simd. При этот запускается итерация хардверного трейса(TF). Такие операции не частые и не особо сказываются на профайле.
Помимо длины нужно определить размер адресуемого блока. Обычно моторы могут только длину и мрм, либо могут всё(Bea), но медленны. Размер блока необходим для обработки изменяющегося кода(апдейтить кэш инструкций при обнаружении записи в код) и поиска строк.

-----
vx

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

difexacaw пишет: Помимо длины нужно определить размер адресуемого блока

Зачастую это все, что требуется от движка. Тем более в большинстве случаев набор инструкций очень ограничен, а неизвестные инструкции можно откинуть, ибо размер можно высчитать относительно известных инструкций, адресация известных инструкций мы же знаем, стало быть не проблема рассчитать неизвестные. Подумаешь будет блок с неизвестными, если не стоит задача полной эмуляции, то зачастую на подобные инструкции забивают кол, а промежуточные данные берут из регистров ежели они конечно важны.
Сейчас сильно в моде проход анализатора и генерация кода под определенный случай, только это сложные и статичные системы.
Скиньте сурсы dizahex если нет никаких зависимостей, то соберу, огрызок компиля есть.

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

neshta

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

Двиг в аттаче, нет трафа на скачку компиля



c8ec_24.10.2016_EXELAB.rU.tgz - Dizahex.rar

-----
vx

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

difexacaw пишет: но всё равно такой вероятностный подход не гуд

В таком случае пилить свой дизасм, ибо не знаю публичного и достаточно вменяемого.
--> Link <--

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

neshta

Сэнк, потестирую его.

Может есчо что найдётся.

-----
vx

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

difexacaw пишет: Может есчо что найдётся.

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

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

neshta

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

7123_24.10.2016_EXELAB.rU.tgz - ICT.png

-----
vx

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

difexacaw пишет: Всё что мощное по функционалу медленно, а упёрлось всё именно в профайл

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

Добавлено спустя 10 минут
difexacaw пишет: По этой причине пришлось запилить модель кэша

Арифметическое сжатие пробовали? Подобные таблицы должны хорошо сжиматься.

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

neshta

dynamorio это шедевр, там масштабный ресерч нэйтива с коментами и запил костылей.

> Подобные таблицы должны хорошо сжиматься.

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

Потестил(линкуется с /nodefaultlib) dizahex, в результате в 30 раз быстрее чем virxasm, соответственно получше гораздо чем hde

-----
vx

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

difexacaw пишет: Не применимо, так как этот механизм и нужен что бы ускорить раскодировку

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

difexacaw пишет: гораздо чем hde

HDE был днищем даже на момент своего создания, скорость не очень и ко всему прочему устарел даже на момент своего создания.

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

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

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

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

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

neshta

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

VodoleY
Слияние кода это не задача дизасма длин, но всё же интересно было бы посмотреть.

-----
vx

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

difexacaw пишет: Для хуков лучше моего мотора(x86) не существует в природе

Если не секретная разработка, скиньте dll + static lib, попробую для скриптов адаптировать.
Есть Deviare, но неюзабельно для моих задач.

Попался на глаза еще один двиг fde64, даже из этого века, но fasm и x64.

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

neshta

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

-----
vx

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

difexacaw пишет:
VodoleY
Слияние кода это не задача дизасма длин, но всё же интересно было бы посмотреть.
ДА ЧТО ВЫ ГОВОРИТЕ??? каким образом тогда происходит внедрение кода в произвольное место проги? читайте мануалы.. гдето с 90 года начиная.. рекомендую журнальчик эллектронный.. Инфектед воис.. выходил когдато такой.
ЗЫ.. собственно дизасм длин нужен всего для 2ух вещей.. 1. для валидного инлайна кода (в случаее борова.. он там был около 300 байт вроде) 2. для эспрес анализа точек входа и прыжков.. (для подмены адреса) вобщем это чисто вирусная технология.. в старых вирусах.. только дизасм длин и оставляли, чтоб не тащить за собой полный дизасм

-----
Наша работа во тьме, Мы делаем, что умеем. Мы отдаем, что имеем, Наша работа во тьме....

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

VodoleY

Перетираемый код целиком куда то переносится, такое никогда не использовалось. Либо используются викс техники - морф и его разновидности. Собрал вам маленький семпл. Есчо вам будет это интересно, так как там происходит патч сотен рандомных функций. vx пасс.

Вот видос как оно происходит(немного из другой темы(защита от ROP), но именно патчит кодес нормальным способом).

Всегда при патче проходится дизасмом длин по началу кода для выделения границы инструкции и места необходимого для записи новой, стаб потом возвращает управление в исходный код. Это изначально не верный подход, если встретиться относительное ветвление(или RIP), то выполнить патч не получится.

> он там был около 300 байт вроде

Хотелось бы глянуть.

28c5_26.10.2016_EXELAB.rU.tgz - Gpp.rar

Добавлено спустя 18 минут
neshta

Посмотрел сурц fde64, там множество манипуляций 8-мибитовыми регистрами. Видемо автор не имеет представления про оптимизацию, использование 8/16 бит операций не профайл, особенно для x64.

Добавлено спустя 4 часа 30 минут
В 5 раз скорость меньше, по сравнению с прямым исполнением при использовании dizahex(без кэширования и с повторной раскодировкой MRM)

-----
vx

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