Здравствуйте
Собственно вопрос. Как можно защитить программу от внедрения в ее процесс. От dll hook'ов.
Подкиньте теорию, можно примеры реализации, желательно на Delphi
С уважением

| Сообщение посчитали полезным:

Qwatr
К примеру перехватить ZwOpenProcess и большенство прог обламается.

| Сообщение посчитали полезным:

PS: еще вопрос, к примру есть у нас запущенная программа А. Есть такая программа ArtMoney, так вот какие есть способы защиты от memory injecting, программы А

| Сообщение посчитали полезным:

И еще вопрос
Можно ли сделать так: поставить хук
function SetWindowsHookEx(idHook: integer; lpfn: TFNHookProc; hmod: HINST; dwThreadID: DWORD): HHOOK; stdcall;
idHook - WH_DEBUG. Фу-ия будет вызываться каждый раз перед любым хуком, а там уже прибивать ненужные процессы?

| Сообщение посчитали полезным:

xShadow
для перехвата обязательно драйвер писать?

| Сообщение посчитали полезным:

Qwatr Дело в том, что способов внедрения в чужой процесс - тонна, тебе надо защититься от всех, или только от каких-то конкретных способов? Запсись в адресное пространство можно отбить, если перехватить ZwWriteVirtualMemory, но для этого надо писать драйвер, который будет патчить Service Descriptor Table

-----
Research is my purpose

| Сообщение посчитали полезным:

Error_Log пишет:
Запсись в адресное пространство можно отбить, если перехватить ZwWriteVirtualMemory, но для этого надо писать драйвер, который будет патчить Service Descriptor Table
Этого мало, надо ещё ZwCreateRemoteThread ловить. Только вот от драйвера или подсовывания левой DLL при старте процесса это не спасёт.

| Сообщение посчитали полезным:

Error_Log А перехватом Read/WriteProcessMemory можно обойтись?

| Сообщение посчитали полезным:

Error_Log насчет защиты от внедрения в процесс, вопрос пока отпадает, буду теорию читать пока
А вот насчет вопроса по поводу записи в адресное пространство ... Есть ли способы попроще? И собственно говоря, какие методы существуют записи в адресное пространство?

| Сообщение посчитали полезным:

Без драйвера я только один способ вижу - постоянно проверять контрольную сумму важного участка кода, сделать эту проверку как можно незаметнее. А чтоб запретить работу API WriteProcessMemory это не реально с третьего кольца что-то сделать.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Ну если только от артмани, просто создай поток, который каждые 1-2 секунды проверяет контрольную сумму блока памяти где переменные лежат, если она изменилась, ExitProcess и всё тут.

| Сообщение посчитали полезным:

Qwatr

dragon дело говорит - имхо это самое простое решение.

-----
Research is my purpose

| Сообщение посчитали полезным:

dragon пишет:
каждые 1-2 секунды проверяет контрольную сумму блока памяти где переменные лежат, если она изменилась, ExitProcess
Так на то они и переменные ;) Ты наверное хотел сказать, что перед каждой официальной модификацией памяти подсчитывать CRC? А ещё можно шифровацца и по обращению - decrypt, по окончанию - encrypt

-----
Я медленно снимаю с неё UPX... *FF_User*

| Сообщение посчитали полезным:

AlexZ пишет:
Ты наверное хотел сказать, что перед каждой официальной модификацией памяти подсчитывать CRC?
Ну естесственно, только не перед а после А с шифрованием это ещё удобнее, особенно если с объектами на C++ прога пишется, но от проверки CRC отказываться не стоит.

| Сообщение посчитали полезным:

Еще можно искать в памяти процесс ArtMoney и завершать его - это еще проще. Или стандартно:

hwnd = FindWindow("Artmoney",vbNullString)
DestroyWindow(hwnd)

-----
Никогда не делай то, что возможно. Стремись сделать то что невозможно впринципе!

| Сообщение посчитали полезным:

GPcH
А его возьмут и переименуют.

| Сообщение посчитали полезным:

Qwatr
Изврат: храни в переменных поксоренные значения.

| Сообщение посчитали полезным:

еще можно перехватить LdrLoadDll()
из ntdll.dll и не грузить левые dll.

| Сообщение посчитали полезным:

Проще прятать значения переменных, шифруй их или храни в памяти MEM_VALUE = VALUE_ON_DISPLAY + 1, а при выводе VALUE_ON_DISPLAY = MEM_VALUE - 1
Простенькая, но защита

-----
Недостаточно только получить знания:надо найти им приложение

| Сообщение посчитали полезным:

2Rascal и др.
Ну так нужно защитить не "мою" программу, а совершенно другую, которую "моя" программа будет искать по названию окна(к примеру)

| Сообщение посчитали полезным:

Qwatr
Ты прямо как агент ФСБ, какие то X с Y придумал и всех просишь, что бы отгадали кто это такие
А на счет “dll hook'ов” ты уверен, что там им место для применения нашлось?
(они имеют место не стабильно работать и в шароварных прогах их мало кто применяет разве что только в…)
Вообще есть такое понятие “цепочка hook'ов ” последний который устоновлен (имею в виду системный) тот самый и главный!
Если ты уверен, что твой самый главный значит, ставь свой hook.
И самое главное не применяй CallNextHookEx! Эта функция разрешает обработку других hook'ов.
(представь, если такой метод применяется в этой проге которую ты юзаешь, а она возьмет, да и твой процесс прибьет, в общем, делай сам выводы!)
Это тебе ответ на твой вопрос:

Можно ли сделать так: поставить хук
function SetWindowsHookEx(idHook: integer; lpfn: TFNHookProc; hmod: HINST; dwThreadID: DWORD): HHOOK; stdcall;
idHook - WH_DEBUG. Фу-ия будет вызываться каждый раз перед любым хуком, а там уже прибивать ненужные процессы?

По названию окна не советую искать программу.

Идентичная тема уже такая была и по этому на мысль наталкивает, что ты тут запостился и дальше этого поста не видишь!
Интересно, что ты от других ждешь?
Поиск рулит в данном случае! www.wasm.ru/article.php?article=apihook_1

-----
ЗЫ: истЕна где-то рядом, Welcome@Google.com

| Сообщение посчитали полезным:

Qwatr
Короче сплась Read&Write. От артмани поможет

-----
Недостаточно только получить знания:надо найти им приложение

| Сообщение посчитали полезным: