Mbt transport driver что это

Обновлено: 25.01.2025

Для будущих студентов курса «Сетевой инженер» и всех интересующихся подготовили полезную статью.

Также приглашаем на открытый вебинар по теме «NAT — не Firewall». Участники вебинара вместе с экспертом рассмотрят NAT и его использование, почему NAT != firewall, а также различные виды конфигураций для разных ситуаций.

В данной статье будет проведено исследование сетевой подсистемы ОС Windows и Linux, а также предложен план изучения подсистем операционной системы. Основная задача исследования - понять, из чего состоит сетевая подсистема; какие поддерживает протоколы из коробки; какие дополнительные механизмы использует в своей работе.

Disclamer: Статья описывает данные, которые с точки зрения автора помогут понять, как работают операционные системы с моделью TCP/IP, и не претендует на полноту.

Инструментарий и метод исследования

Для исследования операционной системы будем использовать следующие инструменты:

Операционная система Linux:

Visual Studio Code;

Операционная система Windows:

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

В нашем исследовании будем руководствоваться двумя правилами:

Используем всю информацию из документации операционных систем;

Проверяем правдивость описанных данных. Для структур данных:

В ОС Windows исследуем соответствующие функционалу dll, sys файлы;

В ОС Linux исследуем исходные коды и отдельные ветки ядра;

Теперь определимся с проблемами, которые вероятно будут нас преследовать на протяжении всего исследования.

Проблемы при исследовании ОС Linux

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

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

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

ограниченности исследования по времени;

объем исходного кода;

принятые правила кодирования проекта.

Как минимизировать количество действий исследователя, чтобы получить как можно больше полезной и интересной информации? Огромную роль играет правильно настроенное рабочее место. В нашем случае верную настройку определяет набор инструментов, который мы описали в разделе "Инструментарий и метод исследования". Также можно применить небольшой лайфхак и не рассматривать каждую строку исходников ядра, а рассматривать только высокоуровневые элементы. Это сэкономит время на изучение языка программирования и даст возможность разобраться, что к чему. Попробуем применить эту тактику на практике.

PCI Express Config Space

Немного отвлечёмся на один нюанс про PCIE Config Space. С этим адресным пространством не всё так просто - со времён шины PCI для доступа к её конфигурационному пространству используется метод с использованием I/O портов 0xCF8 / 0xCFC. Он применён и в нашем драйвере AsrDrv101:

Чтение и запись PCI Config Space

Но через этот метод доступны только 0x100 байт конфигурационного пространства, в то время как в стандарте PCI Express размер Config Space у устройств может быть достигать 0x1000 байт! И полноценно вычитать их можно только обращением к PCI Extended Config Space, которая замаплена где-то в адресном пространстве, обычно чуть пониже BIOS:

Адресное пространство современного x86 компа, 0-4 ГБ

На чипсетах Intel (ну, в их большинстве) указатель на эту область адресного пространства можно взять из конфига PCI устройства 0:0:0 по смещению 0x60, подробнее описано в даташитах:

У AMD я такого не нашёл (наверняка есть, плохо искал), но сам факт неуниверсальности пнул меня в сторону поиска другого решения. Погуглив стандарты, я обнаружил, что указатель на эту область передаётся системе через ACPI таблицу MCFG

А сами ACPI таблицы можно найти через запись RSDP, поискав её сигнатуру по адресам 0xE0000-0xFFFFF, а затем распарсив табличку RSDT. Отлично, здесь нам и пригодится функционал поиска по памяти. Получаем нечто такое:

На всякий случай оставляем вариант для чипсетов Intel

Всё, теперь осталось при необходимости заменить чтение PCI Express Config Space через драйвер на чтение через память. Теперь-то разгуляемся!

Шаг 3. Выполните обновление Windows.

Читаем BIOS

В качестве примера применения нашего "тулкита", попробуем набросать скрипт чтения BIOS. Он должен быть "замаплен" где-то в конце 32-битного адресного пространства, потому что компьютер начинает его исполнение с адреса 0xFFFFFFF0. Обычно в ПК стоит флеш-память объёмом 4-16 МБ, поэтому будем "сканировать" адресное пространство с адреса 0xFF000000, как только найдём что-нибудь непустое, будем считать, что тут начался BIOS:

В результате получаем:

Вот так в 10 строчек мы считали BIOS

Но подождите-ка, получилось всего 6 мегабайт, а должно быть 4 или 8 что-то не сходится. А вот так, у чипсетов Intel в адресное пространство мапится не вся флешка BIOS, а только один её регион. И чтобы считать всё остальное, нужно уже использовать SPI интерфейс.

Не беда, лезем в даташит, выясняем, что SPI интерфейс висит на PCI Express:

И для его использования, нужно взаимодействовать с регистрами в BAR0 MMIO по алгоритму:

Задать адрес для чтения в BIOS_FADDR

Задать параметры команды в BIOS_HSFTS_CTL

Прочитать данные из BIOS_FDATA

Пилим новый скрипт для чтения через чипсет:

Исполняем и вуаля - в 20 строчек кода считаны все 8 МБ флешки BIOS! (нюанс - в зависимости от настроек, регион ME может быть недоступен для чтения).

Точно так же можно делать всё, что заблагорассудится - делать снифер USB пакетов, посылать произвольные ATA команды диску, повышать частоту процессора и переключать видеокарты. И это всё - с обычными правами администратора:

Немного помучившись, получаем ответ от SSD на команду идентификации

А если написать свой драйвер?

Некоторые из вас наверняка уже подумали - зачем так изворачиваться, реверсить чужие драйвера, если можно написать свой? И я о таком думал. Более того, есть Open-Source проект chipsec, в котором подобный драйвер уже разработан.

Зайдя на страницу с кодом драйвера, вы сразу наткнетесь на предупреждение:

В этом предупреждении как раз и описываются все опасности, о которых я рассказывал в начале статьи - инструмент мощный и опасный, следует использовать только в Windows режиме Test Mode, и ни в коем случае не подписывать. Да, без специальной подписи на обычной системе просто так запустить драйвер не получится. Поэтому в примере выше мы и использовали заранее подписанный драйвер от ASRock.

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

Точнее я так думал, до вот этой статьи, глаз зацепился за крайне интересный абзац:

У меня под рукой нет Windows DDK, так что я взял 64-битный vfd.sys , скомпилированный неким critical0, и попросил dartraiden подписать его «древне-китайским способом». Такой драйвер успешно загружается и работает, если vfdwin запущена с правами администратора

Драйвер из статьи действительно подписан, и действительно неким китайским ключом:

Как оказалось, сведения о подписи можно просто посмотреть в свойствах.. А я в HEX изучал

Немного поиска этого имени в гугле, и я натыкаюсь на вот эту ссылку, откуда узнаю, что:

есть давно утёкшие и отозванные ключи для подписи драйверов

если ими подписать драйвер - он прекрасно принимается системой

малварщики по всему миру используют это для создания вирусни

Основная загвоздка - заставить майкрософтский SignTool подписать драйвер истёкшим ключом, но для этого даже нашёлся проект на GitHub. Более того, я нашёл даже проект на GitHub для другой утилиты подписи драйверов от TrustAsia, с помощью которого можно подставить для подписи вообще любую дату.

Несколько минут мучений с гугл-переводчиком на телефоне, и мне удалось разобраться в этой утилите и подписать драйвер одним из утекших ключей (который довольно легко отыскался в китайском поисковике):

И в самом деле, китайская азбука

И точно так же, как и AsrDrv101, драйвер удалось без проблем запустить!

А вот и наш драйвер запустился

Из чего делаю вывод, что старая идея с написанием своего драйвера вполне себе годная. Как раз не хватает функции маппинга памяти. Но да ладно, оставлю как TODO.

Сетевая подсистема Linux

Начнем наше исследование с вот такой интересной картинки:

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

Код, который относится к сетевой подсистеме, находится в директории "net". Посмотрим, из чего он состоит.

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

Оставшиеся файлы в директории "net" описывают работу ядра с различными протоколами. Интересным моментом здесь является то, что фильтрующая подсистема имеет какие-то файлы только в некоторых протоколах и подсистемах:

