Протоколирование обмена информацией между компьютером и внешним запоминающим USB-устройством

Оглавление
Введение. 3
1. Аналитический раздел. 4
1.1 Постановка задачи. 4
1.2 Архитектура WindowsNT 5. 4
1.3 Шина USB.. 7
1.3.1 Внутренняя организация шины USB.. 8
1.4 Драйверная модель WDM.. 16
1.4.1 Драйверные слои. 17
1.4.2 Точки входа WDM-драйвера. 19
1.5 Пакет запроса ввода / вывода (IRP)20
1.6 Уровни запроса прерываний. 24
1.7 Уведомление о завершении запросанижестоящим драйвером. 25
1.8 Работа с файлами в режиме ядра. 26
1.9 Работа с реестром в режиме ядра. 29
1.10 MDL‑списки. 31
2. Конструкторский раздел. 32
2.1 Точки входа разрабатываемого драйвера. 32
2.1.1 Функция DriverEntry. 32
2.1.2 Функция AddDevice. 32
2.1.3 Функция DriverUnload. 33
2.1.4 Функция DispatchRoutine. 33
2.1.5 Функция DispatchInternalDeviceControl33
2.2 Размещение кода драйвера в памяти. 35
2.3 Установка драйвера в системе. 35
3. Технологический раздел. 38
3.1 Выбор языка и средств программирования. 38
3.1.1 Драйвер-фильтр. 38
3.1.2 Управляющее приложение. 39
3.2 Структуры данных драйвера-фильтра. 39
3.2 Интерфейс управляющего приложения. 41
3.3 Тестирование драйвера-фильтра. 42
Заключение. 44
Список литературы и интернет-ресурсов. 45
Введение
При решении широкого круга задач возникает необходимость в получении информации о функционировании какого-либо внешнего устройства компьютера. К категории этих задач можно отнести разработку систем информационной безопасности, что очень актуально в современном мире, где информация является одним из важнейших ресурсов.
Одним из компонентов системы информационной безопасности может быть модуль, выполняющий протоколирование обмена информацией между компьютером и некоторым внешним запоминающим устройством, например USB‑накопителем.

1. Аналитический раздел
1.1 Постановка задачи
В соответствии с заданием на курсовую работу необходимо разработать программный комплекс, обеспечивающий слежение за обменом информацией между компьютером и внешним запоминающим USB‑устройством.
Перечислим требования, предъявляемые к программному комплексу:
· Разрабатываемый комплекс должен отслеживать запросы на чтение и запись, приходящие к устройству;
· От программы не требуется определять, к каким файлам производилось обращение, а лишь то, какие данные считывались и записывались;
· Сохраняемая информация должна обладать структурированностью, таким образом, что при анализе лог-файла можно было определить, передавалась или принималась информация и в каком количестве;
· Программный комплекс не должен приводить к сбоям в работе операционной системы;
· Программа установки должна корректно обрабатывать попытку установки на одно устройство в двух экземплярах.
1.2 Архитектура WindowsNT 5
Архитектура WindowsNT 5 соответствует классическим представлениям о проектировании операционных систем. Наиболее распространены реализации данной ОС для платформы Intelx86 в одно- или многопроцессорных конфигурациях, однако существуют также версии для DECAlpha и MIPS. Данная операционная система использует защищённый режим центрального процессора, реализует механизмы виртуальной памяти и многозадачности.
Исполняемый код в WindowsNT 5 имеет два уровня привилегий: код пользовательского режима и код режима ядра. Уровень привилегий накладывает определённые ограничения: в пользовательском режиме не могут выполняться привилегированные инструкции процессора, не разрешено обращение к защищённым страницам памяти. Эти ограничения накладываются для обеспечения безопасности работы системы. Пользовательское приложение не должно иметь возможность в результате ошибки или преднамеренно вносить изменения в критические таблицы операционной системы или в память других приложений. В частности, такие ограничения запрещают пользовательскому приложению напрямую управлять внешними устройствами, потому что каждое из них является разделяемым ресурсом.
В WindowsNT 5 обеспечение обмена данными и управление доступом к внешнему устройству как к разделяемому ресурсу возлагается на его драйвер. Ввод и вывод в драйверах осуществляется посредством IRP‑пакетов (Input/OutputRequestPacket). Запросы на ввод / вывод, посылаемые приложениями или другими драйверами, обрабатываются драйвером, после чего запрашивающей программе в том же пакете посылается статус завершения операции. Подробнее о пакетах ввода / вывода будет сказано далее, общий же принцип взаимодействия проиллюстрирован на Рис. 1.2.1.

Рис. 1.2.1 Архитектура ввода / вывода WindowsNT 5
Применительно к поставленной задаче, из вышеизложенного следует, что полное протоколирования обмена данными с внешним устройством может быть осуществлено только на уровне драйвера.
Управление внешним устройством в общем случае сводится к заполнению его регистров необходимыми данными. Монопольный доступ драйвера к этим регистрам гарантируется операционной системой. Очевидно, что при данных обстоятельствах требуется, чтобы драйвер устройства выполнялся в режиме ядра.
Обобщённая классификация драйверов WindowsNT 5 может быть представлена следующим образом:
· Драйверы режима ядра:
o Унаследованные драйверы;
o Драйверы файловой системы;
o Видеодрайверы;
o Драйверы PnP (Plug And Play):
- Драйверы WDM.
· Драйверы пользовательского режима.
1.3 Шина USB
Спецификация USB была разработана консорциумом компаний, включая Intel и Microsoft. Целью нового стандарта было обеспечение организации недорогой среднескоростной шины в таких областях применения, как передача цифровых изображений, компьютерная телефония и мультимедийные игры. Текущими версиями спецификации USB является версии 1.1 и 2.0 (во вторую заложены более высокие скоростные характеристики).
Предельная скорость передачи данных по шине USB спецификации 1.1 составляет 12 Мбит/с (FullSpeed). Медленные устройства используют низкую скорость передачи – 1,5 Мбит/с (LowSpeed). Стандарт USB версии 2.0 поддерживает физическую скорость передачи до 480 Мбит/с (HighSpeed). Данные передаются последовательно по паре проводников. Питание для некоторых устройств доступно по отдельным проводникам питания и заземления (для устройств с небольшим энергопотреблением).
Устройства USB могут быть подключены 5-метровым кабелем (а практически – и более длинным). Использование USB‑хаба (hub– концентратор) позволяет увеличить дальность размещения устройств от хост-контроллера, а так же количество устройств, подключаемых к одной шине USB. Последовательно можно подключить до пяти хабов, обеспечив длину соединения 30 метров. К хост-контроллеру можно подключить до 127 устройств, шинный адрес которых устанавливается динамически при подключении устройств.
На рисунке 1.3.1 приведен пример конфигурации сети USB‑устройств:

Рис. 1.3.1 Сеть USB‑устройств
Работа программиста, создающего драйвер внешнего (не находящегося на материнской плате) USB устройства сводится к тому, чтобы воспользоваться программным интерфейсом системных драйверов шины USB, общение с которым происходит при помощи пакетов, называемых URB (USBRequestBlock) пакетами. Работа с регистрами USB контроллеров на материнской плате теперь стала уделом узкого круга специалистов – разработчиков материнских плат и операционных систем. Всем остальным разработчикам USB‑устройств в операционной системе Windows предлагается достаточно развитый программный интерфейс WDM‑драйверов, которые берут на себя все аппаратно-ориентированные операции.
1.3.1 Внутренняя организация шины USB
Все операции по передаче данных по шине USB инициируются хостом. Периферийные устройства не могут сами начать обмен данными, они могут только реагировать на команды хоста. Рассмотрим общую схему обмена данными по шине USB.
Система USB разделяется на три логических уровня с определенными правилами взаимодействия. Устройство USB содержит интерфейсную, логическую и функциональную части. Хост тоже делится на три части: интерфейсную, системную и программное обеспечение. Каждая часть отвечает только за определенный круг задач. Логическое и реальное взаимодействие между ними показано на рисунке 1.3.1.1.
Рис. 1.3.1.1 Взаимодействие компонентов USB
Таким образом, операция обмена данными между прикладной программой и шиной USB выполняется путем передачи буферов памяти через следующие уровни:
· уровень клиентского программного обеспечения в хосте – обычно представляется драйвером устройства USB, обеспечивает взаимодействие пользователя с операционной системой с одной стороны и системным драйвером с другой;
· уровень системного программного обеспечения USB в хосте (USBD, UniversalSerialBusDriver) – управляет нумерацией устройств на шине, управляет распределением пропускной способности шины и мощности питания, обрабатывает запросы пользовательских драйверов;
· хост-контроллер интерфейса шины USB (HCD, HostControllerDriver) – преобразует запросы ввода / вывода в структуры данных, по которым хост-контроллер выполняет физические транзакции, работает с регистрами хост-контроллера.
Уровень клиентского программного обеспечения определяет тип передачи данных, необходимый для выполнения затребованной прикладной программой операции. После определения типа передачи данных этот уровень передает системному уровню следующее:
· буфер памяти, называемый клиентским буфером;
· пакет IRP, указывающий тип необходимой операции. Непосредственной обработкой запроса занимается системный драйвер USB.
Уровень системного драйвера USB необходим для управления ресурсами USB. Он отвечает за выполнение следующих действий:
· распределение полосы пропускания шины USB;
· назначение логических адресов устройств каждому физическому USB‑устройству;
· планирование транзакций.
Логическое устройство USB представляет собой набор независимых конечных точек, с которыми клиентское программное обеспечение обменивается информацией. Каждому логическому устройству USB назначается свой адрес, уникальный на данной шине USB. Каждая конечная точка логического устройства идентифицируется своим номером и направлением передачи (IN – передача к хосту, OUT – от хоста).
Транзакция на шине USB – это последовательность обмена пакетами между хостом и периферийным устройством, в ходе которой может быть передан или принят один пакет данных. Когда клиентское программное обеспечение передает IRP уровню системного драйвера, USB‑драйвер преобразует их в одну или несколько транзакций шины и затем передает получившийся перечень транзакций драйверу контроллера хоста.
Системный драйвер USB состоит из драйвера USB и драйвера хост-контроллера. Когда клиентский уровень передает IRP уровню системного обеспечения USB, USB‑драйвер преобразует их в одну или несколько транзакций шины и затем передает получившийся перечень транзакций драйверу контроллера хоста. Драйвер контроллера хоста принимает от системного драйвера шины перечень транзакций и выполняет следующие действия:
· планирует исполнение полученных транзакций, добавляя их к списку транзакций;
· извлекает из списка очередную транзакцию и передает ее уровню хост-контроллера интерфейса шины USB;
· отслеживает состояние каждой транзакции вплоть до ее завершения.
При выполнении всех связанных с командным пакетом транзакций системный уровень уведомляет об этом клиентский уровень.
Уровень хост-контроллера интерфейса шины USB получает отдельные транзакции от драйвера контроллера хоста (в составе уровня системного обеспечения USB) и преобразует их в соответствующую последовательность операций шины. В результате этого USB‑пакеты передаются вдоль всей физической иерархии хабов до периферийного USB‑устройства.
Нижний уровень периферийного USB‑устройства называется уровнем интерфейса шины USB. Он взаимодействует с интерфейсным уровнем шины USB на стороне хоста и передает пакеты данных от хоста к периферийному устройству в формате, определяемом спецификацией USB. Затем он передает пакеты вверх – уровню логического USB‑устройства.
Средний уровень периферийного устройства USB‑устройства называется уровнем логического USB‑устройства. Каждое логическое USB‑устройство представляется набором своих конечных точек, с которыми может взаимодействовать системный уровень USB‑хоста. Эти точки являются источниками и приемниками всех коммуникационных потоков между хостом и периферийными USB‑устройствами.
Самый верхний уровень периферийного USB‑устройства называется функциональным уровнем. Этот уровень соответствует уровню клиентского обеспечения хоста. С точки зрения клиентского уровня, нижележащие уровни нужны для организации между ним и конечными точками прямых «каналов данных», которые идут вплоть до функционального уровня. А с точки зрения нашей схемы функциональный уровень выполняет следующие действия:
· получает данные, посылаемые клиентским уровнем хоста из конечных точек каналов данных нижележащего уровня логического USB‑устройства;
· посылает данные клиентскому уровню хоста, направляя их в конечные точки каналов данных нижележащего уровня логического USB‑устройства.
Логически передача данных между конечной точкой и программным обеспечением производится с помощью выделения канала и обмена данными по этому каналу, а с точки зрения представленных уровней, передача данных выглядит следующим образом:
Рис. 1.3.1.2 Уровни передачи данных
Конечная точка (Endpoint) – это часть USB‑устройства, которая имеет уникальный идентификатор и является получателем или отправителем информации, передаваемой по шине USB. Проще говоря, это буфер, сохраняющий несколько байт. Обычно это блок данных в памяти или регистр микроконтроллера. Данные, хранящиеся в конечной точке, могут быть либо принятыми данными, либо данными, ожидающими передачу. Хост также имеет буфер для приема и передачи данных, но хост не имеет конечных точек.
Конечная точка имеет следующие основные параметры:
· частота доступа к шине;
· допустимая величина задержки обслуживания;
· требуемая ширина полосы пропускания канала;
· номер конечной точки;
· способ обработки ошибок;
· максимальный размер пакета, который конечная точка может принимать или отправлять;
· используемый конечной точкой тип посылок;
· направление передачи данных.
Любое USB‑устройство имеет конечную точку с нулевым номером (EndpointZero). Эта точка позволяет хосту опрашивать устройство с целью определения его типа и параметров, выполнять инициализацию и конфигурирование устройства.
Кроме нулевой точки, устройства, обычно, имеют дополнительные конечные точки, которые используются для обмена данными с хостом. Дополнительные точки могут работать либо только на прием данных от хоста (входные точки, IN), либо только на передачу данных хосту (выходные точки, OUT).
Нулевая точка устройства доступна после того, как устройство подключено к шине, включено и получило сигнал сброса по шине (busreset). Все остальные конечные точки после включения питания или сброса находятся в неопределенном состоянии и недоступны для работы до тех пор, пока хост не выполнит процедуру конфигурирования устройства.
Спецификация шины определяет четыре различных типа передачи данных для конечных точек:
· управляющие передачи (ControlTransfers) – используются хостом для конфигурирования устройства во время подключения, для управления устройством и получения статусной информации в процессе работы. Протокол обеспечивает гарантированную доставку таких посылок;
· передачи массивов данных (BulkDataTransfers) – применяются при необходимости обеспечения гарантированной доставки данных от хоста к функции или от функции к хосту, но время доставки не ограничено;
· передачи по прерываниям (InterruptTransfers) – используются в том случае, когда требуется передавать одиночные пакеты данных небольшого размера. Каждый пакет требуется передать за ограниченное время. Операции передачи носят спонтанный характер и должны обслуживаться не медленнее, чем того требует устройство;
· изохронные передачи (IsochronousTransfers) – применяются для обмена данными в «реальном времени», когда на каждом временном интервале требуется передавать строго определенное количество данных, но доставка информации не гарантирована (передача данных ведется без повторения при сбоях, допускается потеря пакетов).
Канал(pipe) – это логическое соединение между конечной точкой устройства и ПО хоста. Существует две модели каналов:
· потоковый канал (или просто поток, streamingpipe) – это канал для передачи данных, структура которых определяется клиентским ПО. Потоки используются для передачи массивов данных, передачи данных по прерываниям и изохронной передачи данных. Поток всегда однонаправленный. Один и тот же номер конечной точки может использоваться для двух разных потоковых каналов – ввода и вывода. Передачи данных в потоковых каналах подчиняются следующим правилам:
· запросы клиентских драйверов для разных каналов, поставленные в определенном порядке друг относительно друга, могут выполняться в другом порядке;
· запросы для одного канала будут исполняться строго в порядке их поступления;
· если во время выполнения какого-либо запроса происходит серьезная ошибка (STALL), поток останавливается;
· канал сообщений (messagepipe или controlpipe) – это канал для передачи данных, структура которых определяется спецификацией USB. Каналы этого типа двунаправленные и применяются для передачи управляющих посылок. Каналы сообщений строго синхронизированы – спецификация USB запрещает одновременную обработку нескольких запросов: нельзя начинать передачу нового сообщения, пока не завершена обработка предыдущего. В случае возникновения ошибки передача сообщения может быть прервана хостом, после чего хост может начать передачу нового сообщения.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать полную версию