Jump to content

WinNTSetup v5.3.4


JFX

Recommended Posts

Testing now on my own computer ASUS-Z170

In case of wimgapi for Apply in WimBoot mode then some drivers seem to be unsigned and seem to have missing certificate.
Updating the driver using the already present driver files resolves the problem. The Certificate is now visible.

Where are the Certificates located and are they may be wof compressed for the drivers having problem ?

btfilter_Unsigned2019-09-27_102539.thumb.png.81165b46ace37d0c803972869d83b4ea.png ==  btfilter_Signed_2019-09-27_102730.thumb.png.7d099ad8e429ffae39341c92fdb5a04d.png

Edited by wimb
Link to comment
Share on other sites


34 minutes ago, JFX said:

What happens if you delete Tools\WimBootCompress.ini and try than with wimgapi + wimboot?

Removed WimBootCompress.ini and did Apply wimgapi + WimBoot Mode.

Result is that system boots ok, but as before there are 3 drivers with exclamation mark due to apparently missing certificate.
Do you know where the driver certificates are located ?

Edited by wimb
Link to comment
Share on other sites

3 party drivers are usually directly signed (having the a signature inside the *.sys file).
But also could be signed inside a *.cat files like it is with build in drivers.

Use sysinternals: sigcheck.exe -i "file"
to find the respected cat file.

 

Link to comment
Share on other sites

2 hours ago, JFX said:

3 party drivers are usually directly signed (having the a signature inside the *.sys file).
But also could be signed inside a *.cat files like it is with build in drivers.

Use sysinternals: sigcheck.exe -i "file"
to find the respected cat file.

 

Thanks for giving info about where and how to find driver certificate info.
The three drivers giving problem have their signature inside the sys file.
The drivers appear as Unsigned, but after Update driver then the same driver file appears as Signed.

So it seems to me that the only problem is that the Certificate is not recognised ....

Edited by wimb
Link to comment
Share on other sites

1 hour ago, wimb said:

So it seems to me that the only problem is that the Certificate is not recognised ....

Or maybe, since certificates are "secure" (please take notice of the double quotes) the compression algorithm/procedure (or the way they are stored inside the .wim) *somehow* makes some internal hash/check/whatever invalid, so - for your own good - the MS tool prevents them from properly installing. :dubbio:

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

After Apply wimgapi + WimBoot Mode I tried to replace the complete registry with a backup (12 files) where drivers were working OK.

It turns out that this replacement of the registry did not solve the problem.

The three drivers as before were having exclamation mark due to seemingly Unsigned drivers, but as we know now it is only the Certificate that is not taken properly into account.

Anyway I thought it is interesting to mention that a replacement of the registry cannot solve the issue.

Where is the problem located ? Somewhere in ProgramData ? Some WOF Compressed files ?

I checked in the VHD by using 7-zip that the drivers\*.sys files and Catroot folder are not WOF Compressed.
Could it be that some other essential files need to be Uncompressed ?

Anyway when WimBoot mode is not used in wimgapi Or when wimlib + WimBoot is used then all drivers are working OK.

Edited by wimb
Link to comment
Share on other sites

@wimb

I assume you are running WinNTSetup_x64.exe, it uses WinNTSetup\Tools\x64\wimgapi.dll version 10.018362.1. And WinNTSetup_x86.exe still uses WinNTSetup\Tools\x86\wimgapi.dll version 10.015063.0

You may try using WinNTSetup_x64.exe with wimgapi.dll x64 v10.015063.0, version used on older WinNTSetup (x64 & x86), since other versions were buggy, use GetWaikTools to download it.

EDIT: Also we need to remember there has been a change in certificate driver enforcement requiring only SHA2 (since Windows 10, version 1803) and the wimgapi version in use may or may not be able to support SHA1, SHA2 or both. wimgapi.dll version 10.015063.0 (15063= v1703) from the table on previous link 10 v1703 supports SHA1 and also SHA2.

alacran

Edited by alacran
Link to comment
Share on other sites

Thanks for your help :) and suggestion to use x64 wimgapi.dll version 10.0.15063.0 (from Windows 10 version 1703) supporting SHA1 and SHA2

GetWaikTools old Versions has GetWaikTools_v17.04 is giving x64 wimgapi.dll version 10.0.15063.0

I tried that wimgapi version in WimBoot mode, but the three drivers still have exclamation mark due to seemingly Unsigned driver.

@jaclaz
Indeed the wimgapi tool might be too "secure" or it might be in the code that JFX is using.
In any case there must be somewhere a difference in the installation as compared to using wimlib.
Until now the installation for Apply in WimBoot mode looks quite the same for wimgapi and wimlib and I haven't found the location giving the driver trouble .....

 

Link to comment
Share on other sites

After Apply with wimgapi + WimBoot mode then the three problem drivers have in Properties missing Digital Signature tab

After wimgapi Replacing simply the three drivers btfilter.sys and nvhda64v.sys and TeeDriverW8x64.sys by the drivers found in the wimlib installation solves the problem.

That means the problem is entirely located in the three drivers having missing Digital Signature tab after Apply wimgapi + WimBoot mode

Then I  investigated the drivers in TinyHexer.

To my surprise the driver file after Apply of wimgapi + WimBoot mode is completely filled with byte 00 :ph34r::w00t:

[PrepopulateList] files WOF Uncompression Failure resulting in zeroed driver file ?

After Apply wimgapi + WimBoot Mode                            After Apply wimlib + WimBoot Mode

wimgapi_wimlib-2019-09-28_133428.png.8aafedb7b4881e5bd2626d4c85155d34.png

TinyHexer-2019-09-28_135937.thumb.png.e2189b78088db1ec2f50a1bf5a54c177.png

Edited by wimb
Link to comment
Share on other sites

On 9/28/2019 at 1:47 PM, wimb said:

[PrepopulateList] files WOF Uncompression Failure resulting in zeroed driver file ?

You mentioned that the problem only also occurred with deleted "Tools\WimBootCompress.ini".
So it this earlier test it should have been (still) a pointer file. :ph34r:

 

Edited by JFX
Link to comment
Share on other sites

44 minutes ago, JFX said:

You mentioned that the problem only also occurred with deleted "Tools\WimBootCompress.ini".
So it this earlier test it should have been a pointer file. :ph34r:

Inside the Captured WIM file there is another Windows\System32\WimBootCompress.ini that is probably used when Tools\WimBootCompress.ini is removed.

What is WofTab doing ?

Edited by wimb
Link to comment
Share on other sites

Both are used the WIM internal by wimgapi and the Tools one later by winntsetup.
First one does not decompress any driver file other than wof.sys.

WofTab extend your file property dialog with WOF related infos.

Link to comment
Share on other sites

18 minutes ago, JFX said:

Both are used the WIM internal by wimgapi and the Tools one later by winntsetup.
First one does not decompress any driver file other than wof.sys.

WofTab extend your file property dialog with WOF related infos.

When Tools\WimBootCompress.ini was removed then the After Apply wimgapi + WimBoot mode the driver files are present as file and not as pointer.
So I thought that may be the {PrePopulateList] of the internal WimBootCompress.ini was used.

Install of WofTab does not make any change on Properties of driver files.
The drivers in the VHD are not compressed and I copied also these drivers to internal SSD for investigation of Properties.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...