Comments 9
я так понимаю, вы эту мухобойку не только на лягушках применяете ;)
Как все сложно в MHook, с madCHook было все намного проще.
Не слышал. Можете пример привести? Ну, и не исключено, что я усложняю.
Основной плюс madCHook от других библиотек в том что она сама генерирует трамплин для функции. Это очень удобно когда необходимо перехватывать множество функций.
Вот пример перехвата на Delphi (на C++ примерно также)
TerminateProcessCallback — наша функция обработчик перехваченной функции TerminateProcess.
TerminateProcessNext — указатель на оригинальный метод TerminateProcess
Взято от сюда help.madshi.net/HowToUseMadCodeHook.htm
Библиотека madCHook (http://madshi.net/) раньше была вообще бесплатной, а теперь уж платная.
Вот пример перехвата на Delphi (на C++ примерно также)
HookAPI('kernel32.dll', 'TerminateProcess', @TerminateProcessCallback, @TerminateProcessNext);
TerminateProcessCallback — наша функция обработчик перехваченной функции TerminateProcess.
TerminateProcessNext — указатель на оригинальный метод TerminateProcess
Взято от сюда help.madshi.net/HowToUseMadCodeHook.htm
Библиотека madCHook (http://madshi.net/) раньше была вообще бесплатной, а теперь уж платная.
Сам то хук — дело техники.
Вот гораздо интереснее найти минимально интрузивный способ попасть в адресное пространство нужного процесса.
В своё время собаку съел на плагине для OE/WM (outlook express и позже windows mail). Увлекательнейшее занятие! Очень не хотелось идти проторенной дорожкой и вешать постоянно висящий в памяти процесс-хукер. И ведь есть же решение, которое заставляет указанные бинари загрузить именно Вашу библиотеку к себе в семейство!
(ну а дальше рутина — хуки на оконные процедуры, хуки на интерфейсы — обычная жуть).
Вот гораздо интереснее найти минимально интрузивный способ попасть в адресное пространство нужного процесса.
В своё время собаку съел на плагине для OE/WM (outlook express и позже windows mail). Увлекательнейшее занятие! Очень не хотелось идти проторенной дорожкой и вешать постоянно висящий в памяти процесс-хукер. И ведь есть же решение, которое заставляет указанные бинари загрузить именно Вашу библиотеку к себе в семейство!
(ну а дальше рутина — хуки на оконные процедуры, хуки на интерфейсы — обычная жуть).
Опять же madCHook позволяет инжектить DLL во все вновь запущенные процессы (можно указать маску в какие процессы инжектить) благодаря его KernelMode драйверу.
>вешать постоянно висящий в памяти процесс-хукер
Не совсем понял, а произвести инъекцию dll во время выполнения приложения, или, например, прописать ее в секции импорта исследуемого процесса было неприемлимо?
Не совсем понял, а произвести инъекцию dll во время выполнения приложения, или, например, прописать ее в секции импорта исследуемого процесса было неприемлимо?
Во время выполнения инъекцию должен будет сделать «кто-то» (тот же процесс-сторож. Свой или чужой — неважно). А изменение секции импорта — опять же, не бесследно (если патчить системный файл — это нарушение его подписи, а значит при определённой достаточно строгой настройке безопасности напряжёт сисадмина, может напрячь антивирус. А после прилетевшего от MS апдейда для этого файла так же напряжёт пользователя и через него вас). В общем — оба способа в принципе работают (например, nectra oeapi пользуется инъекцией через «сторожа») — но при этом как бы подчёркивают, что «вы здесь чужой».
Гораздо безболезненнее сделать так, чтобы чужой процесс сам загрузил вашу DLL как свою родную. Никаких сторожей, никаких инъекций. Но — требует времени для более детального исследования «жертвы» и нахождения этой самой волшебной пули в реестре или ФС.
Гораздо безболезненнее сделать так, чтобы чужой процесс сам загрузил вашу DLL как свою родную. Никаких сторожей, никаких инъекций. Но — требует времени для более детального исследования «жертвы» и нахождения этой самой волшебной пули в реестре или ФС.
Sign up to leave a comment.
MHook vs Zuma