How is any copy protection useful if the data needs to be readable?


Please correct me, if I am wrong.

CSS from DVD video: The scrambling key is stored on the disc itself? Isn’t that like hiding a door key under the “welcome” carpet.

AACS: Key leak scandal? But didn’t the UHD compliant drives know these keys all the time, if they can read the data? How do they support new released discs then? Is there any additional security by hardware side?


CSS uses a 40 bit cyphers which are encrypted and there are hundreds of keys stored on the disc representing one for each licensed player model.

It should have been relatively secure however, due to inadequacies in the encryption methodology, the cyphers can be brute force attacked in a very short space of time. CSS is therefore pretty much redundant as a method of protection.

For AACS the drives contain decryption routines which are built into the hardware but these routines are themselves encrypted and obfuscated so they’re extremely difficult to reverse engineer.


I see. Thanks for clarification.
So AACS does only rely on manufacturer’s trading secrets?


Yes but the hardware manufacturers licences can be revoked at any stage and their devices rendered inoperable.

In practice that’s very unlikely to happen so if details were compromised without the manufacturers knowledge it’s more likely that the compromised details would be revoked and new secure ones issued so that the devices would continue to operate but the compromised details would then be useless.


If you want to find a way of cracking bluray entirely, figure out an easy way to crack government grade AES encryption. The aes algorithm’s technical description is entirely public.

Give it a shot, if you know what you’re doing. :slight_smile:


It is not easy, but no encryption wall of the past managed to resist time for too long, and AACS was already strong.

But the drives have to know the key.

How is the movie playable then?
And is BluRay not already cracked?


The original hackers cracked the key schedule of aacs. Not the actual aes encryption algorithm itself.

If one can find an easy known-plaintext attack on AES, then you don’t have to know what the actual encryption keys are. An easy attack on AES will be able to recover the key easily. (Currently such an “easy” attack is not known publicly).

The original dvd css algorithm was so poorly designed, that the actual css stream cipher encryption algorithm could be easily attacked directly without knowing any of the encryption keys a priori. Most of the attacks directly on the actual css stream cipher encryption algorithm, are known-plaintext attack which can easily recover the encryption key.


IIRC, there is a 2048 bytes sector in the “control zone” of a dvd which contains 408 possible obfuscated disc keys (each obfuscated by a different player key in principle). The first 5 bytes of this particular sector is some kind of hash.

This hash could also be easily cracked and reveal the unobfuscated disc key without knowing any of the player keys a priori. Also one could reverse-engineer “generate” the player keys by a different algorithm.

I strongly suspect these two things are the primary reasons why the dvd licensing folks never bothered to revoke any of the player keys. It would be completely pointless to do so, if either the player keys or the disc keys could be easily cracked. (This is all in addition to brute force cracking of the title keys, where one doesn’t have to know any of the player or disc keys).

In this situation of css being easily cracked at three different stages in the decryption process, there was no way they could stay one step ahead of the ripping program folks.


For amusement yesterday evening, I decided to take a closer look at what this 2048 bytes sized block of hash + 408 obfuscated disc keys actually looks like. Easiest way to do this was looking through the libdvdcss code.

So I went through more than a dozen dvd discs of various vintages from y2k to several years ago. (I don’t have any current 2018 movies on dvd). These were primarily american region1 releases. I only have a few region2 dvd discs, which I also checked.

Even without running any cracking code, it was obvious there were only around 33 unique obfuscated disc keys, where each unique obfuscated key was repeated around 11 or 12 times (except the hash and one key entry). I only found one disc which didn’t exhibit this specific repetition pattern, where this particular disc turned out to have 64 unique obfuscated disc keys with varying patterns of repetition. (This particular “anomalous” disc was a german release of a 90s era uk film, with a y2k date on the back cover).

I ran through the old Frank Stevenson code from 1999 which did the disc key crack on the hash, and another Frank Stevenson code which did this reverse engineering “generating” of the player keys. Lo and behold, 32 out of the 33 unique player keys from these dozen+ dvd discs were all identical on these dvd discs from y2k to around 2016/2017. (The 33rd key appeared to be a dud which didn’t return back anything on one disc, or returning back different possible reverse engineered keys which didn’t match at all between different dvd discs).

On the lone “anomalous” german y2k disc, 32 out of the 64 unique player keys were identical to the ones from the american region1 dvd discs I looked at. I have no idea what these remaining other 32 unique player keys were for.

The other few region2 specific dvd discs I checked, also had the same unique 32 player keys as the american region1 discs I looked at. I don’t have any dvd discs from other regions, which had css encryption.

I’m guessing after CSS was first cracked in late 1999, these 32 unique player keys ended up being “frozen in time” when the dvd licensing folks came to the realization that there was no point in changing/revoking player keys. My suspicion is that these 32 player keys were most likely specific to hardware standalone players which were already manufactured over 1997-1999.


In the case of that lone “anomalous” german y2k disc with 32 “extra” unique player keys, I don’t know offhand what they could have been for.

As a wild guess, some of these “extra” 32 player keys might have been player keys allocated to computer software dvd players ? Or were these “extra” 32 player keys never used at all by any dvd players?

(Computer software dvd players can be easily upgraded/patched if the player keys were changed, while older dvd players from the 1996-1999 era usually didn’t upgrade the firmware).

The other few region2 dvd discs I have, do not use any of these “extra” 32 player keys. These are region2 discs released after 2000, where the video is in the PAL format. (American dvd discs will have the video in the NTSC format).


I looked through more region1 dvd discs from my collection, which were originally manufactured back in 1998, 1999 or 2000. It turns out they also used the same 32 player keys which have since been “frozen in time” to the present day, but with the dud 33rd key absent.

I came across an archive of documents from the 2600 magazine lawsuits over deCSS back in the early-2000s. One particular official document asserted that the dvd licensing folks revoked the player key of Xing Technology’s software dvd player back in late-1999, which the deCSS folks allegedly reverse engineered.

Xing Technologies was an american company which specialized in audio/video streaming type stuff back in the 1990s.

As far as I can tell, there doesn’t appear to be any revoked player keys on american region1 dvd discs. It would be somewhat odd if Xing’s dvd player program was not available in america, whether as a download or sold offline as a packaged software box.

I’m guessing the dvd licensing folks never actually revoked Xing’s player key.


I came across a legal document which was filed by the dvdcca (which handles the licensing of the dvd css encryption stuff), back in early y2k. It explicitly lists the relevant leaked decss code (exhibit b), and explains how the dvdcca folks actually figured out definitively that it was the Xing player key that was compromised.

The leaked decss code just happens to mention a single player key, which the dvdcca says is exactly the Xing player key.

This same Xing player key is also in that list of 32 player keys which has since been “frozen in time” on subsequent dvd discs after y2k to the present day.


As to why these 32 particular player keys have been “frozen in time”, I can only think of two obvious reasons. Most likely these were the 32 keys which were already allocated to the dvd player manufacturers back in the late 1990s (before the css crack). These same 32 keys were probably also the ones which had previously been used on ALL css encrypted dvd discs manufactured worldwide up until the end of 1999.

Besides Xing, I can only guess as to which other dvd player manufacturers were already allocated a player key before the css crack. For example, probably companies like:

  • LG
  • Samsung
  • Panasonic
  • Sanyo
  • Sony
  • JVC
  • Microsoft (ie. dvd player in Windows 98)
  • Phillips (or Magnavox)
  • Pioneer
  • Mitsubishi
  • Sharp
  • Hitachi
  • Yamaha
  • Thomson (ie. RCA)
  • LiteOn
  • BenQ (Acer)
  • Cyberlink (ie. PowerDVD)
  • Apple (macos dvd player)
  • Toshiba
  • etc …

I wouldn’t be surprised if the remaining companies which were allocated player keys, were various chinese dvd player manufacturers. (ie. The “made in china” players which were $100 or less after y2k).

Probably also a few software dvd players, such as ATI, Corel/InterVideo (ie. WinDVD), etc …


My guess is the dvdcca technical folks quickly figured out that the Frank Stevenson css cracks made key revocation completely pointless. They probably hired someone (or had an intern) which cobbled together the open source css code and the Frank Stevenson codes already public in late-1999, which demonstrated that all possible player keys could be cracked in a few minutes from several dvd discs.

Somebody even posted up all the possible 32 player keys on a slashdot thread, several days after the Frank Stevenson cracks were revealed.

I imagine once the dvdcca folks figured out it was pointless to revoke any player keys, the least problematic way of going forward was to use these “frozen in time” 32 player keys, so that there isn’t any disruptions to already existing and future dvd players. In those days, upgrading firmware wasn’t typically done for standalone dvd players.