Why can't I copy my DVD with dd?

People mention that opening the DVD with VLC (which displays the DVD menu) magically makes the data accessible to dd, but nobody has yet explained why that is and how VLC accomplishes this feat.

I managed to replicate this behavior when trying to play a DVD in my computer from a Kodi device hooked up to my TV, by using SMB to share the root of the DVD drive over the network. It didn't work, unless I first opened the DVD with VLC, at which point Kodi could magically play the files.

This sort of magic offends my sensibilities, so I went digging. The underlying cause of the issue is that your DVD drive is working against you. As per Wikipedia:

However, if the drive detects a disc that has been compiled with CSS, it denies access to logical blocks that are marked as copyrighted (§6.15.3[2]). The player has to execute an authentication handshake first (§4.10.2.2[2]).

So it's not just that you will get encrypted data that can't be played if you read the DVD; the drive won't send back the bits unless some program on your machine has authenticated itself to the drive, using some DVD-specific IOCTLs exposed by the Linux kernel (in this case, DVD_AUTH). That's why this manifests as an I/O error.

More information on how these IOCTLs work is available in this mailing list post from the person who implemented them, but basically they provide a way for userland software to perform the secret handshake with the DVD drive hardware.

VLC performs this secret handshake through libdvdcss, which in turn seems to do it in GetBusKey() in css.c. Presumably a standalone program that linked against libdvdcss could be written to unlock the drive for access as files, instead of relying on all of VLC. Once it's unlocked, the drive can't tell which program is reading from it, so it sends back the (still encrypted but now readable) bits to anyone, including dd or cp.

(Interestingly, the DVD IOCTLs are also the only real way to get the decryption key used to decrypt the data on the disk, once you've read it. If you are playing a copied directory of files, you don't have access to the IOCTLs to get the keys, so libdvdcss resorts to statistical cryptanalysis to crack the encryption.)

I think that the simplest answer is that dd, dd_rescue and ddrescue are not designed to defeat copy protection schemes. They make no assumptions about the format of the data and try to maintain the integrity of the whole of the original on disk data.

In the case of dd I suspect that it is terminating due to an intentional read error on the disk that is part of the copy protection scheme. It would help to confirm this if you included the commandline output from dd with your question. You may also find some read errors recorded in the dmesg command output.

You may get dd to copy more of the file by passing the noerror flag to it on the commandline. However you may find that this just leaves you with corruption in your final image.

I'm not sure why this works but opening the DVD first with VLC, just enough to view the menu, and then pausing lets dd work.