Ключевой момент такой: API_FUNC_stub: push func_id ;5 байт jmp hook_prologue ;5 байт Для нормальной работы API функции сперва нужно восстановить первые 10 байт. Я делаю это по заранее сохраненным первым 10 байтам. И пишу в начало перехватываемой функции при помощи WriteProcessMemory. После вызова, опять, патчу начало функции. Так вот вопрос: Как перехватить вызов самой WriteProcessMemory. Т.к. она не сможет восстановить сама себя. (Получается зацикливание) Конечно можно не патчить её изначально , но из-за этого её вызовы не будут отслеживаться ;(((
Конечно, слышал. Этот метод негодится. Т.к. не позволяет ставить хук на функции которых нет в таблице импорта...
В таблице какого модуля нет функции? WriteProcessMemory -> NtWriteVirtualMemory Можно смело ловить NtWriteVirtualMemory а она импортируется kernel32.dll
>>Как перехватить вызов самой WriteProcessMemory. Патчи свою таблицу импорта. >>сохраненным первым 10 байтам Существуют функции размером меньше 10 байт. >>После вызова, опять, патчу начало функции. А если произошло переключение контекста и эта функция была вызванна ещё и другим приложением, пока ты не записал снова джамп в начало. Или ты пишешь хук для одной проги?
Вроде разобрался. Заглушка теперь не 10, а 5 байтов. А в память процесса пишу при помощи NtWriteVirtualMemory
Только Код (Text): "WriteProcessMemory tries to modify the protection on the virtual memory to ensure that write access is granted and flushes the instruction cache after the write (by calling ZwFlushInstructionCache)" Поэтому лучше посмотреть код WriteProcessMemory и попробовать написать аналог, заюзав дополнительно NtProtectVirtualMemory, хотя может и не нужно, если не важно отработает функция или нет.
Есть способ патчинга таблицы экспорта библиотеки. Он достаточно надёжен. Если библиотека подгружается динамически перехватывай функцию LdrLoadDll из ntdll.dll.
Спасибо за разъяснения. Буду писать шпион дальше. Как только напишу, так выложу для тестирования. Шпион получается очень интересный. Есть возможность подключения собственных плагинов и перехвата собственных функций из собственных dll. Нужно только добавить ее в базу. Ну в общем как напишу, так выложу на суд.
Неустраивает BoundsCheckер (Работает как отладчик, работает долго итп...) Пишу свой, чтобы был таким, какой хочу. PS что за autodebug такой?????
А если в то время как ты убрал хук что бы вызвать оригинальную функцию, например, другой треад вызовет ту же функцию, то твой хук не сработает
Tellur Поэтому хуки, если по уму, никто и никогда не снимает, в драйверах чаще всего так, т.е. хукающие драйверы делают невыгружаемыми. Процедура обработки хука должна быть прозрачна для всего того что ей не требуется отлавливать, а обрабатывать только то для чего собсно ставился хук.
Тут еще один интересный момент есть с хуками: Допустим у нас все хуки ссылаются на один обработчик, где это дело обрабатывается (определяется хукнутая функция а эта функция вызывает другую - в результате получим, что обработчик вызовется дважды. А если используются глобальные переменные, то второй вызов затерет значения первого, получится полная х. Один (нелучший) способ - восстановить все функции при работе обработчика, чтобы небыло повторного вхождения. Но тогда не будут учитываться вызовы функций из других потоков. А чтобы вызывать только из нашего потока, для обработчика можно использовать критическую секцию. Есть варианты???
