Pull to refresh

NDIS. Введение

Reading time 4 min
Views 24K
Собственно, как и обещал, начинаю цикл статей о подсистеме NDIS и о том, что с ней связано. Решил связать его с процессом собственного обучения на своей первой работе. Если цикла не получится, значит меня загрузили по самые уши, или вообще уволился.

Вступление



Для чего, вообще этот NDIS? Зачем его придумали, если и всё и так хорошо?

NDIS — это одна из подсистем ядра Windows, которая имеет прямое отношение к спектру начиная от драйверов сетевых карт и заканчивая интерфейсами для протоколов сетевого уровня. NDIS состоит из т.н. стека драйверов (хотя, как по мне, так это никакой не стек, а очередь), но для общего понимания лучше представлять себе это так:

image



Хорошо, но мне этого мало!



Если копнуть поглубже, то NDIS состоит из обязательной части — самого себя (файл NDIS.SYS), и теоретически неограниченного количества пользовательских драйверов, которые этот самый NDIS.SYS оборачивает. При этом драйвер, обязан выполнить некоторые действия, чтобы подсистема NDIS вообще посчитала его местным, и смогла интегрировать в свой «стек», который очередь. Минимальные условия это:
  • Драйвер должен себя зарегистрировать. Это означает то, что драйвер при загрузке указывает ядру, чтО он есть на самом деле и какого он типа;
  • Драйвер должен предоставлять минимальный набор интерфейсных функций, которые он предоставляет NDIS'у. Собственно, за эти функции NDIS и будет тягать этот самый драйвер;
  • Так же драйвер дожен, в зависимости от своего типа, реализовать функции управления собой, которые так же тягаются во время выполнения. Отличие от предыдущего пункта в том, что эти функции для каждого типа драйвера уникальные.


Все эти драйверы делятся на несколько типов, а именно:
  • Драйверы минипорта;
  • Драйверы протокола;
  • Промежуточные драйверы;
  • Драйверы-фильтры.


Зачастую на практике пишутся драйверы-фильтры и промежуточные драйверы, т.к. в остальных потребность есть у небольшого круга компаний выпускающих собственные сетевые решения. Во времена XP разработчики часто использовали промежуточные драйверы (потому, что фильтров не было), начиная с Windows Vista лучше использовать фильтры, т.к. они проще в своём устройстве и основную функцию (а для нас это практически во всех случаях — модификация трафика) выполняют «на ура». Итак, как мы помним, «сверху» NDIS'a у нас протоколы (IP, IPX, ARP, RARP, etc.), а снизу сетевые карты. На этом промежутке мы будем выполнять свои магические заклинания над трафиком.

Разберемся с тем, чем именно отличаются драйверы-фильтры и промежуточные драйверы. Итак, когда трафик движется в сеть, т.е. от протокола к сетевой карте, он проходит через очередь пользовательских драйверов, которую сформировал NDIS. В самой середине этой очередь (честно, не знаю как найти середину, если в очереди 3 драйвера, однако с MSDN'ом не поспоришь) NDIS располагает промежуточные драйвера. Эти драйверы выстраиваются в свою очередь по неизвестному алгоритму, однако NDIS гарантирует, что трафик пройдёт через каждый драйвер в «стеке». Промежуточный драйвер представляет собой обманку, «сверху», т.е. для драйверов, которые располагаются над ним, он выглядит как минипорт (хотя настоящие минипорты еще далеко внизу), а «снизу» выглядит как протокол (протоколы далеко вверху). Т.о. промежуточный драйвер является прозрачным, и зачастую его используют не для фильтрации или модификации трафика, а для «рассылки» трафика одного протокола нескольким минипортам (они же интерфейсы сетевых карт). Ну, или, наоборот: рассылки трафика сетевой карты по нескольким протоколам.

Ок, с этим понятно, теперь о драйверах-фильтрах. Драйвер-фильтр — это драйвер, который располагается так же на пути следования трафика от сетевой карты до протоколов, однако конкретное местоположение в очереди определяется настройками, и о них чуть позже. Сейчас же ознакомимся с тем, что драйверы-фильтры бывают двух типов (не следует путать тип, который задаёт местоположение драйвера и основной тип):
  • Драйвер-монитор, не подвергает трафик изменению, но может его «воровать»;
  • Драйвер-модификатор, полный контроль над трафиком, меняй, удаляй, добавляй своё — что угодно.


Из названия понятно какая между ними разница, однако стоит отметить, что при установке оба драйвера устанавливаются и «работают» нормально. Т.е. если вы написали функции слежения, то трафик вы увидите. Однако, драйвер-модификатор в некоторых случаях потребует перезагрузки. Если перезагрузки не будет, то мониторить трафик вы сможете, а, допустим, ронять пакеты — нет. Функциональная особенность.

Теперь разберемся с местом драйверов-фильтров в очереди. Положение в очереди определяется назначением драйвера. Назначение драйвера (обычное назначение, т.е. для чего этот драйвер используется) устанавливается на этапе установки в его .INF файле. Полный список назначений я не приведу, но примерно картину обрисую. Допустим драйвер предназначается для сжатия трафика, для этого мы в .INF файле укажем «compression», так же есть назначение «encryption», ну или «Custom».

Тут можно ознакомиться со всем списком. Скажу так же, что custom — самые нижележащие драйверы, а, например, scheduler — самые «верхние».

Пожалуй, на сегодня хватит, дополнительную информацию читаем тут:

msdn.microsoft.com/en-us/library/ff557563(v=VS.85).aspx

В следующий раз поговорим о минимальной реализации драйвера-фильтра

Tags:
Hubs:
+36
Comments 15
Comments Comments 15

Articles