不使用第三方工具或漏洞让Windows系统加载自己签名的内核驱动

whdfog

看论坛内帖子“从Sandboxie源码分析软件注册机制及逆向思路”（https://www.52pojie.cn/thread-1793118-1-1.html）发现最后加载驱动时要关闭驱动程序强制签名，而关闭强制签名会被部分游戏或程序检测到导致程序拒绝启动。如果能够不关闭强制签名去加载内核驱动，对系统的影响是最小的。

（以下方法在Windows 10 企业版 21H2 19044.5011测试通过）

在网络上查资料找到了这个项目“HyperSine/Windows10-CustomKernelSigners”（https://github.com/HyperSine/Windows10-CustomKernelSigners），
查看项目介绍（https://github.com/HyperSine/Windows10-CustomKernelSigners/blob/master/README.zh-CN.md#1-%E4%BB%80%E4%B9%88%E6%98%AFcustom-kernel-signers）

Custom Kernel Signers(CKS) 是Windows10（可能从1703开始）支持的一种产品策略。这个产品策略的全名是CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners，它允许用户自定义内核代码证书，从而使得用户可以摆脱“驱动必须由微软签名”的强制性要求。

如果一个Windows10 PC满足下列条件：

    1. 产品策略CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners是开启的。 （也许CodeIntegrity-AllowConfigurablePolicy也要开启。）

    2. SecureBoot也是开启的。

那么任何拥有该PC的UEFI Platform Key的人都可以自定义内核代码证书。这意味着，在不开启调试模式、不开启TestSigning、不关闭DSE的情况下，他可以使系统允许自签名驱动的加载。

于是跟随项目内教程（https://github.com/HyperSine/Windows10-CustomKernelSigners/blob/master/asset/build-your-own-pki.zh-CN.md）创建了3个证书（localhost-root-ca，localhost-km，localhost-pk），localhost-root-ca作为根证书用于签发localhost-km和localhost-pk，localhost-km用于给要加载的内核驱动签名，localhost-pk作为PK 证书用于导入UEFI 固件。
为了导入自己PK 证书需要先将安全启动重置为Setup Mode，重置后现有PK 证书会被清除。如果电脑的BIOS设置可以直接导入crt格式PK 证书直接导入就行，不必重置进Setup Mode。部分BIOS只支持通过AUTH文件导入PK 证书，这种就需要重置为Setup Mode。
生成AUTH文件需要efitools，efitools只能在Linux系统上使用。Windows电脑可以通过WSL 1（不需要WSL 2）安装一个Ubuntu，在Ubuntu内安装efitools的命令是

[Shell] 纯文本查看 复制代码

sudo apt install efitools

efitools的软件包下载网页：
https://packages.ubuntu.com/zh-cn/jammy/amd64/efitools/download
efitools二进制文件下载网页：
https://archlinux.org/packages/extra/x86_64/efitools/（下载地址：https://archlinux.org/packages/extra/x86_64/efitools/download/）

以下是在WSL内用efitools生成AUTH文件的代码的示例

[Shell] 纯文本查看 复制代码

cert-to-efi-sig-list -g "$(cat GUID.txt)" "localhost-pk.crt" "localhost-pk.esl"
sign-efi-sig-list -k localhost-pk.key -c localhost-pk.crt PK localhost-pk.esl PK.auth
sign-efi-sig-list -g "$(cat GUID.txt)" -k localhost-pk.key -c localhost-pk.crt PK /dev/null WipePK.auth

openssl x509 -inform der -outform pem -in "microsoft corporation kek 2k ca 2023.crt" -out "microsoft corporation kek 2k ca 2023.pem"
openssl x509 -inform der -outform pem -in "MicCorKEKCA2011_2011-06-24.crt" -out "MicCorKEKCA2011_2011-06-24.pem"
cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b "microsoft corporation kek 2k ca 2023.pem" "microsoft corporation kek 2k ca 2023.esl"
cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b "MicCorKEKCA2011_2011-06-24.pem" "MicCorKEKCA2011_2011-06-24.esl"
cat "kek 2k ca 2023.esl" "MicCorKEKCA2011_2011-06-24.esl" > "kek.esl"
sign-efi-sig-list -k localhost-pk.key -c localhost-pk.crt KEK kek.esl KEK.auth

openssl x509 -inform der -outform pem -in "MicCorUEFCA2011_2011-06-27.crt" -out "MicCorUEFCA2011_2011-06-27.pem"
openssl x509 -inform der -outform pem -in "microsoft uefi ca 2023.crt" -out "microsoft uefi ca 2023.pem"
openssl x509 -inform der -outform pem -in "MicWinProPCA2011_2011-10-19.crt" -out "MicWinProPCA2011_2011-10-19.pem"
openssl x509 -inform der -outform pem -in "windows uefi ca 2023.crt" -out "windows uefi ca 2023.pem"
cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b "MicCorUEFCA2011_2011-06-27.pem" "MicCorUEFCA2011_2011-06-27.esl"
cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b "microsoft uefi ca 2023.pem" "microsoft uefi ca 2023.esl"
cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b "MicWinProPCA2011_2011-10-19.pem" "MicWinProPCA2011_2011-10-19.esl"
cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b "windows uefi ca 2023.pem" "windows uefi ca 2023.esl"
cert-to-efi-sig-list -g "$(cat GUID.txt)" "cert_uefidb.crt" "cert_uefidb.esl"
cat "MicCorUEFCA2011_2011-06-27.esl" "microsoft uefi ca 2023.esl" "MicWinProPCA2011_2011-10-19.esl" "windows uefi ca 2023.esl" "cert_uefidb.esl" > "db.esl"
sign-efi-sig-list -k localhost-pk.key -c localhost-pk.crt DB db.esl DB.auth

sign-efi-sig-list -k localhost-pk.key -c localhost-pk.crt DBX x64_DBXUpdate.bin DBX.auth

需要在运行Shell的目录下创建一个GUID.txt，文件内容是自己生成的8-4-4-4-12格式的GUID（如微软的所有者 GUID：77fa9abd-0359-4d32-bd60-28f4e78f784b）。
Shell的目录下还需要有base-64编码的证书文件localhost-pk.crt及其私钥localhost-pk.key。
涉及到的证书文件在文章最后有下载地址。

设置好PK 证书后就要构建内核代码证书规则。一个现成的内核代码证书规则文件（https://www.geoffchappell.com/notes/windows/license/selfsign.xml.htm）。
这个规则文件需要包含自己生成的localhost-km证书。
转换localhost-pk.crt为签名可用的localhost-pk.pfx的代码

[Shell] 纯文本查看 复制代码

openssl pkcs12 -export -in localhost-pk.crt -inkey localhost-pk.key -out localhost-pk.pfx

导出localhost-pk.pfx时会提示输入密码，全部留空直接回车即可。

规则生成并签名后需要移动到当前系统的EFI目录下（以下提供的命令可自动完成）。
以下是构建内核代码证书规则的PowerShell代码

[PowerShell] 纯文本查看 复制代码

if(!([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) {
Start-Process -FilePath PowerShell.exe -Verb RunAs -ArgumentList ("-NoExit",("cd {0} ;" -f $PSScriptRoot),("`"$($MyInvocation.MyCommand.Path)`" $($MyInvocation.UnboundArguments)"))
Exit
}

Write-Host "本脚本同目录下需要有signtool.exe/localhost-km.crt/localhost-pk.pfx 3个文件"
Set-Location -path "$(Get-Location)"
New-CIPolicy -FilePath SiPolicy.xml -Level RootCertificate -ScanPath C:\windows\System32\
Add-SignerRule -FilePath .\SiPolicy.xml -CertificatePath localhost-km.crt -Kernel -Update -Supplemental
Set-RuleOption -FilePath .\SiPolicy.xml -Option 2 -Delete   #2 - Required:WHQL
Set-RuleOption -FilePath .\SiPolicy.xml -Option 3 -Delete   #3 - Enabled:Audit Mode (Default)
Set-RuleOption -FilePath .\SiPolicy.xml -Option 12 -Delete  #12 - Required:Enforce Store Applications
Set-RuleOption -FilePath .\SiPolicy.xml -Option 6   #6  - Enabled：Unsigned System Integrity Policy
Set-RuleOption -FilePath .\SiPolicy.xml -Option 9   #9  - Enabled：Advanced Boot Options Menu
Set-RuleOption -FilePath .\SiPolicy.xml -Option 10  #10 - Enabled：Boot Audit on Failure
Set-RuleOption -FilePath .\SiPolicy.xml -Option 17  #17 - Enabled: Allow Supplemental Policies
Set-CIPolicyVersion -FilePath .\SiPolicy.xml -Version 10.0.0.0
Write-Host ""
Write-Host "    <!-- For Wellknown CertRoot `"01`" the certificate chain is too long or "
Write-Host "      reaches a certificate whose issuer is not in the chain and does not "
Write-Host "      have the same name as any known Microsoft root. -->"
Write-Host "    <Signer ID=`"ID_SIGNER_KNOWNROOT_1`" Name=`"Unknown Root`">"
Write-Host "      <CertRoot Type=`"Wellknown`" Value=`"01`" />"
Write-Host "    </Signer>"
Write-Host "    <!-- For Wellknown CertRoot `"02`" the certificate chain reaches a "
Write-Host "      certificate that is its own issuer but which does not have the same "
Write-Host "      public key as any known Microsoft root. -->"
Write-Host "    <Signer ID=`"ID_SIGNER_KNOWNROOT_2`" Name=`"Self-Signed Root`">"
Write-Host "      <CertRoot Type=`"Wellknown`" Value=`"02`" />"
Write-Host "    </Signer>"
Write-Host ""
Write-Host "          <AllowedSigner SignerId=`"ID_SIGNER_KNOWNROOT_1`" />"
Write-Host "          <AllowedSigner SignerId=`"ID_SIGNER_KNOWNROOT_2`" />"
Write-Host ""
Read-Host -Prompt "修改SiPolicy.xml完成后按任意键继续"
ConvertFrom-CIPolicy -XmlFilePath .\SiPolicy.xml -BinaryFilePath .\SiPolicy.bin
signtool.exe sign /v /p7 . /p7co 1.3.6.1.4.1.311.79.1 /fd sha256 /ac localhost-root-ca.crt /f localhost-pk.pfx SiPolicy.bin
Move-Item -Force -Path .\SiPolicy.bin.p7 -Destination .\SiPolicy.p7b
mountvol X: /s
Copy-Item -Force -Path .\SiPolicy.p7b -Destination X:\EFI\Microsoft\Boot\
Write-Host "(EFI)SiPolicy.p7b签名状态："
certutil.exe -asn X:\EFI\Microsoft\Boot\SiPolicy.p7b
mountvol X: /d
Read-Host -Prompt "已完成，请按任意键继续"
$host.SetShouldExit(0)

需要根据脚本的提示修改生成的SiPolicy.xml内Signers和AllowedSigners项的内容。
signtool.exe是Windows Software Development Kit (SDK)的一部分，可以在网络上单独下载到。

据项目介绍（https://github.com/HyperSine/Windows10-CustomKernelSigners/blob/master/README.zh-CN.md#25-%E5%BC%80%E5%90%AFcustomkernelsigners）

CKS 的开关保存在HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions键的ProductPolicy值里。

尽管管理员可以修改这个值，但是这个值在被修改后会立即恢复原状。这是因为在内核初始化完后，这个值只是内核里一个变量的映射，只有通过ExUpdateLicenseData这个内核API才能修改。而这个API只能在内核里被调用，或者通过NtQuerySystemInformation的SystemPolicyInformation功能号间接调用。很遗憾的是后者只有Protected Process才能 成功 调用。

所以我们只能在内核还尚未初始化完的时候修改 CKS 开关。有这个机会吗？有，Windows的Setup Mode可以给我们提供这个机会。
我已经写了一个程序来帮助我们打开 CKS，二进制程序是EnableCKS.exe。EnableCKS.exe会自动启动并开启
CodeIntegrity-AllowConfigurablePolicy
CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners

但微软在新系统中删除了CodeIntegrity-AllowConfigurablePolicy这个产品策略，运行EnableCKS.exe后程序无法开启CodeIntegrity-AllowConfigurablePolicy会导致无限重启。（如果已经无限重启，可进PE的注册表编辑器，点击HKEY_LOCAL_MACHINE，再点击文件-加载配置单元，选择C:\Windows\System32\config文件夹下的SYSTEM文件，修改加载的注册表HKEY_LOCAL_MACHINE\SYSTEM\Setup下SetupType的值为0即可。修改完成后记得卸载配置单元保存修改。）
我用了另一个项目valinet/ssde（https://github.com/valinet/ssde），这个项目作者编译的ssde_enable.exe解决了这个错误，可以正常开启CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners并重启。

据项目介绍（https://github.com/HyperSine/Windows10-CustomKernelSigners/blob/master/README.zh-CN.md#26-customkernelsigners%E6%8C%81%E4%B9%85%E5%8C%96）

CustomKernelSigners持久化

重新进入正常模式后，你应该就可以加载由localhost-km.pfx签署的驱动了。但是别高兴得太早，大约在10分钟之内，CKS 会被sppsvc服务重置为关闭，除非你的Windows10是中国政府特供版。但不用担心，关闭还得等重启后才会实际生效。

所以我们得趁这个机会，加载自己编写的驱动，通过不断调用ExUpdateLicenseData来持久化 CKS。

ssde项目的作者同样编译了一个驱动ssde.sys来持久化 CKS，但是这个驱动没有签名。需要通过以下命令用localhost-km证书签名ssde.sys

[Shell] 纯文本查看 复制代码

signtool sign /v /fd sha1 /ac localhost-root-ca.crt /f localhost-km.pfx /tr "http://timestamp.digicert.com" ssde.sys
signtool sign /v /fd sha256 /as /ac localhost-root-ca.crt /f localhost-km.pfx /tr "http://timestamp.digicert.com" ssde.sys

将签名完成的ssde.sys复制到%SystemRoot%\System32\drivers\目录下（一般都是C:\Windows\System32\drivers\）。
然后用管理员权限运行以下命令

[Shell] 纯文本查看 复制代码

sc create ssde binpath=%SystemRoot%\System32\drivers\ssde.sys type=kernel start=auto error=normal

注意命令中的%SystemRoot%最好不要替换为%Windir%，尽管%SystemRoot%和%Windir%的值应该都是C:\Windows\，但个人实测使用%Windir%会导致驱动无法启动，而用%SystemRoot%驱动就可以启动。
根据微软官方文档（https://learn.microsoft.com/zh-cn/dotnet/api/system.serviceprocess.servicestartmode#fields），start参数最好是auto，设置为boot可能会导致ssde.sys驱动没有对应的设备从而无法启动。

现在再重启电脑，产品策略CodeIntegrity-AllowConfigurablePolicy-CustomKernelSigners应该会保持开启（注册表HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\CI\Protected的值为1即为开启），也就可以加载自己签名的内核驱动了。以后启动Windows系统CustomKernelSigners策略应该都会保持开启。

微软KEK和DB证书（https://learn.microsoft.com/zh-cn/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guIDAnce）：
Microsoft Corporation KEK CA 2011
    SHA-1 证书哈希：31 59 0b fd 89 c9 d7 4e d0 87 df ac 66 33 4b 39 31 25 4b 30。
    SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
    可从以下位置下载 Microsoft KEK 证书：https://go.microsoft.com/fwlink/?LinkId=321185
Microsoft Corporation KEK 2K CA 2023
    SHA-1 证书哈希：45 9a b6 fb 5e 28 4d 27 2d 5e 3e 6a bc 8e d6 63 82 9d 63 2b。
    SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
    可从以下位置下载 Microsoft KEK 证书：https://go.microsoft.com/fwlink/?linkid=2239775
Microsoft Windows Production PCA 2011
    SHA-1 证书哈希：58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d。
    SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
    Windows Production PCA 2011 可以从以下位置下载：https://go.microsoft.com/fwlink/p/?linkid=321192
Windows UEFI CA 2023
    SHA-1 证书哈希：45 a0 fa 32 60 47 73 c8 24 33 c3 b7 d5 9e 74 66 b3 ac 0c 67。
    SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
    可从以下位置下载 Windows UEFI CA 2023：https://go.microsoft.com/fwlink/?linkid=2239776
Microsoft Corporation UEFI CA 2011
    SHA-1 证书哈希：46 de f6 3b 5c e6 1c f8 ba 0d e2 e6 63 9c 10 19 d0 ed 14 f3。
    SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
    可从以下位置下载 Microsoft Corporation UEFI CA 2011：https://go.microsoft.com/fwlink/p/?linkid=321194
Microsoft UEFI CA 2023
    SHA-1 证书哈希：b5 ee b4 a6 70 60 48 07 3f 0e d2 96 e7 f5 80 a7 90 b5 9e aa。
    SignatureOwner GUID：{77fa9abd-0359-4d32-bd60-28f4e78f784b}。
    Microsoft 会向合作伙伴提供证书，可将该证书添加为 EFI_CERT_X509_GUID 或 EFI_CERT_RSA2048_GUID 类型的签名。
    可从以下位置下载 Microsoft UEFI CA 2023：https://go.microsoft.com/fwlink/?linkid=2239872

从 Microsoft 下载最新的 UEFI 吊销列表【禁止的签名数据库（DBX）】：https://www.uefi.org/revocationlistfile

其他参考文章：
Licensed Driver Signing in Windows 10（https://www.geoffchappell.com/notes/windows/license/customkernelsigners.htm）
实施 Secure Boot（https://cascade.moe/posts/secure-boot/）
Properly install into a new system #4 （https://github.com/valinet/ssde/issues/4#issuecomment-1926593978）

Nettos

好麻烦，直接花钱去买个黑签

wapj258

不错的思路

whdfog

SiPolicy.xml其实可以不用修改，把脚本第35行Read-Host直接注释掉，或者脚本运行时不修改SiPolicy.xml文件直接回车让脚本继续运行即可。

moxiaobei890512

门外汉，完全看不懂

chplifeng

有点儿看不懂，还是支持一下吧。

Cleopatra

这个仓库看了一下5年前的，不知道现在还能过杀软不

maoyj

厉害，我的兄弟

liltn

很详细，感谢楼主分享

Aurelion

我按Windows10-CustomKernelSigners这个项目所说的最终加载成功了, 但是,  某些驱动反而无法加载,  如YDARK, WKE,  企鹅的ACE驱动,WEGAME驱动 全都失效, 重启也没用, 现在还要想办法恢复


2024.10.14 ps:  若要恢复, 删除掉刚刚写入进启动分区的文件 X:\EFI\Microsoft\Boot\SiPolicy.p7b.    bios重置平台密钥
2024.10.15 ps:  企业版中重新生成了p7b文件放到上面的路径, 其他驱动可以正常加载了. (项目中说必须在企业版或教育版中执行, 其他版本无法完成, 但我WIN10专业版依旧可以完成)






WKE与YDARK都是黑签, 直接加载不了, 本来是正常的. 但鹅厂正规的驱动怎么也会加载不了?