Прямоугольниками выделены те протоколы и подсистемы, которые содержат файлы netfilter . Как видно из картинки, механизм фильтрации трафика работает не со всеми протоколами. Также интересно то, что он присутствует не только в протоколах, но и в более высокоуровневой абстракции - bridge. Теперь понятно, почему bridge от Linux можно настроить настолько гибко и контролировать пересылаемые данные.

Что в итоге? Всего по 4м картинкам структуры исходных кодов ядра мы уже обладаем информацией о том, какие поддерживаются протоколы в ядре Linux, какие механизмы интегрированы в протоколы для контроля и фильтрации и где найти базовые элементы, которые позволяют использовать сеть. Попробуем найти эту информацию и в ОС Windows.

Через Python в дебри

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

Первым делом нужно установить драйвер в систему и запустить его. Делаем "как положено" и сначала кладём драйвер (нужной разрядности!) в System32:

Раньше в похожих ситуациях я извращался с папкой %WINDIR%\Sysnative, но почему-то на моей текущей системе такого алиаса не оказалось, хотя Python 32-битный. (по идее, на 64-битных системах обращения 32-битных программ к папке System32 перенаправляются в папку SysWOW64, и чтобы положить файлик именно в System32, нужно обращаться по имени Sysnative).

Затем регистрируем драйвер в системе и запускаем его:

А дальше запущенный драйвер создаёт виртуальный файл (кстати, та самая колонка "имя" в таблице с анализом дров), через запросы к которому и осуществляются дальнейшие действия:

И ещё одна полезная программа для ползания по системе, WinObj

Тоже ничего особенного, открываем файл и делаем ему IoCtl:

Вот здесь чутка подробнее. Я долго думал, как же обеспечить адекватную обработку ситуации, когда таких "скриптов" запущено несколько. Не останавливать драйвер при выходе нехорошо, в идеале нужно смотреть, не использует ли драйвер кто-то ещё и останавливать его только если наш скрипт "последний". Долгие упорные попытки получить количество открытых ссылок на виртуальный файл драйвера ни к чему не привели (я получал только количество ссылок в рамках своего процесса). Причём сама система точно умеет это делать - при остановке драйвера с открытым файлом, он остаётся висеть в "Pending Stop". Если у кого есть идеи - буду благодарен.

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

А дальше просто реверсим драйвер и реализуем все нужные нам вызовы:

Легко и непринуждённо в пару команд читаем физическую память

Выводы?

Как видите, имея права администратора, можно делать с компьютером практически что угодно. Будьте внимательны - установка утилит от производителя вашего железа может обернуться дырой в системе. Ну а желающие поэкспериментировать со своим ПК - добро пожаловать на низкий уровень! Наработки выложил на GitHub. Осторожно, бездумное использование чревато BSODами.

В Windows есть фича "Изоляция ядра", которая включает I/O MMU, защищает от DMA атак и так далее (кстати об этом - в следующих сериях)

Так вот, при включении этой опции, некоторые драйвера (в том числе RW Everything и китайско-подписанный chipsec_hlpr) перестают запускаться:

