Клавиатурные шпионы (кейлоггеры) - Обработка клавиатурного ввода приложениями
ОГЛАВЛЕНИЕ
Обработка клавиатурного ввода приложениями
Поток необработанного ввода (получение данных от драйвера)
В предыдущем разделе мы наблюдали примеры построения клавиатурных стеков в режиме ядра операционной системы. Теперь мы рассмотрим, как происходит передача информации о нажатии клавиш приложениям пользовательского режима.
Подсистема Microsoft Win32 получает доступ к клавиатуре, используя поток необработанного ввода (Raw Input Thread, RIT), который является частью системного процесса csrss.exe. Операционная система при старте создает RIT и системную очередь аппаратного ввода (system hardware input queue, SHIQ).
RIT открывает объект «устройство» драйвера класса клавиатуры для эксклюзивного использования и с помощью функции ZwReadFile направляет ему запрос ввода-вывода (IRP) типа IRP_MJ_READ. Получив запрос, драйвер Kbdclass отмечает его как ожидающий завершения (pending), ставит в очередь и возвращает код возврата STATUS_PENDING. Потоку необработанного ввода приходится ждать завершения IRP, для чего используется вызов асинхронной процедуры (Asynchronous Procedure Call, APC).
Когда пользователь нажимает или отпускает одну из клавиш, системный контроллер клавиатуры вырабатывает аппаратное прерывание. Его обработчик вызывает специальную процедуру обработки прерывания IRQ 1 (interrupt service routine, ISR), зарегистрированную в системе драйвером i8042prt. Данная процедура считывает из внутренней очереди контроллера клавиатуры появившиеся данные. Обработка аппаратного прерывания должна быть максимально быстрой, поэтому ISR ставит в очередь вызов отложенной процедуры (Deferred Procedure Call, DPC) I8042KeyboardIsrDpc и завершает свою работу. Как только это станет возможно (IRQL понизится до DISPATCH_LEVEL), DPC будет вызвана системой. В этот момент будет вызвана процедура обратного вызова KeyboardClassServiceCallback, зарегистрированная драйвером Kbdclass у драйвера i8042prt. KeyboardClassServiceCallback извлечет из своей очереди ожидающий завершения запрос IRP, заполнит максимальное количество структур KEYBOARD_INPUT_DATA, несущих всю необходимую информацию о нажатиях/отпусканиях клавиш, и завершит IRP. Поток необработанного ввода пробуждается, обрабатывает полученную информацию и вновь посылает IRP типа IRP_MJ_READ драйверу класса, который опять ставится в очередь до следующего нажатия/отпускания клавиши. Таким образом, у стека клавиатуры всегда есть по крайней мере один ожидающий завершения IRP, и находится он в очереди драйвера Kbdclass.
Рис. 6. Последовательность запросов от RIT к драйверу клавиатуры
С помощью утилиты IrpTracker, разработанной упоминавшейся ранее компанией Open Systems Resources, можно отследить последовательность вызовов, происходящих при обработке клавиатурного ввода.
Рис. 7. Обработка клавиатурного ввода в пользовательском режиме
Как же RIT обрабатывает поступившую информацию? Все пришедшие клавиатурные события помещаются в системную очередь аппаратного ввода, после чего они последовательно преобразуются в сообщения Windows (типа WM_KEY*, WM_?BUTTON* или WM_MOUSEMOVE) и ставятся в конец очереди виртуального ввода (virtualized input queue, VIQ) активного потока. В сообщениях Windows скан-коды клавиш заменяются на коды виртуальных клавиш, соответствующие не расположению клавиши на клавиатуре, а действию, которое выполняет эта клавиша. Механизм преобразования кодов зависит от активной раскладки клавиатуры, одновременных нажатий других клавиш (например, SHIFT) и других факторов.
Когда пользователь входит в систему, процесс Windows Explorer порождает поток, который создает панель задач и рабочий стол (WinSta0_RIT). Этот поток привязывается к RIT. Если пользователь запускает MS Word, то его поток, создавший окно, немедленно подключится к RIT. После этого поток, принадлежащий Explorer, отключается от RIT, так как единовременно с RIT может быть связан только один поток. При нажатии клавиши в SHIQ появится соответствующий элемент, что приведет к тому, что RIT пробудится, преобразует событие аппаратного ввода в сообщение от клавиатуры и поместит его в VIQ потока приложения MS Word.
Обработка сообщений конкретным окном
Как же поток обрабатывает сообщения от клавиатуры, попавшие в его очередь сообщений?
Стандартный цикл обработки сообщений обычно выглядит следующим образом:
while(GetMessage(&msg, 0, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
С помощью функции GetMessage события от клавиатуры извлекаются из очереди и перенаправляются с помощью функции DispatchMessage оконной процедуре, которая производит обработку сообщений для окна, где в данный момент сосредоточен фокус ввода. Фокус ввода — атрибут, который может присваиваться окну, созданному приложением или Windows. Если окно имеет фокус ввода, соответствующая функция этого окна получает все клавиатурные сообщения из системной очереди. Приложение может передавать фокус ввода от одного окна другому, например, при переключении на другое приложение с помощью комбинации Alt+Tab.
Перед функцией DispatchMessage обычно вызывается функция TranslateMessage, которая на основе сообщений WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP создает «символьные» сообщения WM_CHAR, WM_SYSCHAR, WM_DEADCHAR и WM_SYSDEADCHAR. Образованные символьные сообщения помещаются в очередь сообщений приложения, причем оригинальные клавиатурные сообщения из этой очереди не удаляются.
Массивы состояния клавиш клавиатуры
Одной из задач при разработке модели аппаратного ввода Windows было обеспечение ее отказоустойчивости. Отказоустойчивость обеспечивается независимой обработкой ввода потоками, что предотвращает неблагоприятное воздействие одного потока на другой. Но этого недостаточно для надежной изоляции потоков друг от друга, поэтому система поддерживает дополнительную концепцию — локальное состояние ввода. Каждый поток обладает собственным состоянием ввода, сведения о котором хранятся в структуре THREADINFO. В информацию об этом состоянии включаются данные об очереди виртуального ввода потока, а также группа переменных. Последние содержат управляющую информацию о состоянии ввода. Относительно клавиатуры поддерживаются следующие сведения: какое окно находится в фокусе клавиатуры, какое окно активно в данный момент, какие клавиши нажаты, каково состояние курсора ввода.
Информация о том, какие клавиши нажаты, сохраняется в массиве синхронного состояния клавиш. Этот массив включается в переменные локального состояния ввода каждого потока. В то же время массив асинхронного состояния клавиш, в котором содержится аналогичная информация, — только один, и он разделяется всеми потоками. Массивы отражают состояние всех клавиш на данный момент, и функция GetAsyncKeyState позволяет определить, нажата ли сейчас заданная клавиша. GetAsyncKeyState всегда возвращает 0 (не нажата), если ее вызывает другой поток, а не тот, который создал окно, находящееся сейчас в фокусе ввода.
Функция GetKeyState отличается от GetAsyncKeyState тем, что возвращает состояние клавиатуры на тот момент, когда из очереди потока извлечено последнее сообщение от клавиатуры. Эту функцию можно вызвать в любой момент; для нее неважно, какое именно окно в фокусе.