Vista LOSES Yet Another Feature

Associate
Joined
27 Jan 2005
Posts
830
Vista is apparantly losing yet another feature in the 32 bit version of its OS.

Full article here: http://www.apcstart.com/site/dwarne...other-feature-full-hd-playback-in-32bit-vista

Microsoft revealed today that no 32-bit versions of Windows Vista will be able to play back “next generation high definition protected content” (translation – studio-released BluRay and HD-DVD movies).

By far the majority of PCs use 32-bit processors, because despite AMD’s efforts to push 64-bit CPUs into the marketplace early, Intel’s first widely-promoted 64-bit CPU is the just-released Core 2 Duo.

PC users will now have to choose between a PC that can play high definition content (64 bit) versus one that can potentially run older devices that only have unsigned drivers available (32 bit).

“Signed drivers” are ones that have undergone a Microsoft quality-assurance process and received a digital certificate that certifies them as stable for installation on 64-bit Windows.

Microsoft’s move to drop support for playback of studio-released HD movies on Vista is likely to anger the large number of people who were hoping they could use their existing 32-bit PC with an upgrade version of Vista.

The surprising disclosure was made by Senior Program Manager Steve Riley during a presentation on Windows Vista security at Tech.Ed 2006 Sydney today.

“Any next-generation high definition content will not play in x32 at all,” said Riley.

“This is a decision that the Media Player folks made because there are just too many ways right now for unsigned kernel mode code [to compromise content protection]. The media companies asked us to do this and said they don’t want any of their high definition content to play in x32 at all, because of all of the unsigned malware that runs in kernel mode can get around content protection, so we had to do this,” he said.

Riley then attempted to pre-empt audience concerns over the newly imposed limitation by asking how many of the Tech.Ed attendees currently played high-definition movies at home.

“How many of you have a DVD player that you know can output a proper 1080 line non-interlaced?”

No-one raised their hands.

“OK… look around. By the time that stuff becomes popular, it’ll no longer be an issue because everyone will be running 64-bit Windows,” he said.

However, earlier in his presentation, Riley had explained why Microsoft had decided to let unsigned code run in 32-bit Windows, but not in 64-bit Windows.

“Imagine how difficult it would be for you [the Tech.Ed attendees] to update your environment. It would be a non-starter, right?”

“We can’t do that [lock out unsigned drivers from 32 bit Windows]. The app-compat hit, as we say in Microsoft, would be far too great if we did it in 32-bit Vista.”

In an interview hastily organised by Microsoft public relations staff after they learned APC was planning to run this story, Riley was at pains to point out that Blu Ray and HD-DVD were storage media and “you could put an MPEG-4 movie on them and play them on a 32bit Vista PC just fine.”

But he conceded that a commercially-produced BluRay or HD-DVD movie with next-generation high definition protected content wouldn’t play on a 32 bit PC.
 
not too worried about this.

also face it, when vista comes out the average pc on the high street will be shipping with the 64bit version.

Also it could mean good news for most of us, looks like 64bit drivers will be of better quality lol :D
 
If I read that correctly though he's also saying you won't be able to run non signed code on Vista x64 (At least at kernel level)? I can think of quite a few people that might annoy.
 
Pretty stupid move when companies aren't even constraining the resolution of hi def over analogue and non hdcp outputs meaning you can just copy the hd movie by connecting your graphics card to a capture device. So it doesn't matter how many holes there are.
 
bam0 said:
If I read that correctly though he's also saying you won't be able to run non signed code on Vista x64 (At least at kernel level)? I can think of quite a few people that might annoy.
Hmm, let me think..... hackers and script kiddies? :p

It's an obvious move really. What good is HDCP if all it takes is some hacker to make a kernel driver that bypasses the content protection?

BTW the signing can be obtained by anyone. All its doing is providing an assurance to the user that the device driver came from the intended source.
 
NathanE said:
BTW the signing can be obtained by anyone. All its doing is providing an assurance to the user that the device driver came from the intended source.
Are you sure about that? I thought this was more like the WHQL signing, and you aren't going to get that quite so easily.
There go the community tweaked drivers, or plenty of open source legitimate security tools.
 
Yes I'm sure about it. WHQL is a strictly managed testing procedure. Kernel driver signing in Vista (although originally had similar plans) will be nothing like that.

The thing with security tools that use kernel hacks is... it's just positive vs negative. At the end of the day, nobody wins. It's just a constant arms race to one-up the other. So the only solution is to remove the possibility of kernel hacks altogether. Sure that will upset folks like Symantec and smaller security software vendors (and of course the hackers themselves)... but ultimately it provides a more secure operating system.


http://www.osronline.com/article.cfm?id=465 said:
Take Two - x64 Driver Signing
The NT Insider, Vol 13, Issue 3, May - June 2006 | Published: 22-May-06| Modified: 22-May-06

The article titled, "It's Not Your Computer - Microsoft to Block Unsigned x64 Drivers on Vista", described Microsoft's plans for an x64 driver signing program. The article also reviewed a number of objections the community raised about the implementation details of that program. Now, at least partially as a result of that community feedback, Microsoft has made a number of changes to the way the x64 driver signing program is being implemented. And we're pleased that those changes will go a long way toward overcoming the community's objections.


Ding-Dong the PIC is Dead
The most startling change in the x64 driver signing program is the total elimination of the Microsoft-issued Publisher Identity Certification (PIC) for signing shipping drivers. In its place, driver developers and publishers will use their Class 3 Code Signing Certificate, along with a new readily available item called a cross certificate, to sign their CATs and x64 kernel-mode executables.

What's a cross certificate? The clearest description I've found was written by Roberta Bragg in her November 2003 editorial on Redmondmag.com titled Cross Certification Trusts. The way cross certifications will be used for the x64 kernel- mode code signing program is as follows: there will be one cross certificate issued by Microsoft for each Certificate Authority (CA) whose Class 3 Code Signing Certificates Microsoft trusts for x64 code signing. Because the cross certificate is neither secret nor valuable by itself, Microsoft anticipates making these certificates easily available. For example, they may be downloadable from Microsoft's Web site.

When a driver developer or publisher uses the signtool utility to sign their CAT or x64 executable, they specify both their code signing certificate (issued to the company by one of the trusted CAs) and the cross certificate (issued by Microsoft indicating that the CA is one that is trusted). Changes to the signtool utility were needed to support cross certificates. The new version is available in versions of the WDK starting with build 5370.

The elimination of PICs is sure to make life easier for driver developers and publishers. For one thing, it presumably means that a winqual account is no longer necessary. For another, not having to get a PIC means not having to get somebody at your company to review and sign a Microsoft legal agreement. If you ask me, any time you can avoid getting lawyers involved, you're automatically better off.

More CAs
By itself, simply eliminating PICs isn't likely to satisfy the objections raised by the community to the initial x64 driver signing program. Our previous article indicated one of the biggest problems with the initial program was that the only certificate authority (CA) announced as being "trusted" to issue Class 3 Code Signing Certificates was Verisign. This made it very difficult, if not downright impossible, for small companies in certain parts of the world to get a certificate. An integral part of the revised program is the approval of additional "trusted" CAs. While the final list of trusted CAs was not available when this article was written, the names we've heard mentioned should make it possible for companies, regardless of their size or where they're located, to sign their x64 kernel-mode executables. We expect the initial list of CAs to be announced by Microsoft at WinHEC. Also, it's important to keep in mind that because of the way the x64 kernel-mode code signing program is structured, Microsoft can add trusted CAs to the list at any time.

Test Signing
Possibly the biggest issue that concerned the community in the initial incarnation of the x64 driver signing program was the lack of any realistic accommodation for testing. The revised program has good news in this area, too. A developer or tester can enable "test signing mode" on a given machine using BCDEdit. Once enabled, this mode will include some visual distinction on the desktop such as that presently provided in safe mode. When in test signing mode, x64 kernel-mode code signing will still be required, but Windows will not check to see if the certificate used to sign the executable is rooted in one of the trusted certificate authorities. This means that even a self-issued certificate created using the WDK's makecert utility will be sufficient to install or load an x64 driver in test mode.

We couldn't be happier with the plan for test signing. It provides significant flexibility to devs and testers while securing the certificate that will ultimately be used for release signing. Once test signing is enabled on the target machine in your office and on the machines in your test lab, you'll be able to sign your x64 kernel-mode executables with any old cert and get on with your testing without further annoyance.

Further, while it falls short of a generic method for bypassing code-signing entirely, turning on test signing at least provides some practical method (beyond hooking-up a debugger and leaving it connected) for a user to load a driver that hasn't been signed with a certificate from a trusted CA. While not perfect, test signing provides a cost-free mechanism that enables users to run community-developed x64 kernel-mode software.

Much Better This Time
This revision of the x64 kernel-mode code signing program sounds much better to us than the program that was initially announced. In summary, the main features of the program are:

Get a Class 3 Code Signing Certificate from one of the trusted CAs. Microsoft is expected to announce the initial list of these authorities at WinHEC.
Get the cross certificate that corresponds to the authority that issued your company's Class 3 Code Signing Certificate. This certificate will likely be downloadable from Microsoft.com in the near future. Again, expect more information at WinHEC.
For testing purposes, enable test mode using BCDEdit. Sign your x64 executables and CAT files using any certificate, even one you create on the spot with the makecert utility.
For final release signing, use the new version of signtool that is distributed in build 5370 and later of the WDK to sign your x64 executables and CAT files. You must use both your Class 3 Code Signing Certificate and the appropriate cross certificate.
If you just plain hate the idea that the origin of every kernel-mode module has to be identified, then there's not much in this new version of the x64 driver signing program to make you happy. In that case, given that Microsoft has made it clear they consider kernel-mode code signing to be a primary tool in the battle against kernel malware, you've got to either get over it or write software for another operating system. We're proud of the community for speaking up on this issue, and we're pleased with the revisions to the program designed to address the community's concerns.
 
Interesting, I had seen that much detail before.
But I can't be the first person to think about the fact that the "test signing" makes null the reason given in the first piece for not allowing HD playback on Vista x32, unless there are further restrictions of test signing mode.
 
Unfortuatly those of us who use our pc's for gaming will have no option to upgrade to vista one way or the other, Directx 10 will already only be available to vista users and linux has zero support for direct x games. All the rebooting between os's just to play games would drive me nuts

When u think about it this is probably what 64-bit computing needs cause xp-64 was a disaster....no support what so ever for popular hardware from the likes of canon etc. This might kick the whole thing into action. We might finally get full 64-bit support and computing for every type of software, especially games

It does suck that HD content will not be available, especially when media center type pc's are just taking off, but to this day microsoft havent made a product that hasnt been hacked so...........................
 
The Mad One said:
Agreed, if you ask me they shouldn't even release a 32bit version, but thats me :P

Thats fine if you wana buy a new pc each time microsoft releases an os but I don't they rip you off enough with the licence fee's and the 64bit isn't going to make any significant performance, and almost all personal computers are currently 32bit so they cant just cut off the rest of the world.

Btw... Whats gona be left in Vista that makes it worth having? I don't see any difference between vista and xp which really wows me. I mean WinFS - canceled, EFI - canceled, whats left? a Aero? that is horrificly ugly.
 
HDCP's pretty weak as cryptographic systems go. I doubt it will be long before "patches" are produced.

For more information on it, http://cryptome.org/hdcp-4attacks.htm

gizmoy2k said:
It does suck that HD content will not be available, especially when media center type pc's are just taking off, but to this day microsoft havent made a product that hasnt been hacked so...........................

Actually the xbox360 is doing quite well at the moment protection wise, the engineers made a good job of it. No unsigned code is able to run on it, however I got some ideas on this.
 
Last edited:
unknowndomain said:
Thats fine if you wana buy a new pc each time microsoft releases an os but I don't they rip you off enough with the licence fee's and the 64bit isn't going to make any significant performance, and almost all personal computers are currently 32bit so they cant just cut off the rest of the world.

Btw... Whats gona be left in Vista that makes it worth having? I don't see any difference between vista and xp which really wows me. I mean WinFS - canceled, EFI - canceled, whats left? a Aero? that is horrificly ugly.
EFI is still there. Windows Server has had it for ages... Not that average joes care whether they're running a traditional BIOS or EFI... :p

64-bit does actually have significant performance benefits, it's just they are relatively unpublicised as of right now.
 
gizmoy2k said:
Serious backtrack time

http://blogs.technet.com/windowsvista/archive/2006/08/24/450081.aspx

http://news.com.com/2061-10794_3-6109427.html

Basically it was a mistake all along!!!

Mibbe saw the reaction they got hehe
Not a mistake at all, just people went OTT when they read the initial media articles. The level of content protection is always controlled by the copyright holder. Microsoft simply exposes a set of controls (e.g. "Allow HD playback on 32-bit", "Deny HD playback on non-HDCP hardware" and so on) which the content owners can tick or untick depending on their requirements for that particular movie. Most of the big Hollywood studios have already said they won't be using HDCP at all for the initial HD rollout (probably a good year or two). Only once HD media has settled in are they likely to start using the content protection features of HDCP.
 
Back
Top Bottom