Можно ли стандартными API написать AntiKeyLogger? Или хотя бы узнать чьи процессы имеют хук на клаву?? Есть ли уже готовые решения??
А как нибудь побыстрее?? Ситуация: сидит класс студентов. Подходит админ, вводит пароль. Надо чтобы перед вводом админ узнал из каких процессов поставлен хук.
Список хуков в системе, насколько я знаю, хранится где-то внутри user32.dll. Лично я бы решил эту проблему интерсептом SetWindowsHookEx, загружаться в процессы, которые юзают user32.dll можно через AppInit_Dlls. Не исключено также, что клава хукается с помощью драйвера- фильтра(сырцы подобного есть на sysinternals.com)
Если резюмировать методы и контрметоды, получится следующее: 1. Хук. Его можно словить с помощью отладочного хука или чего-то вроде моего AVZ. Библиотека слишком заметна и выдает его. Поведенческий анализатор в антикейлоггере AVZ по сути хукает кучу функиций и выводит в лог данные о их использованиии 2. Глобальный хук. Отличается от обычного тем, что обработчик может быть в теле EXE - принцип тот-же, но заметность меньше. Поймать сложнее - только глобальный перехват SetWindowsHookEx и мониторинг 3. Циклический опрос клавиатуры. Стандартным API не ловится, ловится перехватом функций, отвечающих за опрос клавиатуры и мониторингом 4. Драйвер-фильтр. Его можно изловить, изучив стек драйвера клавиатуры, но возможны ложные срабатывания 5. Подмена драйвера клавиатуры - ловится проверкой его ЭЦП по каталогу безопасности Microsoft 6. Кейлоггер-руткит UserMode. Идея - перехват API, отвечающего за получение сообщений - далее отфильтровываются сообщения типа "клавиатура" и дело в шляпе. Помогает даже от экранных клавиатур ... ловится антируткитом, который показывет перехваты в user32.dll 7. Ядреный кейлоггер-руткит. Аналог 6 в режиме ядра, поймать его сложно - нужно отслеживать перехваты в KeSDT Shadow и целостность ядреного кода По моей статистике в основном доминируют методы 1,2,3; реже - 4. Студент скорее всего применит метод 1, ибо его исходники лежат на каждом углу. Слудовательно, можно применить отладочный хук + контроль за левыми DLL, внедряющимися в GUI процессы, в большинстве случаев этого имхо достаточно
green_newbie Судя по "где-то внутри user32.dll" матчасть мы не знаем. Об основных методах известно заинтересованным, а вот новичкам можно почитать книгу того же Зайцева о руткитах либо о клавиатурных шпионах (в первой всё собрано в куче).
Уж извините, но стандартными Win32Api этот сделать не представляется возможным. Мелкомягкие такой интерфейс 3-ему кольцу не предоставили. То о чем Вы говорите, в полной мере, возможно лишь с уровня ядра. Когда-то данный вопрос уже обсуждался на форуме. Ответ следующий (привожу для W2k): 1) Получить KTEB 2) Получить THREADINFO (или как её называют _WIN32_THREAD – в Шрайбера). pThread = [KTEB + 124h] 3) Получить стуктуру десктопа DESKTOPINFO (недокументированна) pDesktopInfo = [pThread + 34h] 4) После чего получить доступ к масиву хуков HOOK установленных для даного потока pHook = (pDesktopInfo + 10h) + i*4 5) Имея в наличии хотя бы одну из стуктур HOOK можна пройтитсь по связанному списку для получения всех остальных. 6) Отбрасывая ненужные типы набрать список хуков для клавы с их хенделами, DLL или именем процесса, адресами процедур… 7) Становиться возможным закрывать “неугодные” хуки. Код (Text): Структура хука для W2k: typedef struct _OBJECT_USER_HOOK { DWORD dwHANDLE_HOOK; DWORD dwReference;//?? PDWORD unknow0; PDWORD DesktopObject; DWORD dwCurrentAddrStruct; DWORD uknow1; DWORD dwTypeHOOK; DWORD dwProccAddr; DWORD dwflags; DWORD dwIndexMasAtom; } OBJECT_USER_HOOK, *POBJECT_USER_HOOK, **PPOBJECT_USER_HOOK; P.S. Наведённый алгоритм не является единственным, возможен доступ к структуре хука другими способами, но только в ядре. Более того – в WinXP структуры, которые я называл, изменились. А значит – другие смещения. Что там в Winst-e я не интересовался.
