Как самому подписать драйвер windows 10 — Ваш верный помощник с OS Windows

Windows 10, 8.1 и Windows 7 позволяют отключить обязательную проверку цифровой подписи драйверов и установить неподписанный драйвер, однако если в последних версиях ОС это нужно сделать на постоянной основе, изменение опций с помощью bcdedit не помогает. Однако, может помочь самостоятельная подпись драйвера и его последующая установка, о чем и поговорим.

В этой инструкции подробно о том, как самостоятельно подписать драйвер для Windows 10, 8.1 или Windows 7 x64 или 32-бит (x86) для последующей установки в системе на постоянной основе без отключения проверки цифровой подписи драйверов, избежав при этом ошибок наподобие «INF стороннего производителя не содержит информации о подписи».

Что потребуется для подписи драйвера

Для того, чтобы выполнить все описанные далее шаги, скачайте и установите следующие инструменты с сайта Майкрософт:

Microsoft Windows SDK for Windows 7 https://www.microsoft.com/en-us/download/details.aspx?id=8279
Windows Driver Kit 7.1.0 https://www.microsoft.com/en-us/download/details.aspx?id=11800

Из первого набора достаточно будет установить Tools, из второго (представляет собой ISO-образ с установщиком, с которого нужно запустить KitSetup.exe) — выбрать Build Environments и Tools.

Обратите внимание: это не последние версии наборов инструментов, но они в равной степени подойдут для самостоятельной подписи драйверов для последующей установки во всех ОС от Windows 10 до Windows 7, при этом в инструкции не потребуется вдаваться в некоторые дополнительные нюансы.

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

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

Создайте в корне диска C какую-либо папку (так к ней проще будет обращаться в дальнейшем), например, C:\cert, где мы будем работать с сертификатами и драйверами.
Запустите командную строку от имени администратора (нужны для 18-го шага). Далее используем следующие команды по порядку. Файлы драйвера пока не потребуются. Во время выполнения второй команды вас попросят ввести пароль, я использую password в окне запроса и далее в командах, вы можете использовать свой.

cd "C:\Program Files\Microsoft SDKs\Windows\v7.1\bin"

makecert -r -sv C:\cert\driver.pvk -n CN="remontka" C:\cert\driver.cer

cert2spc C:\cert\driver.cer C:\cert\driver.spc

pvk2pfx -pvk C:\cert\driver.pvk -pi password -spc C:\cert\driver.spc -pfx C:\cert\driver.pfx -po password

До этого этапа всё должно пройти как на скриншоте ниже, командную строку не закрываем.

Картинка с сайта: remontka.pro
В папке C:\cert создайте вложенную папку, например, drv и поместите туда свои файлы драйвера. Но: если вам требуется драйвер только для x64, не копируйте .inf файл для x86 систем в эту папку и наоборот.

Картинка с сайта: remontka.pro

В командной строке используем следующие команды:
```
cd C:\WinDDK\7600.16385.1\bin\selfsign\
```

inf2cat.exe /driver:"C:\cert\drv" /os:7_X64 /verbose

В предыдущей команде для драйвера 32-бит укажите X86 вместо X64. Если будет предложено скачать .NET Framework, согласитесь, установите, а затем заново выполните команду. В идеале вы должны будете получить сообщение об успешном создании .cat файла для подписи. Однако, возможны ошибки, о наиболее частых — следующие два пункта. После исправления ошибок повторите команду из пункта 10.
DriverVer set to incorrect date — возникает при дате в файле драйвера до 21 апреля 2009 года. Решение: откройте файл .inf из папки drv в текстовом редакторе (можно в блокноте) и в строке DriverVer установите другую дату (формат: месяц/день/год).
Missing AMD64 CatalogFile entry (для 64-бит) или Missing 32-bit CatalogFile entry. Решение: откройте файл .inf из папки drv в текстовом редакторе и в разделе [Version] добавьте строку CatalogFile=catalog.cat
В итоге вы должны получить сообщение: Catalog generation complete с указанием пути к файлу каталога, в моем случае – C:\cert\drv\catalog.cat. Далее используем следующие команды (требуется подключение к Интернету).

Картинка с сайта: remontka.pro

cd "C:\Program Files\Microsoft SDKs\Windows\v7.1\bin"

signtool sign /f C:\cert\driver.pfx /p password /t http://timestamp.verisign.com/scripts/timestamp.dll /v C:\cert\drv\catalog.cat

Результат подписи файла драйвера без ошибок на скриншоте ниже. Следующий шаг — добавить самоподписанный сертификат в список доверенных в системе, сделать это можно следующими двумя командами по порядку

Картинка с сайта: remontka.pro

certmgr.exe -add C:\cert\driver.cer -s -r localMachine ROOT
certmgr.exe -add C:\cert\driver.cer -s -r localMachine TRUSTEDPUBLISHER

В результате вы должны получить сообщение «CertMgr Succeeded». Если Failed или certmgr.exe не является внутренней или внешней командой — убедитесь, что командная строка запущена от имени администратора, а вы находитесь в нужной папке (см. 15 шаг).

И вот теперь можно закрыть командную строку и установить драйвер из папки C:\cert\drv с помощью диспетчера устройств, или нажав правой кнопкой по .inf файлу и выбрав пункт «Установить». Потребуется подтвердить установку драйвера в окне «Не удалось проверить издателя этих драйверов» — нажать «Все равно установить этот драйвер».

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

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

Источник

(6 votes, average: 5.00 out of 5)

An average of 46% of buyers interviewed by Forter in 2023 are willing to spend more with vendors they trust. Boost customers’ trust by showing your users that your drivers are authentic (i.e., published by you) and unmodified. Follow our step-by-step instructions to learn how to use SignTool to sign your drivers

In today’s digital world, driver signing has become a “must-have” tool for your toolbox. Threats are lurking around every corner. In the first half of 2023, S21Sec Cyber Solutions by Thales reports that ransomware attacks have increased by an astonishing 43% compared to the previous six months. The AV-TEST Institute reports that nearly 9 million new malware and unwanted applications are identified every month. And what better way to prevent someone from tampering with your software files than to digitally sign them before release?

If you’re a software developer or a vendor who’s trying to figure out how to digitally sign a driver that meets the industry’s new code signing requirements, then search no more; we’re here to help.

This step-by-step tutorial will walk you through how to digitally sign a driver with a code signing certificate.

Getting Started – What Do You Need to Sign a Driver for Windows?

Here is the essential checklist of the five actions to carry out before signing a driver:

Essential Tools For Signing Windows Drivers	Description
1. Install SignTool.exe on the Windows device you’ll use to sign your driver.	The SignTool is a command-line tool embedded in Windows SDK that lets you sign, timestamp, and verify Microsoft Authenticode-supported file formats such as .exe, .cat, .cab, .jar, and of course, drivers (i.e., .sys, .dll files).
2. Purchase a code signing certificate issued by a publicly trusted certificate authority (CA).	A standard certificate, like the one used in this guide, works in many cases. However, in some cases, you may need to sign using an extended validation (EV) code signing certificate (more details in the following sections).
3. Set up the hardware security token sent to you by the CA.	This reflects the new industry criteria requiring, since June 2023, that all code signing certificates’ keys are stored on cryptographically secure hardware (e.g., USB tokens).
4. Download and install the authentication client provided by the CA.	This is the software you utilized to set up your secure token when you received it. In this tutorial, we’ll use the SafeNet Authentication client.
5. Get administrator permissions.	The SignTool.exe will work only with admin permissions. Contact your IT department if you don’t have admin access on your device.

Did you check all the five points? Well done. We can now move on to the next section and discover the steps to sign a driver. Let’s get the party started!

How to Sign an Unsigned Driver With Microsoft’s SignTool

Got your driver to sign at hand? Good. In our demonstration, we’ll sign a user-mode driver (e.g., a .dll file). However, the same process can be used to sign kernel-mode drivers (e.g., .sys files) and driver packages (e.g., .cat files). Ready? C’mon, it’s driver-signing time, baby!

1. Connect Your Hardware Token and Open the Authentication Client

This is the first thing you’ll have to do each time you must sign a file or software. Should you forget about it and try to do it later in the process, it won’t work.

2. Open a Command Prompt Window (CMD) as Administrator

If you’re already logged in as an admin, click the CMD app icon. If you aren’t, search for “cmd” using the Windows search box. Under the Command Prompt App icon, select Run as administrator. Enter your admin password when prompted.

Image caption: The screenshot shows how to find and open the CMD with administrator permission in Windows 10.

3. Switch to the Directory Containing Microsoft’s SignTool

To change directories after you’ve installed Windows SDK in the default folder (i.e., .bin), use the command below.

cd C:\Program Files (x86)\Windows Kits\10\bin\YourSDKversion\x86

Replace “YourSDKversion” with the correct version number installed on your machine (in our example, shown in the screenshot, it’s 10.0.22621.0).

If SDK has been installed in a different directory, adapt the script to reflect the specific file path and folder name:

cd C:\your filepath\your folder

Did you have to log in as an admin when you first opened the CMD? Jump to step four.

Were you already logged into your device as an admin? After executing the cd command illustrated above, in the same window, type “c:” and hit enter.

4. Sign (and Timestamp) Your Windows Driver

OK. Now, this is the part when you get to really sign your driver. This section will walk you through how to add an optional timestamp to your digital signature. Wondering why you should do that if Windows policies don’t require it? Because doing so is generally a good idea.

In a way, a timestamp is like a free extended warranty. When applied, it’ll keep your signature valid, even when your code signing certificate expires. This means no ugly warnings will be displayed to the users when they attempt to install your driver. Yeah!

So, how can you sign and timestamp your driver in one go? All you have to do is type the command below in the command line. Get your CA’s timestamp’s server information (which is usually available on their support page) and replace the “CAtimestamp.server.com” bit with it. Double-check you’ve also entered the correct driver’s file path and name.

signtool sign /tr http://CAtimestamp.server.com /td SHA256 /fd SHA256 /a "C:\filepath\Mydriver.dll"

Here’s what it looks like for us when using the DigiCert timestamp server:

Once you hit enter, a pop-up will prompt you to type your Authentication client password (as shown below).

Once the password has been entered, click on the OK button. That’s all, folks! If you did everything correctly, you should see a message like the one displayed in our screenshot below:

Want to sign without timestamping? Use this command instead:

signtool sign /td SHA256 /fd SHA256 /a "C:\filepath\Mydriver.dll"

Last but not least, regardless of whether you signed your driver with a timestamp, take the time to verify your signature was applied successfully. As the Scottish historian and philosopher Thomas Carlyle said: “One must verify or expel his doubts, and convert them into the certainty of yes or no.”

5. Verify Your Signed Driver

Two scripts can be used to verify your signature in CMD. The verbose one (shown below) will provide:

Highly detailed information about the signature;
The code signing certificate used; and, if applied
The timestamp data.

Want to use it? In the same CMD window type:

signtool verify /pa /v “C:\filepath\Mydriver.dll”

A plethora of juicy details will be displayed, like in the following example:

You didn’t add a timestamp? You’ll still get an exhaustive list, down to the fine points. SignTool’s verification information will also clearly state that the driver comes without a timestamp:

Would you rather get a more concise summary? Use this script instead:

signtool verify /pa “C:\filepath\Mydriver.dll”

Et voila’. The results boil it down to covering only the most essential information.

At last, we can confirm that we’ve signed the driver correctly. Do you want to sign a driver package (e.g., a .cat file)? Follow the same process.

Are you planning to distribute the driver through the Windows Update program? Then you’ll have to follow some additional steps. And this isn’t the only case. Let’s find out more about these different situations.

Additional Steps to Follow for Kernel Mode Release Drivers, Driver Packages Signing, and Other Exceptions

Before the advent of Windows 10 version 1607, the code signing process we’ve just described was the only requirement to release any kind of Windows driver. As time passed, cybercriminals’ attacks got more sophisticated. As a result, organizations had to beef up their security measures, and so did Microsoft’s driver signing policy.

Now, the Windows Driver Signature Enforcement requirements are more strict:

Kernel-mode drivers can no longer be signed with a standard certificate. All drivers “talking” directly to operating systems’ cores (i.e., kernel-mode drivers, usually indicated by the .sys extension) must be signed with the more secure EV code signing certificate. The standard code signing certificate can still be used to sign user-mode drivers (i.e., those running separately from the core operating system).
An additional signature is required. Did you develop a kernel or user mode driver, or a driver package that’ll be distributed through the Windows Update program or other MS-supported distribution mechanisms? On top of creating the digital signature you’ve just learned to apply, you must:
- Create an account using the Windows Hardware Developer Center Dashboard portal (Dev Portal),
- Ensure your public release driver undergoes testing using the Windows Hardware Certificate Program testing kits (e.g., WHLK for Windows 10, 11, and Windows Server 2016 or later; WHCK for Windows 8.1 and earlier; and WLK for Windows Server 2008 and older), and
- Create a driver submission package (i.e., .hlkx/.hckx or .cab for WLK hardware) for a Windows Hardware Certification Program (WHCP) digital signature in the Dev portal. If successful, your submission will return a WHCP-signed .cat file.
To access the Dev Portal, you’ll need an EV certificate. If your code must also be certified and signed by Microsoft, as explained above, you’ll have to register with the Dev Portal. And guess what? You’ll need an EV code signing certificate to do that.

Moreover, Microsoft’s Windows driver signing tutorial specifies:

“The mandatory kernel-mode code-signing policy applies to all kernel-mode software for x64-based systems that are running on Windows Vista and later versions of Windows. However, Microsoft encourages publishers to digitally sign all kernel-mode software, including device drivers (user-mode drivers included) for 32-bit systems as well. Windows Vista and later versions of Windows, verify kernel-mode signatures on 32-bit systems. Software to support protected media content must be digitally signed even if it is 32-bit.

User-mode drivers, like the Printer driver will install and work in an x64-based computer. A dialog will appear to the user during installation asking for approval to install the driver. Beginning in Windows 8 and later versions of Windows, installation will not proceed unless these driver packages are also signed.”

Does the driver you’ve just signed fall into one of these examples? If this is the case, to complete the process and get it ready for release, follow the above-mentioned Microsoft tutorial.

Pro tip: If you want to sign a driver package, don’t forget to individually sign your driver (e.g., SYS or DLL) and the .cat file. If you don’t, Windows will still consider the package as unsigned.

Looking to sign other file types? You can do that using the same code signing certificate. Discover how by exploring our compelling guides:

Sign and timestamp JAR file.
Sign MSI installer files and packages.
Sign EXE files using a code signing certificate.

Final Thoughts About How to Digitally Sign a Driver for Windows

Cryptographically signing Windows drivers isn’t too much of a headache, provided that you have the right tools (e.g., an EV certificate for kernel-mode drivers or those you’ll distribute through Windows update) and a good, comprehensive step-by-step tutorial to follow. We hope this guide serves as a useful tool you’ll want to share with friends or colleagues who want to understand how to digitally sign an unsigned driver for Windows systems.

The digital world is a tough place for organizations and users alike. However, you can offer your customers a much more enjoyable and secure experience by signing your drivers. What’s in it for you? Among all the benefits, it’ll boost customers’ trust in your brand and software, which can help expand your potential buyers’ pool.

Gone are the times when users blindly trusted what they were downloading from the internet. In this day and age, to be successful, learning how to sign drivers and software is something that no developer or software vendor can forgo.

Источник

12.08.2016, 21:32. Показов 48552. Ответов 41

Эта статья — быстрый онлайн-помощник для тех, кто переходит на новое
подписывание драйверов в Windows 10 (EV, WHDC-портал). Здесь я постараюсь
дать основные рекомендации, чтобы помочь избежать глупых ошибок и, не
теряя времени, скорее адаптировать свои проекты под новые требования.

Для того, чтобы начать подписывать драйверы по-новому, вам потребуется:

* EV-сертификат, приобретенный у Symantec, DigiCert, GlobalSign, WoSign
или Entrust. В тот момент, когда пишутся эти строки, поддерживаются только
сертификаты, приобретенные в перечисленных выше организациях. В будущем список,
вероятно, будет дополняться.

По тексту ниже подразумевается, что сертификат уже установлен на вашем компьютере.

* Аккаунт на Microsoft (LiveID). Регистрация там бесплатная и занимает несколько минут.

* Утилита signtool с поддержкой SHA256. Утилиту лучше взять из последних версий WDK
(8 и выше), так как старые версии не поддерживают SHA256 и некоторые другие возможности,
которые вам потребуются.

* Несколько часов свободного времени.

Первое, что вам нужно сделать — зарегистрировать свою компанию на портале WHDC.
Идем сюда:

Microsoft Hardware Dev Center
https://developer.microsoft.co… s/hardware

жмем ‘Dashboard’ и логинимся в свой аккаунт Microsoft.

Далее вам будет предложено скачать файл winqual.exe, подписать его своим сертификатом и
загрузить обратно. Так портал определяет валидность сертификата, а также сможет сопоставить
цифровую подпись с вашей компанией, если это будет необходимо. Команда подписи для
signtool.exe затруднений вызывать не должна:

Code

1	signtool.exe sign /n "My EV Certificate Name" /a /fd SHA256 /tr http://timestamp.globalsign.com/?signature=sha2 /td SHA256 winqual.exe

Для вашего сертификата опции могут быть немного другие. Обратите внимание на ключи /fd и /td —
они указывают, что и для цифровой подписи, и для timestamp-сервера следует использовать
SHA256, а не SHA1. EV-сертификаты используют только SHA2. Также обратите внимание,
что здесь и далее больше не будут использоваться никакие кросс-сертификаты (ключ /ac),
так как для ‘attestation signing’ (подписывание драйверов через веб-портал) это не требуется.

Точно такой же командой вы будете подписывать submission (архив с файлами для подписи).

Подписав и загрузив winqual.exe, вы попадете на страницу, где вам предложат указать
сведения о компании — название, юридический адрес, почтовый индекс, телефон, e-mail…
Судя по всему, эта информация не проверяется и нужна только «для галочки».
Но указывать откровенно «липовые» данные, разумеется, не стоит.

Вот и все, теперь вы успешно зарегистрированы на веб-портале WHDC.
Осталось немного — дать нужные разрешения (permissions), а также подписать несколько
соглашений, которые предлагает вам Microsoft (по поводу Anti-Malware, DRM и остальные в
таком же духе, всего штук 10). Я не буду подробно описывать нужные шаги, т.к. они
достаточно очевидны.

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

Подписывание драйвера.

Сначала вам нужно создать cab-архив с файлами для подписи внутри.
Если пакет драйверов только один, cab-файл должен иметь такую структуру:

Code

1
2
3

DriverPackage\
    mydriver.sys
    mydriver.inf

Если пакетов драйверов несколько, тогда добавляется нумерация:

Code

DriverPackage1\
    drv1.sys
    drv1.inf
DriverPackage2\
    drv2.sys
    drv2.inf
...
DriverPackageN\
    drvN.sys
    drvN.inf

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

Кликните здесь для просмотра всего текста

Code

;
; TODO: Add copyright info here.
;
 
[Version]
Signature                = "$Chicago$"
Provider                 = %Provider%
Class                    = "LegacyDriver"
ClassGuid                = {8ECC055D-047F-11D1-A537-0000F8753ED1}
DriverVer                = 07/24/2015,1.0.0.0
DriverPackageType        = KernelService
DriverPackageDisplayName = %PackageDisplayName%
CatalogFile              = setup.cat
 
[DefaultInstall]
CopyFiles = Setup.CopyFiles
 
[DefaultInstall.Services]
AddService = mydriver,,Setup.AddService
 
[SourceDisksFiles]
mydriver.sys = 1
 
[SourceDisksNames]
1 = "Disk"
 
[DestinationDirs]
DefaultDestDir = 12 ; "system32\drivers" directory.
 
[Setup.CopyFiles]
mydriver.sys
 
[Setup.AddService]
ServiceName   = mydriver
DisplayName   = %DrvDisplayName%
Description   = %DrvDescription%
ServiceType   = 1 ; SERVICE_KERNEL_DRIVER
StartType     = 1 ; SERVICE_SYSTEM_START
ErrorControl  = 1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %12%\mydriver.sys ; 12 - "system32\drivers" directory.
 
[Strings]
Provider           = "My Driver Provider Name"
PackageDisplayName = "My Driver Package Display Name"
DrvDisplayName     = "MyDriver"
DrvDescription     = "My Driver Description"

Я сразу советую проверять, валиден ли ваш INF-файл, используя утилиту inf2cat из WDK.
Например:

Code

1	inf2cat.exe /v /DRV:C:\MyDriverPackage /OS:XP_X64

Для создания cab-архива можно использовать разные программы, но проще всего
задействовать штатную утилиту Windows под названием makecab:

Code

1	makecab.exe /f путь-к-файлу-ddf

В файле ddf описываются директивы для создания cab-архива.
Я использую примерно такой шаблон:

Code

.OPTION EXPLICIT
.Set CabinetFileCountThreshold=0
.Set FolderFileCountThreshold=0
.Set FolderSizeThreshold=0
.Set MaxCabinetSize=0
.Set MaxDiskFileCount=0
.Set MaxDiskSize=0
.Set CompressionType=MSZIP
.Set Cabinet=on
.Set Compress=on
.Set CabinetNameTemplate=submission-8.cab
.Set DestinationDir=DriverPackage1
C:\SUBMISSIONS\MyDriver1\64\MyDriver1.sys
C:\SUBMISSIONS\MyDriver1\64\setup.inf
.Set DestinationDir=DriverPackage2
C:\SUBMISSIONS\MyDriver2\64\MyDriver2.sys
C:\SUBMISSIONS\MyDriver2\64\setup.inf

Файл cat, который сгенерировала утилита inf2cat.exe, в архив класть не нужно,
он все равно будет проигнорирован и портал при подписи создаст новый.

Важный момент: все пакеты драйверов в архиве должны быть под какую-то одну
архитектуру — или x64, или x86. На MSDN пишут, что Driver Package может
быть под обе архитектуры, но как правильно их упаковать в cab-архив — я
так и не понял. Попытки добавить еще один уровень в дереве папок внутри
архива (32/64, x86/x64, i386/amd64) успехом не увенчались.
Видимо, самый простой путь — делать две submission, одну чисто под x64,
вторую чисто под x86.

Когда cab-архив будет готов, вам нужно подписать его своим сертификатом.

Далее на веб-портале идем в раздел ‘File signing services’ и выбираем
пункт ‘Create driver signing submission’. После этого все очень просто:
вы указываете название своей submission (произвольное, это нужно только
для информативных целей), является ли ваш драйвер универсальным (см. концепцию
‘Universal Driver’ в MSDN), а также платформы, под которые собран драйвер,
их в настоящий момент четыре:

Microsoft Windows 10 AU Client family, x86
Microsoft Windows 10 AU Client family, x64
Microsoft Windows 10 Client family, x86
Microsoft Windows 10 Client family, x64

C x64/x86 все понятно, а вот разницу между Client и AU Client я не нашел —
подпись в конечном итоге получается одинаковая.

После этого вы загружаете свой cab-архив и жмете ‘Submit’. Все.

Обработка submission (процесс называется review) занимает некоторое время, у
меня было где-то около 15 минут, иногда может затянуться, как пишут, на
часы или даже сутки. Но обычно слишком долгий процесс обработки submission —
признак того, что что-то пошло не так и процесс будет завершен с ошибкой.

По завершении вам придет письмо на почту и архив с подписанными файлами можно
будет скачать там же, на веб-портале.

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

В сведениях о цифровой подписи файлов, которые вам вернет портал, вы с удивлением
(а кто-то, возможно, и с радостью) обнаружите, что вместо ‘OOO Vasya Pupkin’ будет
вписано безликое и ужасное ‘Microsoft Windows Hardware Compatibility Publisher’.

Теперь драйвер можно ставить и запускать на Windows 10 — 1607 и никакие
Secure Boot, Device Guard и т.п. не помеха.

———————————————————————————-

Теперь вопросы чисто практического плана.

Q: Как быть с предыдущими версиями Windows (Vista, Windows 7, Windows 8, Windows 8.1)?

A: К сожалению, здесь без вариантов: либо вам придется купить еще один сертификат SHA1 и
использовать его, либо попробуйте пройти HLK-тесты через веб-портал и тогда получите
подпись, которую понимают все указанные выше версии Windows.

Прохождение HLK-тестов — достаточно большой и серьезный «квест», затрагивать эту
тему здесь я не буду.

Q: Как быть с Windows Server 2016 (vNext)? Его ведь нету в списке при отправке
submission на веб-портале…

A: Для Windows Server 2016 прохождение HLK-тестов для драйвера — единственный
легальный способ поддержки, другие типы цифровых подписей система принимать
не будет. Так что ждите через некоторое время очередную статью от меня про HLK.

Q: Как обстоят дела с двойными сигнатурами?

A: Портал добавляет свою подпись, не затирая старую. Поэтому можно, например,
подписать .sys-файл сначала стандартным сертификатом с SHA1 старым способом с
кросс-сертификатом (cross-signing), а затем отправить его на веб-портал, где
ему будет добавлена вторая подпись SHA256 для Windows 10 (attestation signing).
Такой драйвер сможет запускаться на любых версиях Windows.

Однако в случае с cat-файлами это не сработает, потому что, как уже писалось выше,
портал генерирует свой cat-файл, игнорируя тот, что лежит внутри cab-архива.

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

Q: Что делать с модулями, которые собираются с ключом /INTEGRITYCHECK и,
согласно MSDN, должны подписываться с опцией /ph (generate page hashes)?
Например, драйвер, использующий Object Callbacks (ObRegisterCallbacks)?

A: Ничего не нужно. Система подписывания остается такой же, как и для
остальных драйверов Windows 10.

Q: EV-сертификат поставляется на USB-токене, это секьюрно, но неудобно.
У нас разработчики географически удалены друг от друга, а подписывать,
получается, может только один?

A: К сожалению, здесь действительно есть ряд неудобств.
Например, токен SafeNet не работает нормально в RDP-сессии и время
от времени начинает требовать ввод пароля (PIN).

Для решения этой проблемы можно настроить параметры, как написано здесь:

Automate Extended Validation (EV) code signing
http://stackoverflow.com/quest… de-signing

А также воспользоваться приведенным кодом и утилитой RemoteSignTool
(обертка над signtool.exe, работающая через интернет).

В настоящее время ведутся дебаты о том, чтобы оставить EV только для регистрации
на веб-портале, а для подписи submission использовать «обычные» сертификаты
(т.е. без USB-токенов и тому подобного):

EV Cert to be Requires for EVERY sysdev submission…
http://www.osronline.com/showt… ink=278314

Источник

Пролог

Начиная с версии Windows 10 1607 корпорация Microsoft ввела обязательную сертификацию сторонних драйверов по программе Windows Hardware Compatibility Program (новость об этом в блоге msdn , пост на хабре ). Работает это нововведение на чистых установках Windows 10 соответствующей версии с включенным режимом Secure Boot .

Несоблюдение этого условия в лучшем случае (при отключенном Secure Boot) приведет к появлению предупреждения:

В худшем — к запрету на установку драйвера:

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

Краткий обзор всей последовательности действий:

Подготовка парка машин
Развертывание тестового фреймворка Windows Hardware Lab Kit
Создание и конфигурация тестового проекта
Прохождение списка тестов
Подготовка финального пакета с результатами
Обработка результатов на серверах Microsoft и получение подписи

Дебют или этап подготовки

Очевидным предварительным условием для сертификации является наличие следующего:

EV сертификата;
Подготовленных компонентов драйвера (файлы .inf, .sys, .map, .pdb);
Сгенерированного утилитой inf2cat (входит в состав Windows SDK ) cat-файла .

Файлы .sys и .cat должны быть подписаны EV сертификатом. Для этого используется утилита singtool из Windows SDK.

В нашем случае файлы .inf, .sys, .map, .pdb и .cat представлены в двух экземплярах для архитектур x86 и x64 соответственно.

Первым шагом к сертификации драйвера является прохождение серии тестов на совместимость оборудования для Windows. Для этих целей Microsoft предоставляет специализированный фреймворк Windows Hardware Lab Kit , ранее называвшийся Windows Hardware Certification Kit (HCK). А еще ранее этот же фреймворк носил имя Windows Hardware Logo Kit, что доставляет неудобство в поиске информации, так как по запросу HLK нередко выпадает устаревшая. С кратким обзором концепции тестирования можно ознакомиться по ссылке . В состав HLK входят серверная часть (включает в себя менеджер тестов HLK Controller и управляющую консоль HLK Studio ) и клиентская часть (HLK Client). Таким образом, HLK предполагает наличия тестового парка из как минимум двух машин.

Подготовка парка машин

Для серверной части HLK ограничением является необходимость развертывания на Windows Server 2012, Windows Server 2012 R2 или Windows Server 2016.

Начиная с релиза 1709 HLK поддерживает тестирование клиентов только соответствующей версии Windows 10 , предыдущие редакции кита предусматривали возможность работы с некоторым подмножеством обновлений этой операционной системы.

Табличка поддерживаемых версий:

HLK version	Supported version	Accepted device/component	Accepted system
1803	1803 – Client	1803 Client Device/Component	1803 Client Systems
1709	1709 – Client	1709 Client Device/Component	1709 Client Systems
1703	1703 – Client	1703 Client Device/Component	1703 Client Systems
1607 — Client	1607 Client Device/Component
1607	1607 – Client	1607 Client Device/Component	1607 Server Systems
1607 – Server, Azure Stack, SDDC	1607 Server Device/Component
1511 — Client	1511 Client Device/Component

Для организации тестирования нам понадобятся одна управляющая машина с серверной версией Windows и две тестовые машины с 32 и 64-битными версиями Windows 10 в одной сети. При наличии нескольких доступных клиентов одной битности их можно использовать совместно, проводя тестирование параллельно. Альтернативной конфигурацией, в случае тестирования драйвера для двух архитектур, может быть схема с одним контроллером и одним клиентом (предполагается смена ОС клиента между тестовыми сессиями). Однако в этом случае возможны проблемы с настройкой пулов тестовых машин и потерей результатов тестирования. Кто виноват и что делать в такой ситуации будет рассказано ниже.

Миттельшпиль или работа с HLK

Важно: рекомендуется использовать свежеустановленные версии Windows с английской локалью во избежание появления внезапных проблем с тестами. Вас предупреждали.

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

Развертывание HLK

На контроллере устанавливаем свежескаченный HLK корректной версии. В нашем случае это HLK 1803, поскольку на клиентах будет установлена Windows 10 с обновлением 1803. Существует вариант установки одной HLK Studio, однако он полезен только для работы с финальными пакетами hlkx.

Так же на контроллере должен быть установлен EV сертификат, которым были подписаны .sys и .cat файлы. Он понадобится нам позже, на этапе подготовки пакета для сабмита в Microsoft.

Клиентская часть ставится на тестовые машины по сети с контроллера:

\\контроллер\HCKInstall\Client\setup.exe

Установка драйвера

На каждую машину нужно установить наш подопытный драйвер. Для этих целей используется утилита hdwwiz (выполнить из Windows -> Run -> hdwwiz).

Стоит упомянуть о такой замечательной особенности Windows, как наличие кэша драйверов Driver Store. Если ранее в системе был установлен драйвера с версией, равной или новее той, которую вы пытаетесь поставить сейчас, существует вероятность, что Windows проигнорирует ваши попытки и возьмет копию из кэша. Для того, чтобы окончательно удалить предыдущий инстанс, можно воспользоваться приложением Driver Store Explorer .

Фильтры и плейлисты

Иногда с релизом нового обновления Windows или новой версии HLK часть тестов ломается. Результатом выполнения любого из них является ошибка, которая позже помешает нам подготовить финальный пакет hlkx. Для исключения сломанных тестов из общего списка тестирования, Microsoft выпускает специальные пакеты фильтров (HLK Filters). До начала процедуры тестирования необходимо скачать на контроллер архив самых свежих фильтров , распаковать их по пути

C:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Controller

и запустить приложение UpdateFilters.exe, расположенное там же.

