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

[arnezami]

I guess its official now.

The new Processing Key was posted by BtCB on freedom to tinker about a week ago (release day +1).

its:

45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

Save it. Store it.

This opens up all newly released (and many to be released) HD DVD and Blu-ray discs. Wanna understand: go here.

Regards,

arnezami

PS. I strongly advise everybody who knows how it was retrieved not to talk about it publicly.

-- Btw: To get a VUK you first need to get the Volume ID of the disc (there are several ways). If you have that you can use aacskeys with this Volume ID as input. --

[zeroprobe]

damn I need a new jacket.

Who dares to post it on digg lol. Would surely start another riot.

[Zotty]

Nice one, thank you!

Oooh these are the moments I hate going to work. I'd rather stay home and play around with this new 'toy'

[bob0r]

BtCB Says:

May 23rd, 2007 at 4:02 am
Here’s mine:

45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2

What are the odds that this is the new processing key?

...

Priceless

[FoxDisc]

Originally Posted by arnezami

PS. I strongly advise everybody who knows how it was retrieved not to talk about it publicly.

BtCB made it clear where it came from. He used Ed Felten's automatic key assignment proggie on that web page. Wow! It's amazing that he happened to be assigned a valid PK! I wonder what the chances are that it will happen again..... say shortly after the next revocation.

[mixanobios]

i wonder if i can get next week's lotto numbers using the same tool

[zeroprobe]

aacs la must be really unlucky, whats are the odds of that happening lol.

[FoxDisc]

Originally Posted by arnezami

I strongly advise everybody who knows how it was retrieved not to talk about it publicly.

On a more serious note, let's look at what the disclosure of this PK tells the AACS LA about where it came from:

The AACS LA knows the content of the last MKB (can anyone tell me where the "V3" number comes from? Is it built into the MKB?) The last MKB had only 15 S-D sets that matched 15 DKs and 15 PKs (these 15 are in the software branch - there are another 511 non-software branches). Presumably, this PK is one of the 15. Some of the 15 are as small as a single device. One of them is huge (about 2^22), but I strongly suspect that this is not that big set. I'll guess that this PK is one of the other 14, all of which fall within 128 devices. By matching this PK to the MKB released, they narrow the device down, and may have pinpointed it.

Even if the group that matches this PK is not a single device, they may be able to narrow it further. A processing key corresponds to a device key. A device key corresponds to a specific subset difference set, i.e., a specific node on a specific "floor" of the entire tree. The LA knows the matching floor and node numbers. They also know that the matching DK can only be calculated from DKs on this floor that are on the binary tree above this node. Finally they know which DKs have been given out. They may be able to narrow the device down if not all DKs that can calculate this PK have been assigned.

I'd like to know which of these groups match the PK just disclosed. It's something the LA already knows, and it's something that could be calculated with a moderate bit of effort.

umask:uv number
05:0000001C
03:0000002A
05:00000028
03:00000046
02:00000049
02:0000004F
02:00000055
02:0000005B
03:00000069
05:00000068
02:00000085
02:0000008B
04:00000091
07:00000090
17:00000080

[mrazzido]

wow very great! i hope i get some days new european bluray disc with new keys. then i check this.

[Bystander]

Attempting to decrypt my Pirates of the Caribbean: Dead Man's Chest with new info.

New Proessing key works. However, it is required to copy the Certificate folder as well as BDMV folder.

Used fetchvidbr to get vid, then inserted the new processing key into the simple.txt file for aacskeys. Then used aacskeys to calculate the hash and vuk while using the vid in the command line args. Then inserted into DumpHD database and presto.

[Sirber]

already on digg

http://digg.com/security/455FE10422C...Processing_Key

[FoxDisc]

Originally Posted by arnezami

The new Processing Key was posted by BtCB on freedom to tinker about a week ago (release day +1).

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

[evdberg]

@FoxDisc,

According to my (updated) MKB tool the media key is found at entry 4 (zero-based, so the 5th entry).

can anyone tell me where the "V3" number comes from?

It is stored in a long word at offset 8 in the beginning of the file (in the 'Type and Version' section to be precise).

[FoxDisc]

Originally Posted by evdberg

According to my (updated) MKB tool the media key is found at entry 4 (zero-based, so the 5th entry).

Thanks.
Would that be: 02:00000049? ( I think the order is correct)

00000049 points to a revoked node on the lowest level (the device level) in the V3 MKB (PK/DKs are located at the difference part of the S-D sets - i.e., at revoked device nodes or above groups of revoked devices - devices don't have the PK/DK associated with their own device number.) The only device that has that PK/DK is the adjacent (to the right) 0000004B device (the 02: part tells us this floor has only 2 devices and one is revoked). That means the LA knows exactly where this PK came from. I suspect some software player company got another nasty phone call from an irate LA exec.

I've been trying to figure out BtCBs "hint" of uv:00000047. That points to one of a pair of revoked devices, but the associated PK/DK is not used in the MKB V3. My guess as to the "hint" is that it is the device number of one of the revoked software players, but maybe I'm missing something.

[Fahzuu]

Originally Posted by FoxDisc

I've been trying to figure out BtCBs "hint" of uv:00000047. That points to one of a pair of revoked devices, but the associated PK/DK is not used in the MKB V3. My guess as to the "hint" is that it is the device number of one of the revoked software players, but maybe I'm missing something.

...or maybe it's just a typo and should read 00000049...

[Galileo2000]

Originally Posted by FoxDisc

I've been trying to figure out BtCBs "hint" of uv:00000047. That points to one of a pair of revoked devices, but the associated PK/DK is not used in the MKB V3. My guess as to the "hint" is that it is the device number of one of the revoked software players, but maybe I'm missing something.

Is it possible he is pointing to the player tampering with which gave him a key?

[arnezami]

Its another one of those good days .

Here is a screenshot of aacskeys working with the new Processing Key:



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 . Still quite a bit to do. But I will now have more time for programming again...

Ooh. And for those (other) "key finders" out there: we still need a Host Private Key for (really) easy Volume ID retrieval. That would be great. For aacskeys users: keep in mind the current version of aacskeys does not give a proper error when trying and failing to retrieve a Volume ID: but if the VID is all 00's then you know you first have to get the Volume ID yourself and then input it into aacskeys (like I did above).

Btw: the uv 47 is a typo : it should be 49 (as can be seen in the above screenshot).

Regards,

arnezami

[FoxDisc]

Originally Posted by Galileo2000

Is it possible he is pointing to the player tampering with which gave him a key?

No, only the 4B player has that key. Arnezami says it was a typo, which makes sense.

[FoxDisc]

Originally Posted by arnezami

Btw: the uv 47 is a typo : it should be 49 (as can be seen in the above screenshot).

I notice that the aacskeys screenshot is giving the uv number, which includes the path and the v-mask encoded together, but I don't see the u-mask. The u-mask gives the "floor" that this node is on and is necessary to figure out how many other devices are in the set that has access to this PK. Unless I'm missing something, you might want to add it - it's only one byte value. I'm used to the 02:00000049 format where the u-mask precedes the uv number and is separated by a colon.

[jetsetter]

Originally Posted by bob0r

Priceless

Yes. Nice way to post that. I suppose future keys will require ever-more-subtle leaks onto the webs.