Signing drivers, visual studio 2013

[TNOMCat]

When I'm installing my driver theres a warning under it saying "this driver is not digitally signed".
A few seconds after installing I get a pop up saying this version of windows requires a digitally signed driver.
If I try to start the driver (net start mydriver) I get system error 577 (ERROR_INVALID_IMAGE_HASH, Windows cannot verify the digital signature for this file. )

It's a kernel driver, and not boot-start.
I configured the driver's Package project to Test Sign the driver. The catalog file is generated successfully while building the driver, and I get "Successfully signed: C:\Users\Flcat\Documents\Visual Studio 2013\Projects\mydriver\x64\Win7Release\Package\mydriver.cat"

So why am I getting spammed with not signed errors when I try to install it?

[Darwin226]

Maybe this will help [url]http://msdn.microsoft.com/en-us/library/windows/hardware/ff547621(v=vs.85).aspx[/url]

[TNOMCat]

[QUOTE=Darwin226;45103676]Maybe this will help [url]http://msdn.microsoft.com/en-us/library/windows/hardware/ff547621(v=vs.85).aspx[/url][/QUOTE]

So is there no way of running custom drivers without using a testsigning boot config that watermarks my desktop and everything?

[Darwin226]

I'm pretty sure you can remove the watermark. I know of a program that boosts your mouses refresh rate that needed this configuration and it also had a "remove watermark" button. So it can be done.

[ThePuska]

You gotta pay Microsoft if you want to run your drivers without test-mode.

[ben1066]

[QUOTE=ThePuska;45104427]You gotta pay Microsoft if you want to run your drivers without test-mode.[/QUOTE]

This is the reason that actually made me try linux, I got far too annoyed with some development tools from TI having unsigned drivers.

[Cold]

They pretty much got forced into changing it to this, to deal with the whole kernel level rootkits/viruses bullshit that was popular during the Windows XP era.

[TNOMCat]

Why am I getting a file not signed error from windows for the .sys file that is signed and timestamped, with a certificate that I added to my trusted root certification authorities store? (the driver binary has an embedded signature, and a valid signed cat file) Is this because its a test signature? Whats the actual difference between a test signature and a legit one when I have both in my trusted authorities store?

Also, I took a look at verisign's code signing certs

$500 PER YEAR FOR INDIVIDUALS HOLY FUCK

[Tamschi]

[QUOTE=TNOMCat;45109891]Why am I getting a file not signed error from windows for the .dll file that is signed and timestamped, with a certificate that I added to my trusted root certification authorities store? (the driver binary has an embedded signature, and a valid signed cat file) Is this because its a test signature? Whats the actual difference between a test signature and a legit one when I have both in my trusted authorities store?

Also, I took a look at verisign's code signing certs

$500 PER YEAR FOR INDIVIDUALS HOLY FUCK[/QUOTE]

I think the local root certs are only for websites, for Windows drivers you really need one by the right authority.

Allowing you to add a root cert would defeat the whole purpose of not allowing unsigned drivers in the first place.

[Fuxed]

If I remember rightly, getting a driver signed is about 230 USD. If it's a USB device, you're probably going to need a vendor-ID from the Implementers Forum though, which is hugely expensive.

[TNOMCat]

[QUOTE=Cold;45105414]They pretty much got forced into changing it to this, to deal with the whole kernel level rootkits/viruses bullshit that was popular during the Windows XP era.[/QUOTE]

If thats the case then why, according to microsoft's driver signing policy, does 32bit windows allow non-boot drivers without a signature?

[Tamschi]

[QUOTE=TNOMCat;45112972]If thats the case then why, according to microsoft's driver signing policy, does 32bit windows allow non-boot drivers without a signature?[/QUOTE]

Company clients, all the private users switch to x64 (by default at least) while companies with legacy hardware can stay on the old system.

[TNOMCat]

[QUOTE=Tamschi;45113215]Company clients, all the private users switch to x64 (by default at least) while companies with legacy hardware can stay on the old system.[/QUOTE]

might be a dumb question, but how is it old if the 32 and 64 bit versions of windows 7 were released at the same time? I doubt microsoft was like "hey 64bit is the way forward and everyone will use it in the future, so lets enforce signatures only on the 64 version, and only check for sig but not make it mandatory on 32"

edit: nvm this was about hardware, you mean all computers that ship with win7 have 64bit, and 32 is only for those who update the os but dont have the ram for 64?

[Cold]

[QUOTE=TNOMCat;45112972]If thats the case then why, according to microsoft's driver signing policy, does 32bit windows allow non-boot drivers without a signature?[/QUOTE]

Reverse Compatibility reasons.

[Tamschi]

[QUOTE=TNOMCat;45113604]might be a dumb question, but how is it old if the 32 and 64 bit versions of windows 7 were released at the same time? I doubt microsoft was like "hey 64bit is the way forward and everyone will use it in the future, so lets enforce signatures only on the 64 version, and only check for sig but not make it mandatory on 32"

edit: nvm this was about hardware, you mean all computers that ship with win7 have 64bit, and 32 is only for those who update the os but dont have the ram for 64?[/QUOTE]

That and companies that only upgrade for security patches (so they don't have to pay millions to Microsoft for extended support) but still need their legacy software that uses system drivers but hasn't been updated for half a decade or so.

Almost all users will use the secure version because they don't need the insecure one and/or are too lazy/not competent enough/gamers and/or others who need a lot of RAM. With the other version's setting Microsoft appeases company clients who'd otherwise have to invest huge sums of money to get their software moved to the different system (but [I]maybe[/I] should think about using Linux anyway to get rid of the license costs for good. The problem is that corporate systems are [I]incredibly[/I] slow to change and continuously deadlocked on legacy componets, as much in hardware as in software).