Just got a cat file off them and although signtool /verify says its OK, and the driver update UI initially says its signed, it later says there is a problem with the signature and 'error code 52’s it.
I noticed to a new tab on the sys file properties that the o9ld signed drivers don’t have.
Clearly MSFT changed something recently, and broke it. Anyone else seeing problems?
(I noticed some changes on the dashboard too when uploading, you no longer need to select the package file twice. Another indication they made changes recently)
Apparently they updated win7 to accept SHA2, https://technet.microsoft.com/en-us/library/security/3033929 recently. Looks like it, and the new signing process aren’t compatible (did you notice you now download all the files, cat, and inf+sys, and that the sys file has a new tab on Properties).
Anyway, I just tested in win7 32, XP, and win 7 64. 32 and XP are OK, win 7 64 is broken. The drivers uninstalled OK at first, asked for a reboot, and on reboot got an error 52 ‘cannot verify digital signature’.
So anyway its currently broken, just to let you all know.
The problem is that the 3033929 didn’t download, despite updates being set to automatic.
Anyway, with the patch installed its OK now.
Yet another head shakingly stupid screw up by Microsoft, who not only failed to advertise the fact that the signing had changed on the dashboard, but that this patch is needed. And not only that, to have had two days of useless emails with them, mostly (all bit one) unanswered, with the entirely useless and semi comprehensible suggestion that “On Windows 7, the Security Catalog is the signature for your binaries. You?ll need to include it with your old driver as old process”
Another classic example of MSFT documentation, and support!
So, first, the heads-up is appreciated. But that’s a whole lot of whining and blaming Microsoft for what amounts to a lack of notice by them (I agree, annoying) and then you not noticing that the file is signed with SHA256. That “digest algorithm” field is displayed for a reason, you know.
I’m pleased to hear that the signatures from MSFT are now SHA2. That the signatures have changed over should be no surprise. Microsoft announced, what… at least two years ago… that SHA1 would be discontinued and as of Jan 2016 SHA256 would be required. For Win10 signatures, *companies* need to sign their drivers with SHA2 to upload them to sysdev (where they will be signed by Microsoft).
We’ve discussed the move to SHA256 here for, oh, at least a year… maybe 2.
We discussed the newly released update to Win7 as late as last month. I know, because I’m the one who made the post.
So, while (a) I appreciate your post letting us all know that sysdev is now signing with SHA256, and (b) I agree that some notice on the sysdev dashboard would be helpful like “NOTICE! Starting 1 May 2015 (or whatever it is) drivers will be signed by SYSDEV using SHA2 instead of the previous SHA1” … I feel like your level of bile is more than a little bit mismatched to the problem.
The problem is that the 3033929 didn’t download, despite updates being set to automatic.
From the KB3033929:
[quote] We have been able to verify that systems that have the Windows
boot loader enabled as the primary loader are successfully able to
install this update and that systems that have a non-Windows boot loader
specified as the primary boot loader cannot install the update, even if
the user uses that loader to select Windows.
To work around that issue, you can either use Windows as the default
boot loader or you can change your BIOS settings to enable the Windows
boot loader directly when you install this update. [/quote]
Can it be the case for your hardships with installing this update?
I had noticed quite recently that HCK submissions seem to be coming back
with an embedded signature on the driver as well as the normal .cat
signatures. I knew this was happeninig for the Windows 10+ HLK
submissions, but it wasn’t clear that the HCK signing process was going to
change to match as well. Anyways, the plan I think would be to apply your SHA1 cert as an embedded signature prior to HCK submission, then
when the package comes back the driver will have both a SHA1 embedded
(yours) and a SHA256 (Microsoft) embedded signature and all OSes should be
able to load the driver.
There *may* or may not have been a policy shift regarding code signing
certs past 2016 - you might inquire with your cert vendor again.
t.
On Wed, May 13, 2015 at 7:28 AM, Pavel A. wrote:
> On 13-May-2015 15:59, zzebowa@ wrote: > >> The problem is that the 3033929 didn’t download, despite updates being >> set to automatic. >> > > From the KB3033929: > >
Win10 doesn’t care if you sign your binaries at all. It just cares that
you have a HLK signature from Microsoft (a SHA256 with per-page hashes).
So the only reason at this point forward to sign driver binaries yourself
is for back-OS support, and the only cert that will work there is a SHA1.
I’ve got questions about these Win10 signing requirements. Do these apply to the Tech Preview too? I’ve recently loaded previously released drivers on Win10 without any problems. Some were never sent through the old sysdev system. They are simply signed with our Class3 code signing cert and cross-signed with the old MSCV-VSClass3.cer
There will be some as yet unannounced cut off date is my understanding.
T.
Sent from my Windows PhoneFrom: xxxxx@hotmail.com
Sent: 5/13/2015 4:48 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Microsft signign broken?
I’ve got questions about these Win10 signing requirements. Do these
apply to the Tech Preview too? I’ve recently loaded previously
released drivers on Win10 without any problems. Some were never sent
through the old sysdev system. They are simply signed with our Class3
code signing cert and cross-signed with the old MSCV-VSClass3.cer
@Peter “I feel like your level of bile is more than a little bit mismatched”
There is almost no level of bile mismatched to any kind of relationship with Microsoft. I have been writing drivers for Windows for 18 years Peter, since NT4, you cant tell me of the frustrations I have had over that time. They are so bad at documentation and support, and it is getting worse and worse as its offshored. We all know that, its as clear as day in the kind of support you get of sysdev and logo these days, its appalling. You are lucky if your emails even get answered.
“We discussed the newly released update to Win7 as late as last month” So I have to come here for Microsoft documentation?
@Pavel: Re boot loader. Hmmm, don’t know, its a laptop that’s only had Windows on it, ever, so AFAIK its using a Windows boot loader. The patch installed by the way OK when I did it manually, on both test machines.
@anyoneelse: What’s all this about embedding my SHA1 certificate? What are the hoops to jump through to achieve that? Is there any kind of reliable documentation on it?
(And oh, just for the fun of it, I now have an inf file signed for 5.1.2600 (according to signtool) that gives an error on install on POS Ready 2009. Once more unto the breach that is logo/sysdev support…)
I would not call MY overall experience writing Windows drivers any more “frustrating” than any other software development effort. And I’ve certainly written/designed/reviewed my share. For the most part, I find the documentation to be decent and largely valuable.
I wonder what accounts for our very different perceptions and experiences during that time? For the record, I started writing drivers for Windows NT in 1993.
Well that IS interesting. And to think I just recently wrote in an answer to somebody here on NTDEV that we (OSR) have always found sending email to sysdev “responsive and typically helpful” or something similar. Now, admittedly, we haven’t needed anything from sysdev for about a year… but up to that time, we’ve always gotten a semi-intelligent answer to our semi-intelligent questions.
Again, I wonder what accounts for our differing experience in this regard?
HAVE to, no. But there are many sources of “Microsoft documentation” including conference presentations, whitepapers, and the like. You could personally wade through them all or you could come here (NTDEV) or our Developer’s Blog: https:</https:> … where we try to wade through them all FOR you so that you get a “heads up” on things that are important.
HAVE to, no. But there are many sources of “Microsoft documentation” including conference presentations, whitepapers, and the
like. You could personally wade through them all or you could come here (NTDEV) or our Developer’s Blog: https:</https:> … where we try to wade through them all FOR you so that you get a “heads up” on things
that are important.
Is this a way of “good documenting” ? I personally spent too much of time on gathrering information from Microsoft - now and in
the past. Something is described in "paper 1 " , something about the same is explained in "paper 2 " , but cannot be understand
before reading “paper 1” ,. There are changes about this described in “paper 3” , and corrections described in “paper 4”.
Once upon a time in the far Europe , everything about one particular “something” was described in one single paper , one single
chapter , and that chapter was alive since it got updated every time a change about that “something” happened.
Also ( , with the introduction of EV certificates as per example ) , I get the impression that Microsoft is slowly closing the
doors to low profile developers and companies. Things get more complex , become more expensive and take more time to figure out
how to adapt. This is probably no problem for big companies who can spend a lot of money ( and a lot of time ) but for a single
developer in a ( very ) small company , it may become a nightmare. The best times when XP was alive and kicking seem to be history
, at least , that is my impression.
Christiaan
----- Original Message -----
From: To: “Windows System Software Devs Interest List” Sent: Friday, May 15, 2015 3:05 PM Subject: RE:[ntdev] Microsft signign broken?
>
> > Wow. Venomous. > > I would not call MY overall experience writing Windows drivers any more “frustrating” than any other software development effort. > And I’ve certainly written/designed/reviewed my share. For the most part, I find the documentation to be decent and largely > valuable. > > I wonder what accounts for our very different perceptions and experiences during that time? For the record, I started writing > drivers for Windows NT in 1993. > >
> > Well that IS interesting. And to think I just recently wrote in an answer to somebody here on NTDEV that we (OSR) have always > found sending email to sysdev “responsive and typically helpful” or something similar. Now, admittedly, we haven’t needed > anything from sysdev for about a year… but up to that time, we’ve always gotten a semi-intelligent answer to our > semi-intelligent questions. > > Again, I wonder what accounts for our differing experience in this regard? > >
> > HAVE to, no. But there are many sources of “Microsoft documentation” including conference presentations, whitepapers, and the > like. You could personally wade through them all or you could come here (NTDEV) or our Developer’s Blog: > https:</https:> … where we try to wade through them all FOR you so that you get a “heads up” on things > that are important. > > Peter > OSR > @OSRDrivers > > > — > NTDEV is sponsored by OSR > > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev > > OSR is HIRING!! See http://www.osr.com/careers > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
@Peter
I just don’t see why they cant put a big banner on their upload page saying ‘win7 64 bit now uses SHA2 signing, you need this hotfix for it to work’
They couldn’t even give me a straight answer, sysdev, when I asked. And logo just ignored my emails. I had to rummage around the net and come up with it myself.
Just last week sysdev suggested I contacted the developer of an errata filter to get information on it, without providing the devs name.
If you want a truly pleasurable experience writing complex code, then try Linux. It really is a breeze. Everything works as you expect it to, and while there isn’t centralised documentation, the sheer quantity of on line data more than makes up, plus the fact you can step through the entire kernel, at source level.
But its not so much the development process persee on windows that’s so painful, its the stuff round the edge. Like trying to get a MSDN account activated, that was a disaster, until, being a French speaker, I was able to go through French support and not India to get it done.
And the HCK is a joke. 14 hours to test a driver per OS? And if CHAOS test fails, because of a bug in the usbsubsys/hardware (power state failure, I am sure you have seen it) just unplug the device and it will pass. I mean, what IS the point?
@anyoneelse: What’s all this about embedding my SHA1 certificate? What are the hoops to jump through to achieve that? Is there any kind of reliable documentation on it?
You’re making a mountain out of a molehill. You embed a certificate
with “signtool sign”. You only get one chain, but you can sign your SYS
file with an SHA1 certificate and your package (that is, CAT file) with
an SHA2 certificate. That would allow the driver to run on the older
systems.
(And oh, just for the fun of it, I now have an inf file signed for 5.1.2600 (according to signtool) that gives an error on install on POS Ready 2009. Once more unto the breach that is logo/sysdev support…)
INF files do not get signed. Only executables (SYS files) and CAT files
get signed.
5.1.2600 is Windows XP, and POS Ready 2009 is based on XP SP3. What
error do you see?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
@Tim, interesting. So which certificate do I embed? I have the Symantec one I bought that’s tied to the company and is used for signing the hckx package for upload. I also have the test signing one I created to get test drivers installed, but I am sure its not that one to be used.
And I guess its the sys file I embed my SHA1 cert in?
“You’re making a mountain out of a molehill” No, that is Microsofts job.
“INF files do not get signed” This is an rndis wrapper inf. It has our hardware ID, and calls into the system rndis inf file, and is signed with a cat file. So, does this cat file also reference, oe, include, the sys files for rndis on XP and win7? When I ran the signtool /verify it was on a Win7 machine, so the XP sys files wouldn’t be present and it said it was XP signed OK, so it seems to me like this rndis inf is signed without the sys file information being present. (Its like a null device signing according to logobf)
@Tim, interesting. So which certificate do I embed? I have the Symantec one I bought that’s tied to the company and is used for signing the hckx package for upload. I also have the test signing one I created to get test drivers installed, but I am sure its not that one to be used.
And I guess its the sys file I embed my SHA1 cert in?
Well, I wasn’t the one that made the original claim that we could sign a
single package with both SHA1 and SHA2 certificates. I’m not convinced
that’s possible.
You COULD sign the SYS file with an SHA1 (with appropriate
cross-certificate) and the CAT file with an SHA2. That would let you
install and operate everywhere, although you would get the dreaded
“unsigned driver” warning on XP and Vista.
“INF files do not get signed” This is an rndis wrapper inf. It has our hardware ID, and calls into the system rndis inf file, and is signed with a cat file. So, does this cat file also reference, oe, include, the sys files for rndis on XP and win7?
No. The CAT file checksums the INF and whatever files are mentioned
directly in that INF. It doesn’t include binaries dragged in by
Needs/Includes.
My point was that the signature goes in the CAT.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>Well, I wasn’t the one that made the original claim that we could sign a single package with both SHA1 and SHA2 certificates. I’m not convinced that’s possible
