0

I'm very new to windows driver development. I've written a KMDF windows driver and I'm able to test deploy it to my target machine using VS deploy. It worked fine and now I'd like to ship this driver with the application that uses this driver.

Here the problem comes... I couldn't find anything on Google that telling us how to distribute a KMDF driver(like making an installer). This driver is an upper class filter driver and it is only needed for my application so it should not be published to windows update.

My question is how to make something like an installer to distribute this driver? Thanks for any suggestion or tutorial.

EDIT 1 It is a fake device driver(meaning there is no physical device to drive)

MiDaa
  • 1,149
  • 1
  • 11
  • 25

1 Answers1

2

Usually, device drivers for software won't be pushed out through Windows Update. There's exceptions for vendors like Intel, AMD, NVIDIA, but that is because of what those companies are and how popular/well-used they are (they will be working with Microsoft for such). You can't just have your driver pushed out via Windows Update.

You're going to need a digital signature to sign your kernel-mode software with as long as you're going to be distributing it onto machines using modern versions of Windows x64 (for the record, even Windows Vista x64 will enforce this requirement). This requirement will not be present on x86 versions of Windows as-of right now, but in all truth, it would be unethical to not sign your kernel-mode software anyway.

Starting on Windows 10 on a specific patch which was released really early-on, the requirement changed from having a normal digital signature which could work for signing kernel-mode binaries to it having to be an EV digital signature; to get your hands on an EV digital signature for kernel-mode software signing, you will undoubtedly need to be legally registered as a company (and likely require a company bank account as well).

See the following for more information about this.

https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/04/01/driver-signing-changes-in-windows-10/

Here's the twist though... For systems which are using Secure Boot (new modern systems tend to have it enabled by default now, it is a security feature), you will need to have your kernel-mode software co-signed by Microsoft themselves. This will require you to share your kernel-mode software with Microsoft by uploading it via an online portal, but you'll still need your EV digital signature before you can move to that stage.

See the following for more information regarding the Microsoft co-signing requirement (depending on the environment):

https://www.osr.com/blog/2017/07/06/attestation-signing-mystery/

Note: Please do not try to come up with ideas to circumvent this (e.g. enabling Test Mode on a clients system and then using a Test certificate for your driver, or disabling Secure Boot on a system which relies on it... such work-arounds come with a huge price of reducing the security on the system, and should never be applied as a solution to this problem in the real-world).

For actually installing the device driver, you could programmatically use the .INF file with the Win32 API and then use the StartService routine to start the service post-installation with the .INF. Also see: https://msdn.microsoft.com/en-us/library/aa376957%28v=vs.85%29.aspx

Alternatively, you can register the service yourself with the CreateService routine and then start it with the StartService routine (or reboot and have it load on start-up depending on the flags for the service creation).

Bear in mind, sometimes using the Service Manager, you'll miss important things in registration for some driver types (e.g. Filesystem Minifilter), and you'd need to handle this manually otherwise it won't work. Check the .INF and make sure anything that needs to be done as an requirement is done when you use the Service Manager for installation (if you decide not to rely on the .INF).

Hope this helps you get to where you need to be.

ImmortaleVBR
  • 640
  • 5
  • 10
  • It seems that installing the driver is not an option for me/us anymore... I also heard that kernel driver can be dynamically loaded when we use it and unload after using, is this true? And does is also restricted by the above? – MiDaa Jun 22 '18 at 13:40
  • You can dynamically load a device driver and unload it, that is correct, but it doesn't change the code signing requirements on 64-bit versions of Windows. For certain types of device drivers though (e.g. Filesystem Minifilter would be an example), the .INF file when used for installation will do things that the Service Manager won't do for you by default, so you'd still have to make-up for that if you didn't use the .INF file programmatically and your device driver fitted into that category. – ImmortaleVBR Jun 22 '18 at 13:42
  • However, if you did have a loaded driver (it would also work if it was officially "installed" and loaded automatically at boot or by other ways, by the way), you can just stop the service you registered for the device driver via ControlService. You'd need to have a DriverUnload routine in your driver though, otherwise it won't work. Alternatively, you could use NtUnloadDriver, but this is not recommended since it is undocumented (and wouldn't change the fact that you'd still need a DriverUnload routine registered in your driver for it to work). – ImmortaleVBR Jun 22 '18 at 13:44
  • By "DriverUnload", I mean you need to register it in the _DRIVER_OBJECT pointed to by the pointer you get from your DriverEntry routine. However, sometimes for types like Filesystem Minifilter, you will have different way of registering it... e.g. via registration info of a callback. You'd have to check the documentation for your type of driver. – ImmortaleVBR Jun 22 '18 at 14:03
  • thanks a lot for your detailed explanation please give me some time to read through and understand! – MiDaa Jun 22 '18 at 14:04