Последнее обновление: 06/30/2021 [Необходимое время для чтения:

Файлы SYS, такие как netbt.sys, классифицируются как файлы Win64 EXE (Драйвер). Как файл MBT Transport driver он был создан для использования в Microsoft® Windows® Operating System от компании Microsoft.

Файл netbt.sys изначально был выпущен с Windows XP 10/25/2001 для ОС Windows XP. Датой самого последнего выпуска файла для Microsoft Office Access 2010 14 является 07/04/2011 [версия 10.0.16299.1087 (WinBuild.160101.0800)]. Файл netbt.sys включен в версии ОС Windows 10, Windows 8.1 и Windows 8.

Ниже приведены подробные сведения о файле, порядок устранения неполадок, возникших с файлом SYS, и бесплатные загрузки некоторых версий файла netbt.sys.

Совместимость с Windows 10, 8, 7, Vista, XP и 2000

Средняя оценка пользователей

Краткий обзор драйверов спецификации NDIS

Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т.п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку:

Минипорт-драйверы (драйверы адаптера)
Промежуточные драйверы (например, psched.sys)
Драйверы протокола (например, tcpip.sys)

Минипорт-драйверы

производит инициализацию своего устройства (адаптера)
создание /включение/выключение/удаление сетевых подключений
выдача клиенту или изменение параметров адаптера
отправка пакетов
получение пакетов
оповещение ОС о состоянии адаптера
перезагрузка и остановка адаптера

Минипорт-драйверы бывают «Connectionless» (например, драйвер Ethernet-адаптера) и «Сonnection-oriented» (например, драйвер модема). У Сonnection-oriented драйверов система коллбэков чуть сложнее, в нее входят обработчики событий, связанных с подключением к каналу связи, отключением от канала, выбором канала (для беспроводных адаптеров) и т.п. Для некоторых операций Сonnection-oriented драйверы вызывают специальные функции NDIS, отличающиеся префиксом «Со» в имени (например, вместо NdisMIndicateReceivePacket Сonnection-oriented драйвер должен вызывать NdisMColndicateReceivePacket).

Каждый коллбэк выполняет свою задачу: выдача информации, отправка данных, прием данных и т.п. Подробнее можно посмотреть в хелпе к WDK (DDK). Там можно получить полную информацию о коллбэках.

Драйверы протоколов могут передоверять минипорт-драйверу (при условии, что минипорт-драйвер это умеет — либо сам, либо адаптер умеет это делать на аппаратном уровне) некоторые свои функции (например, разграничить контрольную сумму или цифровую подпись IP-пакета или принять решение, как фрагментировать большой ТСP-пакет). Это значительно повышает производитель сети.

LBFO (Load Balancing and Fail Over) — позволяет понимающим его адаптерам распределять между собой исходящий трафик и исправлять ошибки друг друга. Впрочем, что имеет смысл только на backbone routers (центральных маршрутизаторах больших сетей), на которые редко ставят Windows
FFP (Fast Forwarding Path) — позволяет понимающим его адаптерам маршрутизировать/фильтровать пакеты чисто аппаратно, вообще без участия ОС и не нагружая основные процессоры компьютера

Промежуточные драйверы

Промежуточный драйвер сверху виден как минипорт-драйвер (смотрим на картинку), т.е. как бы виртуальный адаптер, а снизу — как драйвер протокола (снова смотрим на картинку), как бы виртуальный протокол. Как частный случай, возможна ситуация, когда промежуточный драйвер виден только сверху.

организуют «справедливый» доступ разных клиентских программ к адаптерам дабы программы не мешали друг другу
фильтруют и перехватывают трафик
маршрутизируют пакеты из одной сети в другую, если эти сети различаются (например, Ethernet и WI-FI)

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

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

К драйверам протоколов относятся и драйверы транспорта, реализующие стек сетевых протоколов, такой как например TCP/IP (tspip.sys).

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

Шаг 2. Если вы недавно установили приложение Microsoft Office Access 2010 (или схожее программное обеспечение), удалите его, затем попробуйте переустановить Microsoft Office Access 2010.

Чтобы удалить программное обеспечение Microsoft Office Access 2010, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):

После полного удаления приложения следует перезагрузить ПК и заново установить Microsoft Office Access 2010.

Если на этапе 2 также не удается устранить ошибку netbt.sys, перейдите к шагу 3 ниже.

Microsoft Office Access 2010 14

Windows: достучаться до железа

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

Обзор файла

Сведения о разработчике и ПО
Разработчик ПО:	Microsoft Corporation
Программа:	Microsoft® Windows® Operating System
Авторское право:	© Microsoft Corporation. All rights reserved.

Сведения о файле
Набор символов:	Unicode
Код языка:	English (U.S.)
Флаги файлов:	(none)
Маска флагов файлов:	0x003f
Точка входа:	0x51010
Размер кода:	267264

Информация о файле	Описание
Размер файла:	309 kB
Дата и время изменения файла:	2020:03:04 15:22:02+00:00
Тип файла:	Win64 EXE
Тип MIME:	application/octet-stream
Тип компьютера:	AMD AMD64
Метка времени:	2090:11:07 07:17:26+00:00
Тип PE:	PE32+
Версия компоновщика:	14.10
Размер кода:	267264
Размер инициализированных данных:	53248
Размер неинициализированных данных:	0
Точка входа:	0x51010
Версия ОС:	10.0
Версия образа:	10.0
Версия подсистемы:	10.0
Подсистема:	Native
Номер версии файла:	10.0.16299.1087
Номер версии продукта:	10.0.16299.1087
Маска флагов файлов:	0x003f
Флаги файлов:	(none)
Файловая ОС:	Windows NT 32-bit
Тип объектного файла:	Driver
Подтип файла:	7
Код языка:	English (U.S.)
Набор символов:	Unicode
Наименование компании:	Microsoft Corporation
Описание файла:	MBT Transport driver
Версия файла:	10.0.16299.1087 (WinBuild.160101.0800)
Внутреннее имя:	netbt.sys
Авторское право:	© Microsoft Corporation. All rights reserved.
Название продукта:	Microsoft® Windows® Operating System
Версия продукта:	10.0.16299.1087

✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.

Прокси-драйвера

В итоге получается обходной манёвр – всё, что программе запрещено делать, разработчик вынес в драйвер, программа устанавливает драйвер в систему и уже через него программа делает, что хочет! Более того – выяснилось, что RW Everything далеко не единственная программа, которая так делает. Таких программ не просто много, они буквально повсюду. У меня возникло ощущение, что каждый уважающий себя производитель железа имеет подобный драйвер:

Софт для обновления BIOS (Asrock, Gigabyte, HP, Dell, AMI, Intel, Insyde…)

Софт для разгона и конфигурации железа (AMD, Intel, ASUS, ASRock, Gigabyte)

Софт для просмотра сведений о железе (CPU-Z, GPU-Z, AIDA64)

Софт для обновления PCI устройств (Nvidia, Asmedia)

Во многих из них практически та же самая модель поведения – драйвер получает команды по типу «считай-ка вот этот физический адрес», а основная логика – в пользовательском софте. Ниже в табличке я собрал некоторые прокси-драйвера и их возможности:

Результаты краткого анализа пары десятков драйверов. Могут быть ошибки!

Mem – чтение / запись физической памяти

PCI – чтение / запись PCI Configuration Space

I/O – чтение / запись портов I/O

Alloc – аллокация и освобождение физической памяти

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

MSR – чтение / запись x86 MSR (Model Specific Register)

Жёлтым обозначены возможности, которых явно нет, но их можно использовать через другие (чтение или маппинг памяти). Мой фаворит из этого списка – AsrDrv101 от ASRock. Он устроен наиболее просто и обладает просто огромным списком возможностей, включая даже функцию поиска шаблона по физической памяти (!!)

Неполный перечень возможностей AsrDrv101

Чтение / запись RAM

Чтение / запись IO

Чтение / запись PCI Configuration Space

Чтение / запись MSR (Model-Specific Register)

Чтение / запись CR (Control Register)

Чтение TSC (Time Stamp Counter)

Чтение PMC (Performance Monitoring Counter)

Alloc / Free физической памяти

Поиск по физической памяти

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

Netbt.sys — ошибки «синего экрана» (BSOD)

Существует ряд причин, по которым вы можете столкнуться с проблемами с netbt.sys. Большинство проблем с файлами SYS связаны с ошибками «синего экрана» (BSOD). Эти типы ошибок netbt.sys могут быть вызваны аппаратными проблемами, устаревшей прошивкой, поврежденными драйверами или другими проблемами, связанными с программным обеспечением (например, обновление Microsoft Office Access 2010). В число этих ошибок входят:

Не удается найти netbt.sys.
Не удалось загрузить netbt.sys.
Файл netbt.sys отсутствует или поврежден.
Windows не удалось запустить — netbt.sys.

Обнаружена проблема, в результате которой ОС Windows завершила работу, чтобы предотвратить повреждение компьютера. По всей видимости, причиной проблемы стал следующий файл: netbt.sys.

:( На вашем ПК возникла проблема, которую не удалось устранить, и его необходимо перезагрузить. Сведения об ошибке можно найти в Интернете: [BSOD] (netbt.sys).

STOP 0x0000001E: KMODE EXCEPTION NOT HANDLED (netbt.sys)
STOP 0x00000050: PAGE FAULT IN A NONPAGED AREA (netbt.sys)
STOP 0x0000007E: SYSTEM THREAD EXCEPTION NOT HANDLED (netbt.sys)
STOP 0x0000000A: IRQL NOT LESS EQUAL (netbt.sys)
STOP 0×0000007A: KERNEL DATA INPAGE (netbt.sys)
STOP 0x0000003B: SYSTEM SERVICE EXCEPTION (netbt.sys)

Крайне важно устранять ошибки «синего экрана»

В большинстве случаев ошибки BSOD netbt.sys возникают после установки нового оборудования, программного обеспечения (Microsoft Office Access 2010) или выполнения неудачного обновления Windows. В остальных случаях к ошибке «синего экрана» netbt.sys может привести повреждение программного обеспечения, вызванное заражением вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.

СОВЕТ ОТ СПЕЦИАЛИСТА: Как показывает опыт, целесообразно всегда создавать резервную копию системы Windows и (или) точку восстановления системы, прежде чем вносить какие-либо изменения в аппаратное или программное обеспечение на компьютере. Таким образом, в случае неблагоприятного поворота событий и возникновения связанной с файлом netbt.sys ошибки «синего экрана» после недавних изменений можно восстановить систему в предыдущее состояние.

ОС 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`е. Если нужно восстановить и эти данные, то нужно использовать отладчик ядра.

Таким образом, проводить исследование подсистем любых ОС и их механизмов можно с исходным кодом и без — достаточно выбрать необходимый набор инструментов, а также доступные методы, источники знаний.

Если эти шаги не принесут результата: скачайте и замените файл netbt.sys (внимание: для опытных пользователей)

Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла netbt.sys. Мы храним полную базу данных файлов netbt.sys со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии Microsoft Office Access 2010 . Чтобы загрузить и правильно заменить файл, выполните следующие действия:

Windows 10: C:\Windows\WinSxS\amd64_microsoft-windows-netbt-minwin_31bf3856ad364e35_10.0.16299.15_none_0e98ad3449043908\
Windows 10: C:\Windows\System32\drivers\
Windows 10: C:\Windows\System32\drivers\
Windows 10: C:\Windows\Temp\527D94AF-D053-4381-B105-0D815D53791E\amd64_microsoft-windows-netbt-minwin_31bf3856ad364e35_10.0.16299.1087_none_f329203f098b0316\
Windows 10: C:\Windows\WinSxS\amd64_microsoft-windows-netbt-minwin_31bf3856ad364e35_10.0.16299.1087_none_f329203f098b0316\
Показать на 6 каталогов больше + Windows 8.1: C:\Windows\System32\drivers\
Windows 8: C:\Windows\System32\drivers\
Windows 7: C:\Windows\System32\drivers\
Windows Vista: C:\Windows\System32\drivers\
Windows XP: C:\WINDOWS\system32\dllcache\
Windows XP: C:\Windows\System32\drivers\

Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.

В чём суть, капитан?

В архитектуре x86 есть понятие «колец защиты» («Ring») – режимов работы процессора. Чем ниже номер текущего режима, тем больше возможностей доступно исполняемому коду. Самым ограниченным «кольцом» является «Ring 3», самым привилегированным – «Ring -2» (режим SMM). Исторически сложилось, что все пользовательские программы работают в режиме «Ring 3», а ядро ОС – в «Ring 0»:

Режимы работы x86 процессора

В «Ring 3» программам запрещены потенциально опасные действия, такие как доступ к I/O портам и физической памяти. По логике разработчиков, настолько низкоуровневый доступ обычным программам не нужен. Доступ к этим возможностям имеют только операционная система и её компоненты (службы и драйверы). И всё бы ничего, но однажды я наткнулся на программу RW Everything:

RW Everything действительно читает и пишет практически всё

Эта программа была буквально напичкана именно теми функциями, которые обычно запрещаются программам «Ring 3» - полный доступ к физической памяти, I/O портам, конфигурационному пространству PCI (и многое другое). Естественно, мне стало интересно, как это работает. И выяснилось, что RW Everything устанавливает в систему прокси-драйвер:

Смотрим последний установленный драйвер через OSR Driver Loader

Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):

Если на этапе 1 не удается устранить ошибку netbt.sys, перейдите к шагу 2 ниже.

Читайте также: