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

Не всё гладко обстоит с определением реализаций ВМ, на сегодняшний день примерно каждая третья реализация автоматом не определяется, приходится под неё модернизировать плагин, т.к. не могу сразу предусмотреть все случаи "издевательств" ВМ с кодом примитивов. Лучше дела с восстановлением "исходного" кода защищенных функций - 70% нормально восстанавливается, хотя во многом это зависит от самой структуры функции. Таким образом, если будет заинтересованность и помощь в нахождении подобных ситуаций, то проект может быть доведен до релизной стадии.

ЗЫ: Речь идет об Ореановских машинах. Нигде специально не упоминал.

9c41_03.03.2010_CRACKLAB.rU.tgz - VMSweeperLst.rar

-----
Everything is relative...

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

shellstorm пишет:
Остается мусор и избыточность, а у снежка довольно жесткие паттерны для asm конструкций и на таком коде выхлоп оставляет желать лучшего, он и на чистом коде не особо впечатляет. Проще переписать плагин: https://github.com/avast-tl/retdec-idaplugin под x64dbg, тем более кода там всего ничего, довольно качественный декомпилятор и от разработчиков отлик нормальный, можно озадачивать неправильной декомпиляцией или ошибками. Само ядро незачем тянуть в плагин, после постоянно догонять разработчиков, пусть у них голова болит со сборкой, для активного проекта клиент\сервер лучший вариант.
Вы видимо не использовали RetDec, он работает тока с 32битным кодом. Vamit указал в своем сообщении, что поддержка х64 кода необходима.

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

deniskore пишет: Вы видимо не использовали RetDec, он декомпилит тока 32битный код.

В roadmap x64 есть и думаю в скором времени появится, все равно ТС за один день не портирует проект, к тому времени уже может появится x64 версия, а так, рельсам на данный момент нет альтернативы для x64. Я не только использовал, а еще немного разобрался в исходном коде, в ближайшее время обещают генерацию *.dsm, *.ll, а это бесплатный оптимизатор.

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

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

Добавлено спустя 13 минут
Bronco, а такой момент, как апдейт существующих окон после изменения кода в SDK имеется? А так же вызов менюшных функций или по хоткею.

-----
Everything is relative...

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

Vamit пишет:
если тут он полный как для х32, так и для х64 то это большой плюс.
разрядность кажется только значима для инстр с указателями, в х32 нет ip и disp, поэтому поля в структуре х86, для операндов, при дизе заполняют по разному.
вывод в лог (если необходим), лучше свой, встроенный после 20000 строк, ничинает "плавать", после 100000, может положить.
Vamit пишет:
Да, их тут несколько
пока 3, хотя в фейсе 2, но все с "характером". на мой взгляд, лучший из трёх это XED
Vamit пишет:
или по хоткею.
угу...дескрипторы окон_вкладок(виджеты мать их) хз как достать, пока только так:

Vamit пишет:
как апдейт существующих окон после изменения кода
имеется. для каждой клиентской области.

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

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

Bronco пишет:
для кьютовского гуя нечего нет
А этого что мало? Создаешь свой виджет или по-русски любое окно и пихаешь как тав вкладку.
BRIDGE_IMPEXP void GuiAddQWidgetTab(void* qWidget);
BRIDGE_IMPEXP void GuiShowQWidgetTab(void* qWidget);
BRIDGE_IMPEXP void GuiCloseQWidgetTab(void* qWidget);
BRIDGE_IMPEXP void GuiExecuteOnGuiThread(GUICALLBACK cbGuiThread);
Так же есть функции прямого доступа ко всем встроенным в дебаггер табам.

-----
Everything is relative...

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

Vamit пишет:
А этого что мало?
но это если Ваш проект на кьюте, тогда возможно получить дескрипторы всех виджетов.
ВинАпи они не доступны.
Tyrus пишет:
Protect&Sweeper.pdf
как это,...как это.. ну в общем первый раз прочитал только сегодня. Феньк.

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

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

Сделал несколько тестов и пришел к выводу, что Свипер правильно девиртуализовать некоторые функции на восстановленном дампе не может. Причина разрушение тела вм после восстановления импорта, т.к. вместо пожранного протом импорта он в эту область может поместить свои данные, а дамп без восстановленного импорта неинформативен и без него невозможно определить многие АПИ функции.
Отсюда следует, что вариант 2 с декомпиляцией дампа в Ида отпадает и остается один вариант реализации нового Свипера под х32/64dbg.

-----
Everything is relative...

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

Vamit пишет: декомпиляцией дампа в Ида отпадает и остается один вариант реализации нового Свипера

Как вариант, может выкатить core свипера в dll (чтоб не рипали и не нарушали авторские права) и header к нему, а страждущие пусть биндят к python и пользуются хоть в ida\radare\ninja\etc.

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

shellstorm пишет:
может выкатить core свипера в dll
В принципе возможно сделать для Свипера SDK, но это долго и навряд ли будет эффективно, т.к. собственных асма/дизасма у него нет, а тянуть его из разных дебагеров не выход.

-----
Everything is relative...

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

Vamit пишет: В принципе возможно сделать для Свипера SDK, но это долго и навряд ли будет эффективно, т.к. собственных асма/дизасма у него нет

В python можно подключить практически любой популярный или сделать для него бинд, диз\asm это не проблема ядра, сделать необходимый интерфейс и пусть себе делают бриджи под необходимую структуру, интерфейс можно выдрать и из x64dbg.

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

shellstorm пишет:
а страждущие пусть биндят к python
упс...не уверен что страждущих это вообще коснётся, и не понятна роль питона, если для загрузчика_пакера нужны только хайды, и этот код идёт лесом, а для статик разбора остального (после оеп) нужен тупо рабочий дамп на одну сессию пк.
Vamit пишет:
а дамп без восстановленного импорта неинформативен
можно перенести табличку в другую область образа, для этого есть WannabeUIF, он опен сорс, пока заточен под х64,но сделать под обе архитектуры не проблема.

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

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

Bronco пишет: упс...не уверен что страждущих это вообще коснётся, и не понятна роль питона

У всех перечисленных инструментов есть скриптовый движок, через него проще подключить core чем компилировать плагины, тем более если структура core будет завязана на конкретный дизасм. Тем более самому автору ничего делать ненужно, выкатить SDK, а его уже любой может забиндить через swig.)

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

Bronco пишет:
можно перенести табличку в другую область образа
Я имел в виду не только IAT, но и сами вызовы АПИ из чистого кода сожранные вмпротом,
вместо call [xxxxx]; модуль:имя функи мы увидим мусор.

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

-----
Everything is relative...

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

shellstorm, если есть решение паблить, это одно, но такого решения нет, и как ни странно именно с этим я согласен полностью.
В частных диалогах ограничения нет, доки пишут, если заинтересуют таргетом, могут помочь декомпильнуть.
// я не злоупотреблял, но такие случаи знаю
Этого вполне достаточно, чтобы не было новых гонок по вертикали.
На проект угухали больше 12 лет, и он всё равно допиливается, то есть бетка.
Служебный код паблить надо, антидебаг паблить надо, это даёт вполне весомую возможность изучать остальное.

Добавлено спустя 3 минуты
Vamit пишет:
но и сами вызовы АПИ из чистого кода сожранные вмпротом,
ну так все переходники находят и указатели правят на новую область, для новой иат.
Если родное место иат прот юзает, его можно забекапить, а после переноса иат, восстановить.
я могу скинуть в личку свой плаг, в нём уиф под обе архитектуры, побалуетесь с таргетами. там только переходники, и сама табличка, остальное та же сцилка_импорт допишет.

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

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

Bronco пишет: shellstorm, если есть решение паблить, это одно, но такого решения нет, и как ни странно именно с этим я согласен полностью.
Vamit пишет: В принципе возможно сделать для Свипера SDK, но это долго и навряд ли будет эффективно, т.к. собственных асма/дизасма у него нет, а тянуть его из разных дебагеров не выход.

