MKB V4 and BD+

[evdberg]

The first HD disks with new protections are here and I see no activity or excitement on this forum. Are we just waiting for SlySoft to come with a solution, or do we not want to help Fengtoa ? :) Just wondering ... personally I am quite interested to figure out how BD+ works.

[Doom9]

What makes you so sure the discs use BD+? So far I've only seen a lot of speculation, and seeing that no current software is able to deal with the latest AACS update, we lack confirmation that a properly ripped Fox disc really is still unplayable.

[SuperGoof]

What makes you so sure the discs use BD+? So far I've only seen a lot of speculation, and seeing that no current software is able to deal with the latest AACS update, we lack confirmation that a properly ripped Fox disc really is still unplayable.

No. BD+ is definitely here.

Please read this post:

http://forum.slysoft.com/showthread.php?p=53719#post53719

It has a link to a .rar file for "Day After Tomorrow". Please download it and have a look at dir.txt file there. You will see that this disc has a folder called "BDSVM". You can also see what files it contains. I think "SVM" means "Secure Virtual Machine". It's indeed BD+.

[FoxDisc]

The AACSLA claims they have expired PDVD keys as of September 7. (They also say they have turned on "proactive renewal" automatic key expiration.)

Are there any released HD DVD disks with an MKB v4? BD+ can be implemented independently of the MKB update/revocation processing of AACS. Do we know for certain if the new BD+ disks are the new MKB v4?

[gioowe]

It seems they revoked some more hosts.

V3 = ===============================================
RECORD >>> Host Revocation (3.2.5.3)
===============================================
000000C 21 Record Type OK
------- -----------------------------------------------
000000D 00 00 64 Record Size OK
------- -----------------------------------------------
0000010 00 00 00 06 Total Number of Entries = 6 OK
------- -----------------------------------------------
0000014 00 00 00 06 Number of Entries in Block #1 = 6 OK
------- -----------------------------------------------
0000018 00 09 FF FF 00 00 00 0B Revocation #1 = FFFF0000000B..0014 --
------- -----------------------------------------------
0000020 00 02 FF FF 00 00 00 21 Revocation #2 = FFFF00000021..0023 --
------- -----------------------------------------------
0000028 00 03 FF FF 00 00 00 26 Revocation #3 = FFFF00000026..0029 --
------- -----------------------------------------------
0000030 00 03 FF FF 00 00 00 35 Revocation #4 = FFFF00000035..0038 --
------- -----------------------------------------------
0000038 00 02 FF FF 00 00 00 4E Revocation #5 = FFFF0000004E..0050 --
------- -----------------------------------------------
0000040 00 03 FF FF 00 00 00 54 Revocation #6 = FFFF00000054..0057 --
------- -----------------------------------------------
0000048 33 6E D8 52 52 54 10 75
0000050 4F 0D 12 21 EC 3B C4 25 C6 21 E3 B5 80 EF 60 67
0000060 3F AC EC FB AD 3B D7 0D EC 70 6B 70 C4 E8 AF 87 Signature of Block VERIFIED
------- -----------------------------------------------


V4 = ===============================================
RECORD >>> Host Revocation (3.2.5.3)
===============================================
000000C 21 Record Type OK
------- -----------------------------------------------
000000D 00 00 64 Record Size OK
------- -----------------------------------------------
0000010 00 00 00 06 Total Number of Entries = 6 OK
------- -----------------------------------------------
0000014 00 00 00 06 Number of Entries in Block #1 = 6 OK
------- -----------------------------------------------
0000018 00 09 FF FF 00 00 00 0B Revocation #1 = FFFF0000000B..0014 --
------- -----------------------------------------------
0000020 00 08 FF FF 00 00 00 21 Revocation #2 = FFFF00000021..0029 --
------- -----------------------------------------------
0000028 00 03 FF FF 00 00 00 35 Revocation #3 = FFFF00000035..0038 --
------- -----------------------------------------------
0000030 00 04 FF FF 00 00 00 4E Revocation #4 = FFFF0000004E..0052 --
------- -----------------------------------------------
0000038 00 03 FF FF 00 00 00 54 Revocation #5 = FFFF00000054..0057 --
------- -----------------------------------------------
0000040 00 03 FF FF 00 00 00 5E Revocation #6 = FFFF0000005E..0061 --
------- -----------------------------------------------
0000048 0E 96 07 86 79 CE 33 98
0000050 EC 6E 5A 0A 5E F7 E3 E1 D4 BE 50 96 3C 72 CE 1C
0000060 39 84 09 45 01 89 9F 4D 30 C0 B2 F2 70 AB 07 B7 Signature of Block VERIFIED
------- -----------------------------------------------

[bcrabl]

Hope somebody would find a HD DVD standalone device key. Then we could buy a little more time before they found the key (implement sequence keys I think)

[mrazzido]

i wonder why sonys spiderman 1 2 3 bluray has no new protection :) works fine , i try to get any BD+ disc and test then :)

[greath]

Strange that the new MKB has been released so quickly. When they announced that it was changed I thought that the first release with it would be Transformers. So it's a surprise to see that Fox's discs are the first to use it.

[FoxDisc]

Hope somebody would find a HD DVD standalone device key. Then we could buy a little more time before they found the key (implement sequence keys I think)

Without commenting on whether someone has already found each and every one of the keys in a hardware player (or not), it's not clear having those keys would be useful or that releasing them now would do any good:

1) No one has found an HD-DVD disc that uses a V4 MKB and keys from an HD DVD hardware player won't help with the BD+ issue. (I'm assuming the V4 MKB quoted above is from the referenced BD+ disc not an HD)

2) Even if someone released the keys from a stand alone HD DVD, there is still the KCD problem. KCD was intended to prevent standalone keys from being used with software players. The KCD can be read with the XBOX drive hacks, but as far as I know there's no decrypting software out yet that will let you enter the KCD.

3) PowerDVD may get cracked for the HD-DVD (or may already be cracked for all I know) before anyone gets any HD-DVD discs that need the the keys.

[Thunderbolt8]

fantastic four: silver surfer is also said to be BD+

[Ryokurin]

http://www.highdefdigest.com/news/show/1035 Fantastic Four 2 and The Day After Tomorrow seem to be the first. Samsung's BDP-1200 and LG's BH100 can't play the disks at all, errors and stutter on Samsung's BDP-1000, playable on PS3 and others but some machines are having up to two minutes of load time.

edit: checking avsforum, it seems that the only one is the day after tomorrow, where some BD+ folders can be found when looking at the disk structure. Both disks do have the two minute load time on a bunch of players however.

[greath]

[url]Both disks do have the two minute load time on a bunch of players however.

That's kind of Fox. It gives you time to have a toilet break before the movie starts.............

[SuperGoof]

checking avsforum, it seems that the only one is the day after tomorrow

No, "Fantastic Four 2" also has BD+. The same person who posted info on "Day After Tomorrow" now posted it on Fantastic Four 2. And this movie also has BDSVM folder on disc.

See http://forum.slysoft.com/showthread.php?p=54988#post54988

[evdberg]

1) No one has found an HD-DVD disc that uses a V4 MKB
Evan Almighty seems to have MKB V4.

[SuperGoof]

i wonder why sonys spiderman 1 2 3 bluray has no new protection :) works fine , i try to get any BD+ disc and test then :)

Spider-Man discs are the most weird of all. They don't have BD+, don't even have new MKB (decrypted fine with existing tools), and yet PowerDVD Ultra 3104a does not play them from disc. Only does when ripped to hard drive... I got new version from Cyberlink today, will test tonight whether they fixed this or not.

[SuperGoof]

Evan Almighty seems to have MKB V4.

Also "Troy", as far as I know.

[greath]

The KCD can be read with the XBOX drive hacks, but as far as I know there's no decrypting software out yet that will let you enter the KCD.

Can it? I thought that the way to read the KCD was "secret" and was one of the only hidden parts of the AACS specification.

[FoxDisc]

Can it? I thought that the way to read the KCD was "secret" and was one of the only hidden parts of the AACS specification.

The KCD is intended for use only by hardware standalone players. It's stored on each disc in a way that can't be read by a standard HD-DVD drive when the AACS authentication session is established with a software player. That means that (in theory) a player like PDVD can't use stolen hardware keys since the PDVD player can't ask the drive to give it the KCD data on the disc it would need to use the stolen hardware key.

However, the XBOX drive is unusual in that it has a hardware player built into it. It's not a standard HD-DVD drive intended only for installation in a computer. That design lets Microsoft hand off the whole player task to the drive manufacturer when the drive is in the XBOX. It also means that an XBOX does not have to go through a standard AACS software player<->disc drive authentication session (which would prohibit reading the KCD and would require that the XBOX have software player keys built into it and Microsoft comply with the same terms that other software player manufacturers do - like constant key revocation, proactive renewal, etc.).

Instead, the XBOX drive *is* a hardware player (stored in its firmware), and unlike a standard HD-DVD add-on drive it *can* read the KCD. The XBOX hack that broke the volume ID also broke the KCD. So, bottom line, yes, it can read the KCD.

edit: To be clear - the XBOX drive also functions like a standard HD-DVD drive when a software player talks to it. PDVD can't ask the drive to give it the KCD since PDVD enters into a standard AACS authenticated session with the drive.

The KCD can be used to generate the necessary keys if you have hardware player keys - it's not a hard problem - so hardware keys are useful if you have the KCD. If Slysoft obtains hardware keys, and wants to use them, their customer will need an XBOX drive, or they will need to put the KCD into their software database. Again, those aren't hard problems.

[oeschmar]

I think "SVM" means "Secure Virtual Machine".

Yes, secure virtual machine.

Sony has some patents on it:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=0&f=S&l=50&TERM1=bdsvm&FIELD1=&co1=AND&TERM2=&FIELD2=&d=PG01

[FoxDisc]

Evan Almighty seems to have MKB V4.

Has a version of PowerDVD been released that will play it? Has Slysoft released a version of AnyDVD that will decrypt it?

[evdberg]

Has a version of PowerDVD been released that will play it?
I have read that PowerDVD customers can contact Cyberlink, and then they provide a download link by email.

Has Slysoft released a version of AnyDVD that will decrypt it?
Not yet, as far as I know.

[SamuriHL]

Has a version of PowerDVD been released that will play it? Has Slysoft released a version of AnyDVD that will decrypt it?

As evdberg said, there is a new version of PowerDVD Ultra that you can email support and ask for. Supposedly it'll be officially out next week sometime from what I've heard. AnyDVD hasn't been updated yet to handle MKB4. I haven't seen any ETA on the Slysoft forum as to when that'll be released, but, they are apparently working on it. BD+ is going to take them longer, but, they're looking into that, as well.

[lightshadow]

Yes, secure virtual machine.
By Virtual Machine I don't suppose it means what we relate to a VM from e.g. Java, right?

[gioowe]

Sure it does. A running java application within the drive's "OS" in a virtual machine.

[lightshadow]

Sure it does. A running java application within the drive's "OS" in a virtual machine.
I am impressed by that! I would never have thought that a drive could have that much memory and CPU power to run a VM!

If it is a Java application, would it then be possible to rip out the Java/black box, and then run it on Linux/Windows where there are great debugging tools?

[SamuriHL]

I am impressed by that! I would never have thought that a drive could have that much memory and CPU power to run a VM!

If it is a Java application, would it then be possible to rip out the Java/black box, and then run it on Linux/Windows where there are great debugging tools?

Don't forget that PowerDVD has to run the virtual machine code inside memory on a Windows machine, so, yes, it can probably be debugged, but, it will not be without challenge. The memory will be protected. Also, BD+ has the ability to modify both the video and audio stream on the fly. What this means is that they can add extra layers of encryption within the VM and decrypt all or individual parts of the streams. Very nasty.

[lightshadow]

Don't forget that PowerDVD has to run the virtual machine code inside memory on a Windows machine, so, yes, it can probably be debugged, but, it will not be without challenge. The memory will be protected. Also, BD+ has the ability to modify both the video and audio stream on the fly. What this means is that they can add extra layers of encryption within the VM and decrypt all or individual parts of the streams. Very nasty.
What about for hardware players? What kind of low cost hardware (memory and CPU vise) can handle such a complex VM?

[evdberg]

The VM for BD+ is small and simple, supports only 60 commands and can execute programs of 100 lines of code (see here (http://arstechnica.com/news.ars/post/20070620-blu-ray-content-protection-agency-certifies-bd.html)).
So the 20MB SVM files listed in the directories of Day After Tomorrow seem a bit too big ...

Also as far as I know the BD+ VM runs in the player, not in the drive.

[SuperGoof]

By Virtual Machine I don't suppose it means what we relate to a VM from e.g. Java, right?

No. According to Peer from Slysoft, BD+ is not Java at all:

http://forum.slysoft.com/showthread.php?p=44419#post44419

[gioowe]

Well, the MKB has a size of 1.000.000 bytes but currently only uses 12.628 bytes - the rest is filled with 00h. File size is no information.

I'm not sure where the VM is running in a Host/Drive-Environment. If it runs within the host then it'll be much easier to analyse.

[lightshadow]

The VM for BD+ is small and simple, supports only 60 commands and can execute programs of 100 lines of code (see here (http://arstechnica.com/news.ars/post/20070620-blu-ray-content-protection-agency-certifies-bd.html)).
So the 20MB SVM files listed in the directories of Day After Tomorrow seem a bit too big ...
People report of 2 minutes waiting time on BD+. Could that be the time it takes to do a checksum of 20MB?

Have anyone tried to zip it, just to see what kind of (random) data it contains to hide the actual code?

One positive thing about BD+ though is, that when it have been broken to pieces, people will clearly write some cool applications for the VM =) Perhaps even a debugger for hacking DRM? =)

[gioowe]

Perhaps someone could zip the whole disk (exclusive \BDMV\STREAM) for a first analysis.

The 2 minute startup time might only be related to BD-J and all that interactive stuff, not BD+. Or BD+ checks the firmware and 99% of 00000.svm contain checksums for each player firmware. We'll see..

[evdberg]

I am quite sure the BD+ code is protected by AACS, and since the MKB V4 is not broken yet we can not do much at this moment ... besides hunting for the new Processing Key.

[gioowe]

BD+ is surely not protected by AACS. It is protected by something but it has nothing to do with MKB V4. There's nothing new or different in V4.

[woah!]

I am quite sure the BD+ code is protected by AACS, and since the MKB V4 is not broken yet we can not do much at this moment ... besides hunting for the new Processing Key.

which at least means we (hd-dvd) can carry on regardless of the BD+ crap :)

[Johhn]

Unlikely as the contingency is, I assume that someone continues to monitor the "You Can Own an Integer Too — Get Yours Here" thread on Freedom to Tinker, and to check any numbers that turn up there.

I recall that the last processing key discovered was posted there and it was many days before anyone realised.

[honai]

People report of 2 minutes waiting time on BD+. Could that be the time it takes to do a checksum of 20MB?

No, it's the time needed to kick off the VM and compile the code that "protects" the disc.

Perhaps someone could zip the whole disk (exclusive \BDMV\STREAM) for a first analysis.

The code is digitally signed, and unless the folks at Slysoft find a design flaw in the actual implementation I don't think we're going to see a circumvention of BD+ anytime soon.

[Sharktooth]

Simple solution: dont buy movies on BD.

[woah!]

so now the BR standalones are not going to be quicker at loading anymore, another thing they will have to strike off the plus list... HD-DVD players were slow loading from the start as they are using a completed spec with HDi etc... BR pretty much just had to load a TS file and away it went... not so anymore it seems...

[Wilbert]

Unlikely as the contingency is, I assume that someone continues to monitor the "You Can Own an Integer Too — Get Yours Here" thread on Freedom to Tinker, and to check any numbers that turn up there.
Someone posted a number in that thread (on 07/10). Is that the right one?

[gioowe]

I get no match on a BD V4.

[Ajax_Undone]

I beleave the person involved with trying to crack BD+ will have realy nothing to do but try... (FAIL):eek:

All you need to do is create a Ram resident VM that keeps the BD+ VM busy by Emulating the hardware... Mean while the video is unlocked... find the key and rip at will:devil:

ps i dont know if this will...

[zeroprobe]

Slysoft are feeling confident.

from James

"we can unstick this thread in a 1-2 weeks or so anyway, as then there will be MKB v4 support in AnyDVD HD."
"With a little luck we will be ready for the Transformers HD DVD release on October 16.""

[Wombler]

Slysoft are feeling confident.

from James

"we can unstick this thread in a 1-2 weeks or so anyway, as then there will be MKB v4 support in AnyDVD HD."
"With a little luck we will be ready for the Transformers HD DVD release on October 16.""

The expertise that these guys have constantly amazes me.

Just as well they're on our side! :)


Wombler

[Humpa]

Slysoft are feeling confident.

from James

"we can unstick this thread in a 1-2 weeks or so anyway, as then there will be MKB v4 support in AnyDVD HD."
"With a little luck we will be ready for the Transformers HD DVD release on October 16.""Just some FYI.
James clarified that remark.
He says that they should have MKB4 support by Oct 16th, but BD+ will be more like 6 weeks.

[SamuriHL]

Just some FYI.
James clarified that remark.
He says that they should have MKB4 support by Oct 16th, but BD+ will be more like 6 weeks.

I hope people take these time frames for what they are. They're simply estimates. They're not hard set in stone. If it takes them longer, hopefully we won't see the usual "OMG, they said 6 weeks and it took them x!" kinds of posts. :) BD+ is probably going to be a tough nut to crack. Let's hope they can do it in 6 weeks, but, that's just a guess on their part.

[bob0r]

If you can crack it in 6 weeks, you can track it in 6 minutes.
He just says that to keep customers close.

You cannot give any ETA on cracking, it could be minutes or it could be years, you just never know.

All the true crackers from the passed all have retired, joined the "government" or went commercial.
Just be glad some people are still trying to "give us an open world" and support them in any way you can.

[Wombler]

I hope people take these time frames for what they are. They're simply estimates. They're not hard set in stone. If it takes them longer, hopefully we won't see the usual "OMG, they said 6 weeks and it took them x!" kinds of posts. :) BD+ is probably going to be a tough nut to crack. Let's hope they can do it in 6 weeks, but, that's just a guess on their part.

To be honest if they can crack it at all that will impress me.

Nobody else even seems to be remotely close to this yet.


Wombler

[SamuriHL]

Yea, I agree. My point was simply that when they say "6 weeks" I hope people aren't just sitting by their Blu-ray player counting down the days. bob0r is right in that cracking something like that isn't an exact science where they have a project plan and project schedule in place that says "oh, yea, 6 weeks and we'll have it done." :D it's just a guess to give them some breathing room. I think they'll eventually be able to do it. How long it'll take is a very good question.

[Pulp Catalyst]

it is quite strange, where are all the original crackers of AACS, i don't see any of them posting here no more, have they all retired or something?

[JeffAlso]

it is quite strange, where are all the original crackers of AACS, i don't see any of them posting here no more, have they all retired or something?
My guess is they're working on it in private. Be patient.

[ATARI Vampire]

My guess is they're working on it in private. Be patient.

Some of us are working on MKB v4 right now. Trying to beat SlySoft to the punch. :devil:

[Wombler]

Some of us are working on MKB v4 right now. Trying to beat SlySoft to the punch. :devil:


Now that would be impressive! :)


Wombler

[Turtleggjp]

I have a question about MKBv4.

Around the time that MKBv3 came out, it was known that just like the time before, a single processing key would open the whole thing up again, which in fact it did. Is it known this time whether or not a single processing key will be enough to open up MKBv4?

I know that Atari Vampire was able to discover a lot of (if not all) the additional device keys and processing keys that were revoked the first time around (the 09 F9 processing key) which I'm sure took quite a while. Is this what needs to be done this time around with MKBv4? If so, that would certainly explain why it is taking longer this time...

Matt

[Shinigami-Sama]

it is quite strange, where are all the original crackers of AACS, i don't see any of them posting here no more, have they all retired or something?

prolly changed names and spilt personalities to help not get a visit from the black hats

[mjrweed]

they are probably working on cracking it :)

[dchard]

I enjoy to see a sticky topic about BD+, like "Understanding AACS".

There we can share knowledge, understanding what it is, how it works, and we can group the whitepapers, and other specs. already known.

Dchard

[bcrabl]

I enjoy to see a sticky topic about BD+, like "Understanding AACS".

There we can share knowledge, understanding what it is, how it works, and we can group the whitepapers, and other specs. already known.

Dchard

Well the biggest problem is that such info is scarce and our knowledge is very limited (due to secrecy from the developers of BD+)

[greath]

Yes, the AACS specifications are open so were subject to scrutiny from peers. BD+ is closed. So they took a risk through keeping the specification secret and not open for peer review that they've left a gaping hole in it versus trying to limit knowledge to the hacker groups.

[honai]

The problem of BD+ and the company behind it is that in order to reach critical market penetration for Blu-ray they have to be quite liberal when disclosing the whitepapers to interested clients, i.e. in the end the full spec will be available to 1000s of small clients.

For them it is necessary that *all* partners keep the secret, for "us" it's sufficient that only *one* becomes a traitor.

[dchard]

Okey, I got the point.

So what we have now is just reverse engineering?

Dchard

[captain_video]

The problem of BD+ and the company behind it is that in order to reach critical market penetration for Blu-ray they have to be quite liberal when disclosing the whitepapers to interested clients, i.e. in the end the full spec will be available to 1000s of small clients.

For them it is necessary that *all* partners keep the secret, for "us" it's sufficient that only *one* becomes a traitor.
I'd like to think of them having the public's interest at heart rather than big business. I believe Hero is a term that more aptly applies here.

[woah!]

seems this v4 is more involved as its quiet on all fronts now... looks like i am going back to dvd purchases as of now...

my A2 is great for upconverting so no loss really...

[bob0r]

Best comment ever. :stupid:

[d0ORk]

Also a problem with Die Hard 4.0 BluRay

[chenhua]

seems this v4 is more involved as its quiet on all fronts now... looks like i am going back to dvd purchases as of now...

my A2 is great for upconverting so no loss really...

Anydvd 6.1.8.6 beta breaks mkbv4. :)

[Thunderbolt8]

no, not yet

[chenhua]

The problem of BD+ and the company behind it is that in order to reach critical market penetration for Blu-ray they have to be quite liberal when disclosing the whitepapers to interested clients, i.e. in the end the full spec will be available to 1000s of small clients.

For them it is necessary that *all* partners keep the secret, for "us" it's sufficient that only *one* becomes a traitor.

bd+ not depends on secrecy. Player has vm so no secret. Program on disc is secret and makes security. But program made by studio and different for all disc. More work for slysoft so maybe they charge more soon. :(

[d0ORk]

Anydvd 6.1.8.6 beta breaks mkbv4. :)

but not Die Hard V4.0 :o

[Conquerist]

Anydvd 6.1.8.6 beta breaks mkbv4.

SlySoft hasn't fully cracked mkb v4. From reading their forums, it looks like they've "cracked" Evan Almighty, but not Transformers.

So they probably found some specific key for Evan Almighty, because if they had truly broken mkb v4 (found a processing key or exploitable bug), Transformers would work too.

See http://forum.slysoft.com/showthread.php?t=8883.

[SamuriHL]

Give it time. According to the forum they're apparently working on it.

[Shinigami-Sama]

every new key we find just makes finding the next one easier though
even if we get one or two MKB's behind we're not loosing much more than a few month of waiting to be able to rip the discs
I normally don't buy them till I see them in the 5-15$ bargain bin anyways, and I know a lot of other people like that

[chenhua]

SlySoft hasn't fully cracked mkb v4. From reading their forums, it looks like they've "cracked" Evan Almighty, but not Transformers.

So they probably found some specific key for Evan Almighty, because if they had truly broken mkb v4 (found a processing key or exploitable bug), Transformers would work too.

See http://forum.slysoft.com/showthread.php?t=8883.

Sorry I was mistake. I see Evan Almighty and think mkbv4 is it. Maybe slysoft have Processing Key and never release. Just update Title Key to avoid revocation! :devil:

[bcrabl]

Sorry I was mistake. I see Evan Almighty and think mkbv4 is it. Maybe slysoft have Processing Key and never release. Just update Title Key to avoid revocation! :devil:

They will just revoce all the keys to be sure.:confused:

[zeroprobe]

You would think they would revoke the main PC players like powerdvd and windvd everytime as a precaution as they would be the most vunerable.

[JeffAlso]

You would think they would revoke the main PC players like powerdvd and windvd everytime as a precaution as they would be the most vunerable.

September 7, 2007 – AACS LA Announces Commencement of “Proactive Renewal”

AACS LA announces that it has started periodic “proactive renewals”, which, primarily for software player applications, provide for periodic renewal and refreshing of AACS encryption keys by licensed manufacturers and eventual expiration of old keys by AACS LA. This helps maintain the AACS technology as a vital means of distributing valuable high definition content to consumers. Consumers should expect that updates/patches will be periodically offered by their software manufacturer in order to ensure that the players continue to function as intended. The upgrading of software is a common practice in the software industry. Pursuant to the AACS technology licenses, manufacturers of software players are required to perform such updates in a consumer-friendly fashion.

[chenhua]

September 7, 2007 – AACS LA Announces Commencement of “Proactive Renewal”

AACS LA announces that it has started periodic “proactive renewals”, which, primarily for software player applications, provide for periodic renewal and refreshing of AACS encryption keys by licensed manufacturers and eventual expiration of old keys by AACS LA. This helps maintain the AACS technology as a vital means of distributing valuable high definition content to consumers. Consumers should expect that updates/patches will be periodically offered by their software manufacturer in order to ensure that the players continue to function as intended. The upgrading of software is a common practice in the software industry. Pursuant to the AACS technology licenses, manufacturers of software players are required to perform such updates in a consumer-friendly fashion.

It do not say time to revoke. But it is more than 90 days. So we have until 7/12 before key gone. :p

[oddball]

Transformers HDDVD is already up on a certain site. Also from what people have been able to gather AnyDVD is now using the oracle approach to crack the discs.

[Peer van Heuen]

Also from what people have been able to gather AnyDVD is now using the oracle approach to crack the discs.

That has been mentioned somewhere, but is incorrect (it was a guess of one of our forum members).
Our approach to MKB4 is somewhat different but that has not much to do with the actual processing of discs or calculating keys, there are other reasons for that.

[markrb]

According to Slysoft they Have broken MKB4.

http://forum.slysoft.com/showthread.php?t=8982

We have broken MKBv4. Please be so kind to submit AnyDVD_Info ... files for all BD or HD DVD discs where AnyDVD HD issues an AACS error.

YEAH for the good guys. Now onto BD+

Mark

[deets]

ironically, im now far more likely to invest in an HD DVD player because of this fact!

[Wombler]

According to Slysoft they Have broken MKB4.

http://forum.slysoft.com/showthread.php?t=8982

We have broken MKBv4. Please be so kind to submit AnyDVD_Info ... files for all BD or HD DVD discs where AnyDVD HD issues an AACS error.

YEAH for the good guys. Now onto BD+

Mark

That's only for certain discs.

Hence the request for details of discs that AnyDVD can't cope with.

If you read the updates they state that full support will be included in a future release.


Wombler

[bcrabl]

That's only for certain discs.

Hence the request for details of discs that AnyDVD can't cope with.

If you read the updates they state that full support will be included in a future release.


Wombler

Can somebody with AACS knowledge tell us what this means. They gather some info from the disk but they are not oracles...:confused::confused:

[arctor]

This is good. I wonder if anybody has been able to look at the a decrypted disk that has BD+. I rekaise that it shouldn't be playable but would like to know if raw video/audio files have been changed (one expects them to be altered somewhat ready for the BD+ Program to change them back during playback.)

[bcrabl]

No, this means that all non BD+ titles, where people have posted AnyDVD_Info files, are working.
(Here is your personal cracking service speaking )
BD+ discs will now be AACS decrypted, too, so everyone who want to take a look how BD+ works can do so now (greetings to Arnezami & Co.)

thats what james said.

[Galileo2000]

Essentially SlySoft managed to crack mkb v4 and they are going to break BD+ once and for all pretty soon.

According to them BD+ is nothing more than security by obscurity.

As far as I understand, once they break one BD+ they are able to break all of them.

Good time for all on the Fair Use side.

Bad time for all the account reps who spent millions of $$$ on the "good-for-nothing" schemes.

[markrb]

That's only for certain discs.

Hence the request for details of discs that AnyDVD can't cope with.

If you read the updates they state that full support will be included in a future release.


Wombler


Look at their forum. There is a section for people having problems with the latest version. Not a single reply for HD-DVD. I would say it was definately cracked. Just like before they will need to update for individual discs on occasion, but that has been the case for awhile now.

Mark

[Wombler]

Look at their forum. There is a section for people having problems with the latest version. Not a single reply for HD-DVD. I would say it was definately cracked. Just like before they will need to update for individual discs on occasion, but that has been the case for awhile now.

Mark

I believe they're very very close to fully breaking it but according to SlySoft's list of updates they themselves reckon they're not quite there yet.

The latest version released only yesterday (6.1.9.3) still says that they've added support for "some popular MKBv4 discs" but it also states "Note: Support for all MKBv4 discs will be added in a future release"

I'd assume SlySoft know where they're at. :)


Wombler

[KenD00]

To give all that speculation about what SylSoft can do with MKBv4 and can't a more technical note i add the following: i think currently they are in the BackupHDDVD era, they know how to get the VUK from a title (hence the request for the info files) and are moving on to the aacskeys era (finding a processing key, maybe device keys).

:rolleyes:

[Turtleggjp]

If they are in the BackupHDDVD era, then wouldn't they need an entire disc for a player to play, and not just the MKB info from a disc? Sounds to me like they have a processing key (and host private key) so they can get the VUK using only the MKB from a disc.

[gioowe]

According to James from SlySoft (http://forum.slysoft.com/showpost.php?p=61842&postcount=26) they have a processing key for MKBv4. They just don't want to leak it by releasíng a software that contains it.

[Thunderbolt8]

"We already found a way to crack BD+ and we have just turned to fine-tuning. I should really think about hiring a bodyguard now, since this product won't please everybody."

http://www.cdrinfo.com/Sections/News/Details.aspx?NewsId=21709

[SamuriHL]

Gotta hand it to those Slysoft boys and girls....they sure do know their stuff. :)

[vio_man]

Also James said that they've really cracked MKB v4 but right now only titles with submitted logs are working, because they need to integrate their "universal" MKB v4 decrypter into AnyDVD HD. Once they integrate it all titles will be decrypted. And as many of you said, BD+ will be cracked shortly, James said probably by the end of the year.

[bcrabl]

http://forum.slysoft.com/showpost.php?p=61738&postcount=11

They've gone Oracle.

[SamuriHL]

Also James said that they've really cracked MKB v4 but right now only titles with submitted logs are working, because they need to integrate their "universal" MKB v4 decrypter into AnyDVD HD. Once they integrate it all titles will be decrypted. And as many of you said, BD+ will be cracked shortly, James said probably by the end of the year.

That's not exactly what they said. They said they are going to allow AnyDVD HD to communicate with their server for any new titles that it doesn't have keys for and will discover the key from the information sent to the Slysoft server, and send back a key for that title. The MKBv4 cracking code will not be integrated into AnyDVD HD directly. Each new version will come with an upgrade list of titles that it can decrypt. However, as I said, when a new one is encountered it'll be decrypted for you by the server.

[vio_man]

You're right. I misunderstood.

[JeffAlso]

This brings up an interesting question - if the Device/Processing keys used aren't incorporated into the client software itself, is there any reason to believe that they were originally extracted from a software player?

It would make more sense to extract the keys from a hardware player, which is much less likely to have it's keys revoked by AACS LA. They would have to read the Key Conversion Data from the lead-in, presumably using a XBox drive or other modified hardware in order to get the Volume Unique Keys for the individual disks. This may explain why this one took a little longer than previous MKBs.

If this is the case, then not only does it become more difficult for AACS LA to identify the leaked key, but when they do they have to face the problem of potentially revoking the keys in ten of thousands of hardware players.

[tjf]

It would make more sense to extract the keys from a hardware player, which is much less likely to have it's keys revoked by AACS LA. They would have to read the Key Conversion Data from the lead-in, presumably using a XBox drive or other modified hardware in order to get the Volume Unique Keys for the individual disks. This may explain why this one took a little longer than previous MKBs.


Remember, they now plan to use the oracle approach. It is supposed to work for all the new MKB 4 discs. So they cannot use standalone keys, because AnyDVD HD cannot read KCD and send it to the oracle. What you are saying is that they would have to buy all the MKB 4 discs and read the KCD from them and feed the oracle, which is not realistic.

The question is if the new oracle approach will force AACS LA to use sequence keys to find out which software player was compromised. My opinion is that they do not care, they revoke all three of them anyway, but will the software vendors try to obfuscate the keys more if they are not sure it was their application that was hacked?

[bcrabl]

Thet went oracle because they don't want open source community to crack anydvd and find the device/proseccing keys. That is the only reason. The AACS LA will just revoce all the keys for software players next december.

[linx05]

Thet went oracle because they don't want open source community to crack anydvd and find the device/proseccing keys. That is the only reason. The AACS LA will just revoce all the keys for software players next december.
Actually they don't mind freeware (http://forum.slysoft.com/showpost.php?p=61738&postcount=11) tools using them but they would not like it if other shareware companies stole it.:cool::mad:

[Wombler]

That's not exactly what they said. They said they are going to allow AnyDVD HD to communicate with their server for any new titles that it doesn't have keys for and will discover the key from the information sent to the Slysoft server, and send back a key for that title. The MKBv4 cracking code will not be integrated into AnyDVD HD directly. Each new version will come with an upgrade list of titles that it can decrypt. However, as I said, when a new one is encountered it'll be decrypted for you by the server.

That's a clever way of doing it!:cool:

It completely avoids the possibility of revealing their cracking technique.


Wombler

[SamuriHL]

That's a clever way of doing it!:cool:

It completely avoids the possibility of revealing their cracking technique.


Wombler

It is clever, but, it does have drawbacks, too. A lot of people are complaining about having "offline HTPC's" but then, how do they get AnyDVD updates to that machine in the first place? If they're that concerned about putting the machine online to allow it to crack discs "instantly", they can always wait until AnyDVD is updated with a new key database and update the AnyDVD version "offline". So, yes, people are complaining already about this new method, however, given that it's the *ONLY* method so far, well, not too much to complain about IMO.

[FoxDisc]

"they are going to allow AnyDVD HD to communicate with their server for any new titles that it doesn't have keys for and will discover the key from the information sent to the Slysoft server, and send back a key for that title."

That's a clever way of doing it!:cool:
It completely avoids the possibility of revealing their cracking technique.
Wombler

I don't think "clever" is quite the right word for it. This type of attack is referred to as an "oracle" and the AACS system was built with the assumption that an oracle would be tried. You could say that AACS is years ahead since a "solution" to the oracle attack was built into the AACS specs long ago.

The "solution" is sequence keys which would (eventually) identify the compromised keys used by the oracle. As others have commented, it's likely that the keys came from a software player and they will all be changed by AACSLA on the next MKB cycle. Sequence keys may never be used.

I suspect that Slysoft sees some advantage in hiding the keys they use from their competitors, and some advantage in keeping secret which software player they have compromised to reduce the incentives to harden it.

[Peer van Heuen]

The "solution" is sequence keys which would (eventually) identify the compromised keys used by the oracle. As others have commented, it's likely that the keys came from a software player and they will all be changed by AACSLA on the next MKB cycle. Sequence keys may never be used.

I suspect that Slysoft sees some advantage in hiding the keys they use from their competitors, and some advantage in keeping secret which software player they have compromised to reduce the incentives to harden it.

Well, surely it's not that we are under any illusion that hiding keys by using a key-server would keep AACS from finding out the source of the keys.
That's not really the point. We simply found that there are several advantages to it.
One is: yes, software players have put tremendous effort into hiding their keys lately.
It took me a full 3 weeks to get them, after all, so my hat off ;)

Anyway - while this may encourage people to start hacking into AnyDVD (which is happening all the time anyway for cracking purposes) - AnyDVD does hide it's keys too, but not as efficient as the latest SW players do, I have to admit.
So it would make me feel a little awkward to put all that work into the unwrapping and then see our friend FengTao just copy them from us (which I would do too in his place, I'm not blaming him for that at all).
So instead of adding that amount of hard work to obfuscate keys as well as current SW players do, we decided to not put the keys into danger at all.

Also, this method let's us be right on top of the news, whenever a new encryption comes up, which is the point that has the most sex-appeal to me myself :)

EDIT: there are some additional advantages to the users as well, like SAK/PS3-users using 1:1 images created from their PS3 will typically not have to wait for an AnyDVD update that can crack their known disc - the online query is much more up to date.

[lightshadow]

One is: yes, software players have put tremendous effort into hiding their keys lately.
I have no problem with the oracle/blackbox approach, but I am thinking when you have spend the time to reverse engineer the software players key scrambling, couldn't you just reuse that scrambling routine in AnyDVD?

Keep up the good work! =)

[Peer van Heuen]

I have no problem with the oracle/blackbox approach, but I am thinking when you have spend the time to reverse engineer the software players key scrambling, couldn't you just reuse that scrambling routine in AnyDVD?


Nice thought for sure, but those are several layers and even knowing how they work (some are really beautiful, I'd like to add), it takes longer to implement than to break. That is a basic rule of obfuscation - constantly underestimated.
Also, I prefer to not "steal" more than necessary.

[lightshadow]

Nice thought for sure, but those are several layers and even knowing how they work (some are really beautiful, I'd like to add), it takes longer to implement than to break. That is a basic rule of obfuscation - constantly underestimated.
Also, I prefer to not "steal" more than necessary.
I don't think you can talk about stealing a number, but that's another discussion =)

But I see you point, and when I think about it, it would mean that AACSLA would know exactly how to unscramble the keys. =(

[FoxDisc]

software players have put tremendous effort into hiding their keys lately.
It took me a full 3 weeks to get them, after all, so my hat off ;)

And my hat is off to you too as you appear to be the only one who has achieved this feat.

It would have been nice to know what you learned about the obfuscation/hiding and how you learned it - purely as an intellectual interest - but I understand that you probably don't want to tell your competitors, those who wrote the obfuscation/hiding routines and the AACS about your techniques and failures/successes. Perhaps one day, though ...

[zeroprobe]

Getting ripping them hardware players apart slysoft. Get some more ammo for the future battles.

[Galileo2000]

Well, hats off to Peer!

Now to BD+.

SlySoft forum users (at least 2 of them) report successful ripping of the BD+ title.

http://forum.slysoft.com/showthread.php?t=9120

SlySoft itself did not say new AnyDVD breaks BD+, they said they are working on this.

But..can it be that BD+ has no clothes?

Just complying with the file structure does it?

Wishful thinking I guess.

[blutach]

So it would make me feel a little awkward to put all that work into the unwrapping and then see our friend FengTao just copy them from us (which I would do too in his place, I'm not blaming him for that at all).Peer,

Please keep such comments regarding other members here to yourself or on your own forum. Apart from possibly being libelous (which Doom9 might also be liable for), it is clearly a breach of rule 4.

We do appreciate your participation here, but please be aware of our rules.

TIA.

Regards

[Wombler]

Also, this method let's us be right on top of the news, whenever a new encryption comes up, which is the point that has the most sex-appeal to me myself :)


That's one of the reasons I thought it was particularly clever.

Any new discs that the software can't cope with you learn about immediately! :cool:

Congratulations on some brilliant work.


Wombler

[Johhn]

Well, hats off to Peer!

Now to BD+.

SlySoft forum users (at least 2 of them) report successful ripping of the BD+ title.

http://forum.slysoft.com/showthread.php?t=9120

SlySoft itself did not say new AnyDVD breaks BD+, they said they are working on this.

But..can it be that BD+ has no clothes?

Just complying with the file structure does it?

Wishful thinking I guess.



It is starting to look as if there might be a bug in a software player (as if) that is facilitating by-passing of bd+ somehow. I imagine that exploits of that are a separate matter to progress being made elsewhere.

[Peer van Heuen]

Please keep such comments regarding other members here to yourself or on your own forum. Apart from possibly being libelous (which Doom9 might also be liable for), it is clearly a breach of rule 4.

We do appreciate your participation here, but please be aware of our rules.


Done :)

FengTao is a polite and friendly person. No harm meant.

[Peer van Heuen]

It is starting to look as if there might be a bug in a software player (as if) that is facilitating by-passing of bd+ somehow. I imagine that exploits of that are a separate matter to progress being made elsewhere.

I'll have to look into this further - rest assured, AnyDVD HD is not bypassing BD+ yet.

[lightshadow]

SlySoft forum users (at least 2 of them) report successful ripping of the BD+ title.

http://forum.slysoft.com/showthread.php?t=9120

That sure is an interesting thread!!

For those who haven't read it, it says that if you rip a BD+ title with AnyDVD and then normal file copy the missing folders, BD+ can't tell the difference from the BD and the harddrive, so it plays back the movie perfectly.

Who would have thought that BD+ is independent of the AACS DRM?

[SamuriHL]

Who would have thought that BD+ is independent of the AACS DRM?

Somehow I get the feeling it's not supposed to be. :D Most likely it's a bug in PowerDVD that will eventually get patched. However, it's quite interesting for now, for sure. Now if I could only get my darn PS3 to play nice and allow me to image my Blu-ray discs to my external drive I'd be golden. Almost there on that one. My new HTPC components arrive sometime next week, so, I'm definitely ready.

[lightshadow]

Somehow I get the feeling it's not supposed to be. :D Most likely it's a bug in PowerDVD that will eventually get patched.
Wouldn't it be more like a design bug in BD+? It seams to me that they have forgot to implement a media check in BD+...

[lightshadow]

And my hat is off to you too as you appear to be the only one who has achieved this feat.

It would have been nice to know what you learned about the obfuscation/hiding and how you learned it - purely as an intellectual interest - but I understand that you probably don't want to tell your competitors, those who wrote the obfuscation/hiding routines and the AACS about your techniques and failures/successes. Perhaps one day, though ...
It could be a book like Andew Bunnies "Hacking the XBox" book, sold for $9.99 at Slysoft =)

"Hacking AACS and BD+ for beginners"

=)

[SamuriHL]

Wouldn't it be more like a design bug in BD+? It seams to me that they have forgot to implement a media check in BD+...

No, I think it's a bug in PowerDVD's implementation more than a design flaw in BD+. Also, if you try to burn the contents of the disc to a writable media, PowerDVD will then refuse to play it. It's only playback from the hard drive that is working and only if you include all the BD+ directories and files. There's obviously no way to test stand alone players in that scenario so you could be right in that it could be a BD+ issue, but, regardless I suspect we'll see a PowerDVD patch coming soon. Actually, isn't there a demo of another HD playing software out there? Arcsoft or something? Has anyone checked that one to see if it has the same flaw? I'll post on Slysoft's forum and see if anyone there's tried it. That's a very interesting question, though.

[Doom9]

Seeing as the Blu-ray specs don't mention BDMV playback from non encrypted sources, but don't seem to specifically forbid it either, it could just be another case of the specs not specifically forbidding out-of-spec scenarios. Of course, since BD+ lies on security through obscurity (with the usual success rate if Slysoft is not on a PR spree of BDA like proportions), there's no way to check.

[SamuriHL]

That's certainly a possibility. That's also why I want someone with the Arcsoft demo to try it out and see what happens. If it's just a PowerDVD thing then either they're more relaxed about the specs or it's potentially a bug in their implementation. Either way, it works in this version so that's a good thing. :) When I get my new HTPC built tomorrow I'll be sure to check this out further.

[Peer van Heuen]

That's certainly a possibility. That's also why I want someone with the Arcsoft demo to try it out and see what happens. If it's just a PowerDVD thing then either they're more relaxed about the specs or it's potentially a bug in their implementation. Either way, it works in this version so that's a good thing. :) When I get my new HTPC built tomorrow I'll be sure to check this out further.

I'd like to add, that it may just as well be a thoughtless BD+ usage on these specific discs.
BD+ should well be able to check whether the disc has been decrypted itself and then refuse to descramble the BD+ encrypted parts... But it needs to be coded into the BD+ VM.

[SamuriHL]

I'd like to add, that it may just as well be a thoughtless BD+ usage on these specific discs.
BD+ should well be able to check whether the disc has been decrypted itself and then refuse to descramble the BD+ encrypted parts... But it needs to be coded into the BD+ VM.

So, what you're saying is that Fox waited all this time for BD+ and then pooched the implementation, potentially? Naw, that could NEVER happen, Peer! :D ROFLMAO! Yea, that's also a very good possibility. What a well thought out technology they got themselves there. cough cough :)

[lightshadow]

I'd like to add, that it may just as well be a thoughtless BD+ usage on these specific discs.
BD+ should well be able to check whether the disc has been decrypted itself and then refuse to descramble the BD+ encrypted parts... But it needs to be coded into the BD+ VM.
I wonder if encrypted data would be different, if the BD+ could check for the media in drive?

What I am trying to say is, if BD+ can turn on and off security features, and still work with the same input data, is then really a DRM that is any good (from Hollywoods point of view) ?

Actually I don't really understand what BD+ does besides scramble data. Does it have a same features as AACS?

[lightshadow]

Replying to my own post. Wikipedia had the answer (http://en.wikipedia.org/wiki/BD%2B):

BD+ is effectively a small virtual machine embedded in authorized players. It allows content providers to include executable programs on Blu-ray Discs. Such programs can:


examine the host environment, to see if the player has been tampered with. Every licensed playback device manufacturer must provide the BD+ licensing authority with memory footprints that identify their devices.
verify that the player's keys have not been changed.
execute native code, possibly to patch an otherwise insecure system.
transform the audio and video output. Parts of the content will not be viewable without letting the BD+-program unscramble it.

If a playback device manufacturer finds that its devices have been hacked, it can potentially release BD+-code that detects and circumvents the vulnerability. These programs can then be included in all new content releases.

The specifications of the BD+ virtual machine are only available to licensed device manufacturers. A list of licensed adopters is available from the BD+ website

[woah!]

Replying to my own post. Wikipedia had the answer (http://en.wikipedia.org/wiki/BD%2B):

BD+ is effectively a small virtual machine embedded in authorized players. It allows content providers to include executable programs on Blu-ray Discs. Such programs can:


examine the host environment, to see if the player has been tampered with. Every licensed playback device manufacturer must provide the BD+ licensing authority with memory footprints that identify their devices.
verify that the player's keys have not been changed.
execute native code, possibly to patch an otherwise insecure system.
transform the audio and video output. Parts of the content will not be viewable without letting the BD+-program unscramble it.

If a playback device manufacturer finds that its devices have been hacked, it can potentially release BD+-code that detects and circumvents the vulnerability. These programs can then be included in all new content releases.

The specifications of the BD+ virtual machine are only available to licensed device manufacturers. A list of licensed adopters is available from the BD+ website

oh i see, its a virus .... you dont have a say in its execution it just runs as soon as you put a disc in...

[Galileo2000]

Replying to my own post. Wikipedia had the answer (http://en.wikipedia.org/wiki/BD%2B):

BD+ is effectively a small virtual machine embedded in authorized players. It allows content providers to include executable programs on Blu-ray Discs. Such programs can:


examine the host environment, to see if the player has been tampered with. Every licensed playback device manufacturer must provide the BD+ licensing authority with memory footprints that identify their devices.
verify that the player's keys have not been changed.
execute native code, possibly to patch an otherwise insecure system.
transform the audio and video output. Parts of the content will not be viewable without letting the BD+-program unscramble it.

If a playback device manufacturer finds that its devices have been hacked, it can potentially release BD+-code that detects and circumvents the vulnerability. These programs can then be included in all new content releases.

The specifications of the BD+ virtual machine are only available to licensed device manufacturers. A list of licensed adopters is available from the BD+ website

Scary stuff.

Except it seems that such a frightening code/machine does not really exist.

Can you say "Paper tiger"?

[vio_man]

It seems that Slysoft circumvented BD+

6.1.9.6 2007 11 07

* New (Blu-ray): AnyDVD ripper copies BD+ titles
* New (Blu-ray): Removed "BD+ not supported" warning, as all available BD+ titles can be copied with AnyDVD ripper, or can be watched on HTPC without HDCP using PowerDVD 3104 and AnyDVD. Reports indicate, that burned BD+ titles work on PS3 and standalone players as well.
* Note to Twentieth Century Fox: As you can see, BD+ didn't offer you any advanced security, it just annoyed some of your customers with older players. So could you please cut this crap and start publishing your titles on HD DVD? There are thousands of people willing to give you money.
* Note to people considering to invest in HD media: Please buy HD DVD instead of Blu-ray. HD DVD is much more consumer friendly (e.g., no region coding, AACS not mandatory). Don't give your money to people, who throw your fair-use rights out of the window.
* New (HD DVD & Blu-ray): Support for more MKBv4 titles
* Some minor fixes and improvements
* Updated languages

[honai]

Don't think so. It says that titles can be watched

on HTPC without HDCP using PowerDVD 3104 and AnyDVD

but not that BD+ "protection" is actually stripped from the ripped streams. In other words, it's not really "fair use" if you're still stuck with a shitty player from Cyberlink.

Please correct me if I'm wrong.

[SamuriHL]

It is claimed that some people have burned the ripped image to a blank disc and are able to play it back on their stand alone device such as a PS3. I have 0 knowledge of this as I can barely play BD as it is given that I only have a PS3 and xferring the image to my HTPC has so far failed for me. Nonetheless, this does NOT remove the BD+, it only copies it as well and removes the AACS encryption. Apparently Slysoft believes that the first iteration of BD+ on these discs was not very well implemented. It would appear that's quite accurate.

[vio_man]

Yes, it seems they found a flaw in the way the BD+ was implemented. They don't simply remove BD+, they found it can be copied. But I do think there will be a "fixed BD+" version in a near future.

[honai]

Since the code that is executed in the BD+ VM has a limited instruction set and no direct access to the host's actual hardware, it's likely that the attack vector consists of emulating disc geometry, the content of certain sectors on the disc, etc., all of which are actually implemented by the VM host. In other words, regardless of the complexity and size of the BD+ code the weakest link is a small set of functions in the VM, so instead of breaking/patching the BD+ code you attack the VM and route disc access there to your emulator.

CS 101 (cf. finite state machines) will tell you that the BD+ code cannot enforce integrity of the VM host, so it won't be able to detect that the data it gets from the "disc" is actually being injected by way of hooks in the VM. The whole security model relies on the fact that the BD+ code itself is obscured. But disc access from the VM is not and can be sniffed ...

[lstepnio]

Cars 2006 720p BluRay x264-REVEiLLE was posted on the internet. This should be a BD+ title if I'm not mistaken. How is this possible? This seems to go against what was being said here regarding the state of the BD+ flaw.

[diogen]

Cars 2006 720p BluRay x264-REVEiLLE was posted on the internet. This should be a BD+ title...I believe only FOX uses BD+. Cars is Disney (Pixar).

Diogen.

[lightshadow]

I believe only FOX uses BD+. Cars is Disney (Pixar).


That's a big ironic.

AACS is developed by Disney, Intel, Microsoft, Matsushita (Panasonic), Warner Brothers, IBM, Toshiba and Sony

[honai]

Cars 2006 720p BluRay x264-REVEiLLE was posted on the internet. This should be a BD+ title if I'm not mistaken. How is this possible? This seems to go against what was being said here regarding the state of the BD+ flaw.

When in doubt, trust what is being written at Doom9. ;-)

AACS is developed by Disney, Intel, Microsoft, Matsushita (Panasonic), Warner Brothers, IBM, Toshiba and Sony

Actually, most of the specs was written by Intel engineers, and the studios just gave their "good names".

[diogen]

BD+ (or whatever it was called then) was looked at and voted down on DVD Forum (for inclusion in HD DVD).
BDA put BD+ is BD specs to win FOX over...

And now they both look like jerks: BDA for including a useless component in specs and FOX for holding a
moratorium on its BD releases until BD+ is implemented... and broken a month later.

Diogen.

[JeffAlso]

I'm wondering if anyone here (or elsewhere) is currently working on indentifying a new MKBv4 processing key?

I realize that such an effort can be extremely challenging and time consuming, but I'm beginning to wonder if those involved in the original discoveries have retired from the effort. If so, it would be nice to know, as that might motivate a new group of engineers to throw their hats into the ring.

If anyone here is working on the problem, let us know, as I'm sure I'm not the only one wondering if the effort is still underway.

Thanks much!!

[bcrabl]

I'm wondering if anyone here (or elsewhere) is currently working on indentifying a new MKBv4 processing key?

I realize that such an effort can be extremely challenging and time consuming, but I'm beginning to wonder if those involved in the original discoveries have retired from the effort. If so, it would be nice to know, as that might motivate a new group of engineers to throw their hats into the ring.

If anyone here is working on the problem, let us know, as I'm sure I'm not the only one wondering if the effort is still underway.

Thanks much!!

MKBv5 will come soon so why find the MKBv4 key?

[Turtleggjp]

Could a MKBv5 Processing Key be used on MKBv4 discs? If so, that means that a media key unlockable by the MKBv5 Processing key has been on all discs since the beginning, and the AACS LA is slowly depleting their fairly limited supply of Processing Keys (not sure how many copies of the media key are on each disc, but I don't think it's more than a hundred or so). If they are just replacing the media key encrypted by the MKBv4 processing key with one encrypted by a MKBv5 processing key, then they should have lots more keys still available (millions?), but then that means that software players like PowerDVD will have to hang onto all of their old revoked device keys in order to play back earlier titles. I'm no expert on this AACS stuff, so maybe someone who is could comment further.

[SamuriHL]

MKB v5 will be able to decrypt all titles previous.

http://en.wikipedia.org/wiki/Advanced_Access_Content_System

That should shed some light on the situation.

[gioowe]

Could a MKBv5 Processing Key be used on MKBv4 discs? If so, that means that a media key unlockable by the MKBv5 Processing key has been on all discs since the beginning, and the AACS LA is slowly depleting their fairly limited supply of Processing Keys (not sure how many copies of the media key are on each disc, but I don't think it's more than a hundred or so). If they are just replacing the media key encrypted by the MKBv4 processing key with one encrypted by a MKBv5 processing key, then they should have lots more keys still available (millions?), but then that means that software players like PowerDVD will have to hang onto all of their old revoked device keys in order to play back earlier titles. I'm no expert on this AACS stuff, so maybe someone who is could comment further.

No. Only a (non-revoked) device key can. MKBv4 could also have multiple processing keys. If you have a valid MKBv5 device key it can open MKBv4 but doesn't have to. It is possible that AACS uses 5 device keys to open 1/5 each of all MKBv5 discs and additional device keys to open MKBv4.

It is currently not known if Slysoft has a processing key/device key -or- if they simply use code-injection to "force" PowerDVD to return the VUK. The latest AnyDVD does only contain the processing keys of MKBv1/v3 and a bunch of VUKs for MKBv4.

[bcrabl]

-or- if they simply use code-injection to "force" PowerDVD to return the VUK

This is certainly not happening. They have a key (processing or device), but they use the oraclle approach.

[Turtleggjp]

So let's say you are a software player with MKBv4 device keys (like PowerDVD). If you are asked to play a MKBv1 disc, do your MKBv4 device keys allow you to do this, or do you need to hang on to your old MKBv1 device keys as well? That will help to answer this guy's question:

MKBv5 will come soon so why find the MKBv4 key?

Finding the MKBv4 key(s) will still be needed to decrypt MKBv4 discs, unless MKBv5 key(s) can do it as well.

[FoxDisc]

So let's say you are a software player with MKBv4 device keys (like PowerDVD).

This is an odd way to write this question and it may confuse some people. There aren't really any MKB v.anything device keys. A set of device keys defines the player ID. If you know the keys, you know the player ID and vice-versa.

An MKB is a bunch of encrypted copies of the same media key. A different encryption key (processing key) is used for each encrypted copy of the media key, Each encryption key corresponds to a group of players. Every player in a group can figure out the processing key for his group from his device keys, but can't figure out any of the other processing keys for groups (subset difference sets) that he is not a member of.

MKBv1 had a big group (S-D set) that included all possible software players (and other groups for hardware standalone players). MKB v2-v5 have multiple smaller groups for the software players. All the non-revoked players are in one of the S-D sets for MKBv5 and all other MKBs down to MKBv1.

When you refer to MKBv5 device keys I understand that you mean device keys that can decrypt v5, but they can also decrypt v1-v4 and may decrypt v6 depending on if they get revoked later or not.

If you are asked to play a MKBv1 disc, do your MKBv4 device keys allow you to do this, or do you need to hang on to your old MKBv1 device keys as well?

Device keys don't change. If the player wasn't revoked, it can decrypt v5 to v1 with its DKs.

[SamuriHL]

@FoxDisc

That was a great explanation. Thanks! :)

[deakorn]

Fantastic.Four.Rise.Of.The.Silver.Surfer.720p.BluRay.x264-REFiNED is rlsed now and it is a BD+ title i know for a fact... so someone has cracked it.

[Shinigami-Sama]

Fantastic.Four.Rise.Of.The.Silver.Surfer.720p.BluRay.x264-REFiNED is rlsed now and it is a BD+ title i know for a fact... so someone has cracked it.

it wouldn't surprise me if someone just piped it through the player's RCA into an RCA in card:rolleyes:

[deakorn]

No sample is outstanding quality!

[bcrabl]

Warez here. Thats bad. Anyways its not from BD, but from an unreleased HD DVD (it has German hardcoded locations inside).

[ilhyfe]

Warez here. Thats bad. Anyways its not from BD, but from an unreleased HD DVD (it has German hardcoded locations inside).

The German HDDVD has some other copy protections, its not "encodable" atm, I tried it 2 days ago...

[bcrabl]

The German HDDVD has some other copy protections, its not "encodable" atm, I tried it 2 days ago...

Did you use anydvdHD?

What I am saying is a certainty. It is from the german HD DVD since it has the HD DVD intro

http://www.amazon.de/Fantastic-Four-Rise-Silver-Surfer/dp/B000VWP2GE/ref=pd_bxgy_d_img_b/302-2734829-0012829

[SamuriHL]

That's not going to make the HD DVD crowd happy. sigh.

[FoxDisc]

Could a MKBv5 Processing Key be used on MKBv4 discs?

A PK matches a specific group of players. (That group is called a subset-difference set of players.) MKBv1 had only one huge group (only one group of all released software players, there were 511 other groups, probably for non-software players) MKBv4 had multiple groups of players. Some groups were huge and matched player IDs that would be released in the future. Some groups were tiny, of only one or two software players.

I haven't looked at MKBv5, but I've looked at earlier MKBs and I'd be willing to bet that some of the defined groups in v5 are identical to those in v4, while others were deleted or split up into smaller groups for revocation.

Bottom line is that some PKs that work on v5 would probably work on v4. Any group of players defined in v4 that had no members revoked in v5 would have a corresponding PK that worked on both.

If so, that means that a media key unlockable by the MKBv5 Processing key has been on all discs since the beginning,

No. No v5 PKs would work on a v1 MKB. PKs match a specific group. The only defined group of software players on v1 was the original 09 F9 PK found by arnezami. That PK is no longer in use. (BTW, I'm only referring to software players that do not use the KCD. There are lots of unchanged groups for hardware players on v1 that match v5 groups)

and the AACS LA is slowly depleting their fairly limited supply of Processing Keys (not sure how many copies of the media key are on each disc, but I don't think it's more than a hundred or so).

The supply of PKs is nearly inexhaustable (billions) -one for each possible S-D set of players. There were only 512 on the original MKBv1 and they've only added a dozen or so. IIRC, they have to add about 1.28 keys to an MKB for each randomly revoked player.

"Inquiring minds want to know"

[ilhyfe]

Did you use anydvdHD?

What I am saying is a certainty. It is from the german HD DVD since it has the HD DVD intro

http://www.amazon.de/Fantastic-Four-Rise-Silver-Surfer/dp/B000VWP2GE/ref=pd_bxgy_d_img_b/302-2734829-0012829

Of course I did :). Well the german BluRay worked fine, no BD+ here on it...

[Turtleggjp]

This is an odd way to write this question and it may confuse some people.

Yeah, what I guess I meant to say was a software player with device keys capable of decrypting MKBv4. When PowerDVD was given a new set of device keys, those keys will be able to calculate all needed Processing Keys so far. And it will have instructions (from the MKB it sees) for which Processing Key it will need to calculate. Now with several different MKBs, we are starting to see the higher value of these device keys over the usual Processing Keys we have been looking for already.

Now the question is: with every revocation, does PowerDVD get a completely new set of device keys? If so, it would be a lot of work to find all the device keys, only to have them all revoked in 3 months. I would assume that the AACS LA would decide that the player to be revoked has been completely compromised, so they would make it so that none of that players device keys could be used for newer MKBs.

So to answer my last question from my last post, a MKBv5 Processing Key will not decrypt MKBv4 titles. Therefore, in order to do this, we will need to still find the MKBv4 Processing Key (if there is just one like before, is there?), or else find a lot of device keys from a player capable of decrypting MKBv5.

[LoRd_MuldeR]

As far as I understand a player has a Device Key. From it's Device Key it can derive a number of Processing Keys. Each player has a different Device Key and thus can derive a different set of Processing Keys. The Processing Keys are used/required to decrypt the MKB found on the disc in order to get the Title Keys. To decrypt the MKB on a specific disc, you need to derive a suitable Processing Key from your Device Key. If you can't do that, you can't play the disc! In case a certain player get's revoked, they make sure it cannot decrypt the MKB's found on new discs. The MKB's on the new discs will simply require one of the Processing Keys that the revoked player cannot derive form it's Device Key. So the revoked player is left out from new discs! Players that have not been revoked will still be able to derive the required Processing Keys from their individual Device Key (for the new discs as well as for the old ones). Only the revoked player will need a fresh Device Key. Also I think a player that can derive the Processing Keys for MKBv5 discs from it's Device Key will also be able to derive the Processing Keys for older MKBv4 discs form the very same Device Key. Please correct me, if I'm wrong...

[gioowe]

Almost ;)

One Device Key -> Its Processing Key
MKB tells software which device key is must use. The software has many device keys.

Processing Key -> Media Key
Media Key + Volume ID -> Volume Unique Key
Volume Unique Key -> Title Keys

The MKB is not encrypted. It only contains encrypted media keys and a "map" for the software to determine which device key to use and how to use to calculate the required processing key.

[LoRd_MuldeR]

Okay, thanks :)

But the basic idea still is: There is a number of Processing Keys that a player can derive from its Device Keys. At the same time there is a great number of Processing Keys the player can not derive, because it is missing a suitable Device Key to derive those Processing Keys from. Since each player has different set of Device Keys, the set of Processing Keys a player can derive (or can not derive) also differs for each player.

If a player gets revoked, they make sure the revoked player cannot decrypt any new discs. So on the new discs only Processing Keys will be used, which the revoked player cannot derive from it's Device Keys. The "map" found in the MKB will simply be useless for the revoked player, because it is lacking the required Device Key to start the calculation with. So it cannot derive the required Processing Key and thus won't be able to decrypt the Media Key. Without the Media Key, no Volume Unique Key and no Title Keys... But all the other players will still be able to calculate the Processing Key for the new discs as usual, because their Device Keys have not been revoked. If that wouldn't be the case, then all players in existence would need to get new Device Keys via Software/Firmware update every time one single player is revoked. That obviously isn't the case...

[gioowe]

Correct.

But a software/player has many device keys and not all are used so you don't need to update all players if one device key is revoked. These device key sets are not random, a certain "pattern" (subset) makes it possible to only revoke a single player and let all others "alive". And that's the trick.

[LoRd_MuldeR]

Correct.

But a software/player has many device keys and not all are used so you don't need to update all players if one device key is revoked. These device key sets are not random, a certain "pattern" (subset) makes it possible to only revoke a single player and let all others "alive". And that's the trick.

That's what I tried to say :)

So back to the previous question: With MKBv5 some players will be revoked. The revoked players are able to derive the Processing Keys for MKBv4 discs form their Device Keys, but they will not able to derive the Processing Keys for MKBv5 discs from their Device Keys. Hence the revoked players are left out from all new discs.

All the players that have not been revoked, will be able to derive the Processing Keys for MKBv4 discs and MKBv5 discs from their Device Keys. They neither need to get new Device Keys for MKBv5 nor do they have to keep separate Device Keys for MKBv4 backward-compatibility. They simply keep on using their current set of Device Keys as if nothing had happened.

Only the revoked players need to get new set of Device Keys via Software/Firmware update in order to be able to play the new discs...

[Turtleggjp]

I think everyone got caught up in the excitement of a single key that unlocks all the current discs. Most people think of the Processing Key as the main thing to find, and so far for MKBs 1 & 3, this was the case. People forget that liscensed players are not given a Processing Key, they are given several Device Keys, and from there they calculate whatever Processing Key is needed (if they can). As was said in the Understanding AACS thread, it could be that a different Processing Key is required for every disc within a MKB revision, since there are so many different ones that can be calculated from the same set of device keys. This may finally be the case with MKBv4, which explains why no one but Slysoft has broken MKBv4 yet.

[LoRd_MuldeR]

As far as I understand: In order to "break" a specific MKBvX, you will need to obtain the complete set of Device Keys from a player that is not revoked in MKBvX. This way you will be able to derive all the Processing Keys (from the Device Keys you have) that might be required for a MKBvX disc. Getting only a few Processing Keys doesn't help at all, because even within the same MKB version you might require Processing Keys you don't have yet. If you happen to get the Device Keys, you can derive all Processing Keys of MKBvX, so you can decrypt all the MKBvX discs (no matter which one of the Processing Key the individual discs requires). But even then you are not save, because you can be sure that they will revoke the player from which your Device Keys were leaked! So in the next MKB version after MKBvX you will suddenly require Processing Keys you can not derive from any of the leaked Device Keys! Once again you will need to obtain a complete set of Device Keys from a player that was not revoked in the latest MKB version. And in the case you manage to do this again (which I wouldn't rely on), you can be sure which player is revoked next. There will be no permanent hack...

[Turtleggjp]

That is why I gave Slysoft my money, so that they could wage this cat and mouse war for me. I can only hope that they keep their promise of free updates, and don't get bought out by the AACS LA.

[Inventive Software]

Am I gonna have to find out how this bloody chain of events works between the physical disc and actually giving you a physical image output? All this talk of keys is going over my head. It was easier with the first generation..... :D

[gioowe]

I think everyone got caught up in the excitement of a single key that unlocks all the current discs. Most people think of the Processing Key as the main thing to find, and so far for MKBs 1 & 3, this was the case. People forget that liscensed players are not given a Processing Key, they are given several Device Keys, and from there they calculate whatever Processing Key is needed (if they can). As was said in the Understanding AACS thread, it could be that a different Processing Key is required for every disc within a MKB revision, since there are so many different ones that can be calculated from the same set of device keys. This may finally be the case with MKBv4, which explains why no one but Slysoft has broken MKBv4 yet.

MKBv4 still uses only 1 processing key. I checked all MKBv4 files that I could get and all use the same paths to calculate the processing key. There might be 2 different ones out there but I haven't found any.

It would also be a waste of space in the MKB tree and it doesn't make the system more secure. If you cracked one disc (to be more precise: if you crack the software) you can get the "current" device key or processing key. The only difference is that if you have to make the device key public, the AACS knows its origin. The processing key is "anonymous". And as long as they revoke all device keys with each MKB iteration it doesn't matter.

I currently even doubt that a device key was ever published. Our "known" device key D6767EE013AC19D42233CBF26A631B-- is actually not a device key. Its preceded by (L) 53BDABEB701A7009B15A7048CE7DDE-- and that's actually a device key that PowerVDV used to use.

(calculate all 256 possibilities to confirm)

[LoRd_MuldeR]

Am I gonna have to find out how this bloody chain of events works between the physical disc and actually giving you a physical image output? All this talk of keys is going over my head. It was easier with the first generation..... :D

Security through Obscurity :rolleyes:

[Turtleggjp]

Am I gonna have to find out how this bloody chain of events works between the physical disc and actually giving you a physical image output? All this talk of keys is going over my head. It was easier with the first generation..... :D

The sticky thread about understanding AACS has a lot of information about how this whole Device/Processing Key thing works. I'd suggest you give that another read if you haven't already.

MKBv4 still uses only 1 processing key. I checked all MKBv4 files that I could get and all use the same paths to calculate the processing key. There might be 2 different ones out there but I haven't found any.

It would also be a waste of space in the MKB tree and it doesn't make the system more secure. If you cracked one disc (to be more precise: if you crack the software) you can get the "current" device key or processing key. The only difference is that if you have to make the device key public, the AACS knows its origin. The processing key is "anonymous". And as long as they revoke all device keys with each MKB iteration it doesn't matter.

I currently even doubt that a device key was ever published. Our "known" device key D6767EE013AC19D42233CBF26A631B-- is actually not a device key. Its preceded by (L) 53BDABEB701A7009B15A7048CE7DDE-- and that's actually a device key that PowerVDV used to use.

It would be more secure if all that was being published was the Processing Keys. It's true though that if a players Device Key(s) were to be discovered, then yes multiple Processing Keys would not help at all.

I thought that a Processing Key did reveal some information about which player used it. Most likely, all the software players will head towards the same Processing Key, but I would think if a Processing Key used by say the PS3 were to be published (assuming it calculates a different one than PC software players) then the AACS LA would go "OMG! Now we need to revoke the PS3 too! This is going to hurt..." However, it could be the case that not only the PS3, but all Sony Blu Ray players calculate the same Processing Key. In which case, it would not reveal specific information about the compromise player, only a general idea of who leaked it. Of course, if every player out there calculates "09 F9..." for a MKBv1 disc, then this key would be completely annonymous.

@gioowe
If you know that all MKBv4 discs show the same path to the same Processing Key, is it also possible to know how many other Processing Keys are being calculated for a particular MKB? By this I mean, how many different paths are described in MKBv4? I'm guessing by now that not all players are being directed to the same Processing Key, am I right?

[LoRd_MuldeR]

I thought that a Processing Key did reveal some information about which player used it. Most likely, all the software players will head towards the same Processing Key, but I would think if a Processing Key used by say the PS3 were to be published (assuming it calculates a different one than PC software players) then the AACS LA would go "OMG! Now we need to revoke the PS3 too! This is going to hurt..." However, it could be the case that not only the PS3, but all Sony Blu Ray players calculate the same Processing Key. In which case, it would not reveal specific information about the compromise player, only a general idea of who leaked it. Of course, if every player out there calculates "09 F9..." for a MKBv1 disc, then this key would be completely annonymous.

As far as I understand the theory, the function used to calculate the Processing Keys from the Device Keys is a "one-way" function. So if you got the Device Keys, you can easily calculate the Processing Keys (of course you can only derive Processing Keys that are reachable from your Device Keys). But if you got a Processing Key, you cannot revert the calculation. So calculating the Device Key from a given Processing Key is impossible! Also the same Processing Key might have been derived form different Device Keys. Nevertheless they know which Device Keys are in use (of course they do). So they don't need to invert anything! In case a certain Processing Key is leaked, they simply check all the Device Keys they have given away so far. Then they make a list of the Device Keys from which the leaked Processing Key could have been derived. Exactly those Device Keys will be revoked and at the same time all players that used them! Obviously this procedure is useless if only one single Processing Key is used for all discs and players. In case that one single Processing Keys is leaked, they would have to revoke all players in existence. To make it work, they will have to use a lot of different Processing Keys! Then the same disc can be decrypted with various Processing Keys. Different players will use different Processing Keys to decrypt the very same disc (each player will use the Processing Key it can derive from it's Device Keys). So if one of the Processing Keys is leaked, they can find out which player leaked it. Or at least they can limit it to a few players. Only those "leaky" players will be revoked. From now on they will only use Processing Keys that the revoked players cannot derive from their Device Keys. And of course they won't use any of the leaked Processing Keys on new discs...

[FoxDisc]

As far as I understand the theory, the function used to calculate the Processing Keys from the Device Keys is a "one-way" function. So if you got the Device Keys, you can easily calculate the Processing Keys (of course you can only derive Processing Keys that are reachable from your Device Keys). But if you got a Processing Key, you cannot revert the calculation. So calculating the Device Key from a given Processing Key is impossible!

This is correct.

Also the same Processing Key might have been derived form different Device Keys.

This is not quite correct -it's close though. A PK matches a subset difference set. An S-D set includes a group of players, and every player in that group must calculate the same PK using the same device key. They can get the device key they require by having it assigned and stored at birth, or by having a higher device key in the binary tree from which they can calculate the lower device key they need using a one way function. An original device key is called a <wait for it> "device key." A lower device key calculated from a higher originally assigned device key is called a "subsidiary device key" Player 1's device key may be Player 2's subsidiary device key. They're really the same.

Nevertheless they know which Device Keys are in use (of course they do). So they don't need to invert anything! In case a certain Processing Key is leaked, they simply check all the Device Keys they have given away so far. Then they make a list of the Device Keys from which the leaked Processing Key could have been derived. Exactly those Device Keys will be revoked and at the same time all players that used them!

Close, but not quite right. All they know from a released PK is the S-D set that it matches. They know every player in that S-D set could calculate that PK. They don't have any more information about who the bad boy was. In the first MKBv1 the set was so large it included all players. Obviously they didn't want to revoke all possible players. They just revoked all the players they suspected. In later MKBs, the S-D sets for actually issued player IDs are tiny - and match only one or two players.

Obviously this procedure is useless if only one single Processing Key is used for all discs and players. In case that one single Processing Keys is leaked, they would have to revoke all players in existence. To make it work, they will have to use a lot of different Processing Keys!

Yes.

Then the same disc can be decrypted with various Processing Keys. Different players will use different Processing Keys to decrypt the very same disc (each player will use the Processing Key it can derive from it's Device Keys).

This is what they are doing now. An MKB has lots of entries for different S-D sets. What they are not doing is using a different MKB on every disk.

So if one of the Processing Keys is leaked, they can find out which player leaked it. Or at least they can limit it to a few players.

Only if the S-D set is small, and has only "a few players" which in recent MKBs is true. The AACSLA has control over the size and player members of the S-D sets defined in an MKB.

Only those "leaky" players will be revoked. From now on they will only use Processing Keys that the revoked players cannot derive from their Device Keys. And of course they won't use any of the leaked Processing Keys on new discs...

Correct. When they revoke a player ID, they just omit from MKBs on future disks any S-D set that contains the revoked players.

[FoxDisc]

a software/player has many device keys and not all are used so you don't need to update all players if one device key is revoked.

Device keys are not actually revoked. Player IDs are revoked. Players have a set of device keys that define the revoked player ID, so you could say that the set of DKs is revoked, but I don't think of it that way.

[LoRd_MuldeR]

Thanks for clarification, FoxDisc. Seems like I'm on the way to understand ^^

[FoxDisc]

When PowerDVD was given a new set of device keys, those keys will be able to calculate all needed Processing Keys so far. And it will have instructions (from the MKB it sees) for which Processing Key it will need to calculate.

Correct

Now with several different MKBs, we are starting to see the higher value of these device keys over the usual Processing Keys we have been looking for already.

Hmmmm, I don't really agree. A set of device keys defines the player ID. A revocation of that player ID means none of the DKs can ever be used. If they could, the revoked player would not be revoked.

Now the question is: with every revocation, does PowerDVD get a completely new set of device keys?

Yes. BTW, you can think of every version of PDVD as a different player, with a different ID.


If so, it would be a lot of work to find all the device keys, only to have them all revoked in 3 months. I would assume that the AACS LA would decide that the player to be revoked has been completely compromised, so they would make it so that none of that players device keys could be used for newer MKBs.

I agree.

So to answer my last question from my last post, a MKBv5 Processing Key will not decrypt MKBv4 titles.

It might, or might not. If it matched an S-D set of players, and none of the players in that set needed to be revoked then they probably would have used it again for v5. Realistically, though, if it was a leaked PK, then it was revoked.

Therefore, in order to do this, we will need to still find the MKBv4 Processing Key (if there is just one like before, is there?), or else find a lot of device keys from a player capable of decrypting MKBv5.

You only need one valid PK used on the v4 MKB to decrypt v4 discs. You only need one DK to calculate the PK, but you need the right one, or you need the correct subsidiary DK.

[FoxDisc]

I think everyone got caught up in the excitement of a single key that unlocks all the current discs. Most people think of the Processing Key as the main thing to find, and so far for MKBs 1 & 3, this was the case.

It's still true (in a sense) that the PK is the thing to find. All you need is one for each MKB version, and there are lots of PKs in each version that would work. Some match large groups of players, and some match small groups, but you only need one. Of course, finding that one is not easy.

People forget that liscensed players are not given a Processing Key, they are given several Device Keys, and from there they calculate whatever Processing Key is needed (if they can).

The difference between a DK and a PK is very slight. Think of the binary tree. It's got DK's assigned to the nodes. If you are a player and are assigned a DK for a node, you can process that DK with a one-way function to get a number that is three times as long as your starting DK. The middle third is the PK. The right third is the subsidiary DK for the node to your right and below your current node. The left third is the DK (more accurately the subsidiary DK) for the node to your left and below.

You just keep on working your way left right down the tree to get the PK you need by choosing the correct subsidiary DK and processing it again through the one way function.

As was said in the Understanding AACS thread, it could be that a different Processing Key is required for every disc within a MKB revision,

If there was a different MKB for every disc, then we'd call them MKB v6, v7, v8, etc. up to v1000 if there were a thousand released discs.

[gioowe]

Device keys are not actually revoked. Player IDs are revoked. Players have a set of device keys that define the revoked player ID, so you could say that the set of DKs is revoked, but I don't think of it that way.

You are correct. But I'm a programmer not a crypto analyzer so I have a very simplified view of the world. :)

Of cause you cannot revoke a device key. A device key is nothing else than a calculated hash from a higher level and always fixed. All the AACS LA does is at some node kick out that value and start with a new one. And that new value is unknown. MKB defines which nodes are correct processing keys and so I have to fall down from by "stolen" device key towards any of these processing keys. If nothing is in my way I got it. If something was kicked out on my way down the path I have a problem. I need another starting point, another device key.

From a programmer's view this is all you need. So a "revoked" device key is a key that cannot find a processing key or fell out of all subsets.

[FoxDisc]

MKBv4 still uses only 1 processing key. I checked all MKBv4 files that I could get and all use the same paths to calculate the processing key. There might be 2 different ones out there but I haven't found any.

Thanks for this info. As you know, there's nothing secret about which devices are revoked. You can directly figure that out by reading an MKB.

It would also be a waste of space in the MKB tree and it doesn't make the system more secure. If you cracked one disc (to be more precise: if you crack the software) you can get the "current" device key or processing key. The only difference is that if you have to make the device key public, the AACS knows its origin. The processing key is "anonymous". And as long as they revoke all device keys with each MKB iteration it doesn't matter.

A single DK is just as anonymous as a PK - no more, no less. It matches an S-D set, just like the PK does. (Run the DK through the one-way fn and it gives you the PK for that set.) Everyone in that S-D set could calculate the DK or has the DK from the start. No one outside the S-D set can. Of course if the set is tiny, perhaps with only one member, it's not very anonymous :devil:

[FoxDisc]

@gioowe
is it also possible to know how many other Processing Keys are being calculated for a particular MKB?

Yes, it's very easy. An MKB has multiple copies of the encrypted media key, one for each PK. Just count the entries.

By this I mean, how many different paths are described in MKBv4? I'm guessing by now that not all players are being directed to the same Processing Key, am I right?

You are right. The first MKBv1 had 512 paths, and 512 PKs, but only one for the software players. There are now lots of paths for the various software players - as required to revoke some and leave the others.

[gioowe]

I don't think that 2 players use the same S-D at this time. Would be quite stupid. Even if the S-D as 2-3 levels I think the AACS LA still uses only 1 player in that S-D, the rest are "fillers".

Again, to be more precise: Of cause there are a number of processing keys in MKBv4. Currently 524. The "position" of the processing keys is the same on all discs.

Here's the view of the MKBv4 tree
-------------------------------------------------------------------------------------------------------------------------------------
# | UV | | U-mask (Top->Bottom) | V-mask (Bottom->Top) | Path (from Root) |
-------------------------------------------------------------------------------------------------------------------------------------
001 | 02:00000003 | -- | 11111111111111111111111111111100 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLLLLLLL.. |
002 | 03:0000002A | -- | 11111111111111111111111111111000 | 00000000000000000000000000000011 | LLLLLLLLLLLLLLLLLLLLLLLLLLRLR..* | S
003 | 05:00000028 | -- | 11111111111111111111111111100000 | 00000000000000000000000000001111 | LLLLLLLLLLLLLLLLLLLLLLLLLLR..*** | SC
004 | 03:00000046 | -- | 11111111111111111111111111111000 | 00000000000000000000000000000011 | LLLLLLLLLLLLLLLLLLLLLLLLLRLLL..* | S
005 | 02:00000055 | -- | 11111111111111111111111111111100 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLLRLRLR.. |
006 | 02:0000005B | -- | 11111111111111111111111111111100 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLLRLRRL.. |
007 | 03:00000069 | -- | 11111111111111111111111111111000 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLLRRLR... |
008 | 05:00000068 | -- | 11111111111111111111111111100000 | 00000000000000000000000000001111 | LLLLLLLLLLLLLLLLLLLLLLLLLRR..*** | SC
009 | 03:00000091 | -- | 11111111111111111111111111111000 | 00000000000000000000000000000001 | LLLLLLLLLLLLLLLLLLLLLLLLRLLRL... |
010 | 03:0000009E | -- | 11111111111111111111111111111000 | 00000000000000000000000000000011 | LLLLLLLLLLLLLLLLLLLLLLLLRLLRR..* | S
011 | 05:000000A2 | -- | 11111111111111111111111111100000 | 00000000000000000000000000000011 | LLLLLLLLLLLLLLLLLLLLLLLLRLR....* | S
012 | 07:000000A0 | -- | 11111111111111111111111110000000 | 00000000000000000000000000111111 | LLLLLLLLLLLLLLLLLLLLLLLLR..***** | SC
013 | 17:00000080 | -- | 11111111100000000000000000000000 | 00000000000000000000000011111111 | LLLLLLLLL................******* | SC
014 | 17:00800001 | -- | 11111111100000000000000000000000 | 00000000000000000000000000000001 | LLLLLLLLR....................... |
...
525 | C0:00000000 | RR | 11111111111111111111111111111111
526 | 80:00000000 | R- | 11111111111111111111111111111111
-------------------------------------------------------------------------------------------------------------------------------------
Flags: S = stops before floor (complete revocation) SC = continues again below stop node (partial revocation)

[FoxDisc]

As far as I understand: In order to "break" a specific MKBvX, you will need to obtain the complete set of Device Keys from a player that is not revoked in MKBvX.

No, you only need one DK, but it has to be the right one.

This way you will be able to derive all the Processing Keys (from the Device Keys you have) that might be required for a MKBvX disc.

Only one PK is needed.

Getting only a few Processing Keys doesn't help at all, because even within the same MKB version you might require Processing Keys you don't have yet.

Any valid PK will decrypt the media key in that MKB. The MKB is just lots of copies of the media key encrypted by different PKs.

If you happen to get the Device Keys, you can derive all Processing Keys of MKBvX, so you can decrypt all the MKBvX discs (no matter which one of the Processing Key the individual discs requires).

A version number for an MKB tells you what S-D sets are defined on that MKB. It tells you what PKs/DKs are needed. Any single player ID will be in only one S-D set and be able to calc only one useful PK from a single one of his DKs.

you can be sure that they will revoke the player from which your Device Keys were leaked!

Yes they will.

So in the next MKB version after MKBvX you will suddenly require Processing Keys you can not derive from any of the leaked Device Keys!

Yes.

Once again you will need to obtain a complete set of Device Keys from a player that was not revoked in the latest MKB version.

You'd only need one, but it would have to be a new one. None of the old ones would work.

There will be no permanent hack...

This is the reason I responded here (sorry if my multiple posts seem excessive, I don't get here that often, and I'm particularly interested in this area). I can see two ways to get the permanent hack, but neither seems likely. First you could break the encryption. Anyone for a quantum computer? (This is very unlikely.)

Second, someone could leak the secret AACS master keys. There could even be a single secret master key, from which all other DKs, PKs, etc. could be derived. Again, this is unlikely, but it's at least interesting to contemplate.

[gioowe]

The AACS master key doesn't help. Can be "revoked" too.

[FoxDisc]

I don't think that 2 players use the same S-D at this time. Would be quite stupid. Even if the S-D as 2-3 levels I think the AACS LA still uses only 1 player in that S-D, the rest are "fillers".

I assume you're thinking of software players (i.e., non-KCD players). The S-D sets for the hardware players are huge. There are also many multiple member S-D sets even in the software branch as you can see from your post, but they may be mostly for future player IDs, not yet issued.

[gioowe]

Of cause. The software players are currently the "problem". How many are actually out there?

1) PowerDVD
2) WinDVD (?, quite hard to get from Corel right now)
3) ???

[FoxDisc]

The AACS master key doesn't help. Can be "revoked" too.

No, if there is single master key, it can calculate all issued DKs and all DKs that could be issued. If there isn't a single master key (and I think there isn't) then there are master keys for every node, and from these keys you can calculate all possible DKs present and future for every possible device.

An AACSLA "master key" (a key that is never issued and is only used to create keys that are issued) is the DK for the S-D set comprising all players below a node minus all players below that same node. As you can see that's the null set, so it has no members, so no real players ever get those keys. Nonetheless, the keys do exist. If you process those keys using the one way fn, you get the DKs for the two nodes below it and those keys are issued.

Another way to think of these keys is just the secrets used by AACSLA to create keys they issue. They must have some way to make them. They can't revoke their own secrets without revoking the whole system. If they ever leaked, the system would collapse.

[FoxDisc]

Of cause. The software players are currently the "problem". How many are actually out there?

1) PowerDVD
2) WinDVD (?, quite hard to get from Corel right now)
3) ???

I heard there was another one from Japan a month or so ago, but I haven't heard much about it. From the point of view of the MKB/AACS system, each version of PDVD/WDVD is a different player, but each copy of that version is the same player. The hardware players are different. Each player has a unique ID, even if it's the same model number from the same manufacturer, it gets a unique ID.

[gioowe]

I have some kind of thinking problem with this. I assumed that each S-D set starts with a new (randomly generated) key.

Our 9F-Key is M of level 32. We got the sub device keys of level 32 (AA 85 ...), 31 (CC BF ...), 30 (6A 5A ...), 29 (BD 2B ...), 28 (D6 76 ...) and the device key (53 BD ...) at level 27. From there we can calculate all 3^5 keys = 243. MKBv3 redefines subset of level 28 (05:0000001C) and that key changed! I could recalculate it from level 27 and actually both L und R sub-device keys are rewritten. So the tree changes with every MKB iteration beginning with each new S-D start.

Or am I missing something?

[gioowe]

got visual aid...

http://img248.imageshack.us/img248/4163/visualaidic0.png

[FoxDisc]

I have some kind of thinking problem with this. I assumed that each S-D set starts with a new (randomly generated) key.

They can't start all possible S-D sets with a randomly generated key (it would be a randomly generated DK). First, there are too many possible S-D sets. Second, you need the upper level DK, which matches an upper level S-D to produce the lower level subsidiary DKs (which match lower level S-D sets= same u-node number, but lower v-node) through the one way function.

You might be thinking that they could only generate the two highest level pair of uv defined S-D sets randomly for each u-defined node (and two v-nodes just below u-node).

Yes, they could do that, but why bother holding twice as many random numbers, when they can generate a single random number just above those two and use the one-way function to produce those two.

They could even have single random number for the root, use the one way for all u-nodes below that, but If I was the AACSLA, that would be too scary. If one number leaked the entire system would crash. By assigning a random number to each node, gigabytes of random numbers would have to leak to bring the whole system down.

the tree changes with every MKB iteration beginning with each new S-D start.

Or am I missing something?

I'm almost out of time, but I'll try a quick response, see if it helps. If not, we can try again. S-D set is a Subset Difference set. I think of the S-node as defining a subset of devices below the S-node and the D-node as being always below the S-node and defining a set of players below the D-node.

For clarity, the S-node is the u-node. The D-node is the v-node in AACS specs. The uv number defines the two nodes. The S-D set is all devices below S that are not below D.

A DK matches a single S-D set. If I give you S-node, I must also give you the D-node for the DK. Every possible S-node has a different AACS master key, that is never released. If you have it you could calc the two DKs for the two S-D sets that have that S node and the two D nodes one below it. No single device ever gets those two DKs. Every starting S-node produces a different set of related S-D sets though the one way fn, but different starting S-nodes produce DKs that have no relation to one another. Each S-node is on one of arnezami's "parking garage floors."

More later ......

[Peer van Heuen]

They could even have single random number for the root, use the one way for all u-nodes below that, but If I was the AACSLA, that would be too scary. If one number leaked the entire system would crash. By assigning a random number to each node, gigabytes of random numbers would have to leak to bring the whole system down.


They might be generating random roots - and if so, they will do that "on-demand", whenever a new root is required.
But I do think they would probably derive the keys by some one-way function (maybe AES-G3, maybe some other function).
After all: if both the one master key and the ("secret") one-way function leak, they can still change the strategy for the next round. So the whole system is not really down that way.
After all it does have some elegance if you can describe all possible root keys with one key and a well defined function - as opposed to storing them all in a huge DB.
But then again - we don't really care, how they do that, right?

The AACS master key doesn't help. Can be "revoked" too.

Could actually - but this would require an update of all players. This includes standalones, PS3, Xbox, .... I say again: all players.

Also, unless my imagination doesn't get the whole picture, all players would have to implement algorithms to cope with old and new device key sets (e.g. require 2 sets of device keys from then on).

That would result in quite a stir :-)

[gioowe]

S-D set (defined by MKB) is clear. How a device key is "revoked" (better removed from all S-D sets) too.

What I not quite understand is why they define new S-D sets below another S-D set. For instance in MKBv3.

[Turtleggjp]

Wow, this thread exploded...

Quick clarification on how the whole "driving" proceedure works. If I understand it correctly, each player starts with its 128-bit device key (one of many it has), and does the magic AES algorithm (publicly known, no mystery here) and what comes out is a 384-bit result (3x as large). From here, you either:

A. Select the first 128-bits and repeat.
B. Select the last 128-bits and repeat.
C. Select the middle 128-bits as your processing key and you are done.

Did I get that right? Is that all it takes to start the process? It sounded like something else was needed to start (like a "floor number" in the "parking garage").

[gioowe]

No.

static byte[] CalculateSubDeviceProcessingKey(byte[] DeviceKey, byte LeftMiddleRight)
{
byte[] Seed = { 0x7B, 0x10, 0x3C, 0x5D, 0xCB, 0x08, 0xC4, 0xE5, 0x1A, 0x27, 0xB0, 0x17, 0x99, 0x05, 0x3B, (byte) (0xD9 + LeftMiddleRight) };

byte[] SubDeviceProcessingKey = Utility.AACS_AES128(DeviceKey, Seed);

for (int I = 0 ; I < 16 ; ++I)
{
SubDeviceProcessingKey[I] ^= Seed[I];
}

return SubDeviceProcessingKey;
}

byte[] AACS_AES128(byte[] Key, byte[] Data);

[Turtleggjp]

Ok, I think I get that now. It's always fun trying to re-learn how to read C++ again. :rolleyes:

So then how does the whole "Parking Garage Floor Number" part come into play?

[FoxDisc]

They might be generating random roots - and if so, they will do that "on-demand", whenever a new root is required.

I got no sleep last night, so it's probably a mistake to disagree with Peer, but (at least for the hardware players) they've already issued full sets of Device Keys that would have to be generated from secret random roots. I don't see how they could generate them after they've issued the DKs. For software players, maybe they could revoke all existing players, then make any changes they want to the software branch.

But I do think they would probably derive the keys by some one-way function (maybe AES-G3, maybe some other function).

This is certainly possible. It just struck me as more secure to use a large database of random numbers.

After all: if both the one master key and the ("secret") one-way function leak, they can still change the strategy for the next round.

I don't follow this (actually, I'm just politely saying I don't agree). I see several possible ways they could have done this.

The most elegant way is to use a single secret master key at the root of the binary tree. Using the one way function nine times (2^9) gives you the secret key at the top of each one of the original 512 subtrees in the original MKBv1. Only one of those subtrees is the software branch.

Second option is to choose 512 secret random unrelated keys, one for the top of each of those branches. Last option is to choose a secret random number for every possible S-node.

I don't see any way to change the secret key at the root of any subtree without changing previously assigned DKs for devices in that subtree. And if you change DKs, you've got problems for previouisly issued discs and MKBs. .

[re revoking secret master key at root of entire system] this would require an update of all players. This includes standalones, PS3, Xbox, .... I say again: all players.

Also, unless my imagination doesn't get the whole picture, all players would have to implement algorithms to cope with old and new device key sets (e.g. require 2 sets of device keys from then on).

That would result in quite a stir :-)

Yes, I agree. This would basically require restarting the whole system from scratch, with some mechanism for dealing with the discs issued with MKBs under the old system.

[FoxDisc]

S-D set (defined by MKB) is clear. How a device key is "revoked" (better removed from all S-D sets) too.

What I not quite understand is why they define new S-D sets below another S-D set. For instance in MKBv3.

They don't. Each different S-node is on a whole separate plane (or parking garage floor per arnezami). The S-node defines the root for a subtree containing DKs and PKs for that S-node. All the DKs and PKs for any given S-node are related, but are unrelated to the keys for any different S-node.
Any other S-node defines an entirely different and independent subtree. In arnezami's analogy, an S-node (u-node in AACS terminology) defines a separate parking garage floor.

DKs (and subsidiary DKs that you can calculate) are assigned to the D-node on the parking garage floor (subtree) defined by the S-node. Each node has multiple DKs (every time it's a D-node), but defines only one subtree/parking garage floor.

I think of it this way - The AACSLA has a secret key (either secretly generated or randomly selected) for each S-node. Take an S-node S1. From the secret key for S1, they can generate all DKs for all possible S1-D sets, i.e., all sets rooted at S1 having a difference set D below S1. If you are a device below S1, you will get some of these DKs (you get one DK for every branch off the upward path from you to S1). If you are not below S1, you get none of those DKs.

(From the above comments, you can derive the number of DKs that each player starts with.)

To revoke a device in a new MKB, you make sure he's not below any S-nodes in the S-D sets of your new MKB or if he is, you make sure he's also below the D-node.

[FoxDisc]

Wow, this thread exploded...

Quick clarification on how the whole "driving" proceedure works. If I understand it correctly, each player starts with its 128-bit device key (one of many it has), and does the magic AES algorithm (publicly known, no mystery here) and what comes out is a 384-bit result (3x as large). From here, you either:

A. Select the first 128-bits and repeat.
B. Select the last 128-bits and repeat.
C. Select the middle 128-bits as your processing key and you are done.

Did I get that right? Is that all it takes to start the process? It sounded like something else was needed to start (like a "floor number" in the "parking garage").

Well gioowe said no, but I'd say yes -that's basically right, with lots of details and add'l complexity. You later asked about the "parking garage floor." That's the same thing as the S-node (u node in AACS-speak) That comes in when you choose the correct starting DK.

The MKB defines lots of S-D sets (and has one encrypted copy of the media key for each set.) You have to find the set you are in. It's the one where you are below the S-node, but not below the D-node (v-node in AACS-speak).

The S-node defines the parking garage floor. The higher the S-node, the larger the floor. Each device has one DK for each level on every floor that it has access to. (It has access to a floor if it is below the S-node) So for the largest floor (like in MKBv1) there are 22 DKs (out of the 253 it started with) to consider. (A DK is assigned to a D-node on an S-floor.)

The device just looks at each S1-D1 set defined in the MKB. It asks if it is below S1, if yes, it asks if it is below D1. If no, then it knows it has the required DK, either originally assigned (it's located at D1 on the S1-floor) or it can calculate it from a DK on floor S1 that is above D1.

If it has to calc the DK, it uses the basic ABC procedure you gave above to come up with the DK for S1-D1, then uses the ABC procedure again to get the PK it needs.

edit: I hope the terms "level" and "higher" when referring to a the nodes of a single binary subtree on a single floor aren't too confusing in the context of the parking garage floor analogy where floors (and therefore different subtrees) can also be thought of as being higher or lower. You should be able to figure them out from the context. Usually the floor you are dealing with is defined early on by the S-node.

[Peer van Heuen]

I don't follow this (actually, I'm just politely saying I don't agree). I see several possible ways they could have done this.


Yeah, sorry, you're right - I had my mind on the wrong end of AACS there for a moment.
I was assuming that the root keys would not need entirely be "in use", but that's nonsense, of course. :-)

[Zotty]

Almost another 2 months have passed, so any news on this front? As more and more MKB v4 discs come out, more and more discs remain unplayable.