Is editing a driver's *.inf possible?
 

Lets assume the following (unspecified so it's easier to understand):
I have two hardware devices with DeviceIDs PCI\001 and PCI\002 and I'm running Windows 10 x64.

Windows has a driver for PCI\001 included, but for PCI\002 it needs a vendor specific driver.

The vendor specific driver comes as a driver package:
driver.sys (signed by vendor and "Microsoft Windows Hardware Compatibility Publisher")
driver.inf (not signed)
driver.cat (signed by "Microsoft Windows Hardware Compatibility Publisher")

driver.inf says that the driver supports PCI\001 and PCI\002, but the vendor driver.sys does not support the PCI\001 device.

The fact that the driver.inf claims it would support PCI\001 makes Windows unload its own driver for PCI\001.

At this point I could either use the Windows default driver for PCI\001 and have a not working PCI\002 or I could use the vendor driver for PCI\002 and have a not working PCI\001.

So the easiest way would be to edit driver.inf and remove the line saying it supports PCI\001. However, driver.cat contains the hash for driver.inf, so if I edit driver.inf Windows will not load the driver because it has no valid signature. If I remove the driver.cat entry from driver.inf or the file driver.cat Windows will not load the driver either.

Is there any way to force Windows to ignore specific sections of *.inf files or to force it to load only its own driver? Or some way to edit *.inf files without invalidating the signature? Since driver.sys is signed and unmodified this could be possible somehow.

You can try install vendor pack, then delete vendor inf and update device tree in the device manager. Or play with different cases around.
Also, if you have own certificate you can try to re-sign the whole package with edited inf

The correct strategy is as far as I know to update to the vendor specific driver. PCI001 will be broken, so you go into device manager, do a "driver rollback", and it will go back to a working driver for that device only, and it will blacklist the new driver for that device. Probably some special exclusion registry key gets set on a per device basis.

Changing the .inf is not the right approach as you point out because of signing. Likely there is no automatic loading. What is most certain is the driver installation oversteps. So you have to let it overstep, then undo the damage on a device by device basis such as with a rollback.

You also can edit the .inf (if you are sure that this will work), delete the signature and then disable de driver signature enforcement feature to install the "new" driver

The inf file is only used for installing, so you should check where the inf file stores the settings which devices to support, and edit it manually after installation. The question is if the .sys binary supports this at all.

But driver load should not cause a reinstallation (that would be a bad behavior), so it can be fixed on a device by device basis without even leaving the device manager and hand tweaking registry keys which require permission of SYSTEM.

Do any of these ideas work in WinPE? I would need to setup both devices during Windows setup in the preinstall environment and make sure Windows never removes one of them.

From the things I've tried so far all edits of the *.inf invalidated the signature and since the driver is a boot-time kernel-mode driver I can't just use any certificate to sign it, it would need to be a WHQL certificate from Microsoft.

I am assuming the driver is being included through dism add-driver option. Why not just mount the SYSTEM registry hive on the WinPE image and fix it based on seeing how the rollback blacklists it?

I think the testsigning option in the BCD should still work however even for boot level drivers.

there is a lot of confusion in this thread. i have a valid code signing certificate, so i will try to clear up the misconceptions.

windows will not even load a driver that has no signature, regardless of how you boot. a pnp driver package typically needs a signed .sys and a signed .cat that vouches for it. "no signature" simply does not work.

you want him to take a registry comparison of before and after installing the driver and work backwards to determine what to add to the .inf? are you kidding?

@chants is almost correct here, let me first correct one thing:

an EV code signing certificate from a microsoft-approved CA is all that is required for most kernel drivers, you do not need to submit for whql except for boot-critical drivers (i am simplifying, in truth this has gotten more complicated as of windows 10 1607, but the details will not matter in your case). you can tell dism and the windows boot process to ignore the whql requirement, however you will still need to test sign your driver after you modify the .inf. this will be a multi-step process if you want the system to boot up with the drivers loaded without further manual intervention.

@Kerlingen first, please read this page in its entirety. you said your third-party driver is "boot-time kernel-mode", but kernel-mode does not imply "boot-time", or at least, it does not imply what most people think it does. since the driver for your PCI\002 device comes with a signed .cat, it is actually not boot-critical (as it would require an embedded signature), but rather a pnp driver; this is the case with nearly all drivers. the important parts of the page:

1. Adding Drivers - you will be using dism offline for this; however, see #3
2. Understanding Driver Ranking - this is how pnp will decide which driver to install
3. Understanding Digital Signature Requirements - you will need to resign the driver with a test signing certificate. you will also need to boot your image to add the test signing certificate to the image. you can *THEN* use dism to add the test-signed driver to the offline image

* how to create test signing certificates and test sign the driver. you will use a catalog file and the inf for this, not embedded signing
* how to use dism to add the driver to the offline image

i would suggest you start by trying to get windows to successfully install and load your driver on an already running system. in other words, edit the .inf, create and install the test signing certificate, create the .cat, sign it and the driver, enable test signing mode, reboot, install the driver, reboot again, and cross your fingers ;]

let me know if you have any questions and i can try to help more. this page also has some useful information if you're really stuck.

also, i'd just like to say that i spent a few hours digging up the references for this post and writing it (even though i do this stuff every day), if you (or anyone else) appreciates it, i would appreciate some rep, it seems to be given out rather sparingly these days even for high-quality posts. hard family to join ;]

The driver is for a RAID controller and, like I wrote, driver.sys is signed both by the vendor and by Microsoft.

I can't install Windows if it doesn't detect any harddisk which could be used for installation.
If I install it with the default Microsoft driver and install the vendor driver on the running system, Windows will unload its own driver, which leads to an instant BSOD since the boot device becomes inaccessible.
I can only load the vendor driver during Windows setup, since WinPE is running from a RAM drive and losing access to the harddisk will not crash it.

thank you for the clarification. distribution via windows update also, if i recall correctly, requires whql, so i figured the driver had gone through that process. i apologize for my tone; i should not have assumed that you might have not known about this detail (microsoft hardly documents it themselves).

is it mandatory that the windows in-box driver for your PCI\001 be working right now? in other words, can you add the vendor driver via the procedure outlined here for adding boot-critical drivers to winPE, install to a drive on the now-visible PCI\002, then use this installation to begin with the process i outlined?

I don't really need to integrate the drivers into Windows setup, I don't care if I need to manually load the drivers each time, I just need both of them to be loaded at the same time.

PCI\001 = SSD connected to AHCI controller
PCI\002 = HDDs connected to RAID controller

Windows will detect AHCI out of the box, but not the RAID controller. If I load the driver for the RAID controller, Windows will unload the AHCI driver (since the RAID driver.inf claims it would support the AHCI and the RAID DeviceIDs, but it only detects the RAID controller).

For obvious reasons I want to install Windows on the SSD and use the HDDs for data storage. Currently I can only use either SSD or HDDs, not both.

I deliberately asked an "unspecified" question starting the topic since I didn't want to inflate a bigger problem-complex which I already had reduced to one specific single problem.

you would need to get the drivers into windows setup somehow so that you don't get the bsod issue (because you'd install onto the raid controller to prevent it, do all this work, then reinstall onto the SSDs with the new driver running PCI\001), or, you can take advantage of this thread to modify the .inf to remove the listed support for PCI\001 from your driver. better move fast on that thread, by the way ;]