Взаимодействие драйвера и приложения

Оглавление

 

Введение

1. Аналитический раздел

1.1 Постановка задачи

1.2 Подсистема ввода-вывода

1.3 Драйверы режима ядра и средства их разработки

1.4 WDM драйверы и многослойная драйверная архитектура

1.5 Механизмы взаимодействия драйвера режима ядра и пользовательского приложения

2. Конструкторский раздел

2.1 Структура разрабатываемого программного продукта

2.2 Анализ и выбор алгоритма сокрытия данных

2.3 Описание функций драйвера

2.4 Описание функций пользовательского приложения

Взаимодействие драйвера и приложения

3. Технологический раздел

3.1 Выбор языка и среды программирования

3.2 Пользовательский интерфейс

3.3 Тестирование драйвера

Выводы

Список используемой литературы

 

Введение

 

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

Скрытие файлов в операционной системе Windows основано на перехвате обращений к файлам, что может осуществляться только резидентной программой. Сегодня распространено два подхода к решению данной задачи. Первый реализует программа Hide Folders XP: скрытие папок осуществляется с помощью специального драйвера, перехватывающего обращения к файловой системе. В программе доступно 3 режима защиты файлов и папок: скрывание, блокирование доступа и комбинированный режим (скрывание и блокирование доступа). Одним из недостатков подобных программ является возможность обойти защиту. Зачастую достаточно бывает перезагрузить систему в безопасный режим. Примером второго подхода, который позволяет решить эту проблему, может служить TrueCrypt. На жёстком диске программа создаёт файл-контейнер, всё содержимое которого зашифровано одним из выбранных криптографических алгоритмов.

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

 

Аналитический раздел

Постановка задачи

 

Основной целью проекта является разработка комплекса программных средств, осуществляющего скрытие файлов на компьютерах IBM PC, работающих под управлением операционной системы Windows XP.

Программный продукт должен обеспечивать удобный интерфейс для выбора скрываемого файла, и хранить в системе имена уже скрытых файлов и директорий. Выходными данными должна быть информация об успешном выполнении операции скрытия или описание произошедшей ошибки.

 

Подсистема ввода-вывода

 

Для реализации поставленной задачи необходимо отслеживать обращение к дискам. Существует несколько подходов к решению этой задачи. Один из подходов – это установление ловушек перехвата сообщений прежде чем они достигнут пользователя. Эта методика очень проста и эффективна, но имеет ряд недостатков, наиболее важный из которых – необходимость прав администратора для работы. Вторая методика – это написание драйвера-фильтра файловой системы, который будет перехватывать запрос обращения к директории и принимать действия в зависимости от внутренних данных и ассоциированных с файлом правил.

Работа с периферийными устройствами в ОС Windows возложена на подсистему ввода-вывода, которая состоит из служб режима пользователя и режима ядра, причем работа непосредственно с устройствами ведется в режиме ядра.

Приложения взаимодействуют с подсистемой ввода-вывода с помощью специальных системных вызовов, которые передают управления коду подсистемы ввода-вывода с учетом всех требований безопасности, и являются частью API исполнительной среды, например Win32.

 

Рис. 1. Схема обращения приложения к внешнему устройству

 

В результате системного вызова связанного с вводом-выводом в подсистеме ввода вывода создается пакет запроса ввода-вывода (IRP – Input/output Request Packet), хранящий информацию об операции, которую необходимо выполнить с устройством: чтение, запись или управление. Также IRP могут создаваться в результате обработки другого запроса одной из компонент подсистемы ввода-вывода. По завершении обработки IRP уничтожаются.

Центральное место в подсистеме ввода вывода занимает менеджер ввода-вывода, – специальная служба режима ядра, которая отвечает за координацию взаимодействия приложений и внешних устройств. В менеджер ввода-вывода передаются запросы из пользовательского режима. Он также координирует работу драйверов, работающих с конкретными типами устройств, которым он перенаправляет запросы ввода-вывода.

Нижележащим звеном в цепи, связывающей приложение с периферийным устройством, являются драйверы устройств режима ядра, – загружаемые модули режима ядра (как правило, это файл с расширением.sys), образующие интерфейс между диспетчером ввода-вывода и соответствующим оборудованием. Драйверы, как правило, поставляются с оборудованием, их набор в ОС не является постоянным. Хотя в состав операционной системы включены драйверы к наиболее распространенным устройствам, для обеспечения дополнительной функциональности зачастую необходимо разработать собственные драйверы.

 

