libdvdcss

[helo2804]

Hi folks,

I had a look at the libdvdcss source code 1.3.99 (originally at 1.2.9, though that seems to be fairly old) and came up with a few inconsistencies (at least I think so). Maybe you want to have a look at them:

(1) The implementation of the disc-key exploit (css.c:CrackDiscKey) appears to be flawed. It uses the first match. However, there might be several matches, then the genuine disc-key needs to be singled out.

(2) The documentation says (http://www.videolan.org/developers/libdvdcss/doc/html): If the default "key" method fails then the "disc" method is used. However, the implementation (css.c:395) runs the "title" method instead of the "disc" method.

(3) The implementation (css.c:AttackPattern) uses a variant of Ethan Hawkes plain-text prediction. There are two differences. First, the counter starts with (i+1) (css.c:1654) instead of (i). This leaves one byte unchecked. Second, the match may be less than 10 bytes (css.c:1670), so the 3rd parameter of css.c:RecoverTitleKey (css.c:1677) may not point to the required 10-byte plaintext (css.c:1377).

Well, nothing of this is serious. The flawed "disc" method is probably never used (because the user has to set up it manually) and probably not necessary at all (the internal player-keys will always succeed).

The skipped byte in the plain-text prediction may actually lead to a quicker title-key recovery. The only harm of the "less than 10 bytes" variant is some wasted CPU time (it would never match).

A few comments in addition:

(A) There is a stub (css.c:AttackPadding) which might be used in the future for an alternative way to recover title-keys. However, you may want to drop the stub. It's not worth the effort. There is only a extremely slight chance to recover a title-key this way after css.c:CrackTitleKey failed.

(B) Your list of player-keys does not cover the key b7:3f:d4:aa:14. Is there a reason?

(C) The implementation of authentication is slightly different to the one published by Derek Fawcus. Libdvdcss uses 4 instead of three tables (csstables.h:p_crypt_tab0..p_crypt_tab3). The sole purpose of p_crypt_tab2 appears to be to disguise the original values. Is there another reason?

Finally, please don't get me wrong. I'm very grateful for your efforts to implement this successful piece of software. It is highly appreciated and helped me greatly to unterstand CSS.

Cheers
helo2804

[Jean-Baptiste Kempf]

1) possible. Did you see a Disc where this was the case.
2) title and disc are different ways of storing the key, so that's the doc is not too wrong...
3) I'm surprised that there would be a big issue in this code, but you know, it's possible.

A) well, it does not hurt.
B) no idea.
C) I think this is a correct assumption.

Patches welcome

And also, a better documentation of how CSS work would be very nice and needy, after your work

[helo2804]

Hi Jean-Baptiste Kempf,

Thank you for the reply! Below you'll find my answers...

(1) VLC fails to play "Alien" (1979, EAN: 4010232109088) when libdvdcss uses DVDCSS_METHOD=disc. Libdvdcss reports (DVDCSS_VERBOSE=2):
...
cracking disc key ae:7d:2b:c0:b1
...
cracked disc key is 74:fb:c8:87:72

Obviously that's not the genuine disc-key. There is only garbled video.

With default method "key" everything is fine.

(Patches) I'd rather not. I stick with: never change a running system (especially one that I don't know good enough).

(Documentation) https://github.com/helo2804/css_study/r ... oc/CSS.pdf (it's a draft)

Cheers
Helo2804