#1
|
|||
|
|||
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. |
#2
|
|||
|
|||
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 |
#3
|
|||
|
|||
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. |
#4
|
|||
|
|||
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
|
#5
|
||||
|
||||
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.
|
#6
|
|||
|
|||
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.
|
#7
|
|||
|
|||
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. |
#8
|
|||
|
|||
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. |
#9
|
||||
|
||||
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.
Quote:
Quote:
Quote:
Quote:
@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 Following User Gave Reputation+1 to bongos_man For This Useful Post: | ||
copyleft (02-27-2018) |
The Following User Says Thank You to bongos_man For This Useful Post: | ||
wild (02-27-2018) |
#10
|
|||
|
|||
Quote:
Quote:
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. |
#11
|
|||
|
|||
Quote:
Quote:
|
#12
|
|||
|
|||
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. |
#13
|
|||
|
|||
Quote:
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
making patch hex editing in .net | js78955 | General Discussion | 4 | 01-21-2015 04:26 |
editing Debug Information Directory in a PE file | jonwil | General Discussion | 6 | 01-15-2005 06:18 |
Editing a .key file? | peedizzle | General Discussion | 1 | 09-09-2004 00:49 |