Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
Кафедра информационных технологий
КУРСОВАЯ РАБОТА
Мониторинга активности пользователя в ОС Windows XP
Работу выполнил ст. 4 курса, 44 гр. Гусаков А.А.
Специальность 010501.65 «Прикладная математика и информатика»
Научный руководитель к.ф.-м.н, старший преподаватель Подколзин В.В.
учен. степень, должность, Подпись дата
Краснодар 2013
Реферат
В курсовой работе 37 листов, 6 рисунков, 1 программное приложение.
Целью курсовой работы является разработка алгоритма мониторинга действий пользователя посредством глобального перехвата системных сообщений с помощь функций и процедур WinAPI.
В рамках курсовой работы были изучены различные методы обработки информации с интерактивных устройств ввода на примере клавиатуры и мышки. Рассмотрены методы перехвата системных сообщений посредством ловушек. Также были рассмотрены аспекты использования объектов файлового отображения и мьютексов.
Курсовая работа состоит из введения, трех глав, практической работы, заключения и списка литературы.
Ключевые слова курсовой работы: МОНИТОРИНГ, KEYLOGGER,КЛАВИАТУРА, DLL, СИСТЕМНОЕ СООБЩЕНИЕ, BORLAND DELPHI.
СОДЕРЖАНИЕ
ВВЕДЕНИЕ..............................................................................................................4
Глава I. Методы и способы обработки клавиатурного ввода в OC Windows....................................................................................................................5
1.1 Принципы работы клавиатуры как физического устройства........................6
1.2 Низкоуровневое взаимодействие с клавиатурой через порты ввода-вывода.......................................................................................................................7
1.3 Архитектура «интерактивных устройств ввода»...........................................7
1.3.1 Стек драйверов для системных устройств ввода........................................8
1.3.2 Стек устройств для Plug and Play PS/2-клавиатуры..................................11
1.4 Обработка клавиатурного ввода приложениями..........................................12
1.4.1 Поток необработанного ввода ....................................................................12
1.4.2 Обработка сообщений конкретным окном................................................14
1.5 Массивы состояния клавиш клавиатуры......................................................15
1.6 Клавиатурные ловушки..................................................................................16
1.7 Общая схема обработки..................................................................................18
1.8 Модель прямого ввода (Raw Input)................................................................20
Глава II. Основные сведения о различных методах клавиатурного мониторинга...........................................................................................................21
2.1 Клавиатурные мониторинги программного типа.........................................21
2.2 Клавиатурные мониторинги аппаратного типа............................................23
Глава III. Реализация глобального мониторинга активности пользователя
в ОС Windows XP .................................................................................................26
3.1 Назначение и функции программы ...............................................................26
3.2 Структура программного приложения..........................................................26
3.3 Виртуальная память .......................................................................................28
3.4 Мьютекс...........................................................................................................29
3.5 Описание блоков программного приложения..............................................31
ЗАКЛЮЧЕНИЕ.....................................................................................................36
СПИСОК ЛИТЕРАТУРЫ....................................................................................37
ВВЕДЕНИЕ
С начала 21 века проблема информационного шпионажа особенно остро проявилась в сфере информационных технологий. С ростом и развитием отрасли IT-технологий наибольшее внимание разработчиков Антивирусных программ вызывает класс вирусов – Keylogger .
Keylogger — программное обеспечение, основным назначением которого является скрытый мониторинг действий пользователя и ведение журнала. В качестве кейлоггеров может использоваться как программное обеспечение, так и аппаратные средства.
Данная технология используется как в виде мониторинговых программ, так и программ незаконного слежения. Она позволяет отслеживать нажатия клавиш клавиатуры, вести журнал запускаемых и закрываемых приложений, нажатие клавиш компьютерной мыши и многое другое.
Глава I. Методы и способы обработки клавиатурного ввода в OC Windows
1.1. Принципы работы клавиатуры как физического устройства
В настоящее время большинство клавиатур выполнено в виде отдельного устройства, подключаемого к компьютеру с помощью одного из разъемов, чаще всего PS/2 или USB. Существуют два микроконтроллера, обеспечивающие процесс обработки клавиатурного ввода: один — на материнской плате ПК, второй — в самой клавиатуре. Таким образом, клавиатура персонального компьютера сама по себе является компьютерной системой. Она построена на основе микроконтроллера 8042, который постоянно сканирует нажатия клавиш на клавиатуре — независимо от активности на центральном процессоре x86.
За каждой клавишей клавиатуры закреплен определенный номер, однозначно связанный с распайкой клавиатурной матрицы и не зависящий напрямую от обозначений, нанесенных на поверхность клавиш. Этот номер называется скан-кодом (название подчеркивает тот факт, что компьютер сканирует клавиатуру для поиска нажатой клавиши). Скан-код — это случайное значение, выбранное IBM еще тогда, когда она создавала первую клавиатуру для ПК. Скан-код не соответствует ASCII-коду клавиши, одной и той же клавише могут соответствовать несколько значений ASCII-кода.
На самом деле клавиатура генерирует два скан-кода для каждой клавиши — когда пользователь нажимает клавишу и когда отпускает. Наличие двух скан-кодов важно, так как некоторые клавиши имеют смысл только тогда, когда они нажаты (Shift, Control, Alt).
При нажатии клавиши на клавиатуре происходит замыкание электрического контакта (см. рис.1). В результате при следующем сканировании микроконтроллер фиксирует нажатие определенной клавиши и посылает в центральный компьютер скан-код нажатой клавиши и запрос на прерывание. Аналогичные действия выполняются и тогда, когда оператор отпускает нажатую ранее клавишу.
Рисунок 1. Микросхема Клавиатуры
Второй микроконтроллер получает скан-код, производит преобразование скан-кода, делает его доступным на порту ввода-вывода 60h и затем генерирует аппаратное прерывание центрального процессора. После этого процедура обработки прерывания может получить скан-код из указанного порта ввода-вывода.
Следует также отметить, что клавиатура содержит внутренний 16-байтовый буфер, через который она осуществляет обмен данными с компьютером
1.2. Низкоуровневое взаимодействие с клавиатурой через порты ввода-вывода
Взаимодействие с системным контроллером клавиатуры происходит через порт ввода-вывода 64h. Считав байт из этого порта, можно определить статус контроллера клавиатуры, записав байт — послать контроллеру команду.
Взаимодействие с микроконтроллером в самой клавиатуре происходит с помощью портов ввода-вывода 60h и 64h. Биты 0 и 1 в байте статуса (порт 64h в режиме чтения) предоставляют возможность управлять процедурой взаимодействия: перед записью данных в эти порты бит 0 порта 64h должен быть выставлен в 0. Когда данные доступны для чтения из порта 60h, бит 1 порта 64h равен 1. Биты включения/выключения клавиатуры в командном байте (порт 64h в режиме записи) определяют, является ли клавиатура активной, и будет ли контроллер клавиатуры вызывать прерывание в системе, когда пользователь нажмет клавишу.
Байты, записанные в порт 60h, посылаются контроллеру клавиатуры, а байты, записанные в порт 64h, посылаются системному контроллеру клавиатуры. Списки разрешенных команд, которые можно послать контроллеру клавиатуры, представлены в двадцатой главе книги «The Art of Assembly Language Programming».
Байты, считываемые из порта 60h, приходят от клавиатуры. Порт 60h при чтении содержит скан-код последней нажатой клавиши, а в режиме записи он используется для расширенного управления клавиатурой. При использовании порта 60h на запись программа дополнительно получает следующие возможности:
Необходимо отметить, что для чтения данных, вводимых с клавиатуры, достаточно уметь считывать значения портов ввода-вывода 60h и 64h. Однако в ОС Windows приложениям пользовательского режима запрещено работать с портами, поэтому эту задачу выполняют драйвера операционной системы.
1.3.Архитектура «интерактивных устройств ввода»
В ОС Windows обработку аппаратного прерывания, которое генерируется при появлении в порту 60h данных, полученных от клавиатуры, производит драйвер i8042prt.sys, он же зарегистрировал процедуру обработки аппаратного прерывания клавиатуры IRQ1. В отличие от времен MS DOS, когда каждый системный компонент был как бы «сам по себе», в Windows все компоненты построены согласно четкой архитектуре и работают по строго определенным правилам, закрепленным программными интерфейсами. Поэтому перед тем как приступить к рассмотрению драйвера i8042prt, мы рассмотрим архитектуру интерактивных устройств ввода, в рамках которой функционируют все программные компоненты, связанные с обработкой клавиатурного (и «мышиного») ввода.
Устройства, используемые для прямого управления операциями на компьютере, в ОС Windows называются интерактивными устройствами ввода. Клавиатура является одним из таких устройств, наряду с манипулятором «мышь», джойстиками, трекболами, игровыми педалями, колесами, шлемами виртуальной реальности и др.
Архитектура управления интерактивными устройствами ввода базируется на стандарте USB Human Interface Device (HID), предложенном организацией USB Implementers Forum. Однако архитектура не ограничена только USB-устройствами и поддерживает другие типы устройств ввода, в частности, bluetooth-клавиатуру, клавиатуру и мышь, подключаемые по PS/2 порту, а также устройства, подключаемые по игровому порту (I/O port 201).
Далее мы рассмотрим принципы построения стека драйверов и стека устройств для PS/2-клавиатур, так как исторически они являются первый типом устройств. USB-клавиатуры используют ряд элементов, введенных при разработке программной поддержки PS/2-клавиатур.
1.3.1Стек драйверов для системных устройств ввода
Драйвера клавиатуры, независимо от схем физического подключения, используют системные драйвера класса клавиатуры для обработки не зависимых от аппаратной части операций. Данные драйвера называются драйверами класса, так как обеспечивают требуемые системой, но не зависимые от аппаратной реализации требования к конкретному классу устройств.
Соответствующий функциональный драйвер (драйвер порта) реализует зависимую от конкретного устройства поддержку выполнения операций ввода-вывода. В ОС Windows для x86-платформ реализован единый драйвер системной клавиатуры (i8042) и мыши.
Рисунок 2. Стек драйверов для Plug and Play PS/2-клавиатур
Стек драйверов содержит (сверху вниз) (см. рис.2):
1. Kbdclass — верхнеуровневый фильтр-драйвер класса клавиатуры;
2. опциональный верхнеуровневый фильтр-драйвер класса клавиатуры;
3. i8042prt — функциональный драйвер клавиатуры;
4. корневой драйвер шины.
В ОС Windows 2000 и старше драйвером класса клавиатуры является драйвер Kbdclass, основными задачами которого являются:
В ОС Windows 2000 и старше функциональным драйвером для устройств ввода, использующих PS/2-порт (клавиатуры и мыши), является драйвер i8042prt, основные функции которого следующие:
Список аппаратных ресурсов, используемых драйвером i8042prt:
В показанном драйверном стеке новый драйвер-фильтр может быть добавлен, например, для специфичной обработки клавиатурного ввода поверх драйвера класса клавиатуры. Данный драйвер должен поддерживать ту же обработку всех типов запросов ввода-вывода и управляющих команд (IOCTL), что и драйвер класса клавиатуры. В этом случае перед передачей в подсистемы пользовательского режима данные будут отданы на обработку в этот драйвер-фильтр.
1.3.2. Стек устройств для Plug and Play PS/2-клавиатуры
Рисунок 3. Стек устройств для Plug and Play PS/2-клавиатуры
Рассмотрим теперь стек устройств, которые создают указанные выше драйвера в драйверном стеке клавиатуры. На рис.3 изображен стек устройств, приведенный в MSDN Library для PS/2-клавиатуры.
В целом стек устройств (правильнее говорить о стеке объектов устройств) PS/2-клавиатуры состоит из:
1. физического объекта устройства клавиатуры (PDO), созданного драйвером шины;
2. функционального объекта устройства клавиатуры (FDO), созданного и присоединенного к PDO драйвером i8042prt;
3. опциональных фильтр-объектов устройства клавиатуры, создающихся фильтр-драйверами клавиатуры, разрабатываемыми сторонними разработчиками;
4. верхнеуровневого фильтр-объекта устройства класса клавиатуры, созданного драйвером класса Kbdclass;
1.4. Обработка клавиатурного ввода приложениями
1.4.1. Поток необработанного ввода
В предыдущем разделе мы наблюдали примеры построения клавиатурных стеков в режиме ядра операционной системы. Теперь мы рассмотрим, как происходит передача информации о нажатии клавиш приложениям пользовательского режима.
Подсистема 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.
Рисунок 4. Поток необработанного ввода
RIT обрабатывает поступившую информацию по следующему принципу(рис.4). Все пришедшие клавиатурные события помещаются в системную очередь аппаратного ввода, после чего они последовательно преобразуются в сообщения 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.
1.4.2. Обработка сообщений конкретным окном
Стандартный цикл обработки сообщений обычно выглядит следующим образом:
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. Образованные символьные сообщения помещаются в очередь сообщений приложения, причем оригинальные клавиатурные сообщения из этой очереди не удаляются.
1.5. Массивы состояния клавиш клавиатуры.
Одной из задач при разработке модели аппаратного ввода Windows было обеспечение ее отказоустойчивости. Отказоустойчивость обеспечивается независимой обработкой ввода потоками, что предотвращает неблагоприятное воздействие одного потока на другой. Но этого недостаточно для надежной изоляции потоков друг от друга, поэтому система поддерживает дополнительную концепцию — локальное состояние ввода. Каждый поток обладает собственным состоянием ввода, сведения о котором хранятся в структуре THREADINFO. В информацию об этом состоянии включаются данные об очереди виртуального ввода потока, а также группа переменных. Последние содержат управляющую информацию о состоянии ввода. Относительно клавиатуры поддерживаются следующие сведения: какое окно находится в фокусе клавиатуры, какое окно активно в данный момент, какие клавиши нажаты, каково состояние курсора ввода.
Информация о том, какие клавиши нажаты, сохраняется в массиве синхронного состояния клавиш. Этот массив включается в переменные локального состояния ввода каждого потока. В то же время массив асинхронного состояния клавиш, в котором содержится аналогичная информация, — только один, и он разделяется всеми потоками. Массивы отражают состояние всех клавиш на данный момент, и функция GetAsyncKeyState позволяет определить, нажата ли сейчас заданная клавиша. GetAsyncKeyState всегда возвращает 0 (не нажата), если ее вызывает другой поток, а не тот, который создал окно, находящееся сейчас в фокусе ввода.
Функция GetKeyState отличается от GetAsyncKeyState тем, что возвращает состояние клавиатуры на тот момент, когда из очереди потока извлечено последнее сообщение от клавиатуры. Эту функцию можно вызвать в любой момент; для нее неважно, какое именно окно в фокусе.
1.6. Клавиатурные ловушки
В операционной системе Microsoft Windows ловушкой, или хуком (hook) называется механизм перехвата событий с использованием особой функции (таких как передача сообщений Windows, ввод с мыши или клавиатуры) до того, как они дойдут до приложения. Эта функция может затем реагировать на события и, в некоторых случаях, изменять или отменять их.
Функции, получающие уведомления о событиях, называются фильтрующими функциями и различаются по типам перехватываемых ими событий. Для того чтобы Windows смогла вызывать функцию-фильтр, эта функция должна быть прикреплена к хуку (например, к клавиатурному хуку). Прикрепление одной или нескольких фильтрующих функций к какому-нибудь хуку называется установкой хука. Для установки и удаления фильтрующих функций приложения используют функции Win32 API SetWindowsHookEx и UnhookWindowsHookEx. Некоторые хуки можно устанавливать как для всей системы, так и для одного конкретного потока.
Если к одному хуку прикреплено несколько фильтрующих функций, Windows реализует очередь функций, причем функция, прикрепленная последней, оказывается в начале очереди, а самая первая функция — в ее конце. Очередь функций-фильтров (см. рис.5) поддерживается самой Windows, что позволяет упростить написание фильтрующих функций и улучшить производительность операционной системы.
Рисунок 5. Очередь функций-фильтров(хуков)
Система поддерживает отдельные цепочки для каждого типа хуков. Цепочка хуков — это список указателей на фильтрующие функции (специальные функции обратного вызова, определяемые приложением). Когда происходит некоторое событие, связанное с конкретным типом хука, система последовательно передает сообщение каждой фильтрующей функции в цепочке хуков. Действие, которое может выполнить фильтрующая функция, зависит от типа ловушки: некоторые функции могут только отслеживать возникновение событий, другие могут модифицировать параметры сообщений или даже остановить обработку сообщений, заблокировав вызов следующей фильтрующей функции в цепочке хуков или функции обработки сообщений окна-назначения.
Когда к хуку прикреплена одна или более функций-фильтров и происходит событие, приводящее к срабатыванию хука, ОС Windows вызывает первую функцию из очереди функций-фильтров, и на этом ее ответственность заканчивается. Далее функция ответственна за то, чтобы вызвать следующую функцию в цепочке, для чего используется функция Win32 API CallNextHookEx.
ОС поддерживает несколько типов хуков, каждый из которых предоставляет доступ к одному из аспектов механизма обработки сообщений Windows.
Для автора кейлоггера могут представлять интерес хуки почти всех типов: WH_KEYBOARD, WH_KEYBOARD_LL (перехват клавиатурных событий при добавлении их в очередь событий потока), WH_JOURNALRECORD и WH_JOURNALPLAYBACK (запись и воспроизведение клавиатурных и «мышиных» событий), WH_CBT (перехват множества событий, включая удаление клавиатурных событий из системной очереди аппаратного ввода), WH_GETMESSAGE (перехват событий, получаемых из очереди событий потока).
1.7. Общая схема обработки
Алгоритм прохождения сигнала от нажатия пользователем клавиш на клавиатуре до появления символов на экране можно представить следующим образом:
1.8. Модель прямого ввода (Raw Input)
Описанная выше модель клавиатурного ввода имеет ряд недостатков с точки зрения разработчиков приложений. Так, для получения ввода от нестандартного устройства приложение должно выполнить значительное число операций: открыть устройство, периодически его опрашивать, заботиться о возможности параллельного использования устройства другим приложением и т.д. Поэтому в последних версиях ОС Windows была предложена альтернативная модель ввода, названная моделью прямого ввода, упрощающая разработку приложений, использующих нестандартные устройства ввода (см. рисунок 3, приложения DirectInput).
Модель прямого ввода отличается от оригинальной модели ввода Windows. В обычной модели приложение получает устройство-независимый ввод в форме сообщений (таких как WM_CHAR), которые посылаются окнам приложения. В модели прямого ввода приложение должно зарегистрировать устройства, от которых оно хочет получать ввод. Далее приложение получает пользовательский ввод через сообщение WM_INPUT. Поддерживается два способа передачи данных — стандартный и буферизированный; для интерпретации введенных данных приложению нужно получить информацию о природе устройства ввода, что можно сделать с помощью функции GetRawInputDeviceInfo.
Глава II. Основные сведения о различных Методах клавиатурного мониторинга
2.1. Клавиатурные мониторинги программного типа
Клавиатурные шпионы (кейлоггеры) пользовательского режима — наиболее простые как для реализации, так и для обнаружения, поскольку для перехвата они используют вызовы известных и хорошо документированных функций программного интерфейса Win32 API.
Установка ловушки для клавиатурных сообщений
Данная методика является наиболее распространенной для клавиатурных шпионов, а суть ее заключается в применении механизма ловушек (hook) операционной системы. Ловушки позволяют наблюдать за сообщениями, которые обрабатываются окнами других программ. Установка и удаление ловушек производятся при помощи хорошо документированных функций библиотеки user32.dll (функция SetWindowsHookEx позволяет установить ловушку, UnhookWindowsHookEx — снять ее). При установке ловушки указывается тип сообщений, для которых должен вызываться обработчик ловушки. В частности, существует два специальных типа ловушек: WH_KEYBOARD и WH_MOUSE — для регистрации событий клавиатуры и мыши соответственно. Ловушка может быть установлена для заданного потока и для всех потоков системы, причем последнее очень удобно для построения клавиатурного шпиона.
Код обработчика событий ловушки должен быть расположен в DLL. Это требование связано с тем, что DLL с обработчиком ловушки проецируется системой в адресное пространство всех GUI(Graphical user interface) -процессов. Интересной особенностью является то, что проецирование DLL происходит не в момент установки ловушки, а при получении GUI-процессом первого сообщения, удовлетворяющего параметрам ловушки.
Методика ловушек весьма проста и эффективна, но у нее есть ряд недостатков. Одним из них можно считать то, что DLL с ловушкой проецируется в адресное пространство всех GUI-процессов, что может применяться для обнаружения клавиатурного шпиона. Кроме того, регистрация событий клавиатуры возможна только для GUI-приложений — это легко проверить при помощи демонстрационной программы.
Использование циклического опроса состояния клавиатуры.
Данная методика основана на периодическом опросе состояния клавиатуры. Для опроса состояния клавиш в системе предусмотрена специальная функция GetKeyboardState, возвращающая массив из 255 байт, в котором каждый байт содержит состояние определенной клавиши на клавиатуре. Данный метод уже не требует внедрения DLL в GUI-процессы, и в результате шпион менее заметен.
Однако изменение статуса клавиш происходит в момент считывания потоком клавиатурных сообщений из его очереди, поэтому подобная методика работает только для слежения за GUI-приложениями. Этого недостатка лишена функция GetAsyncKeyState, возвращающая состояние клавиши на момент вызова функции.
Внедрение в процесс и перехват функций Windows API.
Редко реализуемый метод реализации кейлоггера. Кейлоггер внедряется во все процессы и перехватывает в них функции GetMessage или PeekMessage (см. раздел «Обработка сообщений конкретным окном») из библиотеки user32.dll. Для этого могут быть использованы различные методы: сплайсинг (сплайсинг — метод, используемый для перехвата вызова API-функций; суть метода состоит в замене нескольких (обычно 5) первых байт функции инструкцией JMP, передающей управление коду-перехватчику), модификация таблицы адресов импортируемых функций IAT, перехват функции GetProcAddress, возвращающей адрес функции из загруженной динамической библиотеки. Кейлоггер может реализовываться в виде DLL или при помощи непосредственного внедрения кода в целевой процесс.
В результате получается следующее: когда приложение вызывает, к примеру, функцию GetMessage для получения следующего сообщения из очереди сообщений, этот вызов приходит в код перехватчика. Перехватчик вызывает исходную функцию GetMessage из user32.dll и анализирует возвращаемые результаты на предмет типа сообщений. При получении клавиатурного сообщения вся информации о нем извлекается из параметров сообщения и протоколируется кейлоггером.
К достоинствам следует отнести эффективность: ввиду малой распространенности метода лишь небольшое число программ позволяет находить подобные кейлоггеры; кроме того, против подобных кейлоггеров бесполезны стандартные экранные клавиатуры, так как посылаемые ими сообщения также перехватываются.
Недостатки: модификация таблицы IAT не гарантирует перехвата, т.к. адреса функций библиотеки user32.dll могут быть сохранены до того, как кейлоггер внедрился; сплайсинг имеет свои сложности, связанные, например, с необходимостью переписывать «на лету» тело функции.
2.2. Клавиатурные мониторинги аппаратного типа
Для поиска клавиатурных шпионов на домашнем компьютере вполне достаточно удостовериться в отсутствии программ-кейлоггеров. Но в корпоративной среде, в частности на компьютерах, применяемых для выполнения банковских операций, для проведения электронных торгов или для решения задач, связанных с обработкой секретных документов, имеется опасность применения аппаратных средств, предназначенных для регистрации вводимой с клавиатуры информации. Рассмотрим основные каналы утечки информации с точки зрения применения аппаратных средств.
Аппаратная закладка внутри клавиатуры
В любой клавиатуре обычно бывает много полостей, размер которых достаточен для размещения небольшой платы. Питание устройства и съем информации может производиться путем непосредственного подключения к печатной плате контроллера клавиатуры. Аппаратная закладка может быть установлена вручную или промышленным способом.
Считывание данных с кабеля клавиатуры бесконтактным методом
Данная методика предполагает считывание информации посредством бесконтактного датчика. Для установки такого устройства не требуется ни вскрытия клавиатуры, ни включения каких-либо устройств в разрыв кабеля. Бесконтактный аппаратный кейлоггер должен иметь автономное питание, а его устройство значительно сложнее, чем в случае непосредственного подключения. По внешнему виду подобное устройство может выглядеть как съемный фильтр помех, надеваемый на кабель.
Включение устройства в разрыв кабеля
Клавиатурные шпионы данного типа являются самыми распространенными и их легко как установить, так и обнаружить. Аппаратный кейлоггер выполняется в виде небольшого устройства, которое включается в PS/2- или USB-разъем компьютера, а клавиатура включается в разъем на корпусе кейлоггера. Для выполнения подобной операции не требуется никакой квалификации, причем подключение кейлоггера к USB-клавиатуре может производиться без выключения компьютера.
Аппаратный кейлоггер может выглядеть как фильтр помех или переходник. Устройство состоит из входных цепей, предназначенных для фильтрации помех и защиты устройства от перенапряжения, микроконтроллера с малым потреблением электроэнергии и Flash-памяти, предназначенной для хранения собираемой информации. Объем Flash-памяти варьируется от 32 Кбайт до десятков мегабайт; типичный объем — от 128 Кбайт до 2 Мбайт.
Аппаратная закладка внутри системного блока
Этот шпион не отличается по принципу действия от устройств типов закладки внутри клавиатуры и включения устройств в разрыв кабеля, но размещается внутри системного блока. Установить его может только специалист, причем для этого потребуется вскрытие корпуса.
Съем информации на основании анализа акустических и электромагнитных излучений
Уловить электромагнитное излучение клавиатуры на расстоянии весьма сложно (хотя теоретически и возможно), но уловить акустические шумы — на порядок проще. Даже при разговоре по телефону иногда можно отчетливо услышать, как собеседник вводит информацию на клавиатуре. Исследования специалистов в области безопасности показывают, что каждая клавиша при нажатии производит специфический звук, позволяющий идентифицировать нажимаемые клавиши.
Глава III. Реализация глобального мониторинга активности пользователя
в ОС Windows XP
3.1 Назначение и функции программы
В рамках данной курсовой работы, разрабатывается на языке высокого уровня программирования Borland Delphi 7 программное приложение, основной задачей которого является мониторинг действий пользователя в ОС Windows XP.
Данная программа имеет следующие функции и свойства:
3.2 Структура программного приложения
На рисунке 6 приведена блок-схема программного приложения.
Программа состоит из 4 отдельных модулей: клиентское приложение и три динамически подключаемых библиотеки (DLL).
Алгоритм работы программы осуществляется следующим образом:
Во время запуска клиентского приложения происходит активация процесса установки системных ловушек. Необходимым параметром реализации мониторинга является создание собственных фильтр-функций, по перехвату системных сообщений, которые реализованы в DLL. При обнаружении активности пользователя, программа внедряет копии DLL в адресное пространство каждого процесса, на котором проявилась активность. С этого момента действия пользователя в данном процессе сохраняются в базе данных.
Клиентское приложение
Key.dll
Proc.dll
Mouse.dll
Системная очередь сообщений
Действие пользователя
Процесс 1
Процесс 2
Процесс N
…
Mouse 1
Mouse 2
Key 1
Key 2
Proc 2
Мьютекс
Logfile.txt
Виртуальная память
Mouse N
Key N
Proc N
Proc 1
Рисунок 6.
3.3 Виртуальная память
Под памятью в ОС Windows подразумевается не только физическая память (ОЗУ), но также память, резервируемая операционной системой на жестком диске. Этот вид памяти называется виртуальной памятью и образует файл подкачки. По мере необходимости операционная среда обращается к этому файлу, чтобы поместить в него пока ненужные системе данные или наоборот считать в ОЗУ уже потребовавшиеся. WinAPI предоставляет способ работы с файлами подкачки посредством объекта файлового отображения.
Принцип файлового отображения является одним из основополагающих принципов работы с виртуальной памятью в Windows. С помощью техники файлового отображения можно создать область памяти, которая при нехватке физической памяти будет сбрасываться не в файл подкачки, а в какой-нибудь указанный нами файл. Таким образом, при изменении памяти, выделенной и спроецированной с помощью механизма отображения, содержимое файла тоже будет изменено.
Для создания объекта файлового отображения необходимо использовать WinAPI функцию CreateFileMapping. Она имеет следующий формат:
HANDLE CreateFileMapping(
HANDLE hFile,
LPSECURITY_ATTRIBUTES lpFileMappingAttributes,
DWORD flProtect,
DWORD dwMaximumSizeHigh,
DWORD dwMaximumSizeLow,
LPCTSTR lpName );
Функция WinAPI OpenFileMapping открывает существующий объект файлового отображения. Функция имеет следующий формат:
HANDLE OpenFileMapping(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
LPCTSTR lpName );
Для проецирования объекта файлового отображения на память необходимо использовать WinAPI функцию MapViewOfFile. Она имеет следующий формат:
LPVOID MapViewOfFile(
HANDLE hFileMappingObject,
DWORD dwDesiredAccess,
DWORD dwFileOffsetHigh,
DWORD dwFileOffsetLow,
DWORD dwNumberOfBytesToMap );
Функция WinAPI UnmapViewOfFile освобождает выделенную память для объекта файлового отображения. Функция имеет следующий формат:
BOOL UnmapViewOfFile(
LPVOID lpBaseAddress );
Для закрытия объекта файлового отображения необходимо использовать WinAPI функцию CloseHandle. Она имеет следующий формат:
BOOL CloseHandle(
HANDLE hFileMapObj );
Для помещения собранной информации в виртуальную память используем функцию CopyMemory.
3.4 Мьютекс
Во время работы мониторинга, DLL с фильтр-функцией проецируется системой в адресное пространство всех GUI процессов, где фильтр-функции собирают отслеживаемую информацию активности пользователя.
После получения информации нам необходимо поместить её в буфер, организованный в виде объекта файлового отображения. Но так как DLL спроецированы на адресные пространства процессов, и у каждого из них свои системные потоки, то для исключения ситуации асинхронного доступа к буферу памяти необходимо использовать обработчик критических секций. Заменой обработчика критических секций в «межпроцессорном масштабе» являются объекты взаимоисключения – мьютексы.
Мьютекс – одноместный семафор, служащий для синхронизации одновременно выполняющихся потоков. Мьютексы могут находиться в двух состояниях в захваченном и свободном. Также мьютексы, как и любые другие объекты в Windows, могут находиться в двух состояниях: сигнальном и несигнальном состоянии. Когда мьютекс захвачен каким-либо потоком, он находится в несигнальном состоянии, когда мьютекс свободен, он находится в сигнальном состоянии.
Для работы с Мьютексами в ОС Windows определены WinAPI функции:
Функция CreateMutex вызывается для создание мьютекса, её формат:
HANDLE CreateMutex(
LPSECURITY_ATTRIBUTES lpMutexAttributes,
BOOL bInitialOwner,
LPCTSTR lpName );
Функция OpenMutex используется для открытия существующего мьютекса, её формат:
HANDLE OpenMutex(
DWORD dwDesiredAccess,
BOOL bInheritHandle,
LPCTSTR lpName );
Для освобождения мьютекса использована функция ReleaseMutex, её формат:
BOOL WINAPI ReleaseMutex(
HANDLE hMute );
Для осуществления эксклюзивного доступа к буферу используем конструкцию:
WaitForSingleObject();
//код работающий с общими данными
ReleaseMutex();
Функция WaitForSingleObject ожидает, пока указанный объект находится в несигнальном состоянии или пока не истечет время ожидания, задерживая при этом выполнение потока в текущем процессе. При изменении объекта на сигнальное состояние, она получает доступ к буферу и устанавливает мьютекс в несигнальное состояние. Функция имеет следующий формат:
DWORD WaitForSingleObject(
HANDLE hHandle,
DWORD dwMilliseconds );
3.5 Описание блоков программного приложения
Клиентское приложение.
Данное приложение выполняет следующие действия:
Запуск и остановка процесса установки системных ловушек реализован в виде вызова процедур хранящихся в DLL:
Для запуска процесса мониторинга внутри вышеописанных процедур используется встроенная WinAPI функция SetWindowsHookEx, она имеет следующий формат:
HHOOK SetWindowsHookEx(
int idHook,
HOOKPROC lpfn,
HINSTANCE hMod,
DWORD dwThreadId );
Функция SetWindowsHookEx принимает параметр HINSTANCE, который является указателем на DLL, и HOOKPROC - указатель на фильтр-функцию.
HINSTANCE необходим, чтобы узнать какую DLL нужно загружать в каждый процесс. WinAPI функция внедряет указанную DLL в адресное пространство процесса, а затем вызывает фильт-функцию, описанную в этой DLL.
Необходимость расположения фильтр-функции в DLL объясняется тем, что DLL с фильтр-функцией проецируется системой в адресное пространство всех GUI процессов, что невозможно сделать c помощью exe приложения.
Параметр idHook определяет тип устанавливаемой фильтр-функции. В зависимости от типа перехватываемых сообщений оно принимает одно из следующих значений: WH_CBT, WH_MOUSE, WH_KEYBOARD.
Для остановки процесса мониторинга используется встроенная WinAPI функция UnhookWindowsHookEx, она имеет следующий формат:
BOOL UnhookWindowsHookEx(
HHOOK hhk );
Так как мониторинг осуществляет запись активности пользователя не прерывая системные действия, то внутри фильтр-функций при помощи WinAPI функции CallNextHookEx организована передача информации следующей системной ловушке. Функция имеет следующий формат:
LRESULT CallNextHookEx(
HHOOK hhk,
int nCode,
WPARAM wParam,
LPARAM lParam );
Процесс создания объекта файлового отображения и создание мьютекса выполнен перед вызовом процедур из DLL, при помощи соответствующих функций, описанных в главах 3.3 и 3.4.
Также в клиентском приложении описана процедура DumpBufferMapping, которая выполняет функцию вывода информации из буфера в БД, которая представлена текстовым файлом. Внутри процедуры использованы WinAPI функции:
Подключение к объекту объекту файлового отображение внутри всех DLL организовано в момент проецирования копии DLL на адресное пространство всех процессов. Для этого использована функция DLLEntryPoint – функция точки входа, которая получает в качестве параметра следующие значения:
Буффер памяти имеет ограниченный объем, вследствие этого внутри DLL организован вывод информации из буфера в БД, посредством процедуры DumpBufferMapping.
«HookDllKey.dll».
В данной DLL описана фильтр-функция KeyHook. Каждый раз при появлении в системном потоке процесса, в адресное пространство которого была помещена копия соответствующей DLL, сообщения от клавиатуры, WM_KEYUP или WM_KEYDOWN, вызывается функция KeyHook которая занимается обработкой сообщения и получения из него необходимой информации.
Внутри данной функции используются WinAPI функции GetKeyboardState, ToAscii, GetKeyNameText.
GetKeyboardState – служит для опроса состояния клавиш, а также возвращает массив из 255 байт, в котором каждый байт содержит состояние определенной клавиши на клавиатуре.
ToAscii – транслирует заданный код виртуальной клавиши и состояние клавиатуры в соответствующий символ или символы. Функция транслирует код, используя язык ввода данных и физическую раскладку клавиатуры, идентифицированную дескриптором раскладки клавиатуры.
GetKeyNameText – извлекает строку, которая представляет название клавиши, по скан-коду переданному в качестве параметра.
HookDllProc.dll.
В данной DLL описана фильтр функция ProcHook. Система вызывает эту фильтр-функцию перед активизацией, созданием, разрушением, уменьшением, увеличением окна или перед настройкой фокуса клавиатуры:
Внутри фильтр-функции ProcHook используется встроенная WinAPI функция GetWindowText, которая позволяет узнать текст заголовка используемого окна.
HookDllMouse.dll.
В данной DLL описана фильтр функция MouseHook. Система вызывает эту функцию всякий раз для обработки сообщений поступающих от компьютерной мыши:
ЗАКЛЮЧЕНИЕ
Изучены принципы работы клавиатуры и архитектура «интерактивных устройств ввода». Подробно разобран перехват и обработка системных сообщений приложениями на основе функций и процедур Windows API. Рассмотрены аспекты использования обработчика критических секций и объектов файлового отображения.
На программном языке Borland Delphi 7 разработано программное приложение, выполняющее функции мониторинг активности пользователя. Программа относится к виду кейлоггеров с установкой глобальных ловушек для системных сообщений.
Перспективное направление в работе – дальнейшее исследование способов перехвата системных сообщений и модификация программного приложения мониторинга для ОС Windows 7 и Windows 8.
СПИСОК ЛИТЕРАТУРЫ