Важно: рекомендуется устанавливать фильтры до начала тестирования, так как их эффект применяется только к запущенным после установки тестам. Чтобы изменить результаты уже проведенных тестов, необходимо в проекте HLK Studio перейти на страницу Results и нажать кнопку Apply Filters.

Кроме фильтров Microsoft поставляет специализированные плейлисты (HLK Playlist), изменяющие состав базового списка тестов. Скачиваем архив с актуальными плейлистами и распаковываем его на контроллере.

Важно: плейлист может быть применен только к чистому проекту. Использовать его на серии пройденных тестов не удастся.

Информацию по выпуску новых фильтров и плейлистов можно найти в блоге Windows Hardware Certification

Подготовка пула тестовых машин

Пришло время подготовить пулы наших клиентских машин. Они нам понадобятся на этапе создания проекта. На вкладке Configuration все машины отобразятся в Default Pool. Нужно создать свои пулы (кнопка Create Machine Pool) и перетащить в них машины из пула по-умолчанию.

Важно: в одном пуле должны находиться машины с одинаковой битностью.

Поле Status у каждой машины будет Not Ready — нужно щелкнуть по ним правой кнопкой и изменить статус на Ready.

Важно: иногда студия выдает ошибку на попытку изменить статус машины.

Кроме прочего, такая ситуация появляется, когда меняется ОС на тестовом клиенте, например, в схеме с одним контроллером и одним клиентом. Решается это удалением машины из пула (пункт Delete Machine в контекстном меню), что заставляет контроллер создать новый инстанс клиента с правильными характеристиками в Defaul Pool. Внимание, удаление машины приводит к удалению всех ассоциированных с ней результатов тестирования. Во избежание напрасной потери результатов нескольких часов работы, перед удалением машины следует подготовить финальный hlkx пакет, включающий все пройденные тесты. О подготовке файла hlkx будет рассказано далее.

Подготовка и запуск проекта

На странице Projects выбираем Create project и задаем проекту произвольное имя. Активируем проект двойным кликом по нему. Каждый проект может тестироваться только на машинах одной битности.

На странице Selection выбираем пул машин, на котором будет производиться тестирование. В списке отобразятся устройства, подключенные к машинам из этого пула. Отмечаем устройства, которые будут тестироваться.

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

Несмотря на всю подготовительную работу, некоторые тесты все же могут завершаться с ошибками, несвязанными напрямую с качеством тестируемого драйвера. Некоторые из них успешно проходятся со второй попытки. Успех выполнения других, в том числе весьма продолжительные тесты Concurrent Hardware And Operating System , по результатам наблюдений может зависеть от аппаратной начинки клиента. Логи результатов тестирования — основной помощник выявления проблем. Посмотреть их можно на странице Results.

Финальный пакет — это файл с расширением .hlkx (zip-архив), который содержит результаты тестирования. Именно его нужно сабмитить в Microsoft через Partner Dashboard для получения цифровой подписи Microsoft Windows Hardware Compatibility Publisher.

При его создании необходимо указать:

Путь к директории с драйвером (в директории должны находиться inf/sys/cat файлы);
Путь к директории с отладочными символами (pdb/map).

После нажатия на «Create Package» потребуется отметить:

Целевые ОС;
Locales (отмечаем English).

Создание финального пакета hlkx

Можно создавать неподписанные hlkx, например, просто для последующего открытия в студии. Для сабмита в Microsoft файл hlkx необходимо подписать EV сертификатом. Проще всего импортировать сертификат в систему и выбрать его в процессе создания пакета (кнопка Create Packageна странице Package). Получаем файл hlkx с результатами пройденных тестов.

Мерджинг пакетов hlkx

Этот этап выполняется, если вы проходите тестирование для нескольких платформ. В нашем случае, тестирование проводится для x86 и x64.

Для конфигурации с одним контроллером и одним клиентом меняем битность тестовой ОС, повторяем шаги по настройке клиента, переинициализируем машину под соответствующий пул.

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

На шаге создания пакета hlkx дополнительно вызываем меню Merge Package и указываем подготовленный hlkx пакет для платформы другой битности.

У нас готов hlkx пакет для отправки в Microsoft.

Эндшпиль или сабмит финального пакета hlkx в Microsoft

Заходим под своим аккаунтом на https://partner.microsoft.com/en-us/dashboard/.

На панели слева выбирвает Drivers. Нажимаем Submit new hardware.

Заполняем поле Product name и загружаем наш пакет hlkx.

В разблокированной секции Certification заполняем поля тип устройства, дата анонса и опционально маркетинговое имя. Нажимаем Submit.

Через некоторое время получаем результаты сертификации. Подписанные компоненты драйвера можно скачать, нажав по кнопке Download signed files.

Конечный результат всех усилий:

На что следует обращать внимание

Проверить соответствие версии HLK версиям Windows на клиентах;
Настроить английскую локаль на клиентских машинах;
Установить фильтры перед созданием проекта;
Сохранить результаты тестирования в пакет hlkx перед удалением тестовой машины из пула;
Применить плейлист нужной версии до запуска тестов;
Смерджить пакеты hlkx, если тестирование проводится для нескольких платформ.

Источник

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

Итак, прежде всего, я бы хотел выделить два типа сертификатов, которые я буду рассматривать в рамках данной статьи — тестовый и настоящий. Разница состоит в том, что настоящий сертификат подписан доверенным CA (Certification Authorities — доверенный издатель), типа VeriSign, GlobalSign ну или самим Microsoft, а тестовый подписан самопальным сертификатом типа от Васи Пупкина.

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

Сгенерить сам сертификат и установить его. Это можно сделать с помощью тулзы makecert, например так:

Makecert -r -pe -ss PrivateCertStore -n "CN=TestCertforWDK" TestCert.cer

где
PrivateCertStore — название хранилища
TestCertforWDK — название самого сертификата
TestCert.cer — имя файла с сертификатом
(эта тулза входит в комплект WDK 6000/6001 и расположена bin/SelfSign, в WDK 7600 она почему то не входит…)
Добавить этот сертификат в хранилище с доверенным корневыми CA. Открываем в mmc консоль Сертификаты (Run->mmc->File->Add/Remove Snap-in->Certificates) там находим свой сертификат (например в хранилище PrivateCertStore), копируем его в доверенные корневые издатели (Trusted Root Certification Authorities).
Разрешить тестовые подписи. Для этого прописываем в администраторской консоли:
bcdedit.exe –set TESTSIGNING ON
и перезагружаемся, в итоге на десктопе, после перезагрузки, по углам красоваться соответствующие надписи.

Настоящий сертификат
Тут тоже не все так просто. Дело в том, что не любой CA может выдавать сертификаты для подписи драйверов Windows, а только те, которые авторизованы самой Microsoft, это значит, что корневые сертификаты этих издателей должны быть подписаны Microsoft — что, как раз и выражается в виде этого кросс-сертификата. Вот именно из-за отсутствия кросс-сертификата — тестовая подпись, никогда не будет работать как настоящая. Список доверенных CA, которые обладают такими кросс-сертификатами — представлен тут, там же можно скачать и сами кросс-сертификаты.
После того, как вы выложите несколько сотенок $$$ доверенному центру сертификации, они выдадут вам .pfx файл в котором будут содержаться публичный и приватный ключи. Вы его запустите и с помощью нехитрого диалога (как на рисунке ниже), установите в систему.

Подпись драйвера
Процесс подписи для тестового и настоящего сертификата во многом похожи, различия состоят лиш в том, что:

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

Итак приступим

Качаем тулзу для подписи — signtool (тоже входит в комплект WDK6000/6001)
Подписываем, с тестовым сертификатом:
signtool sign /v /s PrivateCertStore /n "TestCertforWDK" driver.sys
где
PrivateCertStore — имя хранилища
TestCertforWDK — имя тестового сертификата
driver.sys — имя драйвера

с настоящим сертификатом:
signtool sign /v /ac MSCV-GlobalSign.cer /s PrivateCertStore /n "YourTrueCertName" /t http://timestamp.globalsign.com/scripts/timstamp.dll driver.sys
где
MSCV-GlobalSign.cer — имя кросс-сертификата
YourTrueCertName — имя настоящего сертификата
timestamp.globalsign.com/scripts/timstamp.dll — адрес таймстампингового центра, в моем случае global sign

Далее драйвер можно установить программно с помощью специальных АПИ либо с помощью замечательной тулзы KmdManager.

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

Корректный inf-файл (запасайтесь бубнами ребятки)
Тулза которая генерит этот cat-файл из inf-файлов — inf2cat (эта тулза входит в комплект WDK6001/7600, и написана, как не странно, на .NET)
После чего генерим cat-файл, например так
inf2cat.exe /driver:release\amd64 /os:Vista_x64,Server2003_x64,Server2008_x64
где
release\amd64 — папка в которой находится inf-файл и драйверы
Vista_x64,Server2003_x64,Server2008_x64 — список ОС, на которых должен работать драйвер
Подписываем его точно также, как и драйвер
signtool sign /v /ac MSCV-GlobalSign.cer /s PrivateCertStore /n "YourTrueCertName" /t http://timestamp.globalsign.com/scripts/timstamp.dll catalog.cat
сам драйвер при этом подписывать не обязательно.
Проверяем, что все хорошо подписалось, для этого открываем свойство .cat файла (или драйвера) и смотрим вкладку Digital Signatures — если есть то можем полюбоваться на результат, если нет, то где-то накосячили.
Также более достоверно можно проверить с помощью командной строки
signtool verify /pa /v /c catalog.cat

EasySign
В результате всех моих исследований на предмет САБЖ-а, я некатал по-быстрому простенькую программку EasySign, которая может подписывать дрова без дополнительного гимора с командной строкой и bat-файлами. Возможно кому-то будет полезно.

Саму прогу можно скачать тут, а мануалку почитать ниже:

Вбиваем в Inf Dir путь к папке где лежит сам .inf файл и все необходимые файлы к нему прилагающиеся.
Выбираем ОСи где работает драйвер.
Cross Cert — указываем путь к кросс-сертификату, если нужно подписать драйвер по-настоящему
Cert Store — названия хранилища, где лежит наш сертификат (например PrivateCertStore)
Cert Name — название сертификата (например TestCertforWDK), если сертификат один в хранилище, то можно и не заполнять это поле.
Time Stamp — адрес таймстампингового центра, для тестового сертификата — можно оставить пустым
Файлы которые надо подписать, тут нужно обязательно добавить cat файл (если еще не создан, то прописать его имя вручную), а также можно добавить все файлы драйверов
Generate Catalog Only — если подписывать не надо, а только создать .cat файл
Жмем Sign — чтобы создать cat-файл и подписать, жмем Log — чтобы почитать что произошло, часто бывают ошибки, например неправильно составлен inf-файл, либо signtool чего-то не нашел и т.п.

Литература по теме
http://msdn.microsoft.com/en-us/library/ff544865(VS.85).aspx

Источник