From maroberts@dial.pipex.com Thu, 11 Nov 1999 11:40:29 +0000
Date: Thu, 11 Nov 1999 11:40:29 +0000
From: Mark A Roberts maroberts@dial.pipex.com
Subject: [Livid-dev] DVD Info
I've just subscribed to the list, mainly after seeing the news on
SlashDot and I'm looking for some more information on DVD layout - can
someone point me to some useful URLs ?
I am a telecommunications software developer, with some experience of
writing decryption software. As a result of browsing through a copy of
the css-auth code I've picked up, I can see a number of places where I
THINK I can optimise/speed up the routines. As I've done this just from
browsing through the code and without a DVD player in sight, I'd like
some real information on the system before I post some proposed changes.
Regards
Mark Roberts
From derek@spider.com Thu, 11 Nov 1999 12:30:45 +0000
Date: Thu, 11 Nov 1999 12:30:45 +0000
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] DVD Info
On Thu, Nov 11, 1999 at 11:40:29AM +0000, Mark A Roberts wrote:
> I've just subscribed to the list, mainly after seeing the news on
> SlashDot and I'm looking for some more information on DVD layout - can
> someone point me to some useful URLs ?
>
> I am a telecommunications software developer, with some experience of
> writing decryption software. As a result of browsing through a copy of
> the css-auth code I've picked up, I can see a number of places where I
> THINK I can optimise/speed up the routines. As I've done this just from
> browsing through the code and without a DVD player in sight, I'd like
> some real information on the system before I post some proposed changes.
There are a number of obvious changes that can be made. Three examples:
a) For a start use one version of the bit generator, this should work
8 bits at a time like the code in css-descramble.c.
b) The current 8 bit generator still does one of the LFSR's in forward
order, then bit reverses the data, it sould be altered to generate
the data directly in bit reversed order.
c) It may actually be faster if that LFSR was coded as shifts and masks
instead of as a table lookup (depends on the processor targeted).
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From maroberts@dial.pipex.com Thu, 11 Nov 1999 15:34:03 +0000
Date: Thu, 11 Nov 1999 15:34:03 +0000
From: Mark A Roberts maroberts@dial.pipex.com
Subject: [Livid-dev] DVD Info
Thanks for your reply.
Derek Fawcus wrote:
> There are a number of obvious changes that can be made. Three examples:
>
> a) For a start use one version of the bit generator, this should work
> 8 bits at a time like the code in css-descramble.c.
I've currently got an improved version of this [untried]. However I
saw what I think are some discrepencies between css-descramble and
css-auth,
hence I wanted some more information. One example is that there is some
similar
code in css-auth and css-descramble that MAY have a bug, assuming they
ARE
meant to do the same thing:
css-descramble:
lfsr0 = ((im[4] << 17) | (im[3] << 9) | (im[2] << 1)) + 8 - (im[2]&7);
============
css-auth:
lfsr0 = (s->b[0] << 17) | (s->b[1] << 9) | ((s->b[2] & ~7) << 1) | 8 |
(s->b[2] & 7);
==============
css-descramble doesn't APPEAR to mask im[2] in the same way as
css-auth does with s->b[2]. Also the '+8' can create a carry, rippling
up the
result, which doesn't appear to be in css-auth. I wasn't sure whether
this
was intentional or irrelevent.
> b) The current 8 bit generator still does one of the LFSR's in forward
> order, then bit reverses the data, it sould be altered to generate
> the data directly in bit reversed order.
As [Derek's ?] comments in the code indicated this was a good idea -
I've started looking at this.
> c) It may actually be faster if that LFSR was coded as shifts and masks
> instead of as a table lookup (depends on the processor targeted).
I don't think this is going to make a huge amount of difference -
swings and roundabouts IMHO. LUT values will probably be cached on a
lot
of processors when working through the calculations; some processors do
shifts in single clock cycles whilst others take multiple clock cycles,
so I don't think one method is better than the other, except shifts MAY
take up less code.
Regards
Mark Roberts
P.S. Any recommendations on DVD drives for a stock RH 6.1 system with
both IDE & SCSI interfaces ?
From alan@lxorguk.ukuu.org.uk Thu, 11 Nov 1999 15:43:19 +0000 (GMT)
Date: Thu, 11 Nov 1999 15:43:19 +0000 (GMT)
From: Alan Cox alan@lxorguk.ukuu.org.uk
Subject: [Livid-dev] DVD Info
> shifts in single clock cycles whilst others take multiple clock cycles,
> so I don't think one method is better than the other, except shifts MAY
> take up less code.
For a modern CPU the most important thing is making operations
not depend on each other and they are fetching from memory rather than
storing to it. That maximises parallelism on a current CPU.
Alan
From derek@spider.com Thu, 11 Nov 1999 15:59:58 +0000
Date: Thu, 11 Nov 1999 15:59:58 +0000
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] DVD Info
On Thu, Nov 11, 1999 at 03:34:03PM +0000, Mark A Roberts wrote:
> Thanks for your reply.
>
> css-descramble:
[snip ]
> css-auth:
[snip ]
That's one of the things I noticed. However it is only the initialiser,
thereafter the algorithm is the same. I had been intending to look closely
at the implications of that to see if it is actually relavent.
Actually it might reflect a bug that only certain people will see (but why
have I not seen it), if there are some people for whom the authentication
(or decryption) failes, they could try swapping one initialiser for the
other and see if it makes any difference.
> As [Derek's ?] comments in the code indicated this was a good idea -
> I've started looking at this.
Yup my comments. It'll save one table look up, replaceing it with (from
memory) an invert in the descramble code, and a no-op in one or both of
the other blocks.
Note some of the tables are large - there is one that's 512 bytes long
containing a repeated sequence of 8 bytes. This is simply to save masking
a 9 bit value down to 3 bits before use. Some of these could be very
relavent it terms of cache use. It all depends upon the nature of the
CPU you're running on.
Also if you've got enougth registers, the manipulation of the LFSR
simply as a set of shifts then xors should be faster. I can't remember
the details - but the ARM could find this usefule giving the form of
some of it's innstructions.
In terms of optimisation, one should (obviously) be working towards
making the stream descramble as fast as possible at the expense of the
other routines (sinc they're only run one and 20 times per disc change).
> I don't think this is going to make a huge amount of difference -
> swings and roundabouts IMHO. LUT values will probably be cached on a
> lot of processors when working through the calculations; some processors
> do shifts in single clock cycles whilst others take multiple clock cycles,
> so I don't think one method is better than the other, except shifts MAY
> take up less code.
Agreed. As I said it depends on the processor. It may be worth having
two versions of the code. One that does it in tables, the other with
shifts (they could then be tested at build time to see which is faster).
I did notice some major differences in the nature of the (x86) assembler
generated in this code from some very simple transformations of the
source. Now, I didn't test these for speed (since clarity and correctness
were my main concerns), but I think there is definitly room to hand
optimise that code.
> P.S. Any recommendations on DVD drives for a stock RH 6.1 system with
> both IDE & SCSI interfaces ?
I'm using a hacked RH 5.1 distribution. I've got a Tosh SD M1212 (ATAPI)
device connected to my (otherwise completely SCSI) fileserver. It works
quite nicely, it also worked well when it was the drive attached to a
workstation (on both SCSI based and ATA based machines).
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From maroberts@dial.pipex.com Thu, 11 Nov 1999 17:05:45 +0000
Date: Thu, 11 Nov 1999 17:05:45 +0000
From: Mark A Roberts maroberts@dial.pipex.com
Subject: [Livid-dev] DVD Info
Back to the original question - any URLs on DVD structure ?
Or have they all disappeared after the recent fracas ?
Regards
Mark Roberts
From derek@spider.com Thu, 11 Nov 1999 17:12:10 +0000
Date: Thu, 11 Nov 1999 17:12:10 +0000
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] DVD Info
On Thu, Nov 11, 1999 at 05:05:45PM +0000, Mark A Roberts wrote:
>
> Back to the original question - any URLs on DVD structure ?
Ask a specific question, you may magicaly receive a specific answer.
There are a lot of people earwigging on this list.
Matt - how many members?
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From jfbeam@bluetopia.net Thu, 11 Nov 1999 12:21:23 -0500 (EST)
Date: Thu, 11 Nov 1999 12:21:23 -0500 (EST)
From: Ricky Beam jfbeam@bluetopia.net
Subject: [Livid-dev] DVD Info
On Thu, 11 Nov 1999, Derek Fawcus wrote:
> Ask a specific question, you may magicaly receive a specific answer.
>There are a lot of people earwigging on this list.
>
> Matt - how many members?
329 Non-digested Members of Livid-dev
112 Digested Members of Livid-dev
--Ricky
From derek@spider.com Thu, 11 Nov 1999 17:23:36 +0000
Date: Thu, 11 Nov 1999 17:23:36 +0000
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] DVD Info
On Thu, Nov 11, 1999 at 12:21:23PM -0500, Ricky Beam wrote:
> On Thu, 11 Nov 1999, Derek Fawcus wrote:
> >There are a lot of people earwigging on this list.
> >
> > Matt - how many members?
>
> 329 Non-digested Members of Livid-dev
> 112 Digested Members of Livid-dev
So given the number of names I've noticed posting in the past, we have
a _lot_ of earwiggers!
Which represent the MPAA :-) [Hi folks]
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
PGP/GnuPG Keys available
From mpav@purdue.edu Sat, 13 Nov 1999 16:58:31 -0500 (EST)
Date: Sat, 13 Nov 1999 16:58:31 -0500 (EST)
From: Matthew R. Pavlovich mpav@purdue.edu
Subject: [Livid-dev] DVD Info
> Ask a specific question, you may magicaly receive a specific answer.
> There are a lot of people earwigging on this list.
>
> Matt - how many members?
447