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

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

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

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

-----
Everything is relative...

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

Bronco

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

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

Что бы получить результ по сабжу нужно снять статистику, это я сделаю в ближайшее время. Идея проста. Нужно получить стату по выборке данных и исполнению. Это поведение потока. Визор трекает выборки из памяти, соответственно вся память должна быть гранулирована и для соотвествующего в логе входа сохраняться событие выборки данных и исполнения и так же счётчики. Это позволит далее отобразить стату в виде графика. Этот функционал давно реализован https://yadi.sk/i/cAAE4aX236nRik
Но не откатан, пока я пилю само ядро мотора. Для быстрого получения результа я просто создам базу данных, в которую буду сохранять всю стату. Проблема будет только в анализе данной инфы - придётся запилить простой гуй для визуального отображения результа.

-----
vx

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

Вот что вызывает прот из АПИ на начальной стадии

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

-----
Everything is relative...

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

Vamit

Могу вам выложить подробный лог по нтапи, но нужно время на импорт логгера.

Вчера кстате вспомнил была забавная ситуация. Семпл первым делом детектит отладчик через винь апи IsDebuggerPresent(). Детект сей основан на проверке флага в PEB. Фишка в том что если его сбросить, то отладочный юзер лог переключится на ядерный и начнётся генерация CC. Конечно нет проблемы пропатчить кодес, но решилось интересно. Просто задана условная конструкция на выборку данных с этого адреса и соответствующее обнуление регистра-ридера. Но далее из не профайла был тупо поставлен евент на возврат из этой апи и фикс результа. забавно да

-----
vx

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

difexacaw пишет:
Да нет, вы не понимаете. Этот визор юзермод.
ну мне прямо полегчало..
ну а на самом деле, конечно интересно практическая сторона мотора.

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

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

Bronco пишет:
конечно интересно практическая сторона мотора

Гражданин навечно застрял в 32-битах, и отвлекает товарища Vamita от работы на 64-битным вмпротом своими
"моторами", работать с которыми может он один, "ввиду их невероятной сложности"

difexacaw пишет:
Если к примеру rdtsc можно забанить настройкой железа(мср), то cpuid так не получится трекнуть.

Давай ты мне тут не будешь рассказывать, а? Засылай любой "сэмпл", я тебе и cpuid, и rdtsc "трекну"

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

oldman

Семпл выше, найдите как детектит варю.

-----
vx

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

difexacaw пишет:
Семпл выше, найдите как детектит варю.

Оба "семпла" запущены под варей. Детектит варю оно элементарно - вызывает cpuid с eax=1, и смотрит в ответе,
включен ли бит 31 в ECX - "Hypervisor present" - бит я выключил. Далее идут вызовы cpuid с eax=0, в надежде
найти вендора "VmwareVmware", но там я заботливо оставил "fuck" Ну там еще с eax=7 вызовы идут,
не вникал зачем оно ему.

Rdtsc юзает активно, но толи криво реализован детект разницы таймеров между прямыми вызовами, и через
форсированый vmexit, толи не для этого вообще используется - вообщем через rdtsc вмпрот варю задетектить не
смог, в отличие от pafish-a, и ему подобных.

ЗЫ. полируем сверху Сциллой и "cэмплы" запускаются под варей и из под x32dbg

ЗЗЫ. На варе установлена win10 anniversary

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

oldman

Не правда, я заменял результ cpuid на тот, который на реал тачке, оно всё равно детектит. И никаких вызовов с 7 нет.

-----
vx

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

difexacaw пишет:
оно всё равно детектит.

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

15 раз выполняет cpuid с eax=0, 24 раз с eax=1, и 11 с eax=7 - это который usermode.exe

С ....kernelmode.exe, тот в сумме 56 раз вызвал.

Добавлено спустя -57 минут
difexacaw пишет:
И никаких вызовов с 7 нет.

Просто мой "мотор" всё палит, и .dll которые процесс подгрузил - тоже

