I have tried to run the NONPNP windows driver code. It installs and when I run the nonpnpapp.exe I get a driver signing error.
"windows requires a digitally signed driver"
I am running this on debug mode and release I am test signing it.
Why am I still getting this error?
I do know that x64 machines needs this, I am on windows7 x64.
So we need to do something else.
Visual studio output says that the sys file is successfully signed.
I trace the code. It copies the sys to system32/drivers after it is signed.
Windows device installation uses digital signatures to verify the integrity of driver packages and to verify the identity of the vendor (software publisher) who provides the driver packages. In addition, the kernel-mode code signing policy for 64-bit versions of Windows Vista and later versions of Windows specifies that a kernel-mode driver must be signed for the driver to load.+
Note Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016 kernel-mode drivers must be signed by the Windows Hardware Dev Center Dashboard, which requires an EV certificate. For details, see Driver Signing Changes in Windows 10. https://learn.microsoft.com/en-us/windows-hardware/drivers/install/driver-signing
Two options there;
1) allow test signing
2) disable driver signature enforcement
If you are using a dedicated test machine, I recommend the second option since I think it's more error proof.
Related
I've developed a kernel-mode driver for Windows 10. How should I properly sign it? I want my driver to be installable without enabling test-signed drivers installation after sign procedure.
I recently took on a task to update our filter driver from building with Visual Studio 2015 -> 2019. I also moved to the latest SDK + WDK 22000 (Which is the new Windows 11 one).
Everything seemed to work except that on Win 7 x64 (with secure boot) boxes the driver no longer loads.. It get's:
Load failed with error: 0x80070241
Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damaged,
or that might be malicious software from an unknown source.
Our driver was/is attestation signed by Microsoft via the MS Hardware portal and so it's joint signed by both our company and Microsoft with a SHA-2 signature each. Windows 7 doesn't support SHA-2 certs out of the box however, it was previously working provided:
Windows6.1-KB3033929-x64
Was installed. Something seems to have changed though and Windows 7 x64 boxes can't load the new driver even with the latest updates. They load the 2015 built driver just fine even though the certificates on both look identical. The new driver loads just fine on Windows 10 machines.
Is anyone aware of any other changes which might make this combination fail to load?
I had a similar issue a few months ago, when we decided to switch our certificate provider. I'll share my knowledge to you, hope that going to help.
A while ago, Microsoft used cross-certificates to validate trusted certificate authorities (CA), so the only thing you needed to sign a driver is a proper certificate bought from a trusted CA. But recently validating process had changed and starting from Windows 10 20H2 you are forced to sign your driver through Microsoft Partner Center and all the cross-certificates was deprecated. However, you still need to use cross sign process for all your drivers prior to Windows 10, actually cross signed driver will work up to Windows 10 20H1 if to be correct.
Now back to the Visual Studio. To properly sign driver, you had to set up production certificate to field Properties -> Driver Signing -> General -> Production Certificate, that causes Visual Studio to use signtool utility to sign driver after the build done. As I presume, Visual Studio 2019 process do not use cross-certificate and looks something like:
signtool sign /v <trusted_certificate> /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a <sys_driver_filepath>
But Visual Studio 2013 actually must use cross-certificate and the command it uses is:
signtool sign /v /ac <microsoft_cross_certificate> /tr http://timestamp.digicert.com /a <sys_driver_filepath>
So what is cross-certificate is? It's a special trusted Microsoft certificate that tied to certified CA. List of all the cross-certificates available can be found here https://learn.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing#cross-certificate-list. To take the correct one you need to check your company certificate first. Take a look into root of certification path of your cert, open View Properties -> Details and find Issuer, that's your CA. Now you need to find exact match on cross-certificate list and download it. Note the thumbprint doesn't need to match (revealed in related issue). After all use a proper signtool command to sign your file.
P.S. If your certificate issuer not present on the list, that means your CA inappropriate and you need to get/buy another certificate.
I'm trying to develop a simple Windows 10 app and I wanted to simulate a Pedometer for testing. How can I do that? And what about other type of sensors, can I simulate them too?
Ok I found a solution.
Microsoft provides sample drivers here and there you can find sensors folder. So download what you need, compile and deploy.
To compile you need Windows Driver Kit.
If you're deploying to a x64 machine the drivers has to be signed. I had trouble signing the drivers so I booted Windows 10 with no driver signature enforcement and deployed the driver using DevCon. Check the driver INF once compiled to see the installation instructions.
To build my driver i used VisualDDK in visual studio 2008. In the beginning i start debugging using my computer and virtualBox machine but when i launch the debugging process in visual studio, my virtual machine did not show me the external ip address(normally should show me 192.168.1.102 and 10.0.1.15 in DDKLauncherMonitor but it show me only 10.0.1.15 ).
I stopped using virtual machine and i decide to use real computer. In the second computer i launched DDKLauncherMonitor. And i start debugging from my first computer. I received Udp package in my second machine and also the driver.sys. But when i tried to load the driver from visual studio(First computer) nothing work. Plus this, in the second machine tell me "Windows required digitally signed driver".
There is same one meet this kind of problem and he/she can help.
Can you go into more details when you say "nothing works"? It's possible that your debugger is not set up properly.
This is kind of a pseudo-answer since I'm not overly aware of VisualDDK, but have you considered trying the standard Microsoft debugging tools like WinDbg? If you can acquire Visual Studio 2012 or 2013 Preview, all of the build and debug tools are integrated into the IDE and you will get full support from Microsoft with any problems you may encounter.
As for your second issue, it sounds like you're building a driver and not signing it. Is your target PC 64-bit? What operating system is it? The 64-bit Windows platform requires signed drivers for installation, but this can be disabled.
You can disable the driver signing requirement using the F8 menu when booting your PC; this should fix your "digitally signed driver required" problem, but needs to be done for each reboot.
Another option would be to add a post-build step or some sort of scripted execution of the Microsoft signing tools (Inf2cat, SignTool) to sign your driver with your company's certificate.
I have written a device driver for a device but each time I connect the device in windows XP 32 bit, "found new hardware" wizard appears.
I am signing the driver using a Comodo code signing certificate and not using the cross certificate chain to link to microsoft root authority. Nor is the driver wql certified.
So my question is to disable the found new hardware wizard on windows xp:
i) Does my driver needs to be wql certified?
ii) signed with microsoft root certificate using cross certificate from verisign?
iii) or something i missed out in my code which needs to be changed?
did some research and found the answer:
windows XP does not support authenticode driver signing and there are no plans to add it. Only way is to sign using microsoft certificate by using a cross certificate
As far as I know, the only driver signing recognized by Windows XP is a WHQL signature. Cross-signing has nothing to do with it. (Cross-signing allows the Windows Vista kernel driver loader to recognize Authenticode signatures. It has nothing to do with Windows XP driver loading.)
Authenticode signatures, while they would validate with DIFx / DpInst, would fail to validate later when SetupAPI tries to install your device driver out of the driver store.