Got VolumeID without AACS authentication :)

[gulikoza]

Originally Posted by Galileo2000

If we can get VUK from HD DVD Xbox without any software player involved

You can't get it directly, you still need the processing key (which is the same for all discs...AT THE MOMENT, but it will be changed sooner rather then later).

[lightshadow]

Originally Posted by arnezami

The Processing Key is in it . So it takes the MKBROM.AACS and the Volume ID and voila it gives a VUK.

evdberg wrote this proggy just after the Processing Key was found...

I see =) Thanks.

It is not quite related, but what is KCD that people are talking about?

[lightshadow]

Just thinking. Would it be a good idea if the leading hackers exchanged contact information in case Doom9 and/or xboxhacker should be taken down, so you are separated if the forums should be taken down?

If you don't want to give out your real email, then use Sneakemail, which makes an email alias to your real email. I have used it for years, and it just works!

[FoxDisc]

Originally Posted by Sulimo

And can't they just revoke the HD-DVD addon hardware?

Yes, using the Drive Revocation List they can revoke drives. I don't know whether individual drives can be revoked (your XBOX 360 HD-DVD drive, but not mine) or if it's just whole classes of drives (all XBOX 360 HD-DVD drives).

[MrDVD]

Originally Posted by dito

I think it would be highly useful if the BluRay in the PS3 could be patched so it works under Linux... Will be good for people just wanting to use the PS3 as a HTPC...

BTW does the Xbox360 HD-DVD work under linux (are there any drivers?)?

Great work guys!

Me dont have an PS3 but i think it works already under linux. There is a UDF patch for the kernel to support UDF 2.5. Check ps3news.com

[Galileo2000]

Originally Posted by FoxDisc

Yes, using the Drive Revocation List they can revoke drives. I don't know whether individual drives can be revoked (your XBOX 360 HD-DVD drive, but not mine) or if it's just whole classes of drives (all XBOX 360 HD-DVD drives).

But why is it important? I will not be able to play HD DVD movie from the drive, but I still will be able to use it for decryption, no?

[bourke]

Originally Posted by arnezami

It gives the volume ID without patching the drive and without doing AACS auth. Meaning this drive has a HUGE security hole in it .

Heads off to buy stockpile of these drives - they're only about US$110 here at the moment (Australia).

They could be worth a mint when they eventually patch the drive firmware LOL!

[bourke]

Originally Posted by Galileo2000

But why is it important? I will not be able to play HD DVD movie from the drive, but I still will be able to use it for decryption, no?

Sure you can read the Volume IDs (and the encrypted disc contents) using this drive - however you still need keys (e.g. a processing key) in order to decrypt those files.

They will be revoking all such publicly known decryption keys as sure as day follows night.

What we need to do is find another processing key... and not release it until about one month from now ;-)

I wonder if this time they will use completely different keys for Blu-Ray and HD-DVD?!

[FoxDisc]

Originally Posted by Galileo2000

But why is it important? I will not be able to play HD DVD movie from the drive, but I still will be able to use it for decryption, no?

That's two questions. Why is it important? Mainly we want to understand what can and can't be done. I suspect that they would not turn off all legitimate XBOX 360 drives with a DRL revocation just to get at some hackers who could probably get around the revocation. I also have my doubts that there is enough space on an AACS disc to individually revoke specific drives, which leads me to guess that DRL is not a big issue. I suppose they might have some way of forcing people to flash upgrade the drives, then they could revoke the old unflashed versions, but even that seems unlikely. Finally, I'm not sure we know where the DRL revocation would be stored (If I saw this in the specs, I've forgotten - arnezami, do you recall?). Is it in the drive, the software? Right now it looks like there would be ways to get around a stored DRL list, but only time will tell for certain.

As to whether you could still use a DRL revoked drive to decrypt - that mostly would depend on what they've changed in the encryption. I agree, the drive could probably still be used to read everything on the encrypted AACS disc with the control that's been gained over the firmware, but will you have all the required decryption DK and SK keys to work through the MKB and the SKB? Again, only time will tell for certain.

[Galileo2000]

Originally Posted by bourke

Sure you can read the Volume IDs (and the encrypted disc contents) using this drive - however you still need keys (e.g. a processing key) in order to decrypt those files.

