[libdvdcss-devel] cache: use libxdg-basedir and save cache into XDG-compliant location.
Bernard Lang
blvlc at datcha.net
Wed Mar 13 01:45:40 CET 2013
belatedly ...
Thanks Reimar for your detailed answer.
I would have replied earlier, but I had to check a few thing, and then
was caught in travel. Sorry.
I understand from your reply that libdvdcss should encounter no CSS
decoding problem if the drive is set on the region of the DVD. If
that is the case, then not being able to identify a key should be a
rare event, and not such a major issue for most users ?
And then, having a drive with no region set should be an inconvenience
rather than an advantage as I believed. Since most of my collection is
region 2, setting the drive to region 2 would ensure perfect decoding
of all DVDs for that region, and would not make things any worse for
other regions. I actually wanted to check that ... but I run into
hardware problems.
* Reimar Döffinger <Reimar.Doeffinger at gmx.de>, le 28-02-13, a écrit:
> If the video is long enough you should get decoding errors quite
> reliably with the wrong keys.
I had at least one long title that disproves that. Decoding that title
was strange in many respect. One key gave only the upper half of the
screen. Another decoding decoded correctly the last third
(approximately) of the title, but not the beginning.
I also have the correct key for decoding it fully.
I can retrieve the reference, as I write down nearly everything I do.
* Bernard Lang said:
> > Actually, I often managed to get the correct keys by other means, and
> > added them by hand in the cache. I confirm it is easier in text format.
* Reimar Döffinger replied:
> In the two cases I had that the keys were identical or simply increasing
> by one between the titles.
These are the more common cases, but there are other cases when keys
can be guessed. Coming back to previous remarks ...
> On 27/02/2013 08:19, Reimar Döffinger wrote:
> > There are also cases where titles are too short for cracking and thus
> > only manually created key files work (which btw. speaks against the
> > binary format, also look at e.g. libaacs, they too use text format
> > files).
* Diego Elio Pettenò <flameeyes at flameeyes.eu>, on 27-02-13, replied:
> Manually created how? If there is a way to "manually create" a key for
> short titles, maybe it's a good idea to just fix libdvdcss so that it
> can generate he same?
There is a big difference, I believe. I assume that the keys
identified by libdvdcss are always the correct keys (am I right ?)
But the various tricks for guessing keys are only hints as to what the
correct key might be. Some of the tricks are fairly reliable (in a
social sense, more than in a mathematical sense), and some others have
a much weaker reliability.
This is why I raised the question of whether one can reliably check
the correctness of a key. And the answer seems to be no.
These tricks are mostly based on regularities in key patterns, for a
DVD or for a collection of DVDs.
But there are possibly other ways. The titles than cannot be decoded
are often short, sometimes no more than 5 sectors. And it is sometimes
the case that those titles are nearly or completely identical to
others that have been decoded. This knwledge could help decode those
for which the key could not be identified. Sometimes, this happens for
longer titles too. Hence my question about identifying the key when
the decoded version of the title is available.
I am currently embedding my knowledge in a program, with a double
purpose :
- to avoid having to repeat by hand what can be done automatically;
- to write down what I learned, in a very precise way;
- to be more systematic in identifying regular structures, because
they are not always obvious. I actually even look for structures
that are very plausible, but that I did not see so far (but would
probably not recognize it I saw them);
- to write down in a log what I do;
- to do statistics about the way CSS is used, even when I have no
decoding problem.
But this is still very experimental, and I am not sure how useful.
As I said, I have some titles that are not decoded by libdvdcss for
about 30% of the DVDs. These titles are often of lesser importance.
If that can be completely solved by a proper setting of the drive
zone, guessing the missing keys when the drive zone is not properly
set seems a minor problem.
I would appreciate opinions on this.
Cordialement
Bernard
* Reimar Döffinger <Reimar.Doeffinger at gmx.de>, le 28-02-13, a écrit:
> On Wed, Feb 27, 2013 at 01:21:42PM +0100, Bernard Lang wrote:
> > Using my drive, with no region set, I found that about 25 to 30% of
> > the DVDs have a title that cannot be found by libdvdcss (though I am
> > not sure whether the region setting of the drive has a responsibility
> > in this).
>
> When the region is not set, libdvdcss can't just ask the drive to
> give it the keys.
> Though I believe some drives cause even more trouble when the region
> is not set, breaking even the fallback methods of cracking the keys -
> though maybe I misremember.
>
> > * Jean-Baptiste Kempf <jb at videolan.org>, on 27-02-13, replied:
> > > Some people actually use that in dvdcss?
> >
> > I do.
> >
> > Actually, I often managed to get the correct keys by other means, and
> > added them by hand in the cache. I confirm it is easier in text format.
>
> In the two cases I had that the keys were identical or simply increasing
> by one between the titles.
>
> > My first question is the following. Given a title and a CSS key, is
> > there a reliable way (other than viewing, which is not always
> > adequate) to check that it is the proper key to decode that title. My
> > experience is that some titles will be 'decoded' (?) without fuss by
> > many keys, and the bad keys will produce garbage without any
> > noticeable protest from the decoding software (libdvdcss, not always
> > within VLC).
>
> If the video is long enough you should get decoding errors quite
> reliably with the wrong keys. However I believe there is no really
> certain way to detect if they key is correct (if there is, we definitely
> should be using it in DVDCSS, I had issues where it came up with the
> wrong key, though I think they were never reproducible enough to debug,
> possibly related to drive read errors).
>
> > Another question is the following. Given a coded title and a decoded
> > one. Is it possible to check that the first is an encoded version of
> > the second. Is it possible to identify more easily the key ? Can that
> > be somewhat easier than finding the key with only the encoded version
> > of the title. I have met that situation in practice.
>
> As far as I can see the most problematic step of the cracking is to
> figure out what the decoded data looks like, see the function
> AttackPattern in the code.
> Since they key is only 40 bit cracking it is fairly trivial if you
> know what some encrypted data should decrypt to.
>
> > My last question concerns my DVD player. I do not wish to change
> > the (absent) region setting, as I have DVDs from several different
> > regions (some films are just not published in region 2).
>
> Setting the region should not make anything worse when it comes
> to playing DVDs from a different region as far as I know.
> For most drives there are also ways to either disable RPC or
> at least allowing to change the region as often as you want.
>
> > Would
> > libdvdcss be able to discover more keys if the player were set to the
> > region corresponding to the DVD.
>
> In that case it should be able to easily get all keys, just like
> a proper DVD player would.
--
Après la bulle Internet, la bulle financière ...
Et bientôt la bulle des brevets
http://www.strategie.gouv.fr/system/files/noteveille81.pdf
http://www.huffingtonpost.com/brian-kahin/the-patent-bubble_b_129232.html
la gestion des catastrophes comme principe de gouvernement
Bernard.Lang at datcha.net ,_ /\o \o/ gsm +33 6 6206 1693
http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ tel +33 1 3056 1693
Je n'exprime que mon opinion - I express only my opinion
CAGED BEHIND WINDOWS or FREE WITH LINUX
More information about the libdvdcss-devel
mailing list