Вопрос по написанию виртуальной машины

Привет.

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

Я уже понял что для обработки "особых" ситуаций по типу исключений нужно будет хукать обработчики начинающиеся на KiUser...

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

 

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

Антидамп тема интересная, но понятие так же не четкое. Защита от чтения каких данных ?

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

 

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

 

shanya0xff

Не понятно ничего. Это эмуляция нэйтива, интерпретация виртуализированного нэйтив кода или интерпретатор своего" вирт кода(своя архитектура вирты не связанная с другими) ?
По понятиям мне тоже не ясно

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

Для нэйтив данных защиту можно построить двумя способами. Первый сложное, необходим датафлоу и его проверка

Предельный(полный) случай обеспечивает полная эмуляция нэйтивного кода. На примере работает это так. Пусть имеется код:
mov r, [v] ; Читает память.
cmp r, n
je L

Строим датафлоу(это называется taint propagation):
mem.v -> cpu.r -> cpu.flags -> cpu.ip или кратко cpu.ip = f(mem.v)

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

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

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

Это если кратко по защите.

 

Ahimov


Остановимся на том, что мне пока что не нужен антидамп, ни кода, ни данных, ни крипт-исполнение частями, только лишь обход ACG.

Из предложенных тобою определений больше подходит «эмуляция нэйтива».
Перед основным циклом эмуляции модуль настроен, релоцирован etc, но глобально никак не изменен. Будь то код, или данные, они остаются нетронутыми.
На вход вирте подается лишь IP, лента нэйтив кода которая и должна эмулироваться, при этом кодсекция модуля находится в неисполняемой памяти.

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

 

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

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

 

А можно небольшой пример кода, как это делать?
Не обязательно на ассемблере, можно на всратом си.

 

Я, к сожалению, сходу не знаю годного примера для x86/x64, который можно в открытом виде посмотреть на гитхабах. Но, например, для некашерных и нескрепных дотнетов есть пример KoiVM: https://github.com/Loksie/KoiVM-Virtualization/tree/master/KoiVM.Runtime - если мне не изменяет память и я ничего не путаю, они CIL-опкоды (которые предназначены для стековой ВМ CLR) конвертируют в свой собственной формат для исполнения на регистровой ВМ. Типа: "эй, пёс, я слышал, что ты любишь виртуальные машины, поэтому я сделал виртуальную машину внутри виртуальной машины" (с).

 

Rel, на всратом си, это к сожалению не означает на дотнете или бэйсике.

Зачем искать, если можно самому по-быстрому набрасать?

Хотелось бы раз увидеть какой-нибудь целостный кодес от преподобного Рела.
Я его батником скомпилирую, и буду от радости тысячи семплов на нем гонять.

 

shanya0xff

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

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

- исключения, можно установить поверх произвольный хэндлер(veh и пр).

- apc, общий хэндлер, который будет вести очередь задаваемых хэндлеров.

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

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

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

 

Для всех, кто не умеет оценивать сложность программных проектов, можете как раз KoiVM посмотреть. Считаем, что CIL-код стековой ВМ с автоматическим управлением памятью существенно проще эмулировать.

 

Сложность кода надо по скорости циклов смотреть, количеству строк, и количеству команды участников проекта.

 

Ahimov

Почему не получится просто выделить память для эмулирования стека чтобы восстанавливать его в RSP перед выполнением системного вызова. О какой защите идёт речь в данном случае?

 

shanya0xff

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

 

Поискал подходящие эмуляторы(которые не авер), готового не видно

unicorn это вроде как транслятор(qemu), значит нужен буфер wx.

Из тем по защите(датафлоу) есть такое RISC-V ISA Simulator, для оценки можно посмотреть математику
Такое(wtf?) не годится, необходим эмулятор архитектуры(isa), реализованный той же архитектурой, как у авера.

По антидампу(защита основана на блокировке памяти, не на флоу) есть poc 1 & 2 16-го года

 

маленький пример
https://connorjaydunn.github.io/blog/posts/binaryshield-a-bin2bin-x86-64-code-virtualizer/
https://github.com/connorjaydunn/BinaryShield

 

alex_dz, сразу видно, что это код здорового человека, а не код курильщика,
который на скрепном дотнете писали сложность которого не сразу оценишь.

 

Research

Как вам этот эмулятор, женский между прочим
Смотрим деление, не хорошо не плохо, но лучше чем своя алгор. реализация.

 

Ahimov, у этой женщины целых 226 репозиториев, это не хорошо и не плохо, но мне надо эмулятор под win.

 

Всё не читал, но судя по #1,
Персонажу нужна вирта,
Которая будет крутить сэмпл до снятия крипта.
А такую здесь, как мы уже знаем, давно запилили и даже прокрутили на ней неимоверное количество сэмплов, которые теперь уже вообще меряем в киловаттах потраченной электроэнергии.