Антиинжект: отловить смену контекста

Есть ли способы как-то узнать (по любому признаку, прямому\косвенному), что у потока сменился контекст?
Например, делают инжект через SuspendThread -> SetThreadContext -> ResumeThread.
Можно ли "поймать" поток на одном из этих участков? Пока вижу единственный вариант - перебирать все регионы памяти и искать исполняемую память, не привязанную ни к чьему модулю. Но в промежутках между поиском можно вполне успеть заинжектиться, выполнить нужный код и бесследно выгрузиться из памяти - проверка ничего не найдёт.

Вариант с драйвером и ObRegisterCallbacks тоже не подходит - CreateProcess(CREATE_SUSPENDED) -> Заинжектить либу -> ResumeThread до старта драйвера.

 

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

 

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

Эта техника называется CCFIR. Ребилд всего кода, это один из базовых способов защиты от OP. Но это не реально реализовать.

 

HoShiMin,

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

Но она так же не полноценна и практически не реализуема.
В любой момент времени управление может быть передано куда угодно. Нельзя заблокировать инжект просто ограничением прав доступа - не корректная обработка данных приводит к выполнению произвольного кода(OP(Oriented Programming)-inject).

Нужно ввести новые понятия, Pointer Flow Graph(PFG).

1. Определение инжекта - нарушение целостности потока данных(DFG).
2. Всякая OP-передача управления есть следствие 1. Множество частных методов решения - CET etc не решает задачу.
3. Необходимо в реалтайме выполнять проверку PFG. PFG есть частный случай DFG по причине профайла.
4. Три проблемы - определение, разложение и смещение указателей. A. Указатель отличается от данных через релок, нет релока - есть лишь вероятность что это указатель. B. При DFG например загрузке указателя в контекст он может быть разложен на части. C. Case-конструкции, указатель смещается от начала структуры. => 5
5. Наследование указателей и вероятных указателей. Для решения проблемы 4 наследуется выборка данных(PFG) через маркеры в памяти двух видов - указатель и вероятный указатель. Всякая их пересылка в DFG наследуется через маркеры в AS(в памяти).
6. PFG/DFG формируется визором. Только прямое исполнение(DYE) может дать реалтайм профайл. Тогда все потоки данных отслеживаются и всё адресное пространство не исполняемо, кроме кода визора и его буферов.
7. Теневой стек в данном случае deprecated. Механизм защиты может быть заложен в железо.

 

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

Если не секрет, где можно почитать Ваши публикации?

И в свете невозможности гарантированно отследить смену контекста, можно предотвратить сам факт смены - сломать NtSetContextThread (пусть только для юзермода, коль скоро нас атакуют оттуда). Например, обойти Copy On Write и заполнить мусором тело функции. Да, восстановить очень просто, но на какое-то время наших диванных хакеров это задержит. Но в юзермоде, насколько понимаю, нет возможности создать отображение на уже существующую память (сделать аналог ядерных IoAllocateMdl -> MmMapLockedPagesSpecifyCache)?

И вопрос с ядерными атаками так и остаётся открытым.

 

Под визором Вы имеете в виду полноценный гипервизор?

 

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

 

HoShiMin,

> Под визором Вы имеете в виду полноценный гипервизор?

Нет.

 

Где об этом почитать?

 

HoShiMin,

Почему вы думаете что где то можно почитать ?

Вы про это всё нигде не почитаете. Вот же наивные думают что альтернативка где то описана

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

Решения для вас нет. То что есть никому не доступно и нигде не описано.

 

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

 

unc1e,

Выделяем исполняемый буфер, определяем размер линейного кода(раскодируем опкоды и находим ветвление), копируем его в буфер и исполняем - это DYE. Гибридный визор с реалтайм профайлом. Про всякие трансляторы llvm и прочее говно речи нет.

 

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

 

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

 

Один человек копает инфу, чего то добивается. Получаются _знания_ - потом их развивают другие. Так происходит прогресс и достижение и развитие чего то. Если знаниями никто не делится - они просто умирают.

 

HoShiMin,

> что мешает сменить контекст у самого визора

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

 

Fail,

Согласен, это так. Но тс нужно слишком подробное описание.

 

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

 

unc1e,

Визор не передаёт управление в исполняемую память, он либо эмулирует инструкции(llvm, pin etc), либо копирует их в изолированный буфер и исполняет(dye). Исходная область памяти с кодом не исполняема.

https://yadi.sk/i/jaRS5EFT3KF38d