отлов WriteProcessMemory/ReadProcessMemory

А я и не говорил, что есть :P Я уже давно разобрался что к чему +) Может мы о разном говорим?
Кстати я и не спорил ) А хамить совсем не обязательно, мы всетаки интеллигентные люди в большей части собрались здесь. Поэтому стоит вести конструктивную дискуссию.

Само собой) Тут тоже никто не спорит. Да, мы точно о разном говорим +)

Ну да, а после sysexit?) можно например логировать системные вызовы так.

ntdll.KiFastSystemCall ? а смысл если руками делать вызов sysenter
или всетаки ntoskrnl.KiFastCallEntry?

 

да
я просто не сильно знаком с названиями функций

 

так вроде из юзермода хотели?)

 

да я уже понял

 

Freeman
Да, спасибо за разьяснения, я перепутал KiFastSystemCall с KiFastSystemCallRet =)

Great

Да, теперь все на своих местах.

 

Вообщем, кажется мы уже ушли от темы.
Стоит обобщить сказанное:

Если программа цивилизованная, то есть юзает ntdl.KiFastSystemCall, как завещал дядя Билл, то можно отловить Read/WriteProcessMemory до ее выполнение, засплайсив KiFastSystemCall или подменив адрес SharedData.SystemCallStub (или как он называется там, не помню).

Если программа совсершенно гадская, нагло напрямую сама дергает sysenter, то перехватить, конечно же, вызов до его выполнения нельзя. Но можно после - после sysexit управление перейдет на ntdll.KiFastSystemCall, из юзермода это нельзя изменить и соответственно это можно отловить, похукав оную.

Если программа совсем-совсем гадская и дергает int 2e, то тут уже молиться только остается.

Уж если теперь вы, товарищ Clerk, будете возмущаться, спорить и хамить, то я уж прям не знаю, что и писать)

 

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

Тогда находим нужные int2e и патчим их. На край не еб*м мозг и пишем драйвер, который будет хучить нужные функции.

 

Ну так вот и я говорил, что мы слегка ушли от темы...

 

Great
Я не грубил(прошу прощения если ты так подумал), это всего лишь моё мнение, не больше.
Вопрос был о способе отлова чтения/записи памяти процесса, насколько я понял.
Этот вопрос(и подобные) актуален только для User-mode. Для режима ядра вопрос не имеет смысла.
На самом высоком уровне можно контролировать SST, сплайсинг обработчика - неудачные способы.
Обработка сервиса NtReadVirtualMemory идёт следующим путём:
NtReadVirtualMemory->ObReferenceObjectByHandle->MmCopyVirtualMemory->KeStackAttachProcess->KiAttachProcess->KiSwapProcess(загружает LDT)->RtlCopyMemory
Для защиты можно перехватывать многие функции, эти и вспомогательные.
Но это не поможет, можно напрямую сменить LDT(lldt) и прочитать память.
Защита записи страниц тоже не поможет - стоит сбросить CR0_WP.
Защитится можно только зная механизм, с помощью которого будет читаться память.
Но ведь можно использовать разделяемую память(как тут не вспомнить секцию "PhysMem")

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

Я имел ввиду что в процессе, из которого читается память нечего при этом изменятся не будет, не будут вызыватся функции ntdll!KiXX

 

Дык в этом никто и так не сомневался)
Хукают NtReadProcessMemory - дергаем KeStackAttachProcess, и т.п. В конце концов можно прочитать память не используя апи, а только оперируя с аппаратной частью.

Чето мы снова про конечную цель забыли. Мы хотим что?
а) отследить вызов?
б) запретить вызов?
в) вмешаться в работу и изменить входные/выходные данные?
Вроде автор хотел лишь отловить, а не затирать ничего =)

 

l_inc

Это ближе к телу
я выделяю память из кучи:

Код (Text):

1. plvi = (LVITEM*)VirtualAllocEx(hProcess,0,sizeof(LVITEM) + strlen(str) + 1,
2.         MEM_COMMIT,PAGE_READWRITE);

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

EvilPhreak

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

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

Конечная цель такова:
Выяснить ли может ли исследуемая программа отлавливать выделение памяти в своем АП, чтение/запись из вне в своем АП, и тут еще вопрос возник, которые напрямую связан со всеми этими:
Если я посылаю сообщение исследуемой программе через Send/PostMessage, может ли она как то определить что сообщение послано не системой, а каким то чужим процессом. Например сообщение о нажатии кнопки мыши. (Все подобные сообщения максимально приближаются к реальным, позиционируется курсор в нужном месте, отсылаются координаты этого курсора...)

Еще полистал форум, понял, что мой вопрос не такой уж и достаточно тривиален, в каждом конкретном случае нужен свой подход, так получается?

 

Автор даже и отлавливать не хотел. Он только хотел проверить, не отлавливает ли конкретная прога (игра). А дискуссия от конечной цели уже далеко ушла.

 

beginner

Если открыто ставить перехваты и запускать внедренный код, то она попалится. Но в принципе существующие методы защиты не очень трудно обходятся.

Хотя бы тот же перехват соответствующих функций.

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

 

beginner
Кстати.

Это не из кучи. Из кучи: HeapAlloc, но не в чужих процессах.