Rawether ndis 6 x spr protocol driver что это
Обновлено: 04.07.2024
На днях уехал в город, с ноутбуком всё было нормально. на днях системные прерывания начали грузить процессор, виноватым оказался данный драйвер. Если будет надо, докину инфу про железо.
скорей всего ничего
значит сетевуха ничего не умеет по железу и все эмулируется на проце
просто чем выше нагрузка (закачка на 100 мбит например) тем сильней грузит
но если раньше такого не было, может это и вирус, маскирующийся под ndis
ОС Windows: сетевая подсистема
Изучить сетевую подсистему этой ОС так же просто, как в ОС Linux, не получится. Самый большой камень преткновения - закрытый исходный код. Однако давайте попытаемся восстановить информацию о том, как работает сетевая подсистема в рамках этой ОС. В качестве целей будем использовать то, что нашли в Linux:
Где располагается код для создания и работы с сокетами;
Какой механизм используется для фильтрации;
Как имплементированы протоколы.
Сетевая подсистема, согласно документации построена по принципу модели OSI. И также приводится описание того, за счет каких технологий и типов файлов реализуется работа отдельных уровней модели.
Имплементация модели OSI в операционной системе начинается со строго определенных уровней. В данном случае всё начинается на уровне "Канальном" и заканчивается на уровне "Транспортном". Имплементация на каждом уровне своя:
Канальный уровень - состоит из MAC и LLC, соответственно и частей имплементации должно быть две:
MAC - miniportdriver это драйвер, который контролирует сетевой интерфейс;
LLC - protocol driver - драйвер, который используется для обработки данных от сетевых устройств;
Уровень сети - protocol driver - драйвер, который используется для обработки данных от сетевых устройств;
Уровень транспорта - protocol (transport) driver;
Вот и выявилось коренное отличие Windows от Linux - вся логика работы сетевой подсистемы разбита на множество элементов. Каждое устройство, каждый протокол и абстракция имплементированы не в ядре, а в модуле ядра - драйвере, который может быть загружен ядром по запросу. Что это значит для нас? У нас нет исходного кода данных драйверов, а значит мы не можем использовать подход, который использовали при изучении ОС Linux.
Как же быть? При разработке эксплойтов исследователи в качестве отправной точки для восстановления структур внутри ядра Windows используют проект с открытым исходным кодом - ReactOS. Попробуем сделать тоже самое. Давайте найдем части подсистемы и затем спроецируем найденную информацию на реальную ОС Windows.
На экране ниже приведен снимок директории с основными драйверами для сетевой подсистемы:
Попробуем найти такие же файлы в реальной ОС. Заглянем в директорию "%Windows%". В качестве исследуемой системы возьмем Windows 7.
Часть файлов действительно имеет названия файлов, которые присутствуют в реальной ОС.
Один из способов проверки функционала уже скомпилированного приложения - прочитать используемые им строки. Можем для этого воспользоваться утилитой strings.exe для tcpip.sys :
Похоже, что данные по работе с сетевой подсистемой можно обнаружить именно в этом драйвере. Поищем функции, которые позволяют фильтровать трафик. Как их идентифицировать?
В операционной системе Windows за всё время её существования было 2 технических спецификаций на основании которых создавались драйвера для сетевого взаимодействия: TDI и WinSock. И все эти спецификации использовали отдельный драйвер для того чтобы можно было собирать весь функционал - NDIS. Значит большая часть функций сконцентрирована в этих драйверах:
Но в них все равно нет функций, которые бы могли фильтровать трафик. Почему так? Дело в том, что до Windows 7 фильтрация трафика как такового была имплементирована в отдельных драйверах, которые настраивались за счет интерфейса Windows. Начиная с Windows 7 была реализована так называемая Windows Filtering Platform, которая определила часть драйверов в специальную категорию, которая и призвана фильтровать трафик.
Часть этих фильтров можно найти по обычному поиску в директориях ОС:
Используем утилиту strings.exe на файлы FWPKCLNT.SYS и wfplwf.sys :
Выше представлена часть строк, которые обнаружились в файле FWPKCLNT.sys , файл wfplwf.sys содержал только названия функций. Почему тогда они здесь вместе? Дело в том, что в импортах wfplwf.sys есть функция, которая берется из файла FWPKCLNT.sy s:
Имплементация всех объектов и механизмов в ядре для работы с протоколами - файлы из директории %Windows%\System32\Drivers . Основные из них - netio.sys, ndis.sys, tdi.sys.
Фильтрацией занимаются драйвера WFP: FWPKCLNT.sys , wfplwf.sys .
Имплементируются через отдельные одноименные файлы, например: tcpip.sys
В ОС Linux мы не задумывались о том как приложения получают доступ к структурам ядра и работают с сетью. Там более-менее всё очевидно и только один шаг до функций, но для Windows всё работает по принципу Callback`ов. Поэтому скорее всего будет несколько оберток для взаимодействия. Попробуем найти эти файлы.
Для поиска файлов, которые используются в качестве обертки-библиотеки, можно использовать следующий метод. Для этого создадим мини приложение, которое будет работать с сокетами, принимать и отправлять данные. Исходный код приложения:
Запускаем файл в ОС, если не возникло никаких ошибок, то необходимо параллельно запустить инструмент Process Explorer. С помощью этого инструмента мы подсмотрим, чем занимается поток, пока ждет соединения. На картинке ниже отображены все описанные действия:
Слева изображен стек вызовов функций, которые задействованы в процедуре настройки сокета и перевода его в состояние bind. Этот набор файлов - mswinsock.dll (Win Sock 2 Service) и WS2_32.dll (Windows Socket 2). Данные библиотеки используются для того, чтобы предоставить приложениям функции по работе с сокетами в ОС Windows.
Стоит отметить, что последовательность функций, которые вызываются для работы сокета в ОС, не виден в Process Explorer`е. Если нужно восстановить и эти данные, то нужно использовать отладчик ядра.
Таким образом, проводить исследование подсистем любых ОС и их механизмов можно с исходным кодом и без — достаточно выбрать необходимый набор инструментов, а также доступные методы, источники знаний.
NDIS. Введение
Собственно, как и обещал, начинаю цикл статей о подсистеме NDIS и о том, что с ней связано. Решил связать его с процессом собственного обучения на своей первой работе. Если цикла не получится, значит меня загрузили по самые уши, или вообще уволился.
Вступление
Для чего, вообще этот NDIS? Зачем его придумали, если и всё и так хорошо?
NDIS — это одна из подсистем ядра Windows, которая имеет прямое отношение к спектру начиная от драйверов сетевых карт и заканчивая интерфейсами для протоколов сетевого уровня. 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 — самые «верхние».
Сетевая подсистема в ОС
Для будущих студентов курса «Сетевой инженер» и всех интересующихся подготовили полезную статью.
Также приглашаем на открытый вебинар по теме «NAT — не Firewall». Участники вебинара вместе с экспертом рассмотрят NAT и его использование, почему NAT != firewall, а также различные виды конфигураций для разных ситуаций.
В данной статье будет проведено исследование сетевой подсистемы ОС Windows и Linux, а также предложен план изучения подсистем операционной системы. Основная задача исследования - понять, из чего состоит сетевая подсистема; какие поддерживает протоколы из коробки; какие дополнительные механизмы использует в своей работе.
Disclamer: Статья описывает данные, которые с точки зрения автора помогут понять, как работают операционные системы с моделью TCP/IP, и не претендует на полноту.
Инструментарий и метод исследования
Для исследования операционной системы будем использовать следующие инструменты:
Операционная система Linux:
Visual Studio Code;
Операционная система Windows:
Инструменты подобраны таким образом, чтобы можно было охватить максимальное количество форматов файлов, которые можно обнаружить в ОС. Для исходного же кода главный инструмент - редактор, который позволяет удобно переходить от исходника к исходнику для разбора кода.
В нашем исследовании будем руководствоваться двумя правилами:
Используем всю информацию из документации операционных систем;
Проверяем правдивость описанных данных. Для структур данных:
В ОС Windows исследуем соответствующие функционалу dll, sys файлы;
В ОС Linux исследуем исходные коды и отдельные ветки ядра;
Теперь определимся с проблемами, которые вероятно будут нас преследовать на протяжении всего исследования.
Проблемы при исследовании ОС Linux
Основной функционал подсистемы целиком находится в ядре. К счастью, исходный код доступен в сети. Исследование исходного кода таких больших проектов всегда довольно сложная задача. На её сложность может влиять несколько факторов:
у каждого исследователя разный уровень экспертизы в области языка программирования, который используется в исходном коде;
у каждого исследователя есть свой собственных подход на интерпретацию полученной информации.
ограниченности исследования по времени;
объем исходного кода;
принятые правила кодирования проекта.
Как минимизировать количество действий исследователя, чтобы получить как можно больше полезной и интересной информации? Огромную роль играет правильно настроенное рабочее место. В нашем случае верную настройку определяет набор инструментов, который мы описали в разделе "Инструментарий и метод исследования". Также можно применить небольшой лайфхак и не рассматривать каждую строку исходников ядра, а рассматривать только высокоуровневые элементы. Это сэкономит время на изучение языка программирования и даст возможность разобраться, что к чему. Попробуем применить эту тактику на практике.
Сетевая подсистема Linux
Начнем наше исследование с вот такой интересной картинки:
Картинка представляет собой структуру директорий исходного кода ядра ОС Linux. На ней видно, что сетевая подсистема вовсе не самая большая часть операционной системы. По правде говоря, можно собрать ядро и без этой части. Сегодня это вариант только для embeded систем, в общем случае без сети представить Linux сложно.
Код, который относится к сетевой подсистеме, находится в директории "net". Посмотрим, из чего он состоит.
На картинке выделены названия файлов, которые описывают основные структуры для работы с сетью. Это создание сокетов, хранение пересылаемых данных и работа с фильтрующей подсистемой bfp . Именно этот код переиспользуется для остальной части сетевой подсистемы.
Оставшиеся файлы в директории "net" описывают работу ядра с различными протоколами. Интересным моментом здесь является то, что фильтрующая подсистема имеет какие-то файлы только в некоторых протоколах и подсистемах:
Прямоугольниками выделены те протоколы и подсистемы, которые содержат файлы netfilter . Как видно из картинки, механизм фильтрации трафика работает не со всеми протоколами. Также интересно то, что он присутствует не только в протоколах, но и в более высокоуровневой абстракции - bridge. Теперь понятно, почему bridge от Linux можно настроить настолько гибко и контролировать пересылаемые данные.
Что в итоге? Всего по 4м картинкам структуры исходных кодов ядра мы уже обладаем информацией о том, какие поддерживаются протоколы в ядре Linux, какие механизмы интегрированы в протоколы для контроля и фильтрации и где найти базовые элементы, которые позволяют использовать сеть. Попробуем найти эту информацию и в ОС Windows.
кто знает что такое NDIS драйвер тот получит 10 баллов.
Network Driver Interface Specification - (спецификатор интерфейса сетевых драйверов), представляет собой mini-port. Грубо говоря, это библиотека функций, позволяющая драйверам сетевых протоколов "гонять" сетевые пакеты, не вникая в детали реализации. Фаервол работающий на NDIS-уровне, перехватывает практически весь трафик, который только проходит через компьютер. "Практически" - потому что обращения к обратной петле через NDIS не проходят и остаются незамеченными, то есть, если дать команду ping 127.0.0.1, пакетный фильтр даже не пикнет. А это значит, что NDIS-брандмауэры хронически не способны обнаруживать подключения к локальным службам. Если на компьютере установлен Proxy-сервер (а он установлен практически на всех домашних сетях), любое приложение может свободно выходить в Сеть и гулять по любым адресам, осуществляя информационный обмен во всех направлениях. К тому же на NDIS-уровне не разберешься, что за приложение ломится в сеть, а без этого невозможно принять решение, пропускать его или нет.
NDIS драйвер способен
распозновать поступающие пакеты и передавать их соответствующим частям
вашего софта, да еще так, что этот самый софт думает что он единолично
передает и принимет сетевые пакеты.
Драйвер под Линух (все в одном) на многих уровнях OSI работает - на каких точно вспоминать влом )
Читайте также: