Обнаружение VM, навороченные методы (vx)

https://yadi.sk/d/CQWCxYvT39FFtx

Защита потока данных (Data Flow Guard)

Защита потока управления (CFG) или данных (DFG) – методы обнаружения нарушения целостности кода или данных, обнаружение чужеродных объектов.

Нарушение целостности кода — появление в нём посторонних инструкций, код может сам изменяться или вызывать чужеродный код косвенным путём — посредством изменения памяти, например указателей в массивах методов или адресов возврата на стеке. В последнем случае защита целостности кода носит название защиты потока управления (CFG). Она реализуется различным путём: NT-CFG, CFI, Intel-CET etc, далее рассмотрена техника DFG, использование её для таких приложений, как обнаружение/обход AVVM и защита памяти.

DFG – есть защита потока данных (см. Data Flow Graph). По сравнению с CFG это более глубокая валидация кода. При CFG проверяются адреса инструкций или их связанность в графе (eg: call-ret). При DFG проверяется на целостность поток данных, используя контекст задачи (потока) и память. DFG позволяет обнаружить атомы.

Атом — объект (присутствующий в коде), изолированный от среды исполнения. Такие объекты выполняют теневые операции, не доступные текущей среде и соответственно нарушают DFG. Примеры атомов:

• Наномиты — в коде ставится точка останова и через отладчик на этой точке останова изменяется контекст задачи/память. Это нарушение целостности потока данных — входные/выходные данные и операция, выполняемая инструкцией (которая является точкой останова) не связаны (eg: Int3 не изменяет контекст задачи).
• Ядерные сервисы — такие объекты передают управление на иной уровень привилегий, где выполняется обработка данных.
• Объекты эмуляции — при обнаружении в коде маркера виртуальная машина (эмулятор) выполняет некоторую функцию.

Код, выполняющий атомы в общем случае изолирован от исходной среды – исполняется на ином уровне привилегий, в контексте гипервизора (VM) etc. Использование атомов позволяет обнаружить виртуализацию (AV-эмуляцию (AVVM)), отладочную активность etc.

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

Выборка данных (Data Fetch)

Для использования DFG необходимо отследить машинную выборку данных (DF). Это операции с памятью, выполняемые CPU. Выполнить это можно двумя путями:

1. Хардверный трек памяти, установка ловушек на память. В этом случае на блок памяти ставится ловушка, которая срабатывает при обращении к памяти.
2. Эмуляция каждой инструкции и раскодировка адресов. Необходима полная трассировка/эмуляция приложения или вызываемой функции. Этот способ медленный и требует сложной системной обработки (события создания потоков, ядерные колбеки etc).

На основе информации про DF (адрес данных, контекст связанный с данными) может выполняться валидация DFG (проверка изменений памяти и результата операции в контексте).

В атомах DF не существует (по причине изоляции атомов от среды). Это даёт метод обнаружения и изоляции атомов. Заблокировав память (блокировка памяти есть установка ловушки на неё) от атома он не сможет выполниться корректно. При DF выборка перенаправляется на другую память или выполняется эмуляция. Эта техника именуется IDP (Intercept Destruction of Pointers – захват разрушением указателей). Изначально применялась как руткит-техника: ссылка на данные делалась инвалидной (ставилась ловушка), DF отслеживалась и данные подменялись.

Защита памяти

IDP кроме изоляции атомов, как следствие, даёт метод защиты памяти. В исходной области памяти данных не существует. Так как DF происходит только из текущей среды (процесса соответственно), то DF из иной среды (процесса или иного CPL (из ядра, если среда – юзермод)) не существует.

Динамическая защита памяти (DYPE: DYnamic ProtEction)

Учитывая выше описанное техника следующая.

Секции защищаемого модуля блокируются и ставится ловушка на DF. В результате:

1. Кода/данных в этих областях не существует. Изолированный из текущего процесса код (Reader) их прочитать не может. Нельзя снять дамп.
2. Атомы выполняться не могут — прекращение работы AVVM при выполнении осевых функций, использующих блокированную память.

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

Валидация ридера (Reader Check)

DF возможна из стороннего кода (ридер), который не безопасен (AV) и загружен в текущий процесс. Проблемы не возникает если в модуле секции кода не содержат данных (констант). В таком случае достаточно полностью запретить DF — выборка кода выполняется AV. Если секции содержат константы, то необходимо определить какому ридеру разрешать DF.
Решения возможны следующие:

1. Валидация ридера, определение что ридер небезопасен (списки AV). Сомнительный способ.
2. Отличить данные (константы) от кода. DF для данных разрешена, для кода запрещена. Универсально, но является сложной задачей.

Обход CFI

Описанная техника позволяет обойти CFG, выполняемую через валидацию вызывающего кода (Caller): CFI. При DF могут быть возвращены виртуальные данные — сформирован корректный код вызова.

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

© Indy, 2016.​

 

Способы обнаружения атомов

Ранее описан способ блокировки исполнения атома — изоляция выборки данных (DF) через блокировку памяти. При обнаружении DF адресация изменяется, но так как в атоме DF не существует, он не может получить доступ к данным. Далее рассмотрены методы не блокировки, а обнаружения атомов.

Для обнаружения атома необходимо в начале получить событие DF. Далее можно выполнить валидацию DFG или иные манипуляции. Базовые способы получения DF:

1. Раскодировка адресов для каждой инструкции, это получение линейного адреса через раскодировку MODRM инструкции. Для этого необходимо обработать поток инструкций — выполнить трассировку или эмуляцию.
2. Установка ловушки. Срабатывание ловушки является событием DF. Ловушка ставится хардверно, через блокировку памяти или установку аппаратных точек останова (не универсально). В первом случае необходимо перенаправить DF на оригинальный адрес (IDP), что бы использовать ловушку повторно.

Помимо базовых способов можно найти системное решение. Так например обнаружить DF можно по расширению стека (доступ к сторожевым страницам). Кроме этого система реализует два монитора памяти: WW (write watch) и WSW (working set watch).

Первый (WW) работает со специальной памятью (MEM_WRITE_WATCH). Второй (WSW) механизм универсален. Это монитор рабочего набора. Лог добавленных страниц доступен из UM: ProcessWorkingSetWatch.

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

WSW это второй (с ProcessHandleTrace) механизм NT, который реализует раскрытие ядерных адресов. Пример лога для для NtQueryInformationProcess с буфером (0x360000), не присутствующем в рабочем наборе:

WSW лог это массив записей:

Код (C):

1. typedef struct _PROCESS_WS_WATCH_INFORMATION {
2.           PVOID FaultingPc;
3.           PVOID FaultingVa;
4. } PROCESS_WS_WATCH_INFORMATION, *PPROCESS_WS_WATCH_INFORMATION;

Как видно первая запись в логе это событие DF в ядре при доступе к аргументу сервиса.

Следующие записи являются результатом работы отладчика (0x80615A85 → 0x53EA85 (смещение при загрузке ядра в OllyDbg, для загрузки необходимо изменить тип подсистемы Native → Gui):

Тот же вызов сервиса но при сброшенном рабочем наборе:

Видна последовательность выполнения кода — вызов сервисного шлюза, возврат на него, DF из буфера и активность EMET. Следует заметить что DF из буфера происходит в ProbeForWrite() — это валидация аргументов сервиса. Под WOW в логе сохраняются UM адреса слоя виртуализации.

Этот (WSW) логгер хорошо подходит для обнаружения атомов. Он пригоден для следующих приложений:

1. Непосредственно обнаружение атомов.
2. Обнаружение отладочной активности.
3. Обнаружение KM фильтров.

Упомянутый выше механизм трассировки описателей (Handle Trace) использовался для обнаружения ядерной фильтрации, что было реализовано в моторе SHDE (2012):

; Валидация ядерной SFC для определения наличия фильтров.
;
; Первый адрес на стеке ядра это kss60, инструкция следующая за процедурным ветвлением kssdoit, вызывающим NT-вектор. Второй адрес принадлежит телу NTAPI. Модель вызова сервисов (KiSystemService()/KiFastCallEntry()) не изменяется. Если вектор в SST направлен в фильтр, либо начало сервиса пропатчено (сплайсинг), то второй адрес будет принадлежать не NTAPI, а фильтру. Возможно что фильтров несколько, в этом случае SFC удлинится. Возможно фильтр не стоит на NTAPI, а находится глубже, например в менеджере объектов. В этом случае он не следит за вызов сервисов непосредственно (eg.: DrWeb ставит фильтр на OBTYPE.OpenProcedure). Однозначно определить NTAPI-фильтр можно только первый. Косвенная фильтрация не может служить для однозначной детекции.

Аналогично может быть использован и механизм WSW. Серию DF из области памяти нельзя отследить через WSW, но можно использовать цикл перезапусков целевого кода со сбросом рабочего набора, что даст все адреса, код по которым выполняет DF.
WSW позволяет исключить сервисы из валидации, так как отслеживает DF в них (сервисы являются атомами).

Перейдём к рассмотрению непосредственно детекта атомов. При обнаружении атомов трек DF является опциональным дополнением к DFG валидации через WSW:

1. Если нет записи WSW и данные изменились, то исполнялся атом.
2. Если есть запись WSW, то DF (WSW) должна быть из целевого кода или из сервиса. Такую проверку можно выполнить при трассировке целевого кода (таким образом выделив все адреса, по которым были DF). Может быть выполнена дополнительная проверка DF (раскодировка адресов) на соответствие WSW.

Например в AVVM сложные API являются заглушками для вызова атомов.

Если атом вызывается без обращений к аргументам до вызова его, то WSW будет пуста (1).
Если до вызова атома имеются DF, то он будет обнаружен через трассировку (2).
Если WSW эмулируется, то валидацию можно выполнить через трассировку (2).

© Indy, 2017​

 

Обнаружил "продолжение темы", если позволите, https://ru-sf.ru/threads/test-av.3217/

 

Indy, нашел куда запостить, там даже VirtualAlloc не знают что такое

 

Уважаемый Инди_, скажи кто Вас там задизлайкал там?

 

Анализ атомов¹ AV

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

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

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

Для детекта шифрованный образ PE декриптуется, выгружается в файл и запускается. Для примера взят Glyn. Так как не все AV его детектят, то для теста других AV следует взять иной образ.

В начале запустим непосредственно декриптор, но после переноса тела API в буфер. Данная манипуляция выполняется конструктором. При этом используется вызов аллокатора, в качестве которого используется VirtualAlloc(). Код конструктора содержит стандартный набор инструкций и не использует системные механизмы(ничего не вызывает вне себя). Это уменьшает его влияние на тесты. Для успешного прохода данного кода AV должен эмулировать аллокатор.

Конструктор пересобирает код API в буфер. Затем этот буфер исполняется, результат исполнения является ключём к декрипту образа. Для тестов взята сложная функция — GetProcAddress(). Результат теста (C1):


Как сказано выше, в тест не включены AV, которые не содержат детект на образ и которые не смогли пройти тестовый код. В буфере код выполнен успешно. Определим число инструкций, из которых состоит тело API. Общее число их описано в графе. Получить его мы не можем, поэтому используем условную конструкцию к заданием возможного числа. Если условие верно (число инструкций < 10), то результатом будет детект (C2):


Только AVG содержит < 10 инструкций в теле этой функции. Увеличим значение до 32 (C3):

Видно, что остальные AV содержат более 10 инструкций. Далее определим структуру кода — наличие в нём ветвлений. Пройдя по всем инструкциям графа найдём ветвления (за исключением инструкции возврата Ret) и при их обнаружении выдадим детект (C4):


Только Ikarus содержит нелинейный код (с ветвлениями). Уточним число инструкций, увеличив лимит до 96 (C3i). Результат тот же. Эта API является сложной реализацией.

Определим какие ветвления присутствуют в данной API у Ikarus (C4i). Перечислив все типы ветвлений, остаётся одно безусловное процедурное ветвление (Call rel).

В теории были описаны способы изоляции выборки данных (DF). Простейший способ обнаружить DF — расширение стека при доступе к сторожевой странице. Из атомов таких обращений нет (если не эмулируются намеренно) — он изолирован от эмулируемой среды. Выполним вызов атома, передав ссылку на гвард страницу стека: После возврата из API проверим стек на расширение и если он не расширен, то выдадим детект (C5).



Изменим условие проверки на обратное для наглядности (C5e)...



Проверим расширение стека непосредственно на инструкциях, что бы узнать поддерживается ли данный механизм. Обратимся напрямую к сторожевой странице и при расширении стека выдадим детект (С6). Ikarus данный механизм не поддерживает. Только Kaspersky выполняет расширение стека API. В таком случае выполняется доступ из тела API к её аргументу, либо стек расширяется при валидации указателей в VM (намеренно):



Разложить код на трассу можно тремя путями — машинной трассировкой (TF), эмуляцией или динамической эмуляцией (DYE). Выполним (C7) это что бы получить доступ к атому (далее можно его исследовать непосредственно)...



Функция трассирована через элементарный DYE-цикл. Детекты BitDefender и его клонов исчезли. Из этого следует что его атомы привязаны к положению частей кода, либо состоят не из одной инструкции, так как при выполнении атома в буфере эмуляция прекращается, убедимся в этом вставив после возврата из цикла DYE прямой вызов декриптора (C8):



Определим номер инструкции, которая является атомом. Этим событием является возврат из атома и соответственно возврат значения в регистр. Зададим для примера минимальное значение в 5 итераций (С9):



У AVG атом расположен на 5-й инструкции. Передадим инвалидный указатель в атом, прежде зарегистрируем ловушку (SEH) и при срабатывании ловушки выведем детект (C11):



AVG и Kaspersky разворачивают исключение при обнаружении инвалидного указателя. Обернём вызов API в SEH и передадим инвалидный указатель (C12):



Появляется детект BitDefender, таким образом он не разворачивает исключение, а возвращает управление из атома. Интересно определить какой адрес передаётся в ловушку...

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

Показан принцип исследования тела апи/атомов. Можно исследовать другие AV (к примеру VBA и Yandex так же успешно проходят пересборку и аллокатор).

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

© Indy, 2017​

 

Я бы просто не стал там отвечать
Статья норм, но вкуривать и вкуривать. Сам с NT-CFG сталкивался.

 

Зря наверное пишу здесь, но интересно а кто вы такой, так ради интереса посмотрел ваш профиль, кроме постов что-вы какой-то там иллито, о котором никто не знает, так путного и не нашел...

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

Или вы думаете что кроме винды ничего нету ?

Сразу скажу, я ни на что не претендую здесь, так-же как и форум, но если считаете себя экспертами, так подтверждайте это, а не:

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

Я не прошу отвечать там, но мы не школьники, нашему форуму около пяти лет, мы не на что не претендуем, но если вы изучили что-то типа курса Нарвахо и считаете себя иллито, то это ваши проблемы, например не думаю что вы лучше меня знаете си например...

Этот пост относится больше к RET, пока-что кроме бла-бла-бла не нашел в ваших постах здесь ничего !

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

 

Я живо представляю себе ситуацию, как RET в реальной жизни обратится куда-нибудь за помощью/информацией, а в ответ услышит

"кыш отсюда школоло"

С такими фразами этот форум действительно обречен.

Давайте уже быть мужчинами, а не детьми..

 

ой ё и здесь уже началось

 

Indy_, значит вы считаете, что все ваши наработки/наброски статей, которые были запостщены в базе этого форума года с 2008 - коту под хвост?

фактически, это хоронить часть своей жизни, потраченную на исследования.

 

Ога, это пост профи, сразу видно...

Хотя справедливости ради, да я ошибся, почитал про VirtualAlloc по лучше, я почему-то думал что это типа malloc в си, а оказалось, что как-раз маллок аллокатор и дёргает VirtualAlloc в винде, так ?

Я VirtualAlloc в общем-то и не использовал никогда, даже когда под винду что-то делал, выделял маллоком, ну и new, если на плюсах...

 

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

 

rmn, т.е. если я в плюсах выделяю память
double *v;
v = (double *)_mm_malloc(sizeof(double)*N, 32);
для дальнейшей обработки массива в AVX (к примеру), то это нормально? Насколько большой массив можно так создать и от чего это зависит? На моем компе получается создать где то 140.000.000 можно как то увеличить?

 

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

 

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

 

Indy_, дальше буду обрабатывать массив случайных чисел с помощью AVX для решения задачи методом Монте-Карло (это к примеру). Просто я новичек в программировании и многие вещи мне до конца не понятны. То что статический массив упирается в небольшую размерность, как я понял, связано с размерностью стека. Но меня интересует создание динамического массива большой размерностью. Но вот он у меня упирается в это число, просто есть ли способы его расширить как единое целое.

 

А выравнивать массив не нужно ?

В gcc есть атрибут __attribute__((aligned(32))); ну в винде тоже что-то похожее должно-быть, попробуйте выровнять массивы тоже...

 

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

 

rmn, т.е. для увеличения динамического массива надо использовать VirtualAlloc() ?