V3 driver что это

Обновлено: 24.01.2025

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

Формально, порты USB 2.0 ещё встречаются на современном железе, но управляются чаще контроллерами версии 3.0, а это значит что без интеграции драйверов в дистрибутив Windows 7 уже не обойтись, ведь семёрка ничего не знает о USB-контроллерах третьего поколения.

Существует несколько специализированных утилит для интеграции драйверов USB 3.0 в установщик Windows 7 от Intel, ASRock, MSI и Gigabyte:

Конечно, можно ещё интегрировать драйвера USB 3.0 вручную, при помощи утилиты DISM или использовать популярную программу для кастомизации дистрибутивов nLite, но зачем усложнять, если всё за вас уже сделали. Если будет интересно, могу рассказать (напишите в комментариях), но полагаю что и этих вариантов будет достаточно.

Лично мне больше по душе варианты от Intel и gigabyte. Сложного тут ничего нет, главное скачайте с сайта Microsoft оригинальный образ Windows 7 (всякие сборки тут могут не прокатить) и по возможности обзаведитесь быстрой флешкой.

Чтобы проверить тип вашего драйвера принтера, выполните следующие действия:

Нажмите клавиши Windows + R или выберите Пуск, введите команду «Выполнить» и выберите её.

Введите printmanagement.msc и нажмите ввод или нажмите кнопку ОК.

Разверните «Серверы печати», разверните имя своего компьютера и выберите элемент «Принтеры». Теперь вы можете увидеть тип драйвера для каждого из установленных драйверов принтера в правой колонке.

Как сделать установочную флешку Windows 7 с USB 3.0 на примере Windows 7 USB 3.0 Creator Utility

Важно! Windows 7 USB 3.0 Creator Utility от Intel работает только на Windows 8.1 и выше.

Ранее на сайте Intel была даже небольшая инструкция по работе с данной утилитой, скачать можно отсюда . Переписываем образ диска Windows 7 (предварительно скачиваем с сайта Microsoft) на флешку с помощью утилиты Rufus (о ней я уже рассказывал подробнее ).

Далее, запустив Windows 7 USB 3.0 Creator Utility остаётся только указать нашу флешку и ждать. Хочу заметить, что на медленных флешках процесс может затянуться на пару часов. Показателем что всё готово, в случае с Windows 7 USB 3.0 Creator Utility будет надпись «SUCCESS!».

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

Опасные 3rd-party драйверы в вашей системе или LOLDrivers

А вы знали, что вполне легитимный драйвер может дать злоумышленнику возможность прописаться в вашей системе надолго, оставаясь внутри даже после ее переустановки? Или превратить ваш компьютер в кирпич? Например, некоторые безобидные на вид доверенные (подписанные) драйверы являются попутно инструментами для перезаписи BIOS. После такой атаки спасет лишь программатор.

В ОC Windows существуют доверенные приложения/скрипты/библиотеки с дополнительной интересной опасной функциональностью вроде исполнения произвольного кода, загрузки файлов, обхода UAC и т.п. Если подобная дополнительная функциональность встречается у компонента ядра, становится еще интереснее.

Начиная с Windows Vista x64, действует политика Driver Signature Enforcement (DSE) – все драйверы уровня ядра должны быть подписаны. Если злоумышленник (с правами пользователя/администратора) после проникновения в систему жаждет получить максимальный уровень доступа (установить kernel rootkit/bootkit/SMM-rootkit/BIOS-rootkit), ему придется как-то обойти требование подписи для драйвера. Возможность вызова из юзермода некоторых функций или инструкций в режиме ядра может дать злоумышленнику инструмент для повышения привилегий, раскрытия информации или вызова отказа в обслуживании. Назовем такую функциональность функциональностью двойного назначения (в некоторых случаях подобное могут называть уязвимостями или бэкдорами, однако дискуссия на тему корректности определения выходит за рамки этой статьи).

Способы решения проблемы:

Выполнить в консоли команду для добавления атрибута "direct"

Способ №2. Удалить обновление, выполнив в консоли с правами администратора команду (номер обновления подставляете в зависимости от версии вашей ОС):

Для Windows 10, версия 2004 и 20H2:

Для Windows 10, версия 1909:

После удаления данного обновления отключить дальнейшие обновления ОС на неделю пока не будет выпущено исправление.

Способ № 4. Для владельцев принтеров от Kyocera, столкнувшихся с данной проблемой.

Для принтеров Kyocera временно установите более старый драйвер KX версии 6.XXX.

Для принтеров Kyocera переустановите другие версии драйвера с сайта производителя или универсальные драйвера Microsoft (Classic Driver PLC, XPS Driver, Classic Universal Driver KPDL, KyoClassicUniversalPCL и др. - для разных моделей оборудования Kyocera вариант совместимого драйвера может отличаться).

Для принтеров Kyocera отключите шрифты устройства. Для этого откройте Панель управления > Устройства и принтеры. На устройстве Kyocera кликните правой кнопкой мыши. Настройка печати > Изображение > Шрифты. Поставьте флаг "Отключить шрифты устройства".

Способ №5. Для владельцев 1С, столкнувшихся при запуске конфигурации с проблемой выпадения BSOD APC_INDEX_MISMATCH.

Установите использовать другое устройство "по умолчанию". Для этого откройте Панель управления > Устройства и принтеры. На любом другом устройстве кликните правой кнопкой мыши и выберите "Использовать по умолчанию". Обратите внимание, что данный вариант не решает полностью проблему. Он позволит запустить программу 1С, но при попытке распечатать на принтере Kyocera, либо любом другом с type 3 драйверами может произойти BSOD.

upd. 15.03.2021 Разъяснения к способу № 4. Для владельцев принтеров от Kyocera, столкнувшихся с данной проблемой.

Аббревиатура "v4" в названии драйвера намекает, что он поддерживает архитектуру v4 драйверов печати от Microsoft (для любопытных все подробности по ссылке: https://docs.microsoft.com/en-us/windows-hardware/drivers/print/v4-printer-driver ). В общем итоге обозначения драйверов печати "type 4" и "v4" несут одинаковую смысловую нагрузку и их можно устанавливать.

Если нет v4 драйверов, пробуйте установить XPS драйвер, при условии, что он одобрен и сертифицирован Microsoft.

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

upd. 17.03.2021 Microsoft выпустили внеочередное обновление, исправляющее данную проблему.

Windows 10, версия 1803 — KB5001565 (Build 17134.2088)

Windows 10, версия 1809 — KB5001568 (Build 17763.1821)

Windows 10, версия 1909 — KB5001566 (Build 18363.1441)

Windows 10, версия 2004 и 20H2 — KB5001567 (Build 19041.868 и Build 19042.868)

Данное обновление:

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

Шаг 1. Всем рекомендуется перейти в центр обновлений Windows и запустить поиск и установку новых обновлений. Данное обновление помечено как "необязательное", потому самостоятельно оно не установится.

Шаг 2. Если вы включали режим direct для своих принтеров.

Убедитесь в наличии данной опции, выполнив команду в консоли с правами администратора:

Выводы

Если что-то подписано, то доверять этому все равно нельзя. Во-первых, подписать так-то можно что угодно, а во-вторых, этим подписанным (даже если оно от доверенного производителя) может воспользоваться злоумышленник.

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

Алгоритм поиска неисправности в драйвере LED лампы или Эркюль Пуаро отдыхает

Недавно один знакомый попросил меня помочь с проблемой. Он занимается разработкой LED ламп, попутно ими приторговывая. У него скопилось некоторое количество ламп, работающих неправильно. Внешне это выражается так – при включении лампа вспыхивает на короткое время (менее секунды) на секунду гаснет и так повторяется бесконечно. Он дал мне на исследование три таких лампы, я проблему решил, неисправность оказалась очень интересной (прямо в стиле Эркюля Пуаро) и я хочу рассказать о пути поиска неисправности.

LED лампа выглядит вот так:

Рис 1. Внешний вид разобранной LED лампы

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

Такое решение – разделить функциональные зоны излучения света, отвода тепла и генерации питающего тока – позволило получить высокие эксплуатационные характеристики лампы по надежности, долговечности и ремонтопригодности.
Минус таких ламп, как ни странно, прямо вытекает из ее плюсов – долговечная лампа не нужна производителям :). Историю о сговоре производителей ламп накаливания о максимальном сроке службы в 1000 часов все помнят?

Ну и не могу не отметить характерный внешний вид изделия. Мой «госконтроль» (жена) не разрешил мне ставить эти лампы в люстру, где они видны.

Вернемся к проблемам драйвера.

Вот так выглядит плата драйвера:

Рис 2. Внешний вид платы LED драйвера со стороны поверхностного монтажа

И с обратной стороны:

Рис 3. Внешний вид платы LED драйвера со стороны силовых деталей

Изучение ее под микроскопом позволило определить тип управляющей микросхемы – это MT7930. Это микросхема контроля обратноходового преобразователя (Fly Back), обвешанная разнообразными защитами, как новогодняя елка – игрушками.

В МТ7930 встроены защиты:

• от превышения тока ключевого элемента
• понижения напряжения питания
• повышения напряжения питания
• короткого замыкания в нагрузке и обрыва нагрузки.
• от превышения температуры кристалла

Декларирование защиты от короткого замыкания в нагрузке для источника тока носит скорее маркетинговый характер :)

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

Рис 4. LED Driver MT7930. Схема электрическая принципиальная

Анализ этой схемы и вдумчивое чтение мануала к микросхеме привело меня к выводу, что источник проблемы мигания – это срабатывание защиты после старта. Т.е. процедура начального запуска проходит (вспыхивание лампы – это оно и есть), но далее преобразователь выключается по какой-то из защит, конденсаторы питания разряжаются и цикл начинается заново.

Внимание! В схеме присутствуют опасные для жизни напряжения! Не повторять без должного понимания что вы делаете!

Для исследования сигналов осциллографом надо развязать схему от сети, чтобы не было гальванического контакта. Для этого я применил разделительный трансформатор. На балконе в запасах были найдены два трансформатора ТН36 еще советского производства, датированные 1975 годом. Ну, это вечные устройства, массивные, залитые полностью зеленым лаком. Подключил по схеме 220 – 24 – 24 -220. Т.е. сначала понизил напряжение до 24 вольт (4 вторичных обмотки по 6.3 вольта), а потом повысил. Наличие нескольких первичных обмоток с отводами дало мне возможность поиграть с разными напряжениями питания – от 110 вольт до 238 вольт. Такое решение конечно несколько избыточно, но вполне пригодно для одноразовых измерений.

Рис 5. Фото разделительного трансформатора

Из описания старта в мануале следует, что при подаче питания начинает заряжаться конденсатор С8 через резисторы R1 и R2 суммарным сопротивлением около 600 ком. Два резистора применены из требований безопасности, чтобы при пробое одного ток через эту цепь не превысил безопасного значения.

Итак, конденсатор по питанию медленно заряжается (это время порядка 300-400 мс) и когда напряжение на нем достигает уровня 18,5 вольт – запускается процедура старта преобразователя. Микросхема начинает генерировать последовательность импульсов на ключевой полевой транзистор, что приводит к возникновению напряжения на обмотке Na. Это напряжение используется двояко – для формирования импульсов обратной связи для контроля выходного тока (цепь R5 R6 C5) и для формирования напряжения рабочего питания микросхемы (цепь D2 R9). Одновременно в выходной цепи возникает ток, который и приводит к зажиганию лампы.

Почему же срабатывает защита и по какому именно параметру?

Первое предположение

Срабатывание защиты по превышению выходного напряжения?

Для проверки этого предположения я выпаял и проверил резисторы в цепи делителя (R5 10 ком и R6 39 ком). Не выпаивая их не проверить, поскольку через обмотку трансформатора они запараллелены. Элементы оказались исправны, но в какой-то момент схема заработала!

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

Дал схеме поработать часок – все ОК.

А если дать ей остыть? После 20 минут в выключенном состоянии не работает.

Очень хорошо, видимо дело в нагреве какого-то элемента?

Но какого? И какие же параметры элемента могут уплывать?

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

Второе предположение

Подозрение пало на трансформатор. Проблема мыслилась так – трансформатор из-за неточностей изготовления (скажем на пару витков недомотана обмотка) работает в области насыщения и из-за резкого падения индуктивности и резкого нарастания тока срабатывает защита по току полевого ключа. Это резистор R4 R8 R19 в цепи стока, сигнал с которого подается на вывод 8 (CS, видимо Current Sense) микросхемы и используется для цепи ОС по току и при превышении уставки в 2.4 вольта отключает генерацию для защиты полевого транзистора и трансформатора от повреждений. На исследуемой плате стоит параллельно два резистора R15 R16 с эквивалентным сопротивлением 2,3 ома.

Но насколько я знаю, параметры трансформатора при нагреве ухудшаются, т.е. поведение системы должно быть другим – включение, работа минут 5-10 и выключение. Трансформатор на плате весьма массивный и тепловая постоянная у него ну никак не менее единиц минут.
Может, конечно в нем есть короткозамкнутый виток, который исчезает при нагреве?

Перепайка трансформатора на гарантированно исправный была в тот момент невозможна (не привезли еще гарантированно рабочую плату), поэтому оставил этот вариант на потом, когда совсем версий не останется :). Плюс интуитивное ощущение – не оно. Я доверяю своей инженерной интуиции.

К этому моменту я проверил гипотезу о срабатывании защиты по току, уменьшив резистор ОС по току вдвое припайкой параллельно ему такого же – это никак не повлияло на моргание лампы.

Значит, с током полевого транзистора все нормально и превышения по току нет. Это было хорошо видно и по форме сигнала на экране осциллографа. Пик пилообразного сигнала составлял 1,8 вольта и явно не достигал значения в 2,4 вольта, при котором микросхема выключает генерацию.

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

Третье предположение

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

По прежнему, система мигала в холодном состоянии и начинала нормально работать при прогреве ножки трансформатора паяльником. Секунд 15 погреть – и все нормально заводится.

Прогрев микросхемы паяльником ничего не давал.

И очень смущало малое время нагрева… что там может за 15 секунд измениться?

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

Что же еще может мешать переходу от режима запуска в рабочий режим.

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

И тут наступило счастье. Заработало!

Замена конденсатора 10 мкф на 22 мкф полностью решило проблему.

Вот он, виновник проблемы:

Рис 6. Конденсатор с неправильной емкостью

Теперь стал понятен механизм неисправности. Схема имеет две цепи питания микросхемы. Первая, запускающая, медленно заряжает конденсатор С8 при подаче 220 вольт через резистор в 600 ком. После его заряда микросхема начинает генерировать импульсы для полевика, запуская силовую часть схемы. Это приводит к генерации питания для микросхемы в рабочем режиме на отдельной обмотке, которое поступает на конденсатор через диод с резистором. Сигнал с этой обмотки также используется для стабилизации выходного тока.

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

Отловить эту просадку напряжения питания осциллографом не получалось — слишком грубая оценка. Мне казалось, что все нормально.

Прогрев же платы увеличивал емкость конденсатора на недостающие проценты — и энергии уже хватало на нормальный запуск.

Понятно, почему только некоторая часть драйверов отказала при полностью исправных элементах. Сыграло роль причудливое сочетание следующих факторов:

• Малая емкость конденсатора по питанию. Положительную роль сыграл допуск на емкость электролитических конденсаторов (-20% +80%), т.е. емкости номиналом 10 мкф в 80% случаев имеют реальную емкость около 18 мкф. Со временем емкость уменьшается из-за высыхания электролита.
• Положительная температурная зависимость емкости электролитических конденсаторов от температуры. Повышенная температура на месте выходного контроля — достаточно буквально пары-тройки градусов и емкости хватает для нормального запуска. Если предположить, что на месте выходного контроля было не 20 градусов, а 25-27, то этого оказалось достаточно для практически 100% прохождения выходного контроля.

Производитель драйверов сэкономил конечно, применив емкости меньшего номинала по сравнению с референс дизайн из мануала (там указано 22 мкф) но свежие емкости при повышенной температуре и с учетом разброса +80% позволили партию драйверов сдать заказчику. Заказчик получил вроде бы работающие драйверы, которые со временем стали отказывать по непонятной причине. Интересно было бы узнать – инженеры производителя учли особенности поведения электролитических конденсаторов при повышении температуры и естественный разброс или это получилось случайно?

Опасная функциональность или функциональность двойного назначения

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

Повышение привилегий до уровня администратора/SYSTEM. Требуется чтение/запись физической памяти. Данную атаку можно совершить, например, с помощью драйвера ASMMAP от ASUS. Для этого надо прочитать физическую память и найти структуру EPROCESS (она является элементом связного списка), после чего пройтись по списку в поисках процесса, чей уровень привилегий мы хотим повысить, а также некоторого известного процесса с уровнем SYSTEM (например, lsass, wininit). Затем скопировать значение поля Token структуры системного процесса в структуру целевого процесса. Более детальное описание атаки приведено здесь.
Отключение SMEP. Для этого нужна запись в управляющий регистр cr4 (точнее, сброс его 20-го бита). Например, драйвер bandainamcoonline.sys не только отключает SMEP, но и услужливо исполняет код по переданному в него от пользователя указателю. Для заинтересовавшихся есть статья с подробным описанием работы драйвера.

Исполнение произвольного кода в режиме ядра. Требуется чтение/запись физической памяти и MSR. Смысл заключается в замене адреса (находится в одном из MSR), на который будет осуществлен переход при совершении системного вызова, на адрес расположения кода злоумышленника. Тут можно найти больше информации об этом. Попутно будет мешать PatchGuard, но с ним при желании можно разобраться.

Поскольку драйвер и PatchGuard оба выполняются в Ring 0, ничто не мешает драйверу отключить проверки PatchGuard (до тех пор, конечно, пока Microsoft не прислушается к Intel и не выйдет за рамки модели с двумя кольцами защиты). Разработчики ядра в Microsoft прекрасно осведомлены об этом факте и выполняют различные действия для скрытия расположения этого кода, обфускации его действий и используемых внутренних структур. Иными словами, из-за невозможности помешать вам модифицировать код PatchGuard они пытаются изо всех сил его скрыть.

— Blunden B. The Rootkit arsenal: Escape and evasion in the dark corners of the system.

Given that driver code and PatchGuard code both execute in Ring 0, there's nothing to prevent a KMD from disabling PatchGuard checks (unless, of course, Microsoft takes a cue from Intel and moves beyond a two-ring privilege model). The kernel engineers at Microsoft are acutely aware of this fact and perform all sorts of programming acrobatics to obfuscate where the code resides, what it does, and the internal data-structures that it manipulates. In other words, they can't keep you from modifying PatchGuard code, so they're going to try like hell to hide it.

— Blunden B. The Rootkit arsenal: Escape and evasion in the dark corners of the system.

Запись BIOS. Пример in the wild – Lojax. Злоумышленники взяли всем известный RwDrv.sys и использовали его для своих грязных целей: прочитали BIOS, модифицировали и записали обратно. Переустановка Windows тут не поможет, так как вредоносный код сидит в прошивке на SPI-flash. Если же перезаписать BIOS неудачно (или специально затереть), то тоже будет неприятно. В любом случае придется сгонять за программатором для исправления досадных последствий.
Вызов SMI-обработчика. Во-первых, не все BIOS’ы одинаково беззащитны против кода в режиме ring0: есть различные механизмы защиты от чтения/записи, так что возможна ситуация, при которой понадобится лезть ниже – в режим SMM (самый привилегированный). Один из способов туда попасть из режима ядра – дернуть SMI-обработчик (довольно часто среди них встречаются уязвимые). Для вызова SMI-обработчика надо иметь возможность писать в I/O порт, а это можно сделать только с привилегиями ring0. То есть драйвер с возможностью записи в I/O порты способен обнаружить уязвимый SMI-обработчик, который может дать злоумышленнику исполнять код в режиме SMM. В примере автор использует драйвер RwDrv.sys.
Информация о системе. Чтение памяти ядра (через чтение физической памяти), чтение BIOS, информация о настройках системы, подключенных устройствах и включенных/отключенных механизмах защиты (через чтение MSR, управляющих регистров, доступ к портам ввода/вывода), в некоторых случаях можно детектировать известный гипервизор (типа VirtualBox через MSR). Для данной задачи чаще всего подойдет даже драйвер, который может только читать, не обязательно писать. Например, для чтения физической памяти подойдет RamCaptureDriver64.sys от Belkasoft.

Если проанализировать различные статьи и заметки о CVE, то можно выделить некоторую классификацию потенциально опасных при доступе из ring3 функций в драйверах. В таблице ниже указаны опасные функции и источники информации о них.

И это далеко не весь список возможных опасных функций. Можно также говорить и о чтении/записи виртуальной памяти ядра, чтении/записи MMIO, доступе к PCI устройствами т.д.

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

В процессе создания данного материала на конференции DEFCON 27 в Лас-Вегасе исследователи Jesse Michael и Mickey Shkatov представили работу "Get off the kernel if you cant drive", в которой также рассказывается о данной проблеме, и мы рекомендуем изучить данный материал для полноты картины. Здесь очень просто и наглядно расписаны сценарии использования подобных драйверов и представлены примеры участков кода, отвечающих за наиболее критичную функциональность. И также представлен код по работе и поиску подобных драйверов.

Вообще стоит отметить, что данная тема уже достаточно давно волнует исследователей безопасности. Еще в 2018 году исследователь Александр Матросов в своей статье "What makes OS drivers dangerous for BIOS?" поднимал данный вопрос и демонстрировал, как достаточно просто можно проэксплотировать BIOS.

Способы обхода DSE

Давайте рассмотрим, какие вообще варианты есть у злоумышленника для обхода DSE (надо же как-то проникнуть в ring0). В таблице ниже собраны способы обхода DSE с их преимуществами и недостатками (для злоумышленника, а безопасники принимают к сведению). Стоит отметить, что данная информация относится к Windows x64, начиная с Vista.

Работает не для всех приложений
Появляется водяной знак на рабочем столе
Необходима перезагрузка

При обнаружении утечки сертификат добавляется в Certificate Revocation List (CRL)

Сложность обнаружения подобных уязвимостей
Зависимость от версий ОС

Сложность модификации
Необходим способ обхода Secure Boot (если включен)
Необходима перезагрузка
Зависимость от версий ОС
Контроль файлов другими средствами защиты

Сложность обнаружения подобных уязвимостей
Блокировка средствами защиты при обнаружении

Сложность поиска (для злоумышленника) драйвера с требуемой функциональностю двойного назначения

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

Microsoft подтвердила проблемы с мартовскими обновлениями для различных версий Windows 10

После установки мартовского обновления KB5000802 (Windows 10, версия 2004 и 20H2, для других версий см. список ниже) вы можете получить ошибку APC_INDEX_MISMATCH в win32kfull.sys при попытке печати на определенных моделях принтеров в некоторых приложениях. Эта проблема затрагивает подмножество драйверов принтера типа 3 (type 3) и не влияет на драйверы принтера типа 4 (type 4).

Проблемы наблюдаются у владельцев оборудования фирмы Kyocera, а также Oki, Ricoh, Konica Minolta, Zebra. Кроме этого были отмечены проблемы с печатью на некоторых моделях принтеров других производителей (Epson, Brother, Lexmark) в виде непечатаемых вертикальных белых полос или наоборот печати полностью черных блоков вместо штрихкодов.

Драйверы с функциями двойного назначения

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

RwDrv.sys – очень популярный драйвер (поставляется с утилитой RWeverything). Читает и пишет физическую память, I/O порты, MSR и управляющие регистры. Был неоднократно использован в разных PoC’ах, а потом и в настоящем ранее упомянутом рутките Lojax. Для него написан интерфейс на C++, а также он используется в chipsec.

Читает и пишет физическую память, порты и MSR. Есть несколько PoC-утилит с его использованием (здесь и здесь).

pcdsrvc_x64 – драйвер от Dell, за дополнительной информацией обращаться в этот пост. Позволяет читать/писать физическую память и в I/O порты.

AsIO64.sys

Он предоставляет возможность чтения/записи физической памяти и I/O портов, а также вместе с ним идет удобная dll’ка для выполнения этих запросов.

Asmmap64.sys – еще один драйвер от ASUS, позволяющий читать/писать физическую память, I/O порты и MSR. Для злоумышленника он был бы особенно приятен, поскольку доступ к драйверу может быть осуществлен от обычного пользователя без прав администратора. Любопытные могут обратиться к первоисточнику.

ntiolib_x64.sys/winio64.sys – драйверы от MSI, подробно о них рассказано в ранее упомянутой статье. С помощью ntiolib_x64.sys можно читать/писать физическую память, I/O порты и MSR, winio64.sys предоставляет все эти функции, кроме MSR.

Обычно описанные опасные функции признают уязвимостями, если драйвер доступен пользователю без прав администратора (неправильный ACL) или когда позволяет исполнять произвольный код напрямую (как в bandainamcoonline.sys). В остальных случаях это просто функциональность, и раз у пользователя есть права администратора, то он может использовать все функции драйверов и это норма.

Если вы думаете, что подобных драйверов не больше десятка, то сильно ошибаетесь. Можете посмотреть данную подборку интересных драйверов. В этом списке есть драйверы от ASUS, AVAST, Razer, LG, American Megatrends и других известных компаний. Так что их много, нужно просто поискать. А значит, они представляют реальную угрозу.

Данную угрозу понимают и сотрудники Microsoft. И будут признательны за информацию о подобных драйверах ;)

Список проблемных обновлений для различных версий Windows 10:

Windows 10, версия 1803 — KB5000809 (Build 17134.2087)

Windows 10, версия 1809 — KB5000822 (Build 17763.1817)

Windows 10, версия 1909 — KB5000808 (Build 18363.1440)

Windows 10, версия 2004 и 20H2 — KB5000802 (Build 19041.867 и Build 19042.867)

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