Force Windows XP to treat signed and unsigned drivers equally?

[LoneCrusader]

Does anyone know if it is possible to force Windows XP (x86/x64) to treat signed and unsigned drivers equally, and not prefer a signed driver over an unsigned one?

I know it is possible to disable signature enforcement and stop the warning popups and such, this is not what I need. I need Windows to stop automatically preferring a signed "generic" (device ClassCode [CC] INF entry) driver over an unsigned "specific" (device [VEN&DEV] INF entry) driver.

I'm trying to manually slipstream motherboard chipset drivers into XP setup.. and the 250+ tiny INF and associated CAT files supplied by the OEM drive me nuts.  So I decided to build a single compiled INF file, similar to what I did for my Windows 9x Chipset INFs. Which is fine, except that it is unsigned, while XP's MACHINE.INF is signed. So Setup refuses to use my INF for, say, the PCI-E Root Ports, because it has a generic Class Code entry for these in MACHINE.INF, and uses it with generic names. But it does pick up my INF for the SMBus controller and gives it its proper name, because no other driver matches it. This is maddening...

Yes, I can manually force the use of the specific unsigned driver on the other devices through the device manager after the desktop is reached, but this defeats the purpose of having the driver slipstreamed to begin with. I can also edit MACHINE.INF with the new data and break its signature in the process.. but this leads to other dumb behavior, such as popups about "Terminal Server" device drivers during SETUP that require user interaction and break the unattended process.

[Tripredacus]

Presumably, you could re-sign MACHINE.INF after editing it, but I do not know if you have to sign it with a certain tool to match how it was signed originally. Also I do not know if you can use just any program to do it. Back when my company had to sign MS OS files, we had to use a PC with a PCI cryptography card to sign files. 

[LoneCrusader]

I've been told (and seen examples, i.e. Fernando's AHCI/RAID drivers) that one can self-sign files and/or obtain a certificate to do so, but I'm not sure that this method would necessarily work during a clean install, as "your" certificate would have to be imported and accepted as trusted prior to setup checking the files. Not saying it might not be possible, but I have no idea if it can be done in practice. I'm not aware of any way to "fix" a signature once it's been broken.. probably be hard information to find, even if it is possible, due to the possibility of using it for malicious purposes.

Any of our "XP on Modern Hardware" gurus care to chime in on this? @Mov AX, 0xDEAD, @Dietmar, @George King, @pappyN4

[George King]

setupapi.dll patch should do that job. I mean use any unsigned driver, including modified INFs during setup. Use patched dll just for setup, replace with original one later. 

	        REM Patch SETUPAPI
	       
	        REM 8B FF 55 8B EC 8B 45 2C 33 C9 3B
	        REM 33 C0 C2 30 00 8B 45 2C 33 C9 3B
	 
	       
	        expand "%~dp0_output\i386\SETUPAPI.DL_" "%~dp0_output\i386\SETUPAPI.DLL" >nul
	        del /q /s "%~dp0_output\i386\SETUPAPI.DL_" >nul
	       
	        "%~dp0apps\bbe\%ARCH%\bbe.exe" -b "/\x8B\xFF\x55\x8B\xEC\x8B\x45\x2C\x33\xC9\x3B/:11" -e "s/\x8B\xFF\x55\x8B\xEC\x8B\x45\x2C\x33\xC9\x3B/\x33\xC0\xC2\x30\x00\x8B\x45\x2C\x33\xC9\x3B/" "%~dp0_output\i386\SETUPAPI.DLL" -o "%~dp0_output\i386\SETUPAPI2.DLL"
	       
	        del "%~dp0_output\i386\SETUPAPI.DLL"
	        ren "%~dp0_output\i386\SETUPAPI2.DLL" "SETUPAPI.DLL"
	

Edited June 22 by George King

[LoneCrusader]

4 hours ago, George King said:

setupapi.dll patch should do that job.

Sounds promising. Tried using that just now, but I'm currently working on the x64 version of XP. Apparently the patch for the x64 version of SETUPAPI.DLL needs further work, it triggers an endless loop. Will elaborate further in that thread.

I put this topic in the main XP section since I meant for it to apply to both x86/x64, but It may need moving to the x64 section later if divergent methods are necessary.

[George King]

Are you sure you really need that driver integrated into setup? 

Try x86 version first. These both XPs are different kernel level 5.1 vs 5.2

 

I think I’m using in XP2ESD only syssetup.dll patches on 5.2. (I’m out of my machine, cant check it today)

 

https://www.wincert.net/forum/topic/17689-xpw2k3-x64-on-modern-hardware/?do=findComment&comment=138860

Edited June 22 by George King

[reboot12]

On 6/14/2024 at 5:24 AM, LoneCrusader said:

I'm trying to manually slipstream motherboard chipset drivers into XP setup..

Use patched sfc_os.dll

[LoneCrusader]

22 hours ago, George King said:

Are you sure you really need that driver integrated into setup? 

Try x86 version first. These both XPs are different kernel level 5.1 vs 5.2

I think I’m using in XP2ESD only syssetup.dll patches on 5.2. (I’m out of my machine, cant check it today)

https://www.wincert.net/forum/topic/17689-xpw2k3-x64-on-modern-hardware/?do=findComment&comment=138860

Need is subjective.. lol. Chipset drivers usually don't "do" anything other than correctly name and prevent unknown devices/yellow bangs under the Device Manager. But installing them is one of the first tasks to be performed every time a new system is set up, so it is preferable to have them integrated and dispense with this task.

Signed manufacturer files might be used somehow, but Intel insists on giving you over a hundred tiny INF and CAT files for a simple task that could be done with 3 files (1 for System Devices, 1 for USB controllers, 1 for Storage devices). And this fileset does not include any newer system devices that are "unsupported" for XP - for those you either make your own or hope XP can use the files provided for NT6x.

At any rate, I tried using my compiled INF file under XP x86 along with the SETUPAPI.DLL patch. It did not have any effect on the problem, so that looks like a dead end.
Still need a fixed SETUPAPI.DLL patch for x64 though, as it does help with the other things I mentioned in the other thread.

Not sure if SYSSETUP.DLL patches would have any effect - there is no warning box or error box, etc. I already prevented those with the relevant registry entries.
The system just silently prefers its signed, generic MACHINE.INF over my unsigned, specific INTELSYS.INF.
See pics below; this is what I see when I examine the Device Manager entries for the devices after reaching the Desktop.

12 hours ago, reboot12 said:

Use patched sfc_os.dll

Error/warning dialogs are not the issue. The problem is the silent preference for signed over unsigned, even if the signed driver is "generic."

[reboot12]

@LoneCrusader

Signed, not sighed - what's the difference? As you noticed, Intel drivers are not-drivers - just a change device names in the device manager. I use WinXP 64-bit on Intel Gen 8 and I made dummy drivers to eliminate yellow exclamation marks of several devices in device manager:

Now I don't have any unknown devices in the device manager

[LoneCrusader]

6 hours ago, reboot12 said:

Signed, not sighed - what's the difference?

Yes, I know. I don't care whether they are signed or not. But Windows does.

Setup refuses to use my specific-device-ID specific-name driver because it isn't signed, and uses its signed MACHINE.INF generic driver instead.

As you see in the shots, I can manually force my driver to be used after Setup is done. But that defeats the purpose of having it slipstreamed.

It also could theoretically cause problems in a situation where Windows has a generic driver pointed to a given installation routine, and you want to add a specific driver that points to a different installation routine.
For example an IDE controller*.. MSHDC.INF will send anything matching PCI\CC_0101 to the generic IDE install routine.
You might want to send PCI\VEN_8086&DEV_1C02 to an AHCI install routine with a specific driver INF.
But Windows would choose the generic signed driver over your INF because yours isn't signed.

*Intel avoids this particular situation because the storage controllers report different DEV ID's for different modes (IDE/AHCI/RAID) but not all manufacturers may do this.

[reboot12]

@LoneCrusader

I do not see the sense of installing these Intel drivers (not drivers) because it does not improve the operation of the device. Intel chipset drivers does not add any new .sys or .dll files only use WinXP e.g. machine.inf and system drivers (files) - only changes the name of the device in the device manager e.g. PCI-to-PCI bridge to Intel 6 Series PCI Express Root bla bla bla and this device PCI bridge will not start working better after installing Intel drivers.

I am glad that there are ported ACPI, AHCI, NVMe and USB 3.x drivers for WinXP - no matter if they are signed or not - it is important that they works.

[LoneCrusader]

On 6/23/2024 at 9:05 AM, reboot12 said:

I do not see the sense of installing these Intel drivers (not drivers) because it does not improve the operation of the device. Intel chipset drivers does not add any new .sys or .dll files only use WinXP e.g. machine.inf and system drivers (files) - only changes the name of the device in the device manager e.g. PCI-to-PCI bridge to Intel 6 Series PCI Express Root bla bla bla and this device PCI bridge will not start working better after installing Intel drivers.

I am glad that there are ported ACPI, AHCI, NVMe and USB 3.x drivers for WinXP - no matter if they are signed or not - it is important that they works.

Sure, they don't change anything. It's just a personal preference, hence why I said above that "need is subjective." But I prefer to have them installed, and it's all the more annoying that Windows refuses to do so, so I am therefore more determined to find a solution.

[D.Draker]

5 hours ago, LoneCrusader said:

Sure, they don't change anything. It's just a personal preference, hence why I said above that "need is subjective."

Windows Hardware Certification Kit User's Guide Article 26/02/2017

https://learn.microsoft.com/en-us/previous-versions/windows/hardware/hck/jj124227(v=vs.85)

Bear in mind, it's not that simple as it may seem. Probably, the easier solution would be to use a third party cert tool, such as guys who made a signed driver for their old VM ware XP driver using some Chinese certification system.

Sorry, can't find the link, it was a long time ago.

That said, I used to sigh my modded nVidia drivers with other methods, unfortunately XP wouldn't accept them.

[Dixel]

On 6/25/2024 at 12:25 AM, D.Draker said:

That said, I used to sign my modded nVidia drivers with other methods, unfortunately XP wouldn't accept them.

Yep, but Vista does. NT6.0 is more tolerant to non-MS certs. With XP one's gotta pay.

[LoneCrusader]

Hmm.. looks like our Russian friends have already solved this issue long ago. Digging through an old RyanVM thread for information on Signing/Certificates inadvertently led me back around to here, and then to a thread on the OSZone Russian forum. Unfortunately I can't speak or read Russian, but a Google translate of paragraph #3 of post #10 refers to "Patch in Setupapi.dll, turning off the lowering of the rank of unsigned drivers when choosing the most suitable driver for the device."

Now the problem is sorting out what patch does what exactly, and if there are any differences in different versions of the DLLs involved, and how to port it all to XP x64. All things I know nothing about. Fun!