Драйвер-фильтр сокрытия файлов в файловой системе NTFS

1

Кафедра «Программное обеспечение ЭВМ и информационные технологии»

Курсовой проект

по системному программированию

Расчетно-пояснительная записка

Тема:

«Драйвер-фильтр сокрытия файлов в файловой системе NTFS»

Москва, 2009 год

Оглавление

Введение

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. На жёстком диске программа создаёт файл-контейнер, всё содержимое которого зашифровано одним из выбранных криптографических алгоритмов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По типу обслуживаемых устройств:

1. Драйверы аппаратных устройств

2. Драйверы файловой системы

3. Драйверы фильтры файловой системы

4. Сетевые редиректоры и серверы

5. Драйверы протоколов

6. Драйверы потоковых фильтров ядра.

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

С этой точки зрения драйверы можно разделить на:

1. Монолитные драйверы - драйверы, которые не участвуют ни в одном стеке

устройств, получая и завершая обработку всех поступающих IRP пакетов, самостоятельно обращаясь к своему обслуживаемому устройству.

2. Унаследованные (Legacy) драйверы - драйверы этого типа могут быть объединены

в стек, но они не поддерживают PnP функции, могут использовать недокументированные функции WinNT 5, из-за чего не всегда переносимы на Win98.

3. WDM драйверы - драйверы написанные в соответствии со спецификацией WDM

(Windows Driver Model), введенной в Windows 2000, поддерживающей Plug and play (динамическая идентификация устройств и энергосберегающие технологии)

С точки зрения WDM, существует три типа драйверов:

1. Драйвер шины (bus driver), обслуживающий контроллер шины, адаптер, мост или

любые другие устройства, имеющие дочерние устройства.

2. Функциональный драйвер (functional driver) - основной драйвер устройства,

предоставляющий его функциональный интерфейс.

3. Драйвер фильтр (filter driver) - драйвер, предназначенный для расширения

возможностей функционального драйвера.

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

Рассмотрим подробнее, как устроен стек драйверов в WDM. Каждый драйвер в стеке изолирует аппаратно зависимые возможности от вышестоящего уровня.

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

Рис. 2. Многослойная архитектура драйверов

Над стеком находятся приложения. Они обрабатывают запросы пользователя или других приложений и вызывают или подсистему Win 32 или клиент драйвер пользовательского режима.

1. Драйвер аппаратной шины находится в самом низу стека. Microsoft предоставляет эти драйвера для всех шин, как часть операционной системы

2. Фильтр-драйвер аппаратной шины обычно добавляет новые функциональные возможности и поставляется Microsoft или системным интегратором. Для одной аппаратной шины может существовать неограниченное число фильтр-драйверов аппаратной шины.

3. Фильтр-драйверы нижнего уровня обычно изменяют поведение устройства или класса устройств.

4. Функциональный драйвер (functional driver) - основной драйвер устройства, предоставляющий его функциональный интерфейс.

5. Фильтр-драйверы верхнего уровня выполняют дополнительные манипуляции над IRP, к которому они подключены. Их количество для одного классового драйвера не ограниченно, при этом они являются для него прозрачными, т.е. классовый драйвер не подозревает о существовании фильтров.

Рис. 3. Место драйверов в операционной системе

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

1.5 Механизмы взаимодействия драйвера режима ядра и

пользовательского приложения

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

1. WMI - расширение WDM предоставляющие интерфейс через который драйверы могут взаимодействовать с приложениями. С точки зрения приложения WMI реализован как COM-интерфейс. Драйвер же реализует функции WMI через специальные точки входа, стандартизированные в расширениях WDM. С помощью WMI можно осуществлять мониторинг и управление устройствами компьютера с другой машины по сети.

2. Системные вызов API Win32 - кроме WMI точек входа, драйверы WDM поддерживают точку входа c кодом функции IRP_MJ_DEVICE_CONTROL, которая отвечает за программное управление устройством с локального компьютера. С точки зрения приложения обращение к этой функции выглядит как вызов API-функции DeviceIOControl.

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

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

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

Необходимые для работы компоненты

1. Пользовательское приложение, обеспечивающее выбор файла для сокрытия,

Отображение уже скрытых файлов, загрузка и выгрузка драйвера

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

Рис.6. Схема взаимодействия драйвера и приложения

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

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

Для скрытия файлов на диске нам нужно перехватить функцию ZwQueryDirectoryFile из ntdll.dll. Она является базовой для всех API перечисления файлов.

API функции представляют и себя ничто иное, как функции в системных DLL. Любой процесс в системе обязательно имеет в своем адресном пространстве Ntdll.dll, где располагаются функции Native API - базовые функции низкоуровневой работы с системой, функции Kernel32.dll являются переходниками к более мощным функциям Ntdll, следовательно, целесообразно будет перехватывать именно функции Native API.

Страницы: 1, 2