On Tue, Aug 11, 2009 at 3:22 PM, Stroller<strol...@stellar.eclipse.co.uk> wrote: > I'm just looking for a better answer than ones prefaced with "presumably" > and which treat DeCSS encryption like it's black magic.
I can't give you a definitive answer to your original question but I can hopefully shed some light on how CSS works, no black magic. Let me say also that I'm no expert and this is all "as I understand it". First, DeCSS is actually one (the first?) decryption method, and is very old and mostly obsolete. What you probably meant to say was CSS (Content-Scrambling System) which is the encryption method. Most likely whatever programs you're running nowadays are using libdvdcss, not DeCSS. DeCSS used a compromised player key (gleamed from Xing player on Windows, IIRC) which was revoked and invalid on newer discs, while libdvdcss uses a computed lookup table of every possible player key (400 or so) as well as falling back to brute force in the event of a disc with a new set of keys so that it can decrypt nearly everything. CSS is handled in a series of keys, and the hardware of the DVD drive is involved in at least some of the key authentication. On the DVD, there are keys at the sector, title and disc level. The disc key is needed to get the title key, and the title key is needed to decrypt the sector keys to get to the actual movie data. The 400+ variations of the disc key (one for each possible player key) stored on the DVD itself in abnormal locations (possibly unreadable to dd?) such as disc lead-in. The DVD player software gives the drive a player key and it cycles through all of the disc keys on the DVD until it finds a match (or doesn't). Even if you made a 100% perfect read of the original, nearly all consumer-grade DVD burners are forbidden from writing the CSS key data to DVD+/-R discs (and I believe DVD-R discs even physically lack the area where they would go). I can't give you a definitive answer on why dd gives you different results, but I would tend to agree with the presumption of the other people who replied. My suspicion is that a valid player key was given to the drive by the other program you used and the "door was left open" so to speak, causing the drive to then output valid data when you used dd on it the second time. I'm not sure how long that player key lasts in the DVD drive (if it does at all). I guess you could look at the sources of libdvdread and libdvdcss to see exactly how it's done. Typically, if you want to reduce wear and tear on your DVD drive, you'd use vobcopy which will handle the decryption and copying of the data in one motion. Then you should be able to transcode from those files to the format you want without needing the disc in the drive. Since transcoding is usually the slow part, if you've got a lot of disc space on this new beast of a machine you might want to do all of the copying first and then just transcode them in a huge batch (perhaps that was already your plan from the beginning). As CSS was rendered obsolete 10 years ago, finding any technical info is kind of hard since it seems people have moved onto more challenging pursuits. Googling mainly results in a billion pages about copying movies on Windows.
