[svlug] Fwd: Ripping DVDs ... and MythTV

Kristian Erik Hermansen kristian.hermansen at gmail.com
Fri Nov 30 11:47:24 PST 2007


Forwarded conversation
Subject: Ripping DVDs ... and MythTV
------------------------

From: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Date: Nov 21, 2007 7:09 PM
To: Jarod Wilson <jarod at wilsonet.com>, cjreyes at gmail.com
Cc: L-blu <discuss at blu.org>


Hey guys,

This came up at the meeting tonight.  Jarod mentioned that he rips
video DVD discs just using dd, but this is not really possible unless
they are unencrypted (you will get an ioerror).  So, for anyone that
wants to rip their CSS encrypted DVD discs (95% of them are), then you
need to use something like dvdbackup or k9copy.  Here are some links,
which are particular to Gentoo, but give you an idea of where to go
from there...
http://gentoo-wiki.com/HOWTO_Backup_a_DVD

Here is a new protection, which in addition to CSS, makes video DVD
decryption difficult...
http://en.wikipedia.org/wiki/ARccOS_Protection

And here's how to rip those discs...
http://gentoo-wiki.com/HOWTO_Backup_a_DVD#vlc

Carlos Reyes mentioned that he wanted to learn how to backup an
encrypted video DVD to XviD.  Here's how to do that...
http://gentoo-wiki.com/HOWTO_Rip_DVD_mencoder#Xvid

However, x264 is a more recent codec which may result in better rips
if you are starting from scratch...
http://gentoo-wiki.com/HOWTO_Rip_DVD_mencoder#H264_.28MPEG4_Part_10.29

And if you ever wanted to know how to convert any video (xvid, divx,
avi, mpeg, qt, mov, etc) to a DVD video, then here is how to do
that...
http://gentoo-wiki.com/HOWTO_Create_a_DVD:Encode

And finally, here is how to burn a DVD...
http://gentoo-wiki.com/HOWTO_Create_a_DVD:Burn

And for those of you who don't know about MythBuntu, it may be the
solution if you are worried that MythDora will not provide you a
consistent upgrade path.  All following MythBuntu releases claim that
they will be released in conjunction with the official Ubuntu releases
every six months, and that the upgrade process will be painless...
http://www.mythbuntu.org/
--
Kristian Erik Hermansen
----------
From: Jarod Wilson <jarod at wilsonet.com>
Date: Nov 21, 2007 8:25 PM
To: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Cc: cjreyes at gmail.com, L-blu <discuss at blu.org>


I believe the above is not quite correct. So far as I know, its only
arccos that makes dd fail. css is an entirely software-based
encryption, on top of the data on the disc. dd operates at the block
device level, css never comes into play. What arccos does is embed
corrupt blocks of data on the physical media, which is what makes dd
fail.

http://en.wikipedia.org/wiki/Content_Scramble_System
Not mentioned are dvdrip (different from lxdvdrip) or handbrake.

http://exit1.org/dvdrip/
http://handbrake.m0k.org/?article=download

I'm quite partial to handbrake myself (though the linux version isn't
nearly as slick as the Mac OS X version, can't comment on the Windows
version, never tried it, I don't do Windows).
I know a few of the guys on the mythbuntu team, they're good guys and
do good work. Would be nice if I could work on MythDora on company
time and keep it in sync w/Fedora, but there's that whole legal
thing, so Red Hat won't (officially) touch it w/a 10-ft pole... :\

--
Jarod Wilson
jarod at wilsonet.com


----------
From: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Date: Nov 21, 2007 8:43 PM
To: Jarod Wilson <jarod at wilsonet.com>
Cc: cjreyes at gmail.com, L-blu <discuss at blu.org>


Naw dude, the DVD drive hardware locks the disc content until your
software goes through an authentication process with the physical
drive firmware.  This is the very first thing libdvdread does when it
opens a CSS-encrypted video DVD for reading.  It goes through the
authentication process in order for the data to be available.  Jarod,
you have probably never seen the problem before because you have
always run a system which already has the libdvdread package installed
:-)  But back in 1999, all of us Linux geeks knew this stuff too well.
 DVD-John broke it for us...
What I said previously is documented in the wikipedia link you sent
yourself above.  The first step is authentication.  After you get past
that with libdvdread, only then do you get to start descrambling the
content :-)  I encourage you to go grab a copy of Red Hat 6 and see
for yourself if dd dumping a CSS-encrypted DVD was possible!
handbrake is excellent and I highly recommend it...so is dvd::rip
--
Kristian Erik Hermansen
----------
From: Derek Martin <invalid at pizzashack.org>
Date: Nov 22, 2007 11:52 PM
To: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Cc: Jarod Wilson <jarod at wilsonet.com>, L-blu <discuss at blu.org>,
cjreyes at gmail.com


dd is not linked against libdvdread:

$ ldd `which dd`
        linux-gate.so.1 =>  (0x00110000)
        librt.so.1 => /lib/librt.so.1 (0x00b19000)
        libc.so.6 => /lib/libc.so.6 (0x00702000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x0088f000)
        /lib/ld-linux.so.2 (0x006df000)

This means that when you use dd to copy a DVD, libdvdread is never
given a chance to come into play.  It just works because it's copying
raw bits off the DVD, which has to be possible, or else it would be
impossible to decrypt the data on the drive (the keys are on the
disc).  This is was well understood when Johansen created dvdcss: he
made the point that it was always possible to copy DVDs, and that his
software was only useful for actually making them playable on Free
OSes.

The key is that CSS considers the "disc content" to be the movie,
rather than the raw bits.  So yes, authentication needs to happen
before you can play the movie.  It doesn't need to happen before you
can read the raw bits.

Red Hat 6 might not copy DVDs, but if so only because hardware support
for DVD drives didn't exist when it was released.

--
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

----------
From: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Date: Nov 23, 2007 1:09 AM
To: discuss at blu.org, Kristian Erik Hermansen
<kristian.hermansen at gmail.com>, Jarod Wilson <jarod at wilsonet.com>,
cjreyes at gmail.com


And it never will be!  libdvdread is a questionable package, which is
not allowed in most jurisdictions.  It will never be installed by
default in a "legal" Linux distro.
I still believe you are incorrect, and please try to follow me on why
this is.  Sure, you think dd is just some sector copying "thing" and
that dumping data should be fine.  This is usually true.  However, you
have forgotten a key element.  The firmware on any DVD reading device
is required to identify when a CSS-encrypted DVD is inserted and go
into a more restrictive mode.  While in this mode, if the CSS
Authentication phase has not completed, and the region code identifier
is not valid, the disc will fail this phase.  While in an unauthorized
mode, the DVD reader will not allow the drive to return many sections
of the DVD video disc, which is why you will notice "input/output"
errors from dd.  Again, only once you have passed the authentication
phase can you fully dump the disc cleanly via dd, as now the firmware
will allow it.  After the disc is dumped, now you have a second phase
of decrypting the disc, titles, etc.

http://rg03.wordpress.com/2007/01/14/backing-up-dvd-movies-under-slackware/
I still believe you are incorrect here, so if you could please provide
valid support of your statement, or some proof of your claim, I would
be quite interested because it contradicts everything I have seen and
known about encrypted DVD videos since 1996...
Any kernel since 2.2.16 should be fine.  I think updates to the base
Red Hat 6 release included this kernel revision...
--
Kristian Erik Hermansen
----------
From: Derek Martin <invalid at pizzashack.org>
Date: Nov 23, 2007 4:15 AM
To: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Cc: discuss at blu.org, Jarod Wilson <jarod at wilsonet.com>, cjreyes at gmail.com


This document points to the Gentoo DVD backup howto, which mentions
that dd usually works.  As you point out, most DVDs are encrypted,
so dd should usually fail if you are correct, often enough that it
would not even be worth trying or mentioning in a document, or at
least mentioning that it would only work when the disc is not
encrypted.  Instead, the document says it ususally works.  When it
doesn't, you get I/O errors, which Jarod already explained:

  http://en.wikipedia.org/wiki/ARccOS_Protection

ARccOS != CSS.  A relatively small percentage of discs will have been
encoded with this protection, since it was a more recent development,
and has been discontinued due to hardware incompatibilities.

The existence of libdvd* on a system does not mean that they have been
used.  Since the dd command is not linked against those libraries,
then it has no means of making use of them -- barring support built
into the kernel, which I'm sure Linus would never allow -- so
basically any successful dd of an encrpyted DVD on any system proves
that CSS does not prevent dd from copying DVDs.
Besides the above, a quick search turned up a few:

http://www.lemuria.org/DeCSS/decss.html

Mentions that DVDs could be bit-wise copied, and sites a
Note that at the time deCSS  was written, DVD burners were not
available, so it was not possible to burn a full DVD using comodity
hardware and media at the time.  It was the writing process, not the
reading process that caused the difficulties referenced in this
document.  (The document references an interview on CNN which
clarifies the time line of the availability of DVD burners):

  http://transcripts.cnn.com/TRANSCRIPTS/0001/11/st.00.html

Jon Johansen (in 2000) mentions that copying was possible even with
the encryption in place.

  http://archives.cnn.com/2000/TECH/computing/01/31/johansen.interview.idg/

Article mentions (in 1999) that it was always possible to copy the encrypted
DVD to a hard drive.

  http://findarticles.com/p/articles/mi_m0FXG/is_12_12/ai_63973528

And also Jarod mentioned that he actually does this. :)

Technically, I haven't "proven" anything....  This is good enough for
me, but if one were so inclined, it shouldn't be too difficult to
test.  You just need a few known encrypted DVD that were released
before 2005 or so (so it will be certain not have ARccOS on it) and a
linux system with a dvd drive in it.  If you want to be thorough,
remove libdvdcss and libdvdread from your system first.  You can try
to play the DVD in Totem (or whatever) once libdvdread and dvdcss have
been removed, to verify it won't play without them.  The reason I say
you need a few DVDs is that dd is not terribly fault-tolerant...
scratches or bad spots on the disc (legitimate ones) will cause the dd
to fail with an I/O error.  Using noerror might help, but the disks
should be in as good condition as possible.  If any succeed, CSS does
not prevent dd from being able to rip DVDs.

----------
From: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Date: Nov 23, 2007 6:30 AM
To: discuss at blu.org, Kristian Erik Hermansen
<kristian.hermansen at gmail.com>, Jarod Wilson <jarod at wilsonet.com>,
cjreyes at gmail.com


CSS will still exist on ARcoOS discs.  And the authentication process
is still the same.  I understand that the protections serve very
different purposes.  I am already aware of that.  But, I come from a
long background of defeating software and hardware protections.  In
high school, around 1996, I began a 'chipping service' for fellow
classmates in my school with PlayStations.  I used to work at an
arcade, and they had soldering equipment there.  I learned all about
PSX copy protections, and eventually, I expanded my research into
generic copy protection, and also DVD protections.  Later on, I went
further into software protections, and reverse engineering.  ARccOS is
nothing new.  In PC game copying, it has been around for ages and
still exists today.  However, almost every protection can be overcome
by clever people.
Yes, I understand linking :-)  But I also hope you understand that
once the disc is in the drive, any program can initiate the CSS
authorization process.  Once that happens, and until the disc is
ejected, the firmware considers the disc "authorized"...
Page 12 of this patent talks about the DVD CSS process.  Notice how it
mentions that copying is not possible until authorization has taken
place...
http://www.google.com/patents?id=ICQSAAAAEBAJ&printsec=abstract&zoom=4&dq=dvd+css#PPA11,M1

Your link had this snippet...
"At this point in time, the only people for whom DVD piracy is
profitable are the professional pirates who own expensive equipment
and couldn't care less for any encryption, since they do bitwise
copies anyways, which means that their pirate copies are precise
duplicates of the originals, including the CSS encryption. The DVD
player will notice no difference between such a copy and the original
version. CSS can not stop this kind of piracy.
personal note"

Notice how it says /expensive equipment/.  I assume this meant
specialized reading hardware which would just produce a master glass
of the disc.  From there, you just start pressing discs as they have
always done in Asia...
"But there is a fly in the ointment. The protective code that prevents
a computer from copying the digital information from a DVD has been
cracked. Hackers in Norway broke through the digital shield and the
how-to information has been posted on the Internet. DVD's backers
aren't happy, but they're not particularly surprised."

Sounds to me like this shows copying data was not possible until that
program was written...
"Jon Johansen: Well, the authors of the other tools are, as far as I
know, anonymous. And [in] the charge, they say that the encryption is
copy protection. But that's not correct at all. Anyone with a little
computer experience knows that anything can be copied bit-by-bit with
the right equipment."

/with the right equipment/.  I assume he is not talking about an
off-the-shelf DVD-ROM drive here!  I bet he is talking about one with
a hacked firmware.  I used to have on DVD firmware myself, however, it
was a bit later, in 2001.  I was a very early adopter of one of the
very first affordable Pioneer 2x PC DVD-R recording devices.  They
were buggy as hell...
The articles still don't provide solid evidence, and actually, it
seems that the articles support my claim, many mentioning specialized
equipment...
/me trots off to locate a CSS-encrypted DVD-Video in his parents house...
--
Kristian Erik Hermansen
----------
From: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Date: Nov 23, 2007 6:52 AM
To: discuss at blu.org, Kristian Erik Hermansen
<kristian.hermansen at gmail.com>, Jarod Wilson <jarod at wilsonet.com>,
cjreyes at gmail.com


On Nov 23, 2007 6:30 AM, Kristian Erik Hermansen
root at khermans-laptop:~# dd if=/dev/dvd of=/tmp/march-of-the-penguins.iso
dd: reading `/dev/dvd': Input/output error
1760+0 records in
1760+0 records out
901120 bytes (901 kB) copied, 2.17189 seconds, 415 kB/s
root at khermans-laptop:~# ls -lsha /tmp/march-of-the-penguins.iso
884K -rw-r--r-- 1 root root 880K 2007-11-23 06:48 /tmp/march-of-the-penguins.iso

So, unless the whole MotP DVD is 885KB, and it is not
ARccOS-protected, I have just proven my point.  Feel free to refute it
if you like.  I am not perfect and have been wrong before.  I am only
pushing this issue because I am very interested in copy protection
mechanisms.  I don't mean to sound like a jerk by continuing to pursue
this thread!!!  I spent a lot of my youth futzing around with copy
protection mechanisms, not just focused on the PC.  Anyone remember
Sony's Macrovision protection on VHS tapes?
--
Kristian Erik Hermansen
----------
From: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Date: Nov 23, 2007 9:24 AM
To: discuss at blu.org, Kristian Erik Hermansen
<kristian.hermansen at gmail.com>, Jarod Wilson <jarod at wilsonet.com>,
cjreyes at gmail.com


I even went so far as to inspect the libdvdread3 code about five
minutes ago to see how it is all implemented.  After inspecting the
files, it really seems to indicate that there are in fact two stages.

1) CSS authentication (to unlock sectors for read accessibility)
2) CSS decrytion (to decrypt the titles, chapters, etc)

Take a look at the attached files.  You can get them by doing this...
$ apt-get source libdvdread3
--
Kristian Erik Hermansen
----------
From: Jarod Wilson <jarod at wilsonet.com>
Date: Nov 23, 2007 10:26 AM
To: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Cc: discuss at blu.org, cjreyes at gmail.com


I swear I wasn't nuts, I've definitely dd'd commercial dvds with css
on 'em in the past... So I tossed a few into my myth box and started
poking too. I believe we were both partially correct and both
partially wrong. :)

You're correct in that css does lock sectors of the disk, so if you
simply insert a dvd and try to dd, it'll at some point. However, if
you insert a dvd, fire up something like xine w/libdvdcss in place,
quit it, *then* do the dd, all is well, as those sectors have been
unlocked.

I've verified this by dd'ing a few of the commercial dvds in my
collection -- prior to xine'ing them, dd fails at some random point,
post-xine, they dd just fine. Thus I'm not crazy, and neither are
you. :)

--

----------
From: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Date: Nov 23, 2007 12:36 PM
To: Jarod Wilson <jarod at wilsonet.com>
Cc: discuss at blu.org, cjreyes at gmail.com


I'm glad we're not nuts!
Exactly :-)  Once libdvdcss authenticates the disc with the drive
firmware (via xine, mplayer, vlc, totem, etc), then you can do
anything you like until the disc is ejected.  Sometimes people have
DVD-autorun enabled, so that the movie starts playing with their
favorite player. but then they close the player and go dd the disc.
If that happens, the CSS authentication issue gets lost in the
background of your autorun app which utilized libdvdcss...
And now we're on the same page!!!  Btw, thanks for the MythTV talk
last night.  My little brother is thinking about setting up a MythDora
box at home for recording TV shows while he is at school (6th
grade)...
--
Kristian Erik Hermansen
----------
From: Jarod Wilson <jarod at wilsonet.com>
Date: Nov 23, 2007 1:30 PM
To: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Cc: discuss at blu.org, cjreyes at gmail.com


I figure that's exactly what happened in my case, and made me think
dd'ing Just Worked for non-arccos discs. I'd not actually done any dd
copying lately, mostly just been using handbrake.

So with a caveat of having to do something to triger decss'ing, dd
does seem to work with all my non-Sony-produced DVDs thus far (Casino
Royale was no-go).
Wish I'd prepared a little bit better, but had fun nonetheless.
Forgot to cover "things we'd like to fix/improve in the next version"
too.
Cool! Hopefully, it goes a bit better than my demo did... ;)
Is he a big fan of soaps or something? :)

--

----------
From: Kristian Erik Hermansen <kristian.hermansen at gmail.com>
Date: Nov 23, 2007 1:48 PM
To: Jarod Wilson <jarod at wilsonet.com>
Cc: discuss at blu.org, cjreyes at gmail.com


I think Sponge Bob is on or something...I'll have to ask him.  If it
is seriously for SOAPs, then my bro has a big problem!!!
--
Kristian Erik Hermansen
----------
From: Derek Martin <invalid at pizzashack.org>
Date: Nov 24, 2007 8:11 AM
To: discuss at blu.org


That's good to know.  I recently bought a bunch of used DVDs, and some
of them are in kind of rough shape.  I haven't felt the need to make
copies of any of my DVDs up to this point, but I think I may need to
copy those, and perhaps a few others I'd regret having to buy again if
they failed... :)


_______________________________________________
Discuss mailing list
Discuss at blu.org
http://lists.blu.org/mailman/listinfo/discuss




-- 
Kristian Erik Hermansen
"I have no special talent. I am only passionately curious."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvd_reader.c
Type: text/x-csrc
Size: 43276 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20071130/02f1e602/dvd_reader.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvd_reader.h
Type: text/x-chdr
Size: 12397 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20071130/02f1e602/dvd_reader-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvdread_internal.h
Type: text/x-chdr
Size: 630 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20071130/02f1e602/dvdread_internal.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvd_input.c
Type: text/x-csrc
Size: 10218 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20071130/02f1e602/dvd_input.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvd_input.h
Type: text/x-chdr
Size: 1903 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20071130/02f1e602/dvd_input-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20071130/02f1e602/PGP.bin


More information about the svlug mailing list