Как обнаружить API-крючок?

Я пытался обнаружить крюк API, встроенный и EAT-крючок.Как обнаружить API-крючок?

На данный момент я не нашел ничего о том, как обнаружить крючок EAT.

Для Инлайн Ring 3 крючка, что я до сих пор:

FARPROC Address = GetProcAddress(GetModuleHandle("kernel32.dll"),"ExitProcess"); 
if (*(BYTE*)Address == 0xE9 || *(BYTE*)Address == 0x90 || *(BYTE*)Address == 0xC3) 
{ 
printf("Api hooked\n"); 
}

Проблема заключается в том, что существует несколько опкодов, которые могут быть использованы для подключения/изменить вводные функции, проверка JMP/NOP/RET тривиально, я видел много типов HOOK, таких как PUSH RET, MOV, RETN и т. д.

Интересно, знает ли кто-нибудь, как обнаружить эти крючки (обходные пути) или модификации API. А также способ обнаружения крюка EAT.

спасибо.

источник

2017-02-09 yudoyo

Если кто-то подключил вашу программу, то они могут подключить ваш детектор крюка. –

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

GetProcAddress может быть подключен также. Кроме того, поскольку вы не могли знать точный API, который был бы исправлен, вам нужно будет проверить все импортированные функции, что довольно утомительно. Поскольку злоумышленник обладает достаточными привилегиями для ввода в адресное пространство вашего процесса и методов API-интерфейсов, честно говоря, почти не существует способа предотвратить его полностью исключить какой-либо механизм защиты. Обычно современные системы защиты программного обеспечения включают драйвер режима ядра, который сканирует память программ и предотвращает впрыскивание dll и удаленную память. Также довольно часто используют системы шифрования/обфускации кода (например, Themida) или даже внутренние машины виртуального исполнения с совершенно чуждыми наборами инструкций процессора, что делает исправление кода «на лету» довольно сложным.

источник

2017-02-09 03:50:47 Ari0nhh

Вы правы, конечно, но я видел довольно эффективные контрмеры - загружая Kernel32.dll вручную с диска, гарантируя, что файл подписан, а также сравнение инструкций и т. Д. Критических функций, таких как GetProcAddress. Если GPA подключен, им придется динамически отцеплять, прежде чем сравнивать данные, чтобы избежать обнаружения. После этого вы можете сравнить функции-инструкции-контрольные суммы с диска с памятью ... и т. Д. Но да, это игра с кошачьей мышью и не имеет дурака. –

Я считаю, вы должны сравнить kernel32.dll с диском с вашей текущей dll в памяти, также вы должны игнорировать IAT и исправлять перемещение, иначе вы получите разные хэши.

Если вы хотите, чтобы более простое решение просто переименовало kernel32.dll и вызовет вызовы API из переименованной библиотеки DLL.

источник

2017-02-09 13:56:40 arasoyo

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

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

источник

2017-04-10 18:44:04

ответ

Смежные вопросы