Yrurtj

I tried dd, dd_rescue and ddrescue, all failed. I thought these tools bypass the filesystem and make a bitwise copy.

dd is fooled, it finishes but just produces a small file and states it's finished.

dd_rescuse and ddrescue are complaining about read errors and are intolerably slow. These tools can copy only a few MB in 10 minutes.

Why is this happening, why are these tools failing?

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.

I can confirm that opening the disc with VLC does bypass the protection. However, when using dd, I had to use this command after opening VLC (discovered by loading the disc and using the directory exposed in VLC).

dd if=/dev/sr0 of=image_of_disc.iso

Which is different from many posts I have read that say this command should work:

dd if=/dev/cdrom of=image_of_disc.iso - NON-WORKING

proof:

me@me:~$ dd if=/dev/cdrom of=/media/me/image_of_disc.iso

dd: error reading ‘/dev/cdrom’: Input/output error

103336+0 records in

103336+0 records out

52908032 bytes (53 MB) copied, 2.04212 s, 25.9 MB/s



me@me:~$ dd if=/dev/sr0 of=/media/me/image_of_disc.iso

dd: error reading ‘/dev/sr0’: Input/output error

2846992+0 records in

2846992+0 records out

1457659904 bytes (1.5 GB) copied, 314.351 s, 4.6 MB/s

me@me:~$ 

I hope this helps.

I can recommend a program called dvdbackup

• http://dvdbackup.sourceforge.net/

I can make a copy of the back-up of the DVD as folders. I don't think it makes an iso. So you need to take that step manually.

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.)