Никто и не говорит об открытие исходников, а речь о dll которую можно использовать в любом вменяемом инструменте. Тот же диз, банально import capstone и выхлоп передавать в бридж декомпилятора vmp, тем более нормальные инструменты позволяют использовать сторонний диз. Проблема плагина, что он прибит к одному инструменту.

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

Vamit пишет:
там может быть ещё не декомпилированный код другой функи

проверено?
или предположение?

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

r99 пишет: проверено?
Да и неоднократно, на любое сожранное место вмпрот может поместить что угодно (обработчики примитивов, обфусцированные куски других функций, кодированный вызов АПИ и т.д.), а так как у него любой функциональный блок тела порублен на мелкие куски (через jmp и call), то вместо любого сожранного кода может находиться несколько кусков тела прота разной функциональности. Пока я только не встречал (а может не помню), нахождение ленты пикода в сожранной области, она у него всё-таки в определенной степени линейна для функции.

-----
Everything is relative...

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

Прошу откликнуться в личку у кого есть вмпротект v3.1 или выше. Попрошу только завиртуализовать тестовый файлик.
Заранее спасибо.

-----
Everything is relative...

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

Последняя ScyllaHide (релиз от 02.12.2017) под x32dbg не справляется с антидебагом VmProtect 3.2
Имеются ли какие-либо решения против этого антидебага?

-----
Everything is relative...

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

Vamit, а что там нового из того, что не обсуждали?

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

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

Bronco
Не знаю, сам пакер вмпрота не смотрел, там всё под вм, с vmp3.1 ScyllaHide справляется, а vmp3.2 уже не берет

-----
Everything is relative...

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

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

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

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

Bronco пишет:
чтобы вызов сервиса был под обффускацией, то же пока не встречал
Уже реализовано под вм запихнул ZwQueryInformationProcess ZwSetInformationThread но не особо это ему помогло небольшие сложности создаёт

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

ClockMan пишет:
под вм запихнул ZwQueryInformationProcess ZwSetInformationThread

тут два выхода либо писать драйвер либо использовать уловку так как vmprot запихнул даже вызов KiFastSystemCall можно конечно разобрать вм либо искать в коде команду SYSENTER и надеятся из 100 найти 2 заветных вызова, а можно пойти на хитрость в windows можно отключить SYSENTER, да да вы не ослышались , идём в ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel и создаём новый параметр DWORD FastSystemCallDisable со значением 1 и пере-загружаемся для внесения изменений ,команда SYSENTER будет вызывать исключения, но есть одно но, vmprot не обрабатывает эти исключения и программа будет крашится, нам придётся помимо того чекать вызова сервиса так ещё и обработать правильно исключения и за паранои создателя vmprota
Также vmprot чекает список загруженных драйверов , если кто напишет драйвер на паблик то готовитесь что создатель vmprota внесёт его в чёрный список))

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

ClockMan

Мисье тоже знает толк в нэйтив извратах

Не знаю вашу задачу, но по описанию выше у вас там полная засада. Если вы откючите быстрые вызовы, то система перейдёт на прерывания(int 2e), никакие ловушки не будут срабатывать. Фолт возникнет если будет прямой вызов заблокированной инструкции, но это никогда не используется из за плавающих сервисных номеров. Шлюзы фиксированы в памяти и расположены рядом.

А даже если и есть быстрый вызов, то его можно мониторить - не зависимо от адреса входа(senter) адрес выхода(Kiexit) фиксирован, там можно пропатчить и все вызовы мониторить, в отличие от int, где возврат на следующую инструкцию.

-----
vx

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

difexacaw
ZwSetInformationThread надо ловить до исполнения и наче ахтунг......... а так я бы не парился поставил бы ловушку на KiFastSystemCallRet да и дело с концом)))

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

ClockMan

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

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

-----
vx

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

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

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

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

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

difexacaw пишет:
Шлюзы фиксированы в памяти и расположены рядом

Шлюзы == gates?

-----
Give me a HANDLE and I will move the Earth.

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

ClockMan

Ну как это можно назвать антиотладкой, да стыдно это видеть.

plutos

> Шлюзы == gates?

Переходники между модами. Это сервисный вызов.

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

-----
vx

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