Технологическая часть

Описание функций драйвера

 

Undocnt.h – заголовочный файл недокументированных функций и структур

Windwos NT, использованных в программе

Drvcomm.h – заголовочный файл определения структур

Структура буфера запроса о сокрытии файла

typedef struct_REQUEST_BUFFER { ULONG status;  // Статус выполнения struct {     WCHAR name[255]; // Имя (идентефикатор) запроса     BOOLEAN active; // Запрос активен / неактивен } protect_object; } REQUEST_BUFFER, * PREQUEST_BUFFER; Структура списка правил о сокрытии файла typedef struct_PROTECT_RULE { WCHAR name[255]; // Имя файла // Указатель на слудующее правило в списке ULONG r_next;       // Указатель на предыдущее правило в списке ULONG r_prev; } PROTECT_RULE, * PPROTECT_RULE;

 

 

Собственный код IOCTL, с которым можно будет обращаться к драйверу при помощи вызова DeviceIOControl

IOCTL_PROTECT_FILE CTL_CODE(FILE_DEVICE_UNKNOWN, 0x01, METHOD_BUFFERED, FILE_READ_DATA | FILE_WRITE_DATA), где, макрос CTL_CODE собирает информацию о типе запроса и на его основе генерирует код запроса

 

#define CTL_CODE(DeviceType, Function, Method, Access) (((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method))

 

 

Driver.c – главный файл драйвера, содержит все основные функции и точки входа, описанные в конструкторском разделе, а так же вспомогательные функции, реализующие сокрытие файлов.

DriverEntry – основная главная точка входа в драйвер, внутри этой функции драйвер выполняет инициализацию для себя и для используемого устройства (в данном случае – «\FileSystem\NTFS». В этой же функции в случае удачи создания устройства создается символическая ссылка на него, устанавливаются обработчики основных функций драйвера (IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_DEVICE_CONTROL), но т.к. нет смысла полностью переопределять обработчик открытия файла (IRP_MJ_CREATE), следует взять адрес старого обработчика и в новом, после выполнения некоторых действий, вызывать его.

Для получения старых обработчиков необходимо отключить защиту ядра от записи и функцией InterlockedExchange подменить их.

 

__asm { cli mov eax, cr0 and eax, not 000010000h mov cr0, eax }   OldCreate = (IRP_FUNC)InterlockedExchange((PLONG)&pTargetDrvObj->MajorFunction[IRP_MJ_CREATE], (ULONG)NewCreate); OldDirectoryControl = (IRP_FUNC)InterlockedExchange((PLONG)&pTargetDrvObj->MajorFunction[IRP_MJ_DIRECTORY_CONTROL], (ULONG)NewDirectoryControl);   __asm { mov eax, cr0 or  eax, 000010000h         mov cr0, eax sti           }

 

 

DeviceControlRoutine - эта точка входа вызывается Диспетчером Ввода/вывода, она необходима, чтобы запросить драйвер инициировать некоторую операцию ввода/вывода. Соответственно, здесь, в случае получения от пользовательского приложения IOCTL_PROTECT_FILE вызываются функции скрытия (PrtAddRule) или открытия (PrtDelRule) файла.

PrtFindRule – функция, просматривающая линейный список уже созданных правил на предмет совпадения имен. Так как представление имен файлов может быть различным, сравнивать имена нужно с конца.

PrtAddRule / PrtDelRule – функции создания и удаления правил о сокрытии файлов. При создании или удалении правила, необходимо проверить его наличие, для этого вызывается функция PrtFindRule. Так как это критическая область, то в этой функции может находиться только один поток, значит необходимо использовать такое средство синхронизации, как семафор.

NewDirectoryControl - обработчик запроса IRP_MJ_DIRECTORY_CONTROL, выполняющего определенную драйвером функцию для существующего файла (в данном случае его сокрытие)

NewCreate – обработчик запроса IRP_MJ_CREATE, соответствующий запросу на обращение к некоторому файлу. При этом проверяется, есть ли правило о сокрытии данного файла в списке правил, и, если оно было найдено, то возвращается STATUS_UNSUCCESSFUL.

Process_Names / Process_Both / Process_Full / Process_Dir – функции, вызываемые в NewDirectoryControl в зависимости от типа FileInformationClass. В них реализуется описанный выше алгоритм удаления файла из информации о директории, при наличии существования соответствующего правила.

Технологический раздел

Пользовательский интерфейс

 

При запуске программы автоматически создается дерево файлов всех дисков NTFS на компьютере. Для загрузки драйвера в память нужно нажать на кнопку «загрузить». При успешной загрузке драйвера будет выдано соответствующее сообщение, в случае ошибки (например, если драйвер уже находится в памяти) пользователю будет выдан тип ошибки.

Рис.7. Вид главного окна

 

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

Если при закрытии приложения драйвер не был выгружен из памяти, то при последующем запуске все скрытые ранее фалы будут показываться в левом окне приложения. Все скрытые файлы хранятся в реестре в ветке HKEY_LOCAL_MACHINE\SYSTEM\Rootkit и удаляются оттуда либо при поступлении команды о снятии правила с файла. Для того, чтобы снять все правила, необходимо нажать на самую нижнюю кнопку и все файлы, находящиеся слева станут видимыми для пользователя.

При сокрытии файлов необходимо помнить о том, что нельзя скрывать те файлы, которые используются в настоящий момент (!) или к ним возможно последующее обращение (!). Если система не сможет получить доступ к файлу, то для этого файла будут накапливаться необработанные сообщения, что приведет к краху системы.

Рис.8. Вид директории до сокрытия файла DjvuReader.exe

 

Рис.8. Вид директории после сокрытия файла DjvuReader.exe

Тестирование драйвера

 

Для тестирования драйвера использовалась программа Driver Verifier, входящая в состав Driver Development Kit (DDK) для Windows XP Service Pack 1 от Microsoft Windows, которая проверяет правильность следующих тестов:

1. Операции с пулами памяти;

2. Корректность уровней IRQL, на которых выполняется код драйвера;

3. Обнаружение взаимоблокировок;

4. Выполнение DMA операций;

5. Стресс-тест (нехватка ресурсов);

 

Рис.9. Диспетчер проверки драйверов

 

Все тесты прошли успешно. Память в системе распределялась правильно, ошибок с ней не возникало. На нехватку ресурсов драйвер реагировал корректно. Нетипичные запросы к драйверу не обрабатывались им.

Выводы

 

В ходе разработки проекта были исследованы и проанализированы подходы к решению проблемы скрытия файлов.

В результате работы над проектом создано программное средство, позволяющее скрывать файлы и папки в ОС Windows XP с помощью установки драйвера-фильтра файловой системы и обеспечивающее интерактивное взаимодействие с пользователем посредством приложения уровня пользователя. Данный программный продукт может использоваться как обычными пользователями для скрытия информации на компьютере, так и в ходе разработки системного программного обеспечения, поскольку возможно расширение функциональности созданной программы, путем добавления обработчиков соответствующих IRP – запросов в драйвер.

Фильтр-драйвер был протестирован с помощью тестовых утилит из состава пакета DDK и отвечает всем современным требованиям, накладываемым ОС Windows на характеристики драйверов.

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

 

Список используемой литературы

 

1. В.П. Солдатов, Программирование драйверов Windows. Изд. 2-е, перераб. И доп. – М.: ООО «Бином-Пресс», 2004 г. – 480 с.: ил. ISBN 5-9518-0099-4

2. MSDN Library, Copyright 1987-2007 Microsoft Corporation

3. Д.Н. Колесниченко, Rootkits под Windows,теория и практика программирования шапок-невидимок, позволяющих скрывать от системы данные, процессы, сетевые соединения, изд. «Наука и Техника»,2006 г

4. Г. Хоглунг, Дж. Батлер, Руткиты – внедрение в ядро Windows, изд. «Питер», 2007 г.

5. Шрайбер С.Б., Недокументированные возможности Windows 2000, Изд. 1-е, 2002 год, «Питер»

Оглавление

 

Введение

1. Аналитический раздел

1.1 Постановка задачи

1.2 Подсистема ввода-вывода

1.3 Драйверы режима ядра и средства их разработки

1.4 WDM драйверы и многослойная драйверная архитектура

1.5 Механизмы взаимодействия драйвера режима ядра и пользовательского приложения

2. Конструкторский раздел

2.1 Структура разрабатываемого программного продукта

2.2 Анализ и выбор алгоритма сокрытия данных

2.3 Описание функций драйвера

2.4 Описание функций пользовательского приложения

Взаимодействие драйвера и приложения

3. Технологический раздел

3.1 Выбор языка и среды программирования

3.2 Пользовательский интерфейс

3.3 Тестирование драйвера

Выводы

Список используемой литературы

 

Введение

 

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

Скрытие файлов в операционной системе Windows основано на перехвате обращений к файлам, что может осуществляться только резидентной программой. Сегодня распространено два подхода к решению данной задачи. Первый реализует программа Hide Folders XP: скрытие папок осуществляется с помощью специального драйвера, перехватывающего обращения к файловой системе. В программе доступно 3 режима защиты файлов и папок: скрывание, блокирование доступа и комбинированный режим (скрывание и блокирование доступа). Одним из недостатков подобных программ является возможность обойти защиту. Зачастую достаточно бывает перезагрузить систему в безопасный режим. Примером второго подхода, который позволяет решить эту проблему, может служить TrueCrypt. На жёстком диске программа создаёт файл-контейнер, всё содержимое которого зашифровано одним из выбранных криптографических алгоритмов.

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

 

Аналитический раздел

Постановка задачи

 

Основной целью проекта является разработка комплекса программных средств, осуществляющего скрытие файлов на компьютерах IBM PC, работающих под управлением операционной системы Windows XP.

Программный продукт должен обеспечивать удобный интерфейс для выбора скрываемого файла, и хранить в системе имена уже скрытых файлов и директорий. Выходными данными должна быть информация об успешном выполнении операции скрытия или описание произошедшей ошибки.

 

Подсистема ввода-вывода

 

Для реализации поставленной задачи необходимо отслеживать обращение к дискам. Существует несколько подходов к решению этой задачи. Один из подходов – это установление ловушек перехвата сообщений прежде чем они достигнут пользователя. Эта методика очень проста и эффективна, но имеет ряд недостатков, наиболее важный из которых – необходимость прав администратора для работы. Вторая методика – это написание драйвера-фильтра файловой системы, который будет перехватывать запрос обращения к директории и принимать действия в зависимости от внутренних данных и ассоциированных с файлом правил.

Работа с периферийными устройствами в ОС Windows возложена на подсистему ввода-вывода, которая состоит из служб режима пользователя и режима ядра, причем работа непосредственно с устройствами ведется в режиме ядра.

Приложения взаимодействуют с подсистемой ввода-вывода с помощью специальных системных вызовов, которые передают управления коду подсистемы ввода-вывода с учетом всех требований безопасности, и являются частью API исполнительной среды, например Win32.

 

Рис. 1. Схема обращения приложения к внешнему устройству

 

В результате системного вызова связанного с вводом-выводом в подсистеме ввода вывода создается пакет запроса ввода-вывода (IRP – Input/output Request Packet), хранящий информацию об операции, которую необходимо выполнить с устройством: чтение, запись или управление. Также IRP могут создаваться в результате обработки другого запроса одной из компонент подсистемы ввода-вывода. По завершении обработки IRP уничтожаются.

Центральное место в подсистеме ввода вывода занимает менеджер ввода-вывода, – специальная служба режима ядра, которая отвечает за координацию взаимодействия приложений и внешних устройств. В менеджер ввода-вывода передаются запросы из пользовательского режима. Он также координирует работу драйверов, работающих с конкретными типами устройств, которым он перенаправляет запросы ввода-вывода.

Нижележащим звеном в цепи, связывающей приложение с периферийным устройством, являются драйверы устройств режима ядра, – загружаемые модули режима ядра (как правило, это файл с расширением.sys), образующие интерфейс между диспетчером ввода-вывода и соответствующим оборудованием. Драйверы, как правило, поставляются с оборудованием, их набор в ОС не является постоянным. Хотя в состав операционной системы включены драйверы к наиболее распространенным устройствам, для обеспечения дополнительной функциональности зачастую необходимо разработать собственные драйверы.