They will be revoking all such publicly known decryption keys as sure as day follows night.

What we need to do is find another processing key... and not release it until about one month from now ;-)

I wonder if this time they will use completely different keys for Blu-Ray and HD-DVD?!

This is understandable.

Processing keys will change, like you said.

New keys will have to be found.

But hardware revocation is irrelevant.

[FoxDisc]

Originally Posted by bourke

What we need to do is find another processing key... and not release it until about one month from now ;-)

Yes, another processing key will almost certainly be needed. Right now, one processing key (plus the Volume ID), is all that's needed to decrypt all of the movie on all discs. Note the two "all"s in that sentence. What may not be apparent, is that 1) if they begin using the SKB system, the new processing key will only decrypt portions of the movie (most, but not all). At up to 32 points in the movie you will need other keys (derived from the six SKBs on the disc and secret Sequence Keys stored in the player). 2) The second limitation, is that they are not required to use the same processing key for all discs (or for HD/BR as you noted).

It should be interesting to see what's on the next AACS discs that are released.

[FoxDisc]

Originally Posted by Galileo2000

hardware revocation is irrelevant.

I'm inclined to agree - but there is an opportunity for the AACS LA to make a huge PR blunder by turning off legitimate drives. People who buy discs may understand that DRM prevents them from copying the discs, but people who buy hardware usually don't understand that the AACS DRM can permanently turn off their hardware so it can't play new discs and it won't even play the same discs it would play last week.

[Galileo2000]

Originally Posted by FoxDisc

I'm inclined to agree - but there is an opportunity for the AACS LA to make a huge PR blunder by turning off legitimate drives. People who buy discs may understand that DRM prevents them from copying the discs, but people who buy hardware usually don't understand that the AACS DRM can permanently turn off their hardware so it can't play new discs and it won't even play the same discs it would play last week.

We are dangerously close to the legal waters now, but let me say that such action would be a kiss of death to any organization or company which does such things.

I put YOUR DISC into MY DRIVE and YOUR DISC killed MY DRIVE and you are telling me just that?

[bourke]

Originally Posted by FoxDisc

Yes, another processing key will almost certainly be needed. Right now, one processing key (plus the Volume ID), is all that's needed to decrypt all of the movie on all discs. Note the two "all"s in that sentence. What may not be apparent, is that 1) if they begin using the SKB system, the new processing key will only decrypt portions of the movie (most, but not all). At up to 32 points in the movie you will need other keys (derived from the six SKBs on the disc and secret Sequence Keys stored in the player). 2) The second limitation, is that they are not required to use the same processing key for all discs (or for HD/BR as you noted).

Yes, arnezami explained this early on in his 'Understand AACS (Subset-Difference)' thread ;-)

I hope they do use different keys for Blu-Ray and HD-DVD - and that we crack the Blu-Ray one(s) first (and much earlier) - that way some studios may shift camps!

Just think - hackers may actually be able to influence the outcome of the format war :-)

After all - I only want to be able to convert region-coded Blu-Ray movies into non-region-coded HD-DVDs - something entirely legal here in Australia :-)

Originally Posted by FoxDisc

It should be interesting to see what's on the next AACS discs that are released.

We're all looking forward to the fun and games ahead :-)

[FoxDisc]

Originally Posted by lightshadow

I see =) what is KCD that people are talking about?

Key Conversion Data. It's not used by software players and is optional for hardware players. Its part of the confidential spec, but it's stored on an AACS disc in a known location, so it's interesting to see 1) if it's currently in use (since it's optional) and 2) if the drives used by software players can even see it (since software players aren't supposed to be able to get it.)

[SuperGoof]

Originally Posted by FoxDisc

I'm not sure we know where the DRL revocation would be stored. Is it in the drive, the software?

To my understanding, according to the specs drives take care of HRLs, while hosts take care of DRLs. In this case, it is up to PowerDVD/WinDVD where they decide to store DRLs. Based on my experience with blu-ray regions, I think they will probably store DRLs in Windows Registry.

[FoxDisc]

Originally Posted by SuperGoof

To my understanding, according to the specs drives take care of HRLs, while hosts take care of DRLs. In this case, it is up to PowerDVD/WinDVD where they decide to store DRLs. Based on my experience with blu-ray regions, I think they will probably store DRLs in Windows Registry.

That makes sense, but it's easier to get around such a revocation (reinstall Windows, then player) than it would be to get around a DRL that's also stored on the drive itself. I really doubt we'll see DRLs on the next discs anyway.

[Boing99]

A few comments and answers:

Current AACS disks (at least those I have looked at) do have a KCD, and (at least some) standalone players have device key sets that require a KCD. That also means that the drives in those players have a modified firmware which allows reading the KCD, using undocumented CDBs. Incidentally, on at least some of the standalone players the drive firmware is modified even more heavily, e.g. to allow the player to read the volume ID and KCD without exchanging host/drive keys first . The AACS specs already hinted at that, and it has been confirmed in real life.

FoxDisc: I agree with the fight not being over yet, but behind the scenes player software, drives and standalones have been penetrated by several people a LOT deeper than has been announced so far. No use in tipping AACS-LA off about the targets and methods quite yet, as long as disk backups can already be made with what has been published so far. Don't be surprised though if the stream of VUKs continues after the first AACS key revocation almost like before. We might even see the new processing key (assuming they still only use a single one for all disks) quite quickly.

The problem for AACS-LA and movie studios is that some hardware and software manufacturers have been sloppy in their protection systems while rushing products to market, so we are seeing drives and standalones that can be updated without public key code signing (X-Box add-on and others), software players that do not handle CRLs, software players with insufficient code armor, software players that keep keys lying around in memory etc. etc. Some of these mistakes are probably irrecoverable except possibly to some degree by using BD+ and SKB. Reverse-engineering is alive and well...

About SKB: I doubt we will see this before the end of the year, and even after that it will probably only be used in certain high-profile titles, because it would be a PITA for movie companies to use. Mastering movies without SKB is relatively simple, as most the burden of MKB, revocation etc. lies with replicators, but with SKB the movie companies probably will have to do a lot more of the work. The question is: will movie companies continue to invest a lot more money, time, training etc. into a system which so far AACS-LA has not been able to demonstrate to be more effective in preventing copying than CSS, despite of the huge effort put into it.

Also, if software players will continue to be penetrated as easily as they have been in the past then there is no point in SKB (except for the one-time effort required by authors of ripping tools to support it in their software), because all sold copies of the same version of a player share the same keys. The use of SKB would just shift the race to a slightly different playing field: can hackers extract device keys and sequence keys out of players more quickly than AACS-LA can revoke and renew them ? My guess (assuming the HD formats continue to penetrate the market) most likely, yes. That would make the SKB system completely useless for AACS-LA, since all it would tell them shortly after each round of revocation is "Win/PowerDVD has been penetrated again." Doh

About drive revocation: I believe individual units can be revoked. It all depends on whether drive ids are assigned per unit or per model. The usual way to test is: if the drive id looks small and simple (like the host id in PowerDVD or WinDVD) then it was probably assigned per model. If it looks complex and irregular, like a serial number, then it is probably unique per drive. Mine looks like a serial number. You can find it in the drive certificate returned by the drive during an AACS key exchange. Just look at a packet trace. Of course, regardless, drive revocation does not affect ripping tools at all, only commercial players. And (at least some) standalones do not use drive keys at all, so their drives can never be revoked.

The PS3 drive does work under Linux (using either a UDF kernel patch or using ripping software that has UDF support built-in). However only file reading works, not the AACS key exchange, because that appears to be blocked by the Hypervisor. This means you will have to get the Volume ID with different hardware.

[Galileo2000]

Wow Boing99 such an excellent post overall.

Originally Posted by Boing99

A few comments and answers:

Current AACS disks (at least those I have looked at) do have a KCD, and (at least some) standalone players have device key sets that require a KCD. That also means that the drives in those players have a modified firmware which allows reading the KCD, using undocumented CDBs. Incidentally, on at least some of the standalone players the drive firmware is modified even more heavily, e.g. to allow the player to read the volume ID and KCD without exchanging host/drive keys first . The AACS specs already hinted at that, and it has been confirmed in real life.

FoxDisc: I agree with the fight not being over yet, but behind the scenes player software, drives and standalones have been penetrated by several people a LOT deeper than has been announced so far. No use in tipping AACS-LA off about the targets and methods quite yet, as long as disk backups can already be made with what has been published so far. Don't be surprised though if the stream of VUKs continues after the first AACS key revocation almost like before. We might even see the new processing key (assuming they still only use a single one for all disks) quite quickly.

And we have seen it by now

The problem for AACS-LA and movie studios is that some hardware and software manufacturers have been sloppy in their protection systems while rushing products to market, so we are seeing drives and standalones that can be updated without public key code signing (X-Box add-on and others), software players that do not handle CRLs, software players with insufficient code armor, software players that keep keys lying around in memory etc. etc. Some of these mistakes are probably irrecoverable except possibly to some degree by using BD+ and SKB. Reverse-engineering is alive and well...

Good.

About SKB: I doubt we will see this before the end of the year, and even after that it will probably only be used in certain high-profile titles, because it would be a PITA for movie companies to use. Mastering movies without SKB is relatively simple, as most the burden of MKB, revocation etc. lies with replicators, but with SKB the movie companies probably will have to do a lot more of the work. The question is: will movie companies continue to invest a lot more money, time, training etc. into a system which so far AACS-LA has not been able to demonstrate to be more effective in preventing copying than CSS, despite of the huge effort put into it.

I bet they will. They still believe they are invincible. They are also slow and if they stop now, quite a few heads will be rolling. And those heads don't want to be rolling. Until someone who is smart and practical will step in, analyze the situation, losses in manufacturing, losses in sales and tell them STFU.

Also, if software players will continue to be penetrated as easily as they have been in the past then there is no point in SKB (except for the one-time effort required by authors of ripping tools to support it in their software), because all sold copies of the same version of a player share the same keys. The use of SKB would just shift the race to a slightly different playing field: can hackers extract device keys and sequence keys out of players more quickly than AACS-LA can revoke and renew them ? My guess (assuming the HD formats continue to penetrate the market) most likely, yes. That would make the SKB system completely useless for AACS-LA, since all it would tell them shortly after each round of revocation is "Win/PowerDVD has been penetrated again." Doh

About drive revocation: I believe individual units can be revoked. It all depends on whether drive ids are assigned per unit or per model. The usual way to test is: if the drive id looks small and simple (like the host id in PowerDVD or WinDVD) then it was probably assigned per model. If it looks complex and irregular, like a serial number, then it is probably unique per drive. Mine looks like a serial number. You can find it in the drive certificate returned by the drive during an AACS key exchange. Just look at a packet trace. Of course, regardless, drive revocation does not affect ripping tools at all, only commercial players. And (at least some) standalones do not use drive keys at all, so their drives can never be revoked.

The PS3 drive does work under Linux (using either a UDF kernel patch or using ripping software that has UDF support built-in). However only file reading works, not the AACS key exchange, because that appears to be blocked by the Hypervisor. This means you will have to get the Volume ID with different hardware.

[FoxDisc]

Originally Posted by Boing99

A few comments and answers:

All very interesting, and lots of good points. Thanks!

with SKB the movie companies probably will have to do a lot more of the work.

If the movie company needs to come up with eight variations of the movie at each of 32 points, this would be a lot more effort, but I was guessing that this was really just an automated process - the movie company provides the movie and an automated tool picks 32 segments and forms 8 watermarked variants for each.

if software players will continue to be penetrated as easily as they have been in the past then there is no point in SKB (except for the one-time effort required by authors of ripping tools to support it in their software),

The LA might consider it to be worthwhile to force hackers through the one-time effort. It makes it harder because there are lots more keys involved. Plus, they may just want to keep an eye on whether the keys are all coming from the software players and not the hardware. Finally, they may need to confirm which software players are being broken so they can point the finger at a specific software company without them all saying "It wasn't me - it was the other guy who wrote sloppy code!"

Nonetheless, I won't be surprised if they don't add SKBs immediately. They may just want to see how well hardening the software works before giving clues on how the SKB system functions. They might even be concerned that poorly written hardware and software players could malfunction as they try to play new discs with a new complex SKB system.