Это, судя по rip - bcryptprimitives.dll вызывает с eax=7

ЗЫ.

cpuid rip = 0000000000895AD6 eax = 0000000000000001
cpuid rip = 000000000068A61E eax = 0000000000000001
cpuid rip = 000000000069BE6E eax = 0000000000000001
cpuid rip = 000000000069BE6E eax = 0000000000000001
cpuid rip = 000000000069BE6E eax = 0000000000000001
cpuid rip = 000000000069BE6E eax = 0000000000000001
cpuid rip = 000000000046F50C eax = 0000000000000000
cpuid rip = 000000000046F51F eax = 0000000000000001
cpuid rip = 0000000000524B67 eax = 0000000000000001

Последние 3 - динамические, при запуске ехе там пусто, но потом :





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

oldman

Может оно от версии оси зависит. У меня нет столько вызовов.

-----
vx

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

difexacaw, вот честно, сделай отдельную тему со своим "мотором", везде им все засрал, я понимаю, что ты тут всех переплюнешь, но пользы в теме "Декомпилятор ВМ" точно никакой, просто нулевая.
Vamit пишет:
Я уже устал говорить, что прот не детектит дебагер со Сциллой. Если код проги не поломан, то все эти rdtsc, cupid пошли нафиг, на них организована проверка целостности кода и антидампинг.

API же Vamit и сам выдернул все.
Ps Я тоже сейчас особо не несу никакой пользы, но хоть не спамлю, а молча сел ковыряться сам, у difexacaw же совсем другие интересы : рассказать какой клевый "мотор" и как все легко, а вы все устарели, тошнит уже, в каждой теме одно и тоже.

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

v00doo

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

Добавлено спустя -22 минут
--> Link <--

В архиве два дампа, секция с семпла и статистика(ужалось в 400k ). Снята для длительного цикла от аллокации памяти до DEADC0DE. Содержит для каждой инструкции счётчик исполнений и счётчик выборок данных из памяти(для каждого адреса). Осталось только как то вывести это на экран, гуй пильнуть.

Добавлено спустя -8 минут
Забыл сказать, можно взять инструкции с макс значением счётчика и выделить так основной цикл в коде и далее можно выделить сам код через граф. То что в 19.#12

-----
vx

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

oldman пишет:
запущены под варей

вари ведь тоже разные бывают-пропатченные или нет.
так что сравнивать реакцию на cpuid и только - не совсем корректно.

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

difexacaw
Ты думашь что эти 60Мб сырого кода будет кто-то смотреть? У меня после Свипера почти 100Мб получается, ну и что, нужен не полуфабрикат, а конечный результат - исходный код стартап секции прота.

-----
Everything is relative...

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

r99 пишет:
вари ведь тоже разные

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

Если прямо так интересно, могу с нуля вообще без твиков виртуалку слепить.

---
ЗЫ. Во время запуска происходит ещё такой вызов апи:



Это оно походу Sandboxie так детектит

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

oldman пишет:
Это оно походу Sandboxie так детектит

да, причем детект песочниц объединен в одной опции вместе с детектом виртуалок, что, прямо скажем, рукажопство.

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

Gideon Vi, возможно это для хомяков, для которых что песочница, что ВМ одно и тоже.

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

oldman пишет:
Гражданин навечно застрял в 32-битах
архитектура не принципиальна для обкатки, а без материала это всё теория.
сам по себе метод интересный.
oldman пишет:
и отвлекает товарища Vamita от работы на 64-битным вмпротом
не в упрёк Vamit, но как я понял, мотивация зависима от интереса к приложению, сам прот чисто как препятствие.
будет апп под х64, возможно будет и декомпиль.

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

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

Вот что юзается при запуске(без подмены результа cupid):



Добавлено спустя -39 минут
Vamit

> У меня после Свипера почти 100Мб получается

Так ведь нужен общий метод что бы как то ориентироваться в таких огромных логах. Вот к примеру овер 1G инструкций, с чего начать подходить к этому. Учитывая что я даже не знаю что есть свипер".

-----
vx

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

difexacaw пишет:
Учитывая что я даже не знаю что есть свипер".

имхо гражданин упорот, ибо так тролить.. ну нельзя просто

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

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

oldman

Я не смотрел, так как мне не понравился пункт:

- точки входа в ВМ находятся вручную

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

-----
vx

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

difexacaw пишет:
Вот что юзается при запуске(без подмены результа cupid):
по результу прикольно, только гипервизор больше сигнатур детектит
difexacaw пишет:
- точки входа в ВМ находятся вручную
да это некорректность вышла, входы в вм автоматом детектят, просто де_компиляция методов на выбор, и действительно вручную надо указать или бряк тыкнуть.

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

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

Bronco

> по результу прикольно, только гипервизор больше сигнатур детектит

Возможно далее если скорректировать результ cpuid. Я это есчо не сделал. В данном случае больше cpuid нет.

-----
vx

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

difexacaw пишет:
точки входа в ВМ находятся вручную
они вообще-то легко сигнатурно детектятся.

-----
IZ.RU

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

Vamit

> У меня после Свипера почти 100Мб получается

Я тут подсчитал число повторений, не уверен что я ровно дамп сохранил, но пока получается следующее. При числе исполненных инструкций 780М, с учётом повторений число инструкций 5K.

Проверил, всё верно. 1.266G общее число инструкций., 1.05G это без учёта ветвлений. Всего инструкций без повторений ~11.6K

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

По данным стата(это делают те 11k инструкций):
Выборок из памяти(R/W) - 230.7M
Без повторений - 4М, но без учёта размера выбираемых данных.

Добавлено спустя 1 час 32 минуты
Пильнул парсер, что бы выделить адреса из дампа. Вот результ в аттаче.

В логе список адресов инструкций, которые выполняют сабжевый гигабайтный цикл. Это 8K кода, остальной(из 11к, удалил из лога) - вызов апи видимо в конце работы цикла.

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

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

5625_17.02.2017_EXELAB.rU.tgz - vmdparse.rar

-----
vx

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

Интересно было посмотреть что за код, захватил конструктором часть из дампа. Может кому интересно --> Link <--

-----
vx

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

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

-----
Everything is relative...

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

Vamit

От вас для меня тоже в данной теме вообще ничего годного

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

-----
vx

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

Всё что описано ниже относится к VmProtect v3
Нормальной декомпиляции функций ядра протектора мешают модифицированные пакетные вызовы виртуализованных функций.

Схема обычного пакетного вызова в основном идентична ранним версиям протектора:
Вызывающая функция (виртализованный код)

Реальная вызываемая функция

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

Схема модифицированного пакетного вызова:
Вызывающая функция (виртализованный код)

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

А вот как девиртуализовать модифицированную пакетную функцию отдельно от вызывающей для меня пока загадка. Конечно есть одна мысль, сохранять состояние декомпилятора на точке 1 пакетного вызова, затем выходим из режима декомпиляции, загружаем в декомпилятор сохраненное состояние, чистим его на предмет данных, не относящихся к пакетной функции и стартуем декомпиляцию с точки 1, но тут большая трудоемкость реализации сохранений/восстановлений состояний декомпилятора. Намного проще другой путь - на точке 1 пакетного вызова производим выбор, что же декомпилить дальше, продолжать декомпиляцию вызывающей функции, оформив пакетный вызов как call xxx или декомпилить только пакетную функцию, предварительно почистив в декомпиляторе все данные не относящиеся к ней. Но эта реализация тоже не проста, как кажется...

-----
Everything is relative...

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

Что значит "пакетный вызов" ?
это передача управления на другой метод под виртой, с восстановлением контекста цпу, или другое?
адрес возрата уникален или меняется?
вопросов много, оссобено по терминам. требую новый словарь.

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

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