отлов WriteProcessMemory/ReadProcessMemory

Есть чужая прога, из нее при помощи WriteProcessMemory/ReadProcessMemory и сообщений - получаю необходимые данные. Исполняемый код не внедряю.
Может ли эта чужая прога отловить момент, что кто-то из-вне записывает или читает данные из ее процесса?
Какими методами может отлавливать? Как проверить отлавливает ли она вообще? Как избежать отлова? И что бы порекомендовали почитать про обнаружение WriteProcessMemory/ReadProcessMemory ?

Заранее спасибо!

 

beginner
Как гадать будем? На звездах, картах Таро, костях животных? Где код?

 

beginner
конечно же может, перехватом этих функций она может контролировать свое адресное пространство
а перехват этих функций может быть где угодно и как угодно, в режиме пользоваетеля - kernel32.dll, ntdll.dll,
в режиме ядра - SDT hooking, kernel splicing.
и читать придётся много )

 

Mikl__
Непонимаю зачем нужен образец кода, когда вопрос более-менее понятен
ну по желанию прошу изучать:

Код (Text):

1.     char str[] = "any text";
2.     char str2[80];
3. // vnedrenie v process
4.     int pid=5;
5.     int NRec;
6.     DWORD i;
7.     HANDLE hProcess;
8.     LVITEM *plvi, *plvi_local;
9. // listView.handle – хэндл списка, глобальная переменная, получена через FindWindow();
10.     GetWindowThreadProcessId(listView.handle, (LPDWORD)&pid);
11.     hProcess = OpenProcess(PROCESS_ALL_ACCESS,0,pid);
12.     if(!hProcess) return 5;
13. // создаем структуру LVITEM в чужом процессе и заполняем поля
14.     plvi = (LVITEM*)VirtualAllocEx(hProcess,0,sizeof(LVITEM) + strlen(str2) + 1,
15.         MEM_COMMIT,PAGE_READWRITE);
16.     if(!plvi) return 5;
17.     i = LVIF_TEXT;
18.     WriteProcessMemory(hProcess,(void*)&(plvi->mask),&i,4,0);
19.     NRec = 5; // номер записи
20.     WriteProcessMemory(hProcess,(void*)&(plvi->iItem),&NRec,4,0);
21.     i = 5; // номер колонки
22.     WriteProcessMemory(hProcess,(void*)&(plvi->iSubItem),&i,4,0);
23.     i = (DWORD)(plvi + 1); // указатель на строку в чужом процессе, куда будет копировать текст
24.     WriteProcessMemory(hProcess,(void*)&(plvi->pszText),&i,4,0);
25.     i=79; // буфер под строку…. Это я заполнял структуру LVITEM в чужом процессе.
26.     WriteProcessMemory(hProcess,(void*)&(plvi->cchTextMax),&i,4,0);
27.     res = SendMessage(listView.handle,LVM_GETITEMTEXT,res,(LPARAM)plvi);
28. // посылаем сообщение о считывании элемента списка и копируем из чужого процесса в свой получаемую строку.
29.     ReadProcessMemory(hProcess, (plvi + 1), str2, sizeof(str2), 0);
30.     VirtualFreeEx(hProcess,(void*)plvi,0,MEM_DECOMMIT);

Код я изменил, упростил, но смысл понятен и свою задачу (получение элемента списка) он выполняет.

0x56
Спасибо
А что можно почитать, или как можно определить, что исследуемый процесс перехватывает эти функции? При условии, что программа может сразу не выдавать сообщение о записи в свое адресное пространство, а теоретически может втихоря отсылать какие то логи на сервер. (это подозрения всего лишь.)
Может можно как то отследить адреса загрузки kernel32.dll, ntdll.dll, а именно функций WriteProcessMemory/ReadProcessMemory, и потом сравнивать с какими то эталонными?
Прости если тут уже говорю чушь, но для меня это пошел темный лес.
Образцы кода - хорошо, ссылку на литературу, на статьи - еще лучше. Хотя бы просто название, что искать и в какой стороне копать.
П.С. в режиме ядра я сомневаюсь что исследуемая программа работает, так как она драйвера никакие не ставит, запускается на другом компе через обычное копирование. Хотя я могу ошибаться.

 

возможно вы хотели записать туда NRec?

 

Freeman
прошу прощения, исправил
просто что бы не утруждать всех обьемом кода, когда там два вложенных цикла, идет перебор по всем записям и по всем полям - я в примере значительно упростил код.
Еще раз раз приношу извинения, спасибо за внимательность и анализ!

 

beginner

О перхвате из режима пользователя много статей прямо здесь на сайте. В частности статьи Ms-Rem (особенно "Инжект, как метод обхода фаерволов", но начать лучше с цикла "перехват API-функций..."). О перехвате из режима ядра, например, 5-я глава книжки "Свэн Шрайбер. Недокумментированные возможности Windows 2000".

Адреса загрузки kernel32.dll, ntdll.dll отслеживать не нужно. В пределах версии системы они для всех процессов одинаковы, и всё отслеживание выполняется с помощью ф-ии GetModuleHandle.
Перехват из режима пользователя можно как раз именно так обнаружить. Сравнить начала ф-ий, перехват которых Вы хотите обнаружить, в своём процессе с таковыми в образе библиотеки на винчестере (это на предмет сплайсинга). Также нужно проверить таблицу импорта. Чтобы не мучаться с обеими библиотеками, используйте ф-ии из ntdll, а не из kernel32. Справочник по нативным функциям: Gary Nebbett. Windows NT 2000. Native API Reference.
С большой вероятностью, если программа ставит перехваты из режима пользователя, то с помощью своей dll (просто этот метод проще, чем внедрение чистого кода). Так что если в АП вашего процесса есть какая-то левая dll, находящаяся к тому же в папке с перехватывающей программой, то она на 99% ставит перехваты, а на что именно, нужно смотреть.

 

Из User-mode отследить ZwWriteVirtualMemory и ZwReadVirtualMemory не удастся. Если чтение или запись в текущим процессе посредством комманд процессора, то отследить можно с помощью аппаратных точек останова(Debug registers).

 

ну наверное, если получается такой трюк, то все нормально и не стоит беспокоиться )
или она настолько хитра, что вместо блокировки доступа может подсунуть вам ложные данные?

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

в крайнем случае выкладываете ее сюда
а мы посмотрим )

 

Clerk

С чего это вдруг? O_o Обычный сплайсинг.

 

Если из чужого процесса вызывается ZwReadVirtualMemory, то ни какие User-mode каллбак функции не вызываются, все действия происходят в ядре. Если даже вызов в текущем процессе, посредством sysenter, отследить можно, но если посредством Int2Eh, то отследить никаким способом не удастся.

 

Стоит разобраться в терминологии. Если вызывается именно функция ZwWriteVirtualMemory из NTDLL.DLL, то можно. Если вызывается напрямую через sysenter/int2e, то получить управление до вызова уже нельзя.

если я делаю сам

Код (Text):

1. mov eax, number
2. mov edx, args
3. call sysenter_call
4. ret
5.  
6. sysenter_call: sysenter

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

 

Clerk
В общем ерунду Вы говорите. Ни о каких callback-функциях речь не идет. Глобализованный на все процессы перехват, например, сплайсингом прекрасно ловит вызов любой хоть нативной, хоть не нативной функции в любом процессе. И о sysenter'ах напрямую тоже речь не идет. Хотя, если топикстартер пишет под конкретную систему, то в случае перехвата в режиме пользователя можно посоветовать, конечно, делать sysenter'ы и не бояться перехватов, хотя это ИМХО извращенно.

 

да проще поснимать хуки с нтдлл или загрузить вторую копию себе, чем хранить все ссдт номера Nt* апишек

 

Great
В User-mode защиты от перхватов нет, вначале разберись, потом cпорь.
Ты наверно уже понял по сорсам, что я использую только входы через Int2Eh.
Глобальные хуки и хуки вообще - это ненадёжный способ контроля.

 

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

l_inc
пролистал первую часть "перехват API функций"
во всех примерах кода есть одна закономерность: название API функции задается явно:

Код (Text):

1. //получение адреса CreateProcessA
2.  AdrCreateProcessA := GetProcAddress(GetModuleHandle('kernel32.dll'), 'CreateProcessA');

отсюда вывод, что если программа ничем не упакована, ничем не защищена - то есть большая вероятность того, что если данная функция перехватывается, то ее название должно быть указано в файлах в явном виде. Поиск по всем файлам - дал отрицательный результат, такие функции(WriteProcessMemory/ReadProcessMemory) вообще не используется.
PEId дал результат Microsoft Visual C++ 6.0 [Debug], все длл так же дебаг версии.

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

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

 

Ну... Это не совсем те закономерности, которые стоит искать при прочтении статьи.

Не совсем правильный вывод. Если Вы прошерстили целиком образ программы и dll'ок, то во-первых адреса перехватываемых функций могут находиться по порядковому номеру aka ординалу, а во-вторых имена функций могут быть в UNICODE'е. Кроме того, сейчас действительно много программ упаковано. Мало того, адрес функции (особенно, если производится перехват функций kernel32/ntdll) может быть зашит прямо в образ и выбираться в зависимости от версии системы.

Вообще программы сами себя не часто от записи в своё АП защищают. Этим заняты антивирусы/фаерволы. А если Вы не пишете в область памяти с атрибутом PAGE_EXECUTE, то и они в большинстве своём промолчат (Oupost, например, может скромно заикнуться). А даже если программа и защищает свои данные от записи, то чаще не перехватом апи, а динамическим подсчетом чексуммы. Правда, на выделенную в их АП чужим процессом память это не должно распространяться.

 

Great

Стоп. Если сплайснуть KiFastSystemCallRet и напрямую вызывать SYSENTER ничего не изменится - т.е. сплайс-хук не сработает. Ведь KiFastSystemCallRet юзают переходники как раз для исполнения SYSENTER. Или по Вашему после SYSENTER вызывается KiFastSystemCallRet? Как раз нет. После SYSENTER идет переход в r0 и EIP меняется на значение определенное в MSR - а именно на KiFastCallEntry в ядре.

beginner
Вам не надо все эти статьи для решения проблемы, учитывая что Вы в этой теме еще не разбирались. Просто возьмите RootkitUnhooker и NIAT AntiRootkit Tools - http://www.rootkit.com/vault/uty/NIAPAntiRootkitTools.rar и посмотрите что похукано вашей жертвой и сделайте противоядие. А то я понимаю так, что надо свой RKU изобретать, но прога ведь конкретная и у нее если есть способы противодействия чтению/записи, то они тоже конкретные. Ну можно и IDA заюзать, хотя тут она может понадобится в последнюю очередь.

 

EvilPhreak, при всем уважении к вам вынужден нифига не согласицо. возврат из sysenter происходит в функцию KiFastSystemCallRet

речь идет как раз о возврате из r0 в r3

йа даж сделол программу на одну строчку

Код (Text):

1. sysenter

открыл в олли поставил бряк на KiFastSystemCallRet, нажал f9 и о чудо, бряк сработал...

 

а почему не KiFastSystemCall?