Avanguard: The Win32 Anti-Intrusion Library

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

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

 

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

 

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

 

я немного про другое. Ты против каких хакЭрских инструментов тестировал свою защиту?

 

rasstriga,

> Поэтому, присоединяйтесь к обсуждению.

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

> зачем мне трассировать все нажатия, когда мне нужно одно, с одной единственной функцией?

Вы видимо не понимаете что спрашиваете. Вопрос просто что бы был, без смысла.

HoShiMin,

> А визор по смыслу и есть трассировщик, только после построения графа функций он их ещё и выполняет

Да, это трассировка, но в совсем ином виде, не как обычно. Не используются ловушки. Вот к примеру предыдущий семпл, по которому заметили что нет импорта - это однопоточное апп и нужно это было для теста AVM, пришлось убрать штатный декодер(ксед), взять минимальный дизасм длин и запилить таблицу MODR/M. Что бы исключить любые события - исключения или апи. Но так как пример минимальный, этим он и хорош. Для первого знакомства с этими техниками следует начинать с простого. Тема реально очень сложна.

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

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

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

 

Взял свой инжектор, который выполняет шелл с GetModuleHandle и LoadLibrary. Потом свой же инжектор через SetWindowsHookEx, потом просто вписал дллку в апп-иниты, все три - детект. Апцшки и контексты буду проверять уже на ExtremeInjector'e - его чаще всего юзают для читов и просто потому что у меня нет готовых самописных инжектов на апцшках и контекстах)

Indy_, как раз вчера хотел спросить про поддержку исключений и забыл (в вмп/темиде, например, поддержка есть). А в чём принципиальная сложность с синхронизацией?

 

HoShiMin,

> А в чём принципиальная сложность с синхронизацией?

С какой не понимаю. ?

 

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

--- Сообщение объединено, 19 мар 2019 ---

Кстати, не совсем по теме, но вот интересный пример чудес кодогенерации: https://github.com/xoreaxeaxeax/movfuscator

 

HoShiMin,

Ты не смог разобрать пример простейший без импорта. Полноценная реализация тянет кучу нтапи для поддержки, поэтому нет смысла рассматривать более сложное. Всему своё время. Когда будет нужно, возьмём более сложное.

 

Пример как должна работать защита от инжекта https://yadi.sk/i/49hXiN0t_E6uvw

Что там происходит. Запускается блокнот под визором, что бы исключить исполнение кода в модулях. Снимается атрибут с образов PAGE_EXECUTE_READ -> PAGE_READONLY. Далее выполняется обычный инжект - установка контекста. После клика на окно(возврат потока из сервиса) в отладчике возникает останов по int3 на буфере с впрыснутым кодом. Он вызывает MsgBox(). Так как секция блокирована от исполнения(R), то передача управления приводит к срабатыванию ловушки(#AV, 8 в инфе про фаулт это флаг исключения по NX). Ну и далее вывод сообщения.

 

А как визор отличает свои потоки от чужих? Например, я вызову CreateRemoteThread, визор должен знать, какие потоки начинать транслировать, а какие отсекать. Аналогично для других методов: оконные хуки, к примеру. Инжектится, предположим, uxtheme.dll - системная либа (она прилетает в процесс через оконные хуки). Заблочить её нельзя (можно, но поедет интерфейс). Вижу ровно те же проблемы, что и у меня.

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

 

HoShiMin,

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

 

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

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

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

Делаю ставку на аппаратную виртуализацию и анклавы. Но требуется поддержка от AMD (странно, почему винда до сих пор не поддерживает их анклавы) или включенный Hyper-V (а у большинства пользователей он выключен).

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

 

HoShiMin,

> Проблема в том, что если нельзя отличить валидную длл от злодейской

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

> Но это решается, если поставить VEH, ловить эксепшны

В идеале нужно блокировать всё ап. Это нельзя сделать в юм, так как область с обратными вызовами ядра(Ki*) заблокирована не может быть. Можно разбить кодовую секцию нт на регионы и блокировать все, которые не содержат обратных вызовов. Иначе нужно писать драйвера, что очень не желательно.

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

Тупо блокировать инжект это не основная цель при использовании таких техник. Обычно инжект обратный, это OP(ROP/COP/etc). Никому не нужно впрыскивать системным путём код в процессы, это блокирует обычное разграничение прав. Именно это и решается через транслятор, я это подробно давно описывал.

> Либо писать свой анклав: драйвер открывает ядерную память в юзермод, ремапит туда модули, найти их нельзя

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

--- Сообщение объединено, 20 мар 2019 ---

HoShiMin,

> драйвер открывает ядерную память в юзермод

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

 

Не согласен: допустим, мы хотим изолировать только один модуль от рантайм-изменения, а остальные не критичны: кладём модуль в анклав, получаем чёрный ящик, который можем лишь исполнять (в гиперви есть готовые функции, но требуют цифровой подписи, на sgx нужно писать самому или юзать гугловскую либу для анклавов). Плюс, PPL, чтобы оградиться от динамического кода. Остаются ROP'ы, что уже очень сложно.

 

HoShiMin,

> чёрный ящик, который можем лишь исполнять

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

> Остаются ROP'ы, что уже очень сложно.

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

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

--- Сообщение объединено, 20 мар 2019 ---

HoShiMin,

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

 

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

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

--- Сообщение объединено, 20 мар 2019 ---

А как насчёт DeviceGuard/HVCI?

 

HoShiMin,

> визор не сумеет отличить валидные либы от недоверенных

Это задача не среды исполнения. Через эту технику можно блокировать все передачи управления и связать указатели(блокировать OP-инжект).

 

В том и дело, что у меня задачи хоть и сходные, но применение визора не так критично, когда есть десятки обходных путей, намного более простых, чем смена контекста и тем более ROP'ы

 

HoShiMin,

> А как насчёт DeviceGuard/HVCI?

Я не знаю как это работает, но сомнительно. Так как обратный инжект не зависит от каких то железячных фич.

> смена контекста и тем более ROP'ы

Тогда что вы строите за защиту, от пары штатных инжектов в лабораторных" условиях ?