67 replies to this topic

[pscEx]

* If you want to do a preliminary test, see if you can suppress the driver signing prompt when using my TrueImage91 Lite script, the ti drivers are doing something and in VMWare, the networking driver is flagged.

With the new version 005 of driverSigning.Script, option 'at build time by program'

there are in VMWare no network driver waqrnings, and TrueImage comes up.


Peter

[Nuno Brito]

Excellent!

[thunn]

Could one of you explain to me why we need a exe which fixes this at boot time?
Can't we create the registry settings at build time?

It was not possible to come up with a configuration in the registry that prevented the functionality, it's by design, MS even had to post that.

Believe me, I tried, for sometime to produce a solution. I scrubbed the net and thought on it again and again, but alas, I too came to the conclusion that if this was to work for everyone, all the time, we needed some help to suppress the check on driversigning policy or rather the correction of it.

This is not controlled by rrsaenh.dll but by setup APIs early on in the startup.
In case it helps anyone though, here the main entry for rsaenh.dll:

RegWrite,HKLM,0x1,"wb-default\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\

{75048700-EF1F-11D0-9888-006097DEACF9}","Version","hex(4):03,00,00,00"

Anyway,
I found no exe or prog to do the job, I tried all the ones you're thinking of. I was at my wits end so I posted here and didn't have to wait long.. Peter found a slick proof of concept program that was never compiled but looked very promising. First Peter took the entries the program suggested modifying and added the local values from his system to a script for testing, but of course that won't work for many people. Then some more attempts and failures at pre build configurations.. finally we both decided to compile the code. Myself in C, and Peter converted the data to Delphi with a few small changes. Early tests of the Exe did not seem to work because we didn't launch it early enough in the startup sequence. Above you'll see I finally, and this I think is no stroke of genius, decided to push it up in the startup order. On the test following that change, the new exe worked! I waited about five minutes because I thought I was dreaming, then did a little dance. And that's the story.

[pscEx]

I did some mod work:

Edited (made line breaks) some 'Code' to make the topic readable again.
I hope, nobody worries.

In addition to Thunn's last post:

Thun, did you already test the version 5 with the 'build time tweak'?

Peter

[thunn]

Nope, and I have to run out for a few hours,
Bottom line as I see it..
Reg entries don't even really matter, just launch your new exe at RonOnceEx entry 000. Please use: "DriverSigning" value: "hiderun /w driversigning.exe"

I'll be back here in a few hours, I still want to do a few more tests before releasing new script sets on my servers.

For now, here's an informative screen shot (not a problem, just a test):

Attached Thumbnails

• 

[pscEx]

Reg entries don't even really matter, just launch your new exe at RonOnceEx entry 000. Please use: "DriverSigning" value: "hiderun /w driversigning.exe"

This will be history, if the 'build time' option works for you, too.

Peter

[MedEvil]

Now i'm confused.
First i did understand that it all boils down to calculating and setting 2 settings, that if not check out are overwritten with a default. (do popup)

Then thunn makes it sound like one would need a program running to prevent the popup.

An now it seems we're full circle, with Peters post.

Could someone please show me the light. I'm lost.

[pscEx]

Could someone please show me the light. I'm lost.

That happens if in the middle of some develop and researching work you ask the developers for information.
In spite that disturbes the developing process, they usually give you the the current knowledge and status.

But if the knowledge changes, the developers do not have an 'automatic update' directed to you.

As a result:

I think, that I brought it to a state where by build time changes, the 'Unsigned Driver' warning is switched off in all cases.

Peter

[MedEvil]

In that case i request an automatic update when the development is finished.
btw. Do we have any scripts at all which development phase is over?

Boy do i hate this, at the moment i have at least a dozend ideas for scripts i would like to work on and here i am, fiddeling since a week with the stupid hardware detection.

[pscEx]

Boy do i hate this, at the moment i have at least a dozend ideas for scripts i would like to work on and here i am, fiddeling since a week with the stupid hardware detection.

In such a case, for me, I mostly decide 'Do It Yourself', sometimes 'Be Patient And Wait For Result'

Peter

[Nuno Brito]

The latest nativeEx files work very well, my best regards to the author..

MedEvil, download updated files from Peter's server and you should have this issue solved.

Good luck!

[MedEvil]

The latest nativeEx files work very well, my best regards to the author..

MedEvil, download updated files from Peter's server and you should have this issue solved.

Good luck!

Little misunderstanding, the point im fiddeling with is several levels below diriver signing problems.
It's just frustrating. Sometimes one has enough time on his hands, but no ideas and then it's like now. Tons of ideas and all the time is eaten up by a single project.

[pscEx]

Sometimes one has enough time on his hands, but no ideas and then it's like now. Tons of ideas and all the time is eaten up by a single project.

Please edit your post and add a [German] section.
Neither I understand the current status nor I have any idea how to proceed.

Peter

[MedEvil]

Please edit your post and add a [German] section.
Neither I understand the current status nor I have any idea how to proceed.

Peter

What are you talking about?

[pscEx]

What are you talking about?

I do not have any idea about the meaning of your sentence:

Sometimes one has enough time on his hands, but no ideas and then it's like now. Tons of ideas and all the time is eaten up by a single project.

Peter

[thunn]

hey MedEvil, how about RUNNING a TEST with the new script and I'll do the same! Later today we'll have your 'answer' and by this evening, I assure you, many worthwhile updates are coming ..
here's a preview of my new networking script- link which is almost finalized.

With this driver signing issue tamed, My new TrueImage Lite will be free of issues.
Perhaps see the post a few pages back ( for links ) and test trueimage too, it seems to be a good test as currently configured to let us know if the policy has really been updated correctly.

A file(s) hash must be calculated and then added to the registry. It would sure be great if pre-installing the value worked. If that method fails we have to let the driversigning.exe tool do the correction on startup. It's very small and does not stay in memory. It can be deleted to get the 20 KB. back.

[MedEvil]

Thanks for you explaination thunn.
But i'm not concerned about memory usage, more about boot up times.
There are still a lot of things done, that should not happen at boot up.
Like installing of components or even just running aps to create all the registry entries that are missing.
I already did prove with my explorer sppedup script that boot times can be cut down considerably, if more entries are incuded at buildtime.

[thunn]

I'm not talking about memory usage, just deleting the file after it runs once, it doesn't matter, it's only 22 KB.. Will you help us run some tests??

Peter has designed his new script so that the exe runs at build time to get needed values and calculate a required hash which is added to the pe registry. It should work like that!

--edit--

nope! calculating the hash at buildtime failed.

It looks like it must gather the needed values for the seed's hash at runtime to always work.

Thank's for recoding the little program though, Peter. It was sure worth a shot.

[MedEvil]

I'm not talking about memory usage, just deleting the file after it runs once, it doesn't matter, it's only 22 KB.. Will you help us run some tests??

Sorry i'm pretty much booked out at the moment. Let's talk again after the release of my project.

[thunn]

I have some excellent news, after checking on some details in Peters new script, I was able to make some corrections to the scripting portion that should allow this driver signing problem to be a thing of the past for us all.
As I mentioned earlier on in the thread, I don't use the api.script, perhaps Peter missed that or wasn't concerned with the 'smaller' details' that may be easily adjusted per user.

Running the Delphi driversigning program that Peter rewrote, a " -W" switch correctly updates a build's registry to eliminate driver signing prompt(s).
In short, once again, the 'driversigning' program gets needed values from the loaded PE system hives to calculate a hash. It may be done during the build, as I just mentioned ..or at startup. I must say, Peter has done us all a huge favor to produce this information and program!

Ive updated the script so thats it's totally portable and may be used on any wb project. I think this script is a good one to have in such form. A few minor registry changes were made, and I removed localized 'seed' hashes for testing. It will now also support a %basedir% with spaces in the path.

In the revised script is a new 'certificate' logo for Psc to hang on his lab wall. Perhaps a new rank of Guru Finder is in order.
Thanks once again, Peter.
Regards, -thuun

Attached Files

•  driverSigning.Script   36.29K   721 downloads

[Nuno Brito]

Very good news indeed!

[Yennix]

I think, this is the way to solve it.

Peter

Hi guys,

Sorry to butt in. I've loved this thread, it's helped me with a real sticky problem in some of my Desktop imaging processes. Specifically, how to turn off this nagging feature.

But, I found something that figured I'd share. I'm building an automated process to generate a Hardware Independent Image for my office's computer fleet. On a T61 laptop that I'm using for a source machine I get an error message when I run the code compiled from Peter's link below:

"Error: Acquisition of context failed., number 80090016"

Picking apart the c code, that number turns out to be the last error code tossed back by the API before the program halted. The error occurs in the CryptAquireContext function and a little researching for "Error 80090016" shows that the error (which MS documentation translates to NTE_BAD_KEYSET) means that the computer ...well I'll just link to the forum post that fixed it for me. It fit my circumstance and is a much more exhaustive discussion of the problem than I want to get into with this simple little shout.

Long story short, I had to change up one of the switches inside the C program and recompile. The last "0" in the call to CryptAcquireContext needed to be removed and replaced with "CRYPT_VERIFYCONTEXT" instead. MS's documentation of this function substantiates that as the verifycontext flag is meant specifically for "ephemeral keys" or just simple hash verification. That's all this program really does, just creates some simple hashes and injects them into the registry.

Here is the hunk of code I modified. Hopefully, if someone has this error message down the line it'll help them out too:

if(CryptAcquireContext(

				&hCryptProv, 

				NULL, 

				NULL, 

				PROV_RSA_FULL, 

				CRYPT_VERIFYCONTEXT)) 

	{

		printf("CryptAcquireContext complete. \n");

	} else {

		MyHandleError("Acquisition of context failed.");

	}

[pscEx]

Hi guys,

Sorry to butt in. I've loved this thread, it's helped me with a real sticky problem in some of my Desktop imaging processes. Specifically, how to turn off this nagging feature.

But, I found something that figured I'd share. I'm building an automated process to generate a Hardware Independent Image for my office's computer fleet. On a T61 laptop that I'm using for a source machine I get an error message when I run the code compiled from Peter's link below:

"Error: Acquisition of context failed., number 80090016"

Picking apart the c code, that number turns out to be the last error code tossed back by the API before the program halted. The error occurs in the CryptAquireContext function and a little researching for "Error 80090016" shows that the error (which MS documentation translates to NTE_BAD_KEYSET) means that the computer ...well I'll just link to the forum post that fixed it for me. It fit my circumstance and is a much more exhaustive discussion of the problem than I want to get into with this simple little shout.

Long story short, I had to change up one of the switches inside the C program and recompile. The last "0" in the call to CryptAcquireContext needed to be removed and replaced with "CRYPT_VERIFYCONTEXT" instead. MS's documentation of this function substantiates that as the verifycontext flag is meant specifically for "ephemeral keys" or just simple hash verification. That's all this program really does, just creates some simple hashes and injects them into the registry.

Here is the hunk of code I modified. Hopefully, if someone has this error message down the line it'll help them out too:

if(CryptAcquireContext(

				 &hCryptProv, 

				 NULL, 

				 NULL, 

				 PROV_RSA_FULL, 

				 CRYPT_VERIFYCONTEXT)) 

	 {

		 printf("CryptAcquireContext complete. \n");

	 } else {

		 MyHandleError("Acquisition of context failed.");

	 }

Hi Yennix!

First: Welcome in our forum!
Second: Thanks four research which may be helpful for several users using this code, too.

But allow me a third statement:
Users using my driverSigning.Script should not worry thay they may get similar issues like you explained.

To write the script (and the underlying program) I only used the text

Liberal usage of regmon revealed that the value is indeed stored in the Policy key of HKLM\Software\Microsoft\Driver Signing, but there was also a write to the PrivateHash key of HKLM\Software\Microsoft\Windows\CurrentVersion\Setup.

With the help of apispy it was easily found out that the PrivateHash is an MD5 hash of the 4-byte-extended value of the Policy Key and some seed. The Seed is the 4-byte value of the seed key from HKLM\System\WPA\PnP).

and developed with this knowledge my own program.

I did not use the linked program, nor I ported that prog into a different language.

Therefore troubles occuring with recompiling of the mentioned prog, are not relevant for my script.

Peter

[bilou_gateux]

Long story short, I had to change up one of the switches inside the C program and recompile.

Please can you share your recompiled code. i would like to try it for the same usage as you (create a master image to deploy on different hardware)

[thunn]

lcc is free and should work to compile the code.. give it a try.