New Processing Key found!! (MKB v3 is now open)

[Revgen]

Originally Posted by arnezami

KenD00 and I are working on a combined program of DumpHD and aacskeys (basicly having the latter being accessed as a backup in case a VUK is not found in the local database and as a source of newly found vuks). Prototype is working

Gimme! Gimme! Gimme!

Thanks a lot to both of you for the work you do.

[abcx]

Awesome! The fight against AACS continues. I'm proud of you guys!

[atzplzw]

Hehe! That took quite a while until someone noticed...

[Galileo2000]

OK, what am I doing wrong?

- put a new key into txt file ProcessingDeviceKeysSimple.txt as the only entry w/o spaces;
- started vid.exe and got the correct VID from Matrix 3;
- started aacskeys with the drive letter and VID from vid.exe in the command line.

No matter what I am getting "Error opening Media Key file f:\AACS\MKBROM.AACS".

I am using aacskeys.exe 2.6. And yes, I enter the correct VID in the command line, I am pretty sure.


Totally drives me nuts.

Suggestions are welcome, thanks.

[arnezami]

Originally Posted by Galileo2000

OK, what am I doing wrong?

- put a new key into txt file ProcessingDeviceKeysSimple as the only entry w/o spaces;
- started vid.exe and got the correct VID from Matrix 3;
- started aacskeys with the drive letter and VID from vid.exe in the command line.

No matter what I am getting "Error opening Media Key file f:\AACS\MKBROM.AACS".

Totally drives me nuts.

Suggestions are welcome, thanks.

Looks like some file access problem (maybe opened by anothe program? anydvd running?). aacskeys version? What happens if you copy the AACS directory into the root of one of your HDDs. So something like C:\AACS\MKBROM.AACS. And then use c as drive letter (don't forget the v for verbose and the vid of course).

arnezami

[Galileo2000]

Originally Posted by arnezami

Looks like some file access problem (maybe opened by anothe program? anydvd running?). aacskeys version? What happens if you copy the AACS directory into the root of one of your HDDs. So something like C:\AACS\MKBROM.AACS. And then use c as drive letter (don't forget the v for verbose and the vid of course).

arnezami

Thanks a lot arnezami.

I did it on the new, pretty fresh system I've assembled not too long ago and Toshiba UDF 2.5 drivers weren't installed.

Installed drivers, rebooted, everything works like a charm now

[mlansell]

Am I missing something? My version of aacskeys spits out the VUK without me needing to find the VID myself.

Does the new version not do this anymore?

[mlansell]

Originally Posted by FoxDisc

there's just no benefit to having two or more PKs released and two or more exploits closed on every round.

Or they could just not release their key and the danger of two being "out there" and revoked together doesn't even come up.

I really don't see how them releasing their key helps them in any way, and seeing as theirs is a comercial operation, it's not reasonable to expect them to release keys just to be nice to us.

Mal

[Galileo2000]

Originally Posted by mlansell

Am I missing something? My version of aacskeys spits out the VUK without me needing to find the VID myself.



Does the new version not do this anymore?

You need to use verbose mode, and then you don't need VID (on my machine).

With normal mode or w/o parameter on my machine (XP SP2) I am getting exception trying to run it with "n" parameter or without any parameters, with or without VID in the command line.

Arnezami, let me know if you want more details, but IMHO this exception error does not matter at the moment.

[FoxDisc]

Originally Posted by mlansell

Or they could just not release their key and the danger of two being "out there" and revoked together doesn't even come up.

They can't "just not release their key." When they release their software, the LA immediately knows what key Slysoft has found. and they'll revoke it on the next round. The LA already knows the key - all they have to do is see which of the C-records AnyDVD accesses. It takes them ten minutes of work. Nothing Slysoft does can hide it.

I really don't see how them releasing their key helps them in any way,

Then you didn't read/understand my post.

and seeing as theirs is a comercial operation, it's not reasonable to expect them to release keys just to be nice to us.
Mal

It's not "just to be nice to us" - it's in their own best interest. They lose two possible exploits instead of a single one if they don't. They may lose one of their own backup keys if they don't.

[zacox]

Not to beat a dead horse or anything, but how many cycles of revoking and releasing new keys will we go through before AACS is deemed as insecure and not worth fixing as CSS?

My guess the upper limit is 340,282,366,920,938,463,463,374,607,431,768,211,456 cycles, but hopefully one or two more before the AACS LS decides it's not really effective protection.

[arnezami]

Originally Posted by mlansell

Am I missing something? My version of aacskeys spits out the VUK without me needing to find the VID myself.

Does the new version not do this anymore?

aacskeys works fine on older discs. No need for volume id inputting. My instructions about inputting the volume id is only if aacskeys itself cannot get the volume id using its Host Private Key (people who have inserted a new disc in their drive at some point have this key being revoked by their drive: the drive won't talk to aacskeys anymore when it comes to the volume id). As I said only if the VID is all 00's do you have to find the VID yourself first and then input it.

Verbose mode itself is not important: but you need to choose a mode: n, v or s when inputting the VID.

arnezami

[arnezami]

Originally Posted by FoxDisc

This is a side note to Slysoft, who I expect monitors this forum. It's in the interest of Slysoft to disclose the Processing Key they have uncovered as soon as they release their software.

If Slysoft does not release the PK they are using, someone here will sooner or later uncover and release a PK. Notice how quickly BtCB had this PK. He published it on release day +1, and may have had it before then. If BtCBs PK is the same one that Slysoft is using in AnyDVD, there's no harm, but what if they are different? If there are two holes, both will get plugged in the next round of cat vs. mouse (IMHO, the LA looks like the poor mouse right now.) It would be better for Slysoft not to have both holes plugged. They may even have found the same PK released here, but used another one and by not publicly disclosing the one they use in their software, they lose this PK as a backup for the next round.

I'd also like to point out that it's in the best interest of fair use lovers here for Slysoft to copy and use any PK released here, if it's released before Slysoft releases their own software, and for any PK released by Slysoft to be used in software released here. No one should complain about such behaviour from Slysoft or open source software authors - for the same reason - there's just no benefit to having two or more PKs released and two or more exploits closed on every round.

My .02

You are right that it would be in the best interest of us and Slysoft if they (in the future) would use an already Processing Key if that key has been released before their own product (with their new key) has not yet been released.

The same is true for us: if they release their key (ehm program) we should use that one. We shoud find one on our own but use theirs. But since it is not known which key they are using its simlply a guess: its possible we find a different Processing Key then they have which (if posting that one) would be a waste: two players instead of one player would be instructed to harden their product.

In order to make sure we release the same key either Slysoft has to tell someone (privately) over here from where they got their key (they wouldn't have to give it away) or we have to ask SlySoft privately whether our to be released key is the same as theirs or we have to figure it out ourselves. Which would take extra time. This would indeed benefit both us and them. To prevent multiple keys from being out there.

On the other hand: the ACCS LA pretty much revoked all players this time so they may do this the next time aswell. But not all players will be ordered to harden themselves so I think this is an important issue. Maybe we should talk with SlySoft about this .

Of course if next time we find the key(s) first this won't be an issue at all .

Regards,

arnezami

PS. A program cannot hide which Device/Processing Key(s) its using. Not from the AACS LA anyway.

[mlansell]

Originally Posted by FoxDisc

They can't "just not release their key." When they release their software, the LA immediately knows what key Slysoft has found. and they'll revoke it on the next round. The LA already knows the key - all they have to do is see which of the C-records AnyDVD accesses. It takes them ten minutes of work. Nothing Slysoft does can hide it.

I don't yet understand how the key stuff works, but couldn't they just access all the C-records, or at least a lot of them, to hide the one they are really using?

It's not "just to be nice to us" - it's in their own best interest. They lose two possible exploits instead of a single one if they don't. They may lose one of their own backup keys if they don't.

But that relies on a random bunch of people unconnected with their operation to not release any other keys they find - do you think that likely? Will people here really not bother to go after other keys, if Slysoft released theirs? We've seen with the latest key that it doesn't stay quiet long when a new one is found...

Mal

[mlansell]

Originally Posted by arnezami

people who have inserted a new disc in their drive at some point have this key being revoked by their drive: the drive won't talk to aacskeys anymore when it comes to the volume id

Thanks for the tip. I think that day is getting closer for me... :-(

[arnezami]

Originally Posted by zacox

Not to beat a dead horse or anything, but how many cycles of revoking and releasing new keys will we go through before AACS is deemed as insecure and not worth fixing as CSS?

There is still quite a bit for them to throw at us: sequence keys, using multiple processing keys, bd+, forced firmware patches. You name it.

It will be interesting what they have to say. What could they say? New version: instantly opened. How do wrap that in a few PR sentences?

arnezami

[oblioman]

Originally Posted by arnezami

There is still quite a bit for them to throw at us: sequence keys, using multiple processing keys, bd+, forced firmware patches. You name it.

It will be interesting what they have to say. What could they say? New version: instantly opened. How do wrap that in a few PR sentences?

arnezami

You don't wrap it in a few sentences. Me been reading your posts for some time and find them most interesting. What me understands is Alice Cooper ( trying to understand frank zappa, but he confuses me),, but to follow yer post's keep's me most intrigued. Learning and listening - Thank you!

[FoxDisc]

Originally Posted by mlansell

I don't yet understand how the key stuff works, but couldn't they just access all the C-records, or at least a lot of them, to hide the one they are really using?

That wouldn't slow them down much. AnyDVD can only decrypt the title with one valid C-record. AACS LA can just keep munging different C-records until AnyDVD fails.

But that relies on a random bunch of people unconnected with their operation to not release any other keys they find - do you think that likely? Will people here really not bother to go after other keys, if Slysoft released theirs? We've seen with the latest key that it doesn't stay quiet long when a new one is found...

You are right that there's some temptation to disclose a new PK once it's found, but as long as there's at least one public PK that works, the temptation can be resisted more easily. If it's not released, and not revoked the next round, whoever found it can release it on 0-day of the next MKB revocation and look like a hero.

[bourke]

I think they're factored in a fair few revokations into the costs of maintaining AACS, however it is not this issue that is affecting the effectiveness of AACS. It seems to be the players not being hardened enough (with Bus encryption) etc. I can't see any Windows software player being hardened enough unless the OS blocks access to the program's memory! Maybe Microsoft want WinDVD and PowerDVD to be revoked entirely so that they can sell their own future player as the only one available for Windows LOL!

However hardware players will probably see hypervisor-style hardening soon if players keep being compromised at this rate!

[Johhn]

According to the Freedom to Tinker article entitled "AACS Updated, Broken Again", the main problem currently faced by the LA is the length of time that it takes to blacklist or revoke. Licence terms require player manufacturers are given at least 90 days notice before new disks can be released, and even if that was reduced, manufacturing and distribution times mean a delay cannot be totaly eliminated. Slysoft and others are not constrained by delays like that, and can put their updates out as soon as they are ready.

As regards hardware solutions, it would appear that they are not currently looking at that. If you look at the Movielabs site, where the studios have a joint enterprise making grants for technological developments, they are looking for ways to hide cryptographic keys in software players without needing harware assist, as they put it. See http://www.movielabs.com/Challenge/h...aphickeys.html

Also, they have other problems looming. There are allegations that aacs itself violates cryptographic patents held by Certicom. And although not directly in point, there are also allegations that technology used in Blu-Ray disks violates patents held by Target Technology.