Возможно ли отключить драйвер dddriver64dcsa sys
Если ваш компьютер имеет 64-битную архитектуру и поддерживает технологии виртуализации Intel VT-X или AMD-v (поддерживаются большинством современных процессоров), то в Windows 10 вам доступны дополнительные функции безопасности на базе виртуализации.
Одна из таких функций называется “Изоляция ядра” (Core Isolation). Она использует аппаратную виртуализацию для изоляции критически важных частей ядра операционной системы от пользовательских драйверов и программного обеспечения, запущенного на компьютере. Изоляция ядра позволяет предотвратить доступ вредоносных программ и эксплойтов к защищенным зонам ядра и заблокировать попытки обхода контроля безопасности, инъекции вредоносных программ и другое потенциально опасное поведение.
Функция под названием “Целостность памяти” (Memory integrity) является подмножеством изоляции ядра. Она защищает от внедрения вредоносного кода в память при вредоносной атаке.
Целостность памяти — это функция Windows, которая гарантирует надежность кода, работающего в ядре Windows. Она использует аппаратную виртуализацию и Hyper-V для защиты процессов режима ядра Windows от инъекции и выполнения вредоносного или непроверенного кода. Целостность кода, который работает в Windows, проверяется с помощью целостности памяти, что позволяет Windows эффективно противостоять атакам вредоносных программ.
“Целостность памяти” могла блокировать драйверы
При включении Memory Integrity, функция блокирует компьютер и может вызывать проблемы с загрузкой или работой драйверов.
В новом документе поддержки Microsoft пояснила, что ошибки или обычно неопасные уязвимости драйверов могут приводить к тому, что “Целостность памяти” блокирует их загрузку.
В таких ситуациях Microsoft рекомендует проверить доступность обновленного драйвера, в котором уязвимость уже может быть исправлена.
Если данный вариант не сработал, то рекомендуется отключить функцию Memory Integrity, чтобы драйвер мог корректно загрузиться.
Для отключения “Целостности памяти”, выполните следующие шаги:
- Перейдите в Параметры > Обновление и безопасность > Безопасность Windows > Безопасность устройства и в секции Изоляция ядра кликните ссылку Сведения об изоляции ядра
В качестве альтернативы можно кликнуть по ссылке windowsdefender://coreisolation/ в Windows 10, чтобы открыть необходимую страницу.
- Когда откроется страница Изоляция ядра, установите переключатель Целостность памяти в неактивное положение. Windows 10 запросит перезагрузку компьютера.
- Выполните перезагрузку, и Целостность памяти будет отключена.
После этого, проверьте, остались ли проблемы с загрузкой драйверов. Если проблема сохранилась, то вам лучше получить помощь у производителя устройства и уточнить, когда станет доступен обновленный драйвер.
Иногда при установке абсолютно любого драйвера могут возникнуть проблемы. Одной из них является проблема с проверкой цифровой подписи драйвера. Дело в том, что по умолчанию можно инсталлировать только то ПО, которое имеет подпись. Причем эта подпись должна быть в обязательном порядке проверена компанией Microsoft и иметь соответствующий сертификат. Если такая подпись отсутствует, система просто напросто не позволит инсталлировать такое ПО. В данной статье мы расскажем вам о том, как обойти такое ограничение.
Как установить драйвер без цифровой подписи
В некоторых случаях даже самый проверенный драйвер может оказаться без соответствующей подписи. Но это не значит, что ПО вредоносное или плохое. Чаще всего от проблем с цифровой подписью страдают владельцы Windows 7. В последующих версиях ОС этот вопрос возникает гораздо реже. Выявить проблему с подписью можно по следующим симптомам:
Способ 1: Временное отключение проверки
Для вашего удобства мы разделим этот способ на две части. В первом случаем мы расскажем о том, как применить данный способ, если у вас установлена Windows 7 или ниже. Второй вариант подойдет лишь обладателям Windows 8, 8.1 и 10.
Если у вас Windows 7 или ниже
Если у вас Windows 8, 8.1 или 10
Независимо от того, какая у вас операционная система, этот способ имеет недостатки. После очередной перезагрузки системы, проверка подписей снова запустится. В некоторых случаях это может привести к блокировке работы драйверов, которые были инсталлированы без соответствующих подписей. Если такое произошло, вам следует отключить проверку насовсем. В этом вам помогут дальнейшие способы.
Способ 2: Редактор групповой политики
Этот способ позволит вам отключить проверку подписей навсегда (или до того момента, как вы сами ее активируете). После этого вы сможете спокойно инсталлировать и пользоваться софтом, который не имеет соответствующего сертификата. В любом случае, этот процесс можно обратить и включить проверку подписи обратно. Так что бояться вам нечего. Кроме того, этот способ подойдет владельцам любой ОС.
Способ 3: Командная строка
Этот способ весьма прост в использовании, но имеет свои недостатки, о которых мы расскажем в конце.
bcdedit.exe -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON
Обратим ваше внимание, что этот способ иногда приходится проделывать в безопасном режиме. Как запустить систему в безопасном режиме, вы можете узнать на примере нашего специального урока.
Воспользовавшись одним из предложенных способов, вы избавитесь от проблемы инсталляции сторонних драйверов. Если у вас возникли трудности с выполнением каких-либо действий, пишите об этом в комментариях к статье. Будем совместно решать возникшие трудности.
Отблагодарите автора, поделитесь статьей в социальных сетях.
Меня всегда интересовало низкоуровневое программирование – общаться напрямую с оборудованием, жонглировать регистрами, детально разбираться как что устроено. Увы, современные операционные системы максимально изолируют железо от пользователя, и просто так в физическую память или регистры устройств что-то записать нельзя. Точнее я так думал, а на самом деле оказалось, что чуть ли не каждый производитель железа так делает!
В чём суть, капитан?
В архитектуре 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
Прокси-драйвера
В итоге получается обходной манёвр – всё, что программе запрещено делать, разработчик вынес в драйвер, программа устанавливает драйвер в систему и уже через него программа делает, что хочет! Более того – выяснилось, что 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 физической памяти
Поиск по физической памяти
Самое нехорошее в такой ситуации - если подобный драйвер остаётся запущенным на ПК пользователя, для обращения к нему не нужно даже прав администратора! То есть любая программа с правами пользователя сможет читать и писать физическую память - хоть пароли красть, хоть ядро пропатчить. Именно на это уже ругались другие исследователи. Представьте, что висящая в фоне софтина, красиво моргающая светодиодиками на матплате, открывает доступ ко всей вашей системе. Или вирусы намеренно ставят подобный драйвер, чтобы закрепиться в системе. Впрочем, любой мощный инструмент можно в нехороших целях использовать.
Через Python в дебри
Конечно же я захотел сделать свой небольшой "тулкит" для различных исследований и экспериментов на базе такого драйвера. Причём на Python, мне уж очень нравится, как просто выглядит реализация сложных вещей на этом языке.
Первым делом нужно установить драйвер в систему и запустить его. Делаем "как положено" и сначала кладём драйвер (нужной разрядности!) в System32:
Раньше в похожих ситуациях я извращался с папкой %WINDIR%\Sysnative, но почему-то на моей текущей системе такого алиаса не оказалось, хотя Python 32-битный. (по идее, на 64-битных системах обращения 32-битных программ к папке System32 перенаправляются в папку SysWOW64, и чтобы положить файлик именно в System32, нужно обращаться по имени Sysnative).
Затем регистрируем драйвер в системе и запускаем его:
А дальше запущенный драйвер создаёт виртуальный файл (кстати, та самая колонка "имя" в таблице с анализом дров), через запросы к которому и осуществляются дальнейшие действия:
И ещё одна полезная программа для ползания по системе, WinObj
Тоже ничего особенного, открываем файл и делаем ему IoCtl:
Вот здесь чутка подробнее. Я долго думал, как же обеспечить адекватную обработку ситуации, когда таких "скриптов" запущено несколько. Не останавливать драйвер при выходе нехорошо, в идеале нужно смотреть, не использует ли драйвер кто-то ещё и останавливать его только если наш скрипт "последний". Долгие упорные попытки получить количество открытых ссылок на виртуальный файл драйвера ни к чему не привели (я получал только количество ссылок в рамках своего процесса). Причём сама система точно умеет это делать - при остановке драйвера с открытым файлом, он остаётся висеть в "Pending Stop". Если у кого есть идеи - буду благодарен.
В конечном итоге я "подсмотрел", как это делают другие программы. Выяснилось, что большинство либо не заморачиваются, либо просто ищут запущенные процессы с тем же именем. Но одна из исследованных программ имела кардинально другой подход, который я себе и перенял. Вместо того, чтобы переживать по количеству ссылок на файл, просто на каждый запрос открываем и закрываем файл! А если файла нет, значит кто-то остановил драйвер и пытаемся его перезапустить:
А дальше просто реверсим драйвер и реализуем все нужные нам вызовы:
Легко и непринуждённо в пару команд читаем физическую память
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 через драйвер на чтение через память. Теперь-то разгуляемся!
Читаем 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.
Выводы?
Как видите, имея права администратора, можно делать с компьютером практически что угодно. Будьте внимательны - установка утилит от производителя вашего железа может обернуться дырой в системе. Ну а желающие поэкспериментировать со своим ПК - добро пожаловать на низкий уровень! Наработки выложил на GitHub. Осторожно, бездумное использование чревато BSODами.
В Windows есть фича "Изоляция ядра", которая включает I/O MMU, защищает от DMA атак и так далее (кстати об этом - в следующих сериях)
Так вот, при включении этой опции, некоторые драйвера (в том числе RW Everything и китайско-подписанный chipsec_hlpr) перестают запускаться:
В этой статье постараюсь описать методику диагностики проблем с неподписанными файлами драйверов в x64 битной версии Windows систем, из-за которых компьютер перестает загружаться и при загрузке падает в BSOD. Но систему все-таки можно загрузить, отключив проверку цифровой подписи при загрузке (F8 -> Disable Driver Signature Enforcement). В качестве примера в этой статье я буду работать с Windows Server 2008 R2 (которая, напомню, бывает только в 64-разрядной редакции), но данная методика подойдет так и для Windows 7 x64 и Vista x64.
Если вернуться к предыстории вопроса, то вспомним, что Microsoft приняла решение о том, что в 64-битных системах, начиная с Windows Vista, Windows загружает драйвера в режим ядра только в том случае, если драйвер имеет цифровую подпись. Если же цифровая подпись драйвера отсутствует, то при загрузке системы случается критическая ошибка (зависит от типа драйвера, загрузка которого заблокирована) и появляется экран BSOD. Конкретная ошибка и ее код зависят от конкретного драйвера, который заблокирован в процессе загрузки. Некоторые ошибок прямо на экране BSOD могут указывать на файл неподписанного драйвера.
В моем случае после обновления драйверов на сервере Windows 2008 r2 при обычной загрузки машины появился синий экран смерти с текстом:
STOP: c000021a (fatal System Error)
The initial session process or system process terminated unexpectedly with a status of 0x00000000 (0xc000428 0x00100448). The system has been shut down
Попробуем выяснить что это за ошибка, какой драйвер ее вызывает т определим по драйверу конкретное устройство.
Преобразуем hex код ошибки в более удобочитаемую форму. Для этого можно воспользоваться встроенной в Windows утилитой SLUI.EXE или же сопоставить код этой ошибки в файле ntstatus.h, найти который можно в Windows SDK. Воспользуемся первым способом, для чего в командной строке выполним:
Как вы видите на скриншоте, мы убедились в том, что BSOD вызвана невозможностью проверить цифровую подпись драйвера (“Windows cannot verify digital signature for this file”)
Перезагружаем наш компьютер и при загрузке жмем клавишу F8. В расширенном загрузочном меню (Advanced Boot Options) отключаем проверку цифровой подписи, выбрав Disable Driver Signature Enforcement .
В том случае, если в таком режиме сервер загрузиться, мы точно уверены в том, что некий неподписанный модуль или драйвер не позволяет системе нормально загрузиться.
Следующий шаг – определение файла проблемного модуля или драйвера. Откроем консоль журнал событий (Event Viewer) и перейдем в раздел Applications and Services Logs -> Microsoft -> Windows -> CodeIntegrity -> Operational.
Примечание: если при доступе к логам в этой ветке появляется ошибка “access denied”, создайте на диске c: каталог, предоставив группе Everyone полный доступ. Затем измените путь к файлу ETL на новый каталог, и отключите и заново включите логирование.
В моем случае, в журнале есть событие EventID 3001 с текстом «Code Integrity determined an unsigned kernel module \Device\HarddiskVolume1\Windows\System32\win32k.sys is loaded into the system. Check with the publisher to see if a signed version of the kernel module is available». Вот мы и нашли проблемный драйвер!
Проверку наличия цифровой подписи выполним командой:
Если подпись отсутствует, то в поле Verified будет указано Unsigned (в противном случае, соответственно Signed).
Перед нами есть два варианта решения проблемы невозможности нормальной загруки системы с неподписанным драйвером:
- Найти подписанную версию драйвера
- Отказаться от использования данного драйвера (и устройства)
- отключить проверку цифровой подписи драйвера в Windows
Третий вариант может не подойти по тем или иным причинам. В первых двух случаях нам нужно определить к какому конкретному устройству относится данный файл драйвера .sys.
Как же определить устройство, зная лишь имя sys-файла? Я использую следующую методику (пусть нам нужно определить устройство, драйвер которого имеет имя HpCISSs2.sys):
1) Открываем редактор реестра и поиском по ветке HKEY_LOAL_MACHINE\SYSTEM\ControlSet001 ищем ключ со значением HpCISSs2.sys
2) В моем случае он нашелся в ветке HKEY_LOAL_MACHINE\SYSTEM\ControlSet001\services\HpCISSs2
3) Разворачиваем вложенную ветку с названием ENUM, нас интересует значение ключа 0, в моем случае это PCI\VEN_103C&DEV_3230&SUBSYS_3235103C&REV_01\4&3b416f2c&0&0018
4) Определяем, что производитель устройства имеет ID 103C, а код устройства 3230
5) Далее на сайте указываем в полях Vendor Search и Device Search найденные нами коды.
6) Получаем что искомое нами устройство контроллер жестких дисков HP Smart Array P400 Controller.
Нам осталось лишь найти новую версию драйвера на сайте производителя оборудования (внимательно смотрите для каких версий ОС подходит нужный вам драйвер) и обновить драйвер на компьютере.
Читайте также: