Почему работает драйвер подписанный сторонним сертификатом

	Комментарий модератора
	Обсуждение вынесено из этой темы Отключение проверки цифровой подписи WIN 7 64 bit

Проще подписать драйвер своей цифровой подписью.
Я так устанавливал старый неподписаный драйвер для звуковой карты


Инструкций в сети полно

Миниатюры

 

0

Как выяснилось, здесь все завязано на особенности работы системы с каталогами
безопасности (файлы с расширением .cat). Как я уже писал выше, cat - это просто
подписанный цифровой подписью контейнер, который хранит хэши файлов, в данном
случае это файлы, являющиеся частью пакета драйвера (driver package).

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

Вот, кстати, почему сам файл драйвера (.sys или .dll) может не иметь "вшитой" подписи
(embedded signature): система легко может проверить ее по .cat-файлу, сравнив хэши.

Теперь тонкий и интересный в контексте данной дискуссии момент: хэши исполняемых
файлов (.sys, .dll, .exe и другие) считаются не "в лоб", а чуть хитрее. На вход функции
хэширования, - это, как правило, SHA-1 или SHA-2, - подается не весь файл, а только
основные заголовки и секции (исполняемый файл - это формат PE), за исключением той
секции, где хранится цифровая подпись и сертификаты. Не знаю точной формулировки, буду
называть это Authenticode-хэш. Выходит, что если взять два одинаковых файла и подписать
их разными сертификатами или в разное время, их файловые хэши будут различаться, а
Authenticode-хэши по-прежнему будут совпадать. Наверное, то же самое справедливо
для ситуации, когда один файл подписан, а другой нет, хотя я не проверял.

И если, к примеру, вытащить какой-нибудь .sys-файл из папки system32\drivers, испортить
ему цифровую подпись и закинуть обратно, то система все равно будет загружать этот
драйвер, пока его Authenticode-хэш будет совпадать с тем, который прописан в cat-файле,
находящемся в системной базе данных. Проверено.

--------

Теперь возвращаемся к нашему вопросу - почему на 64-битной Windows 7 грузится драйвер,
подписанный "левым" сертификатом, хотя по всем канонам не должен ?

А вот почему:

Сообщение от vavun перед установкой ОС я интегрировал все драйверы для своего ПК в install.wim, так что в системе (DriverStore\FileRepository) все еще имеется неподписанная копия t3.sys, но она не активна.

Стопудово, что в системе имеется не только копия t3.sys, но и копия соответствующего
каталога безопасности, причем подписанного "правильным" сертификатом, и Authenticode-хэш
t3.sys, указанный в этом каталоге, в точности совпадает с Authenticode-хэшем файла t3.sys
на диске, даже если последний имеет другую embedded-подпись ("Vavun").

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

Окончательную точку в этом вопросе можно поставить с помощью утилиты SigCheck (Sysinternals),
которая умеет сопоставлять цифровые подписи и установленные в системе каталоги безопасности:

Sigcheck v2.3
https://technet.microsoft.com/... 97441.aspx

Например (выполнять на той же системе, где установлен драйвер t3.sys):
Я не знаю, какие сертификаты она покажет в данном случае, но почему-то уверен,
что там пойдет Symantec и т.п., а в корне будет Microsoft Code Verification Root
или что-то типа того.

Сообщение от vavun Я тут еще на кое что обратил внимание ---- [Свойства: Sound Blaster X-Fi Xtreme Audio] ... Цифровая подпись: Creative Technology [Сведения о файлах драйверов] ... C:\Windows\system32\drivers\t3.sys Цифровая подпись: цифровая подпись отсутствует ---- теперь вообще ничего не понимаю.

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

А в сведениях о файлах драйверах цифровая подпись отображается
только в том случае, если это WHQL.

Кстати, строка "Creative Technology" косвенно доказывает мое предположение выше.
Откуда ей взяться, если signer файла t3.sys - "Vavun" ?

Сообщение от vavun Возник вопрос: а что будет, если установить в систему драйвер, где *.cat имеет валидную подпись, но один из *.sys файлов не имеет подписи вовсе, а уже после установки такого драйвера подписать его левой подписью предварительно добавив её сертификат в систему ? Или заменить неподписаный sys на подписанный левым сертификатом, но опять же, после установки с валидным cat ?

Сообщение от Убежденный В общем, возвращаясь к вопросу о том, что будет, если "установить в систему драйвер, где *.cat имеет валидную подпись, но один из *.sys файлов не имеет подписи вовсе, а уже после установки такого драйвера подписать его левой подписью предварительно добавив её сертификат в систему" - ответ такой: грузиться этот драйвер не будет. Левая подпись, которая "вшита" в sys, для загрузки недостаточна (т.к. она левая). Хэш файла изменился, поэтому пройти проверку по .cat он тоже не сможет. Грузиться не должен после этого.

Теперь становится понятно, что здесь я ошибался.

0