Здрасте.

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

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

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

-----
vx

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

difexacaw
Помнится, что у меня тоже когда-то была задача внедрения своего кода в код приложения. Самое простое решение - это создать новую секцию, копировать туда код нужных функций с вставленным своим, а в нужной функции вставлять джамп на модифицированную. Всё бы ничего, но двиг делал, забыв сначала про фиксапы, что их тоже надо по мере необходимости добавлять в таблицу релоков, а местами и изменять, если функция начинается сразу с подобной mov eax, [address]. Обнаружил эту необходимость позже для dll, и переделывал. Интересно - Вы это учли? )

Добавлено спустя 6 минут
Просто в Вашем алго этого не нашёл )

-----
IZ.RU

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

DenCoder

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

Добавлено спустя 27 минут
Потестил дизасм длин хьюва(Dila), кривая поделка.

-----
vx

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

difexacaw
http://z0mbie.daemonlab.org/
посмотри там
XDE v1.02 -- extended length disassembler
LDE-32 v1.04 -- Length-Disassembler Engine, ~29k
а вообще я повторюсь.. надо вирусные топики рыть.

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

VodoleYka

Зомби двиг очень давно тестился он кривой.

Интересно посмотреть описанный двиг Borov'a, но не получилось его найти, никто про него не знает.

-----
vx

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

а msrem`а двиг пробовали?

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

Medsft

Скорее всего да, но это очень древнее и оно всё бажное.

-----
vx

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

Mediana? https://sourceforge.net/projects/mediana/

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

Archer

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

-----
vx

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

Я бы мог поделиться своим двигом - он изначально делался с выборкой опкодов для декодирования по известному красно-чёному дереву, метод value_compare класса map перегружен:


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

-----
IZ.RU

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

DenCoder

В общем от дизасма нужно следующее(размер данных никакой не даёт, только тяжёлые типо Bea). Он должен определить длину инструкции(и число префиксов желательно, что бы повторный раз их не считать) и наличие адресации - MRM/SIB.

Я потестил dizahex, там тоже не всё ровно, во первых не раскодируется simd. Так же не возвращается число префиксов и не ясно по лимитам на длину инструкции - если она овер 15 байт, то дизасм возвращает абы что. Посему это нужно пофиксить. Так как нужно самому раскодировать MRM/SIB, что бы привести адресацию к линейной(проиндексировать pushad фрейм), то какие то манипуляции дизасмом с ней излишне, нужно только наличие MRM и смещение на неё, а есчо точнее, так как смещение всегда постоянно для 3-х таблиц опкодов, то нужен только факт наличия мрм. В других приложениях наличие мрм определялось по факту выборки данных(ловушка), но тут статик декодирование и посему нужно юзать таблицы опкодов. В принципе можно их просто описать тремя маленькими битмапами, это будет эффективнее всего, но нужно определять длину инструкции всё равно.

-----
vx

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

Ну у меня как-то так

difexacaw пишет:
и наличие адресации - MRM/SIB



с неограниченным детектом префиксов

-----
IZ.RU

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

DenCoder

Опишите плз подробно как там нужный функционал обрабатывается, длина и MRM.

-----
vx

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

intel xed
__https://software.intel.com/protected-download/267266/560870

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

redlord

Посмотрю спс(рипнуть из пина ?).

Пока получилось в таком виде.

4f5a_27.10.2016_EXELAB.rU.tgz - Dasm.rar

-----
vx

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

А вот интересно, с чем связана необходимость такой уж скорости работы, что приходится всякие урезанные примочки использовать?
Или размер? - тоже сомнительно. Полная реализация табличного дизассемблера 16/32 (DOS COM), по опыту, имеет размер 15 килобайт.
Собирался когда-то сделать базонезависимую 32-бит его версию, да так и собираюсь до сих пор.
Алгоритм такого дизасма неплохо реализован в QVIEW.

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

dosprog

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

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

-----
vx

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

difexacaw нахрена трассировка.. это ж вообще ад! я вам в очередной раз рекомендую просмотреть тему про вирусню.. там вариаций было немеренно + оптимизированных..
допустим.. чтоб повысить скокрость.. и сократить обьем кода.. народ искал сигнатуры определенных инструкций.. типа call jmp far .. и туда вливался.. полный дизасм длин, так же не так уж много занимает.. (это из серии.. ради одного колоска заводить целый комбаин) посмотрите код старых вирусов.. они в сорцах типа onehalf там достаточно все по феншую делалось. посмотрите как вирус по коду раскидывал куски метаполиморфного кода, в те времена, люди еще заботились о качестве кода
ЗЫ
если у вас задача вливаться в рандомное место кода.. то прийдется строить карту процедур из сегмента кода.. а это уже достаточно сложный анализатор.. ито.. он идеальный не получится

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

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

VodoleY

> я вам в очередной раз рекомендую просмотреть тему про вирусню..

Наверно вы не понимаете кому это советуете

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

-----
vx

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

difexacaw задавайте правильные вопросы.. получайте правильные ответы. трассировка необходима ток в одном случае.. если вы хотите разрезельвить прыжки типа call eax.. и опять же... тут решения 2.. либо статическая либо динамическая эмуляция кода.. но подозреваю что вам так глубоко не интересно
ЗЫ я не буду уже углблятся.. в то что уже описано Крисом.. что это можно спец командами проца ловить.. но это уже привязка к железу и архитектуре. Есть метода таких себе хардварных бряков, на уровне проца

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

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

VodoleY

Какие хардверные остановы, я говорю про взятие под быструю отладку всего приложения или его части(процедуры или модуля). К примеру поиск в приложении ссылки на строку или отлов cupid, захват графом части кода етц - это задачи автоматики, dbi. Эмуляция не может дать профайл, только прямое исполнение. Те же к примеру точки останова в таком случае сводятся к установке маркера в кэш инструкций и нотифи при выборке из кэша.
Это активно юзается для множества задач, смотрите пример --> Link <--

-----
vx

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

difexacaw пишет: Для этого необходимо её пересобрать полностью - описать графом и сбилдеть в буфер.

Как это работает я знаю.
Из скриптов что то стандартное собрать на c\c++ не проблема, собрать asm код\граф тоже не проблема, но проблема собрать драйвер с необходимым функционалом. Долго объснять, в данном случае речь о физической памяти, в общем забейте.

Ps. По поводу дизасма, то самый быстрый вариант это таблицы, быстрее в принципе ничего нет, а если скорости мало, то можно распараллелить в GPU. Выше писали о дизасме на фолтах, сгенерте с помощью него валидные таблицы или возьмете готовые (в сете полно и даже от intel есть), вряд ли вам нужно запихивать двиг в чужое приложение, следовательно плевать сколько памяти сожрут таблицы, в целом задача не отличима от подсчета хешей, табличные варианты быстрее, запилить функцию декодер, там кода на строчек 50-100, ибо готовое либо плюет на скорость или же убого в своей реализации и точности.

Добавлено спустя 2 минуты
VodoleY пишет: задавайте правильные вопросы.. получайте правильные ответы. трассировка необходима ток в одном случае

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

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

neshta

> проблема собрать драйвер с необходимым функционалом.

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

> Выше писали о дизасме на фолтах, сгенерте с помощью него валидные таблицы или возьмете готовые

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

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

-----
vx

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

difexacaw пишет: Это тормозной метод(для данной задачи, для статик годится), но он необходим для оценки любого прочего мотора, иначе как тестить ?

Я знаю, как это работает, так тестировали еще на древних камнях, то бишь до intel.
Но иначе не собрать валидные таблицы, двиг то используется в своем движке, пох на эти несчастные крохи памяти, важна ведь скорость выполнения, одновременно не бывает хорошо.
Взять например расчет хеша, алго точно так же делятся на память и скорость, одно дело, когда нужно влезть в узкие рамки памяти и совсем другое когда нужно получить скорость чуть ниже аппаратного выполнения.
difexacaw пишет: Мотор выше не привязан к моду

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

Ps. Здесь проскакивала mediana, неюзабельная, медленная хрень, довелось тестировать. Ко всему прочему автор отказался от поддержки, дескать посоны сурсы есть, разбирайтесь сами. udis86 тоже советовали, избыточен и довольно медленный, вариант llvm и тот лучше, хотя толст.

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

difexacaw пишет:
Какие хардверные остановы, я говорю про взятие под быструю отладку всего приложения или его части
это вы наверно не правильно меня поняли.. У Криса есть статья, взлом через покрытие кода. Там как раз рассматривались внутренние хардварные бряки, которые есть у некоторых интелов. можно ставить хардварные бряки на инструкции, которые ломают линейность кода. (call jmp ret jxx). Это самый быстрый способ построения графа кода. Бряки на прерываниях int 3 int 1 жутко тормазные.
PS я вобщем просто хотел упомянуть, что есть такая метода. Но там нужен драйвер. Эти инструкции есть не во всех процах, поэтому эта метода не прижилась. НО быстрее врядли можно будет чтото соорудить. (я про скорость работы) по факту, это наномиты на хардварном уровне

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

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

VodoleY

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

> быстрее врядли можно будет чтото соорудить.

Прямое исполнение в буфере даёт профайл. Для элементарных операций эффективнее эмуляция, но в целом только это(прямое исполнение) единственно годный способ, учитывая всё.

Добавлено спустя 17 минут
Приведу вам профайл юзаемого ранее трассировщика(динамическая эмуляция, DYE):

За единицу принят тайминг прямого исполнения кода.

Хардверная(TF) трассировка через VEH: замедление в ~140 раз.
Хардверная трассировка без возврата в ядро(без перезагрузки контекста NtContinue): 80.
Динамическа эмуляция(с крайне тормозным ядром): 10.
Под отладочным портом замедление невероятно, это сотни тысяч раз.

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

Добавлено спустя 13 часов 2 минуты
Потестил xed, он медленее в ~9 раз dizahex'a.

Добавлено спустя 13 часов 19 минут
Семпл.

f947_30.10.2016_EXELAB.rU.tgz - xed.rar

-----
vx

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

difexacaw
в чем конкретная кривизна ?

и нет, никакого отношения дила к хиеву не имеет, от слова совсем

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

sen

Не проходил тесты на рандом буфере.
Может это не с хьюва дизасм, но на его сайте.
Пока лучше dizahex'a ничего не нашлось.

Добавлено спустя 4 минуты
Есть при тестах один нюанс, инструкция может быть не корректна, такое событие нужно вручную отфильтровать при тестах, но есть иной путь. Можно сгенерить десятки тысяч инструкций автоматикой(системный код) и натравить на них тестируемый мотор.

-----
vx

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

difexacaw
просто пальцем покажи что не так - я исправлю.

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

Та он ужэ забыл


difexacaw пишет:
Тогда во первых соберите это норм компилем, ну что бы не было пустых пространств и прочего треша.

) Слышишь, чудик, хорош уже глупости городить. Ты где там "пустые пространства" увидел, а?
)) Какой нахер "нормальный конпиль" - ты чо вообще
) Оно бы и хер бы с твоими глупостями, если б ты при этом на других людей языком лязгать не пытался.

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

sen

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

-----
vx

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