WinDVD 8 Device Key Found!

[xyz987]

Originally Posted by arnezami

We need the Host Private Key

Just a question. Can they revoke a Host Private Key?

[arnezami]

Originally Posted by BlazingMind

Arnezami:
Thanks for clearing things up... It seems i missed the fact that the optical drive also has a part in this play (Maybe you could add this to your drawing as well? :P)

I have another question or two though... (sorry for not reading all the details on how AACS works).

1. From my understanding, Hpriv is never relly needed for anything else but calculating Hsig. Why on earth would the Hsig be calculated in software, and not on the actual optical drive? Calculating it in the player would expose it to attacks like this, but from what I can see, the other components of Hsig is far less sensitive than Hpriv, and could be sent to the drive for Hsig calculation.

2. You have a complete sniff of the comunication with the drive during this sequence, correct? If these design specs are 100% correct, you should have a sniff of the Hpriv, so if you can't find it, it is probably because your analysis software has flaws.

All in all i do get a feeling that there is something missing from this picture though. The Hsig calculation seems like a red herring to me as I can't see any reason why the Hpriv should need to be accessible outside of the optical drive. Could it be that there are "secret specifications" that says "disregard figure x.x on page x. This is just written to throw off the hackers..." Or... "Hpriv should be encrypted before Hsig is calculated"...


Again, I don't have a good understanding of this system, so it may just be that I'm missing something...

Yeah you're missing something .

The private host key is kept private for the host (= software) while the private device key is kept private for the drive. The private host key is never send towards the drive (as you can see in the picture). That would defeat its purpose. But for a very short amount of time the private host key has to be used to sign the Dn||Hv (and this Hsig is sent to the drive) so the drive knows you have the private key. Only if this signature is given to the drive will it give the volume id later on.

And yes: I have sniffed my usb and can see the Hsig being sent to the drive. I'm even capable of verifying this Hsig using the Host Public Key. Its all working according to specs.

[arnezami]

Originally Posted by xyz987

Just a question. Can they revoke a Host Private Key?

Yes. In fact they can make it impossible for the current WinDVD version to play discs that work now (if you insert a new disc with a new HRL on it). Your drive won't give away the Volume ID anymore using this Host Private Key (you will have to extract a new one from a new version of a software player).

Its called: the Host Revocation List. Please read the AACS Common specs...

Again: we always need two things to decrypt a disc:

- Device/Processing Key
- Host Private Key

Only then can we get to the (unrevokable) VUKs.

[arnezami]

Originally Posted by BlazingMind

It might be that it gets confused by signing? (addresses above 2GB may be interpreted as being negative or positive). Just a guess.

What language is it written in?

I've edited my (red) posting and added some links.

[xyz987]

Originally Posted by arnezami

Yes. In fact they can make it impossible for the current WinDVD version to play discs that work now (if you insert a new disc with a new HRL on it). Your drive won't give away the Volume ID anymore using this Host Private Key (you will have to extract a new one from a new version of a software player).

Its called: the Host Revocation List. Please read the AACS Common specs...

That's what I thought. Host Private Key is just a thing that is useful to get Volume IDs, but they can revoke HPK and Volume IDs can be read by other ways. So I can not understand why you give so big importance to HPK.

Again: we always need two things to decrypt a disc:

- Device/Processing Key
- Host Private Key

Only then can we get to the (unrevokable) VUKs.

No, you are wrong here. We need DK/PK and VolumeID. There are other ways to get VolumeID (USB sniffing, device hacked firmware and probably others).

[arnezami]

Originally Posted by xyz987

No, you are wrong here. We need DK/PK and VolumeID. There are other ways to get VolumeID (USB sniffing, device hacked firmware and probably others).

Hacking firmware for every type of drive sold in the world is much more difficult than getting one HPK. And (sniffing) doesn't work on other platforms like linux and is not practical for non-savvy people.

What people want is a program that works completely independent from the current Software Players, is easy to use and works on all platforms.

[BlazingMind]

Originally Posted by arnezami

I've edited my (red) posting and added some links.

I haven't had time to look into the details of the GetMemoryAddressFromPattern function, but I have a few ideas on what can be wrong...

First of all...

if ((mbi.Type == MEM_PRIVATE) && (mbi.State == MEM_COMMIT))

The type check excludes MEM_IMAGE and MEM_MAPPED. Reasons for excluding memory of this kind...

MEM_MAPPED might be memory mapped files (i.e. very slow), I doubt memory mapped files are used here. It is not likely to be used anyway...

MEM_IMAGE... The only reason I can see for excluding this is because it might represent large memory areas that are unlikely to hold the data we are interested in... This will give a performance boost, but again limit accuracy.

I say you should try to remove the exclusion and see how it goes from there.

[arnezami]

Originally Posted by BlazingMind

if ((mbi.Type == MEM_PRIVATE) && (mbi.State == MEM_COMMIT))

The type check excludes MEM_IMAGE and MEM_MAPPED. Reasons for excluding memory of this kind...

MEM_MAPPED might be memory mapped files (i.e. very slow), I doubt memory mapped files are used here. It is not likely to be used anyway...

MEM_IMAGE... The only reason I can see for excluding this is because it might represent large memory areas that are unlikely to hold the data we are interested in... This will give a performance boost, but again limit accuracy.

I say you should try to remove the exclusion and see how it goes from there.

Thanks. Thats very helpful. Will try it.

[BlazingMind]

Lol... my last post was written during a very stressful period at work, so it turned out to be quite messy...

What I meant to say, of course, was that you might want to try to change the line into something like this instead:

if (mbi.State == MEM_COMMIT)

(I'm sure you already got that, but just for the sake of clarity).

[arnezami]

Originally Posted by BlazingMind

Lol... my last post was written during a very stressful period at work, so it turned out to be quite messy...

What I meant to say, of course, was that you might want to try to change the line into something like this instead:

if (mbi.State == MEM_COMMIT)

(I'm sure you already got that, but just for the sake of clarity).

Its working now! I can now find stuff I couldn't find before.

Now I can go Hunting again

Thanks!

[xyz987]

Originally Posted by arnezami

Hacking firmware for every type of drive sold in the world is much more difficult than getting one HPK. And (sniffing) doesn't work on other platforms like linux and is not practical for non-savvy people.

Just a handful of hackers will develop the hacked firmawe for a handful of widely sold devices, but several thousands of medium/advanced users can flash their devices and get VolumeIDs so they can publish VUKs.

What people want is a program that works completely independent from the current Software Players, is easy to use and works on all platforms.

We already have BackupHDDVD and supposedly BackupBluRay will support VUKs soon. It is command line, but there are people developing GUI versions.

I understand your idea, but the real problem is HPK can be revoked, and soft players can be hardened.

Things that can not be hardened:

A- USB conection
B- Already sold standalones
C- Already sold PC devices

You pointed A and B on previous posts (in fact you was the first person to point them AFAIK). Now you are trying to get a thing that can be revoked (HPK) from a thing that can be hardened (soft player).

[arnezami]

Originally Posted by xyz987

Just a handful of hackers will develop the hacked firmawe for a handful of widely sold devices, but several thousands of medium/advanced users can flash their devices and get VolumeIDs so they can publish VUKs.



We already have BackupHDDVD and supposedly BackupBluRay will support VUKs soon. It is command line, but there are people developing GUI versions.

I understand your idea, but the real problem is HPK can be revoked, and soft players can be hardened.

Things that can not be hardened:

A- USB conection
B- Already sold standalones
C- Already sold PC devices

You pointed A and B on previous posts (in fact you was the first person to point them AFAIK). Now you are trying to get a thing that can be revoked (HPK) from a thing that can be hardened (soft player).

I know your arguments but I'm not going to debate this issue any further other than saying this:

Right now we do not have a program that can independently and easely retrieve a VUK. With the HPK we would have. That's why I believe the HPK is important right now.

Can we please leave it at this (for now).

arnezami

[FoxDisc]

Originally Posted by xyz987

Just a question. Can they revoke a Host Private Key?

This was answered, but I thought I'd add that not only can they revoke the Host with the Host Revocation List (HRL) and/or the Drive with the DRL, there is even an AACS provision for revoking Content with a Content Revocation List. I can't really imagine that they would ever revoke major releases, or revoke all the titles that are currently out there, but they could!

[BlazingMind]

Originally Posted by FoxDisc

This was answered, but I thought I'd add that not only can they revoke the Host with the Host Revocation List (HRL) and/or the Drive with the DRL, there is even an AACS provision for revoking Content with a Content Revocation List. I can't really imagine that they would ever revoke major releases, or revoke all the titles that are currently out there, but they could!

Lol.. call that an added bonus... I hardly think it was in the design specs, but if I'm not mistaken, the system can revoke any key, so why spend time removing this feature... right?

I can see this being a nice feature if some day a movie is rendered illegal in any way.

[FoxDisc]

Originally Posted by BlazingMind

I hardly think it was in the design specs, but if I'm not mistaken, the system can revoke any key, so why spend time removing this feature... right?

They clearly went to a lot of effort to include Content Revocation in the design specs. The CRL is stored on the disc after the MKB and the Sequence Key Block, just before the encrypted content. The SKB is optional, but as far as I can tell, the CRL is not.

I can see this being a nice feature if some day a movie is rendered illegal in any way.

Maybe they'll eventually want to revoke some porno flicks (after they've made money from allowing them in the first place) ! Or perhaps they'll just decide to automatically revoke all licensed content five years after it was released.

I wonder how many people were told that the players or movies they purchased can be revoked? It's so nice to be able to reach into your customer's home and throw the permanent "off" switch whenever you want. Control is a wonderful drug.

[BlazingMind]

Ok... my bad... I gotta start reading those docs before I assume things :P

[FoxDisc]

Originally Posted by xyz987

the capability to get full sets of Device Keys will break [AACS]. It is this capability what matters, not the Device Key itself, and the way to get this capability is getting previously some DKs.

We agree on this. Knowing how to get DKs is more useful to an attacker than actually getting them.

As I previously posted, if attacker A gets a full set of DKs, he can simply publish the DK that directly computes the PK.

The DK that directly computes the PK has the same value and carries the same info as the PK itself. A PK is assigned to each unique S-D set of devices and everyone in that set was given the device key that directly computes that PK or they were given a higher DK that allows the direct DK to be computed as a sub DK.

They can not revoke the player because they don't know its identity.

This goes back to traitor tracing. I'm still slogging through the Sequence Key procedures, but I'm not at all convinced that they will have trouble identifying the device to be revoked. The entire SK system was designed exactly to do that job. My impression is that it will work when they get around to using it. Why they didn't use it from the start is the real mystery.

If they revoke the DK, attacker simply publish the new DK that is used to "encrypt" (to compute the new PK).

They don't actually revoke individual DKs. They revoke devices with whole sets of DKs. Until they know what device to revoke, they won't/can't revoke anything. As an example, in the software player group, right now they are revoking one pseudo device in the lower left corner. Everyone else is not revoked, so everyone else has the necesssary DKs to calculate the PK assigned to this group.

So they must try traitor tracing, but this is probably not effective (i.e. "traitor" can not be traced).

I don't know why you say that. They know the "traitor" now - it's PowerDVD and WinDVD. I presume they will revoke them (and all of their DKs) as soon as they are reasonably sure those two have been hardened against current attacks. When they make that revocation, I suspect they will add the Sequence Key tracing system to the disc.

However to get this capability (getting full sets of DKs) attacker A needs some people have experimented how to get DKs. Attacker A can use this previously found keys to know what to search, or to check if his method is really getting DKs, and previous practice is even more important than keys. That's why I said we need to get so many keys and so hight in the trees as possible.

I agree that previously located keys will be useful to an attacker who is attempting to break new discs. If he can find old keys being calculated by new software, it will help find new keys being calculated. However, I don't think it will help much to have old device keys after they are revoked. They won't be used again.

They can not revoke any player if they don't know its identity. Traitor tracing is at the very center of the problem, if they can not do it effectively, AACS will become quickly broken.

We agree - tracing is the key. What is not clear is how good their SK tracing system is, or when, if ever, they will start to use it.

Edit: just an example:
Let's say WinDVD 8 is player 9 at master tree (22 level), so it has keys 8,5,3 in its DK set.

OK, this is using your numbered tree again (very handy, but it's not reproduced in this thread.) If others want to follow you, they should see the Understanding AACS sticky thread.

If you get its DK set, you know which is WinDVD 8 position at master tree (you know it is player 9). A lot of useful information can be extracted of DK sets.

Yes. Knowing the DKs tells you the device nmber. I have asked a couple of times if anyone has figured out the "device number" for WinDVD or PDVD. I guess no one has. BTW, the original NNL paper talks about some advantages to assigning devices sequentially. We don't know if that was actually done.

This includes knowing if some standalones share the same keys,

Yes, if DKs can be found for several standalones, this would be very interesting. The implication is this: If the same DKs were given to multiple standalones (100s or 1000s), the AACSLA will be very reluctant to revoke them - it would revoke innocent customers. If every SA received different DKs, then revoking just the few owned by bad boys will not be a problem for them.

BTW, I know that arnezami is focused on the Host Private Key. He is right that he needs that for a standalone player. However, that key and the PK/DKs that are currently known are likely to be revoked eventually. I am particularly interested in understanding how revocation works.

[xyz987]

Originally Posted by arnezami

Can we please leave it at this (for now).

Okay.

[xyz987]

Originally Posted by FoxDisc

The DK that directly computes the PK has the same value and carries the same info as the PK itself. A PK is assigned to each unique S-D set of devices and everyone in that set was given the device key that directly computes that PK or they were given a higher DK that allows the direct DK to be computed as a sub DK.

You are right, but it is nicer to publish the DK :-)

I don't know why you say that. They know the "traitor" now - it's PowerDVD and WinDVD. I presume they will revoke them (and all of their DKs) as soon as they are reasonably sure those two have been hardened against current attacks. When they make that revocation, I suspect they will add the Sequence Key tracing system to the disc.

Yes, they know the traitor because there are just 2 soft players and attackers have published here they got the keys from these 2 soft players. This is right because we are just learning how AACS works and how to break it. However if someone finds a way to get the keys from a model of standalone, and an attacker uses this knowledge to get the keys from a unit of this model, LA will need to do real traitor tracing (not just reading Doom9's forum).

I agree that previously located keys will be useful to an attacker who is attempting to break new discs. If he can find old keys being calculated by new software, it will help find new keys being calculated. However, I don't think it will help much to have old device keys after they are revoked. They won't be used again.

Any player has 22 DKs at master tree. Some of the 22 DKs from player A can be computed from the 22 DKs from player B (the contrary is also true).

OK, this is using your numbered tree again (very handy, but it's not reproduced in this thread.) If others want to follow you, they should see the Understanding AACS sticky thread.

My fault. Here it is:

                       1
                      /  \
                     /    \
                    /      \
                   /        \
                  /          \
                 /            \
                /              \
               /                \
              /                  \
             2                    3
            / \                  / \
           /   \                /   \
          /     \              /     \
         /       \            /       \
        4        5          6         7
       / \       / \       / \        / \
      /   \     /   \     /   \      /   \
     8     9   10    11   12   13   14   15

Yes, if DKs can be found for several standalones, this would be very interesting. The implication is this: If the same DKs were given to multiple standalones (100s or 1000s), the AACSLA will be very reluctant to revoke them - it would revoke innocent customers. If every SA received different DKs, then revoking just the few owned by bad boys will not be a problem for them.

A master tree (level 22) has 2^22 (4 millions) leaf keys (level 0) and each player has a leaf DK in its set. You conjetured there are 512 master trees, but spec mentions just one. If there is just one master tree they are dead. There are far more than 4 million players, so they need to give the same DK set to multiple standalones. This is precisely one of the most interesting things we can learn getting DK sets. If your conjeture is true, bad luck for us. If it is false, bad luck for them.

Edit: BTW keyspace is not determined by key length (128 bit) but path length (31 bit), so it is not posible to have 512 master trees because subtrees (21 level and lower) also spend keyspace. It is posible to have 512/22 = 23 master trees (subtrees spend 21 times the space master tree spends), but this allows just a maximum of 23*4 = 92 million players with different DK sets. Still a too low number to give a different DK set to each standalone.

[BlazingMind]

Originally Posted by xyz987

Edit: BTW keyspace is not determined by key length (128 bit) but path length (31 bit), so it is not posible to have 512 master trees because subtrees (21 level and lower) also spend keyspace. It is posible to have 512/22 = 23 master trees (subtrees spend 21 times the space master tree spends), but this allows just a maximum of 23*4 = 92 million players with different DK sets. Still a too low number to give a different DK set to each standalone.

I take it there is no way of reducing the kyspace for brute force attacks, even if we managed to get a key further up in the chain?