Для удобства захотел добавть в свой обработчик исключений (хотя пригодится и в других кейсах) бэктрейс стека, ну думаю вызову CaptureStackBackTrace и дело сделано, но не тут-то было. Оказывается эта "замечательная" функция просто не видит фреймы, если функция не имеет канонических прологов, эпилогов, итп, возвращая бесполезные крохи инфы.
Уточню - никаких заигрываний с исходниками нет, нужен просто сырой бэктрейс из любого приложения.
Отсюда вопрос номер 1,- есть ли готовые "правильные" решения, в идеале статические lib, на случай, если никто ничего интересного не предложит, фоллбэк такой:

буду делать снапшот всего стэка и постфактум разбираться.
Например читаем из тиба



В цикле по 4 байта (для х86) копируем в буфер (StackBase-ESP) байт начиная с ESP, потом по желанию можно пройтись по адресам и откоментить для вывода (далее чисто мои размышления и велосипеды),- нули игнорируем, помечаем EBP как текущий фрейм, все что в границах (Stack Limit<-->Stack Base) - адреса стека или параметры, остальные адреса проверяем с помощью GetModuleHandleEx > GetModuleFileName на возможную принадлежности к текущим модулям и добавляем коментарий, была даже идея подтянуть капстоун и проверять предыдущую инструкцию на call чтобы отмаркировать "вручную" фреймы.

В итоге, стоит ли делать так?
Или есть ли готовые lib (на худой конец dll), или грамотные исходники?
Что из моих "фантазий" годно?

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

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

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

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



Опция CS_OPT_DETAIL ничего не изменяет по размеру памяти. Первые два раза вызывается cs_malloc: 7.4kB, 12.5kB, это не при инициализации, а на декодере cs_disasm()!. Третий вызов не проходит, отваливается при вызове cs_vsnprintf(), я её не определил. Ставим переходник на _vsnprintf(). 6 раз вызывается " + 0x%llx" etc, это нужно как то отключить .

Затем вызывается realloc, её тоже нужно переопределять. Это не интерфейс, а дичайший изврат.

-----
vx

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

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

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Bronco

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

-----
vx

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

difexacaw пишет:
для тестов на профайл
я вчера до обеда обкатывал нопы вниз после яра, страницу почти в 30 метров, в буфер, это 7200 лямов инстр, буфер на диз, выхлоп через надстройку в список, с фильтрами, из списка на асм в буфер, на всё 25, с копейками сек.
хз мне гонять на профайл не нужно. и так убедительно.


-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Bronco

Взял ксед и капс. При дефолтных настройках, те без смены аллокатора результат - ксед быстрее в 42 раза. Чтобы исключить аллокатор использовал индексируемый массив. Из alloc индекс блока увеличивается, из realloc не изменяется. При этом printf остаётся. Результат - ксед быстрее в 25 раз. Таким образом штатный аллокатор вносит задержку в 1.7 раза.

-----
vx

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

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

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Bronco

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

-----
vx

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

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

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

difexacaw пишет: По последнему я ничего сказать не могу, потому что нет билда для теста.

пример использования можешь посмотреть на гхабе, в целом работает быстро, но тайминг с xed'm не сравнивал.

78ae_26.07.2018_EXELAB.rU.tgz - Zydis.7z

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

shellstorm

dumpbin:


Не сбилдится это.

-----
vx

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

difexacaw пишет:
Не сбилдится это.

difexacaw пишет:
А когда сборка начала являться проблемой ?


-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Потестил Зидис на предложенном в сырках сэмпле на .text секции х64 фотошопа - 16.5 секунд
Ведь афтор предлагает нам итерациями делать fread прямо по ходу дизасма
Для сравнения Distorm (в медленном текстовом режиме) - 9.5
Все компилил в х64 с оптимизацией (режим дизасма Decode64Bits|CS_MODE_64 соответственно)

distorm.lib - 89кб
Zydis.lib - 1024кб
(без оптимизации и приоритета скорости кода размеры будут меньше)

Предлагаю на этом же бинаре протестить остальных "кандидатов".
Спецом использовал штатные сэмплы (имхо показательно). Кто захочет реабилитировать зидис - вэлком

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

VOLKOFF, дишторм уже стратил, на нопах больше одного байта. -ди с теста вылетает.
зудис разбирает больше наборов команд, чем капстон. - капс с теста вылетает.
по факту два диза на сегодня актуальны - ксед(??? ) и зудис(- 16.5 секунд ).

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Bronco пишет:
и зудис(- 16.5 секунд ).
ну мой "тест" достаточно ироничный, ведь по "штатной" методике у зидиса (точнее сэмпла) большая часть времени уходит на fread
Если прочитать файл в буфер целиком и потом дизасмить, результат будет другой

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

VOLKOFF пишет:
Если прочитать файл в буфер целиком и потом дизасмить, результат будет другой
VOLKOFF пишет:
Кто захочет реабилитировать зидис - вэлком
попробуйте-ка ещё такой вариант:
https://github.com/athre0z/disas-bench/blob/master/bench/distorm/main.c
https://github.com/athre0z/disas-bench/blob/master/bench/zydis/main.c
https://github.com/athre0z/disas-bench/blob/master/bench/load_bin.inc

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

мне ж не за себя, мне за державу обидно

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

Кстати о xed, решил попробовать, но он у меня никак не хочет собираться. Гугл нашел в двух местах (втч гит x64dbg) единственную скомпилированную lib, решил использовать ее.
Взял из доков минимальный пример и столкнулся с такой проблемой - функции xed_decoded_inst_set_mode() в той библиотеке нет... остальное есть, а ее в экспорте нет.

Может кто поделится полнофункциональным вариантом libxed_x64.lib ?

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

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

-----
В облачке многоточия

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

Ate пишет:
Кстати о xed, решил попробовать, но он у меня никак не хочет собираться. Гугл нашел в двух местах (втч гит x64dbg) единственную скомпилированную lib, решил использовать ее.
Взял из доков минимальный пример и столкнулся с такой проблемой - функции xed_decoded_inst_set_mode() в той библиотеке нет... остальное есть, а ее в экспорте нет.

Может кто поделится полнофункциональным вариантом libxed_x64.lib ?

Последний xed можно взять здесь - --> Link <--, качаем Pin 3.7 (May 08, 2018) Kit-97619, заходим в папку extras\xed-intel64\lib или \extras\xed-ia32\lib и берём последний xed.lib, инклуды в соседней папке. Но вот xed_decoded_inst_set_mode там тоже нет

Из инклудов в файле xed-decoded-inst-api.h


-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

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

Boostyq пишет:
Xed вообще тяжело собирается (
поначалу ебала только с кодировками, питон упёртый, ну может это у меня так.
мбилд обязательно берём с сайта,странно он что не подгружается автоматом, один же автор, тыкаем его или к либам в питон, или в дистриб кседа. инстал, и всё нужное в ките лежит.
вот дальше качели, совместимость с и с+, куча не понятных движений.
mak, в пин, не шибко свежий, а либу один хер собирать...
Ate пишет:
единственную скомпилированную lib
угу... Диа красава, попилил ксед не хило, но либы в 2013 собирались, и там по ходу только енкоде.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

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

Хотел отхватить лойс на халяву, а получил
[EXIT_STATUS ] 399 [STDERR] где-то к середине процесса (при билде некоторых c# файлов)
Притом путь к компилю "/Microsoft Visual Studio 12.0/VC/bin/amd64/cl.exe", похоже это проделки VCForPython27, ибо я снес все студии кроме 2017-ой.

А на линуксе все мухой собралось...

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

VOLKOFF пишет: где-то к середине процесса

в переменные среды нужно добавить пути до windows kits / include или скопировать инклуды в папку инклудов xed'a, а так изи: https://dropmefiles.com/Rhb6i

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

shellstorm пишет:
а так изи

mak пишет:
Но вот xed_decoded_inst_set_mode там тоже нет
Ну как бы да, странные они. В первом же сэмпле доков ее сами юзают
В списке функций тоже присутствует, а в бинаре заинлайнили

Надо кодесы смотреть, мб там воркэраунд какой есть, типа инициализации xed_state_t и вызова xed_decoded_inst_zero_set_mode (не смотрел, просто размышляю! Сам сабж не юзал)

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

VOLKOFF пишет: В списке функций тоже присутствует, а в бинаре заинлайнили


это в pin'e, а в самостоятельной сборке XED_DLL_EXPORT

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

shellstorm пишет:
это в pin'e
это везде

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

VOLKOFF пишет: это везде

сорян, билдил не из репы и попалась древняя версия.
последняя https://dropmefiles.com/iVaap

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

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

Тест на том же коде (по ссылке выше):
16.172 - при полноценном выводе с адекватными настройками форматирования (короче стандартный рабочий кейс)
6.688 - DECODER_MODE_MINIMAL (из выхлопа выпиливаются операнды атрибуты и прочая необходимая инфа)

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

Немного статки:


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

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

VOLKOFF пишет:
однако с джанком зидис дружит (внезапно) сильно хуже остальных
Извините за оффтоп, а для каких целей вам нужен настолько стрессоустойчивый дизасм?

-----
В облачке многоточия

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

Bronco

> А когда сборка начала являться проблемой ?

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

Boostyq

> для каких целей вам нужен настолько стрессоустойчивый дизасм?

Тоесть по вашему нужно юзать кривые и падающие ?

Подробный вывод инфы про невалид инструкции лишь не нужная опция, либо декодировал, либо нет. Это отладочная инфа и она обычно не нужна.

VOLKOFF

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

-----
vx

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