Отслеживание и блокировка доступа к памяти процесса. Ring0

Нет ли ring-0 решений с исходным кодом, которые бы контролировали доступ к памяти процесса?
Если нет, то какие способы наиболее подходят для этой цели?

 

Заперить доступ к старници памяти, и отслеживать прерывание по ошибке

 

+ Отслеживать изменение атрибутов доступа к странице

 

+ Отслеживать случаи когда дескрипторов стриниц на один и тот-же участок памяти - несколько.
+ Отслеживать попытки создания дескрипторов страниц, опять же на этот участок памяти.

 

Благодарю. Вообще-то ) я имел в виду доступ к памяти процесса со стороны - т.е. внедрение кода/изменение структур/хуки и т.п.

 

SomeOne_TT_WORK тоже самое, в r0 по другому не получится

 

Гм. Но это же гигантский оверхед, нет?
Игра с подобной "защитой" от модификации будет еле-еле плестись

 

Для отслеживания записи/чтения в память другого процесса для юзермодных приложений достаточно хукать NtReadProcessMemory/NtWriteProcessMemory

 

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

+ Запретить восстановление оригинального обработчика прерывания, что невозможно в принципе

 

>> Для отслеживания записи/чтения в память другого процесса для юзермодных приложений достаточно хукать NtReadProcessMemory/NtWriteProcessMemory

великое заблуждение... см хотя бы Рихтера

 

?

 

классический способ Рихтера это загрузка dll функцией CreateRemoteThread с LoadLibrary. NtWriteProcessMemory там не используется .

 

А как же WriteProcessMemory с занесением в адресное пространство целевого процесса строки с именем dll? Рихтер как раз использует WriteProcessMemory, что превращается в NtWriteVirtualMemory.
ЗЫ. А NtWriteProcessMemory где такая? Просто ни в экспорте NtDll, ни в Ntoskrnl мне ее не видно...

 

а если подумать чуток?
решение в лоб:
1. любой PE файл имеет ASCIIZ строку
2. системные dll загружены по одним адресам
3. ...

у Рихтера вроде были и другие способы

ЗЫ с NtWriteProcessMemory я ошибся имел ввиду NtWriteVirtualMemory конечно же

 

спасибо за носом об батарею)) и правда не подумал

 

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

 

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

 

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

 

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