[MPlayer-users] Re: how does mplayer circumvent region protected (RPC-2) DVD drives?

[Arpi]

Hi,

> ok, now I got new questions (Sorry!)
argh

if you could accept things as-is once...

> > the key getting process has 2 major steps:
> > 
> > 1. getting the disc key
> > 2. getting the title key
> > 
> > for both steps, there are "white" and "black" method: ioctl() and crack.
> > the ioctl method is the default:
> > 
> > 1. try to get disc key via ioctl()
> >    [if this step fails, it will fallback to disc key crack (using 64mb hash),
> >    this can be also forced by DVDCSS_METHOD=disc]
> 
> In which cases does this step fail again? Afair the disc method 
> is only needed if one doesn't have the player keys...
huh? i don't think so...

> Aren't the player keys used for the disc key (I read it in the 
> README of libdvdcss, I know it's old)?
please quote these 'i read it ...' things

anyway it seems you are right here :)
checked again the code (css.c) it uses the player keys only in disc key
stuff. an dit doesn't even uses ioctl??? i'm also confused now...

after more RTFS, the steps are:

Get disc key:
1. get bus key (a long mix of ioctls and various key exchanges, crypto stuff)
2. read disc key (in crypted form)
3. (pre)decrypt disc key using bus key
4.a. decrypt disc key using player keys, fallback to:
4.b. crack disc key using 64m hash table

Get title key:
1. read title key using ioctl , if failed, then crack title key!
2. Decrypt title key using the bus key 
3. if key!=0 then decrypt title key with disc key

conclusions:
if you have to crack the title key, you don't need the disc key at all.

also, i was wrong about the title key cracking method.
there are 2 methods implemented in libdvdcss:
1. * The original Ethan Hawke (DeCSSPlus) attack (modified).
 * Tries to find a repeating pattern just before the encrypted part starts.
 * Then it guesses that the plain text for first encrypted bytes are
 * a contiuation of that pattern.

2. * Encrypted Padding_stream attack.
 * DVD specifies that there must only be one type of data in every sector.
 * Every sector is one pack and so must obviously be 2048 bytes long.
 * For the last pice of video data before a VOBU boundary there might not
 * be exactly the right amount of data to fill a sector. They one has to
 * pad the pack to 2048 bytes. For just a few bytes this is doen in the
 * header but for any large amount you insert a PES packet from the
 * Padding stream. This looks like 0x00 00 01 be xx xx ff ff ...
 * where xx xx is the length of the padding stream.

i mentioned 2. while it seems current libdvdcss doesn't use method 2 at all.
also i wonder who does method 1 work at all...

> Again, when does this step fail? Can it fail because the region 
> check is performed here (title request as read in another mail) or is the
> region
> check performed somewhere else?
when i try a region1 disc in region2 drive, the disc key reading (with
player keys) works, but it fails at readtitlekey.

> Again, aren't the player keys used in the first step and only 
yes

> the disc key is needed to access the hidden sectors and request 
> the title key afterwards (I read it in another mail before)?
yes

> +  <LI><B>title request:</B>With the title key <B>MPlayer</B> unlocks the
                                       ^^^^^ disc?

> +    <I>hidden sectors</I> and requests the title key via <CODE>ioctl()</CODE>
> +    to read, decrypt and play the files. The region protection of RPC-2 drives

actually it does ioctl first, and decrypt the value (got from the ioctl)
with the disc key.
i don't really understand your 'unlocks the hidden sectors'... what are the
'hidden sectors' ?

> +    is performed while requesting the title key and may fail on this drives.
> +  <LI><B>title:</B> This method is used if the title request failed and does
> +    not rely on a key exchange with the DVD drive. It uses a crypto attack to
> +    guess the title key by knowing the decrypted VOB content (VOB has very
> +    strict file format, so it can be predicted well).
> +    The method is also known as "known plaintext attack" or "DeCSS" (afaik).
no
the original DeCSS didn't used such methods, it was just the player keys stuff.
according the comments in the code, it was developed for DeCSSPlus.

> +    In rare cases this may fail because there is not enough encrypted data on
> +    the disc to perform a statistical attack or because the key changes in the
> +    middle of a title, but on the other hand it is the only way to decrypt a
> +    DVD stored on a hard disk, or a DVD with the wrong region on an RPC2 drive
> +    (slow).</LI>
yes


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu