Re: Understanding The CSS

I think your reading of the C code is a little confused....

> if ((sec[0x14] & 0x30) > 0x00 )

tests bits 4 and 5 of the byte sec[0x14] by ANDing it with the mask 0x30,
it's nothing to do with the byte at offset 0x30.

Likewise

>                         sec[0x14] &= 0x8F;

modifies the byte sec[0x14] ("a &= b"  is C syntax for "a = a & b") by
setting bits 4,5 and 6 to zero, nothing to do with anything happening 143
bytes into the array..

Bruce


"Scott" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> Hi,
>
> I'm doing a small project at University on the Content Scrambling
> System and currently I'm looking at some example css decoding source
> code.  I was hoping someone may be able to clear something up for me
> regarding the reading of the MPEG vobs into a 'decss' type program
> before they are decoded.
>
> My question is regarding a snippet of some example css scrambling code
> from css_descramble.java that deals with PES (Packetized Elementary
> Stream) Control:
>
>
> if ((sec[0x14] & 0x30) > 0x00 ) // PES scrambling control
>                     {
>                         sec = jDeCSS.CSSdescramble(sec, key);
>                         sec[0x14] &= 0x8F;
>                     }
>
> After reading a 2048 byte stream sector from the DVD the css
> descramble program decides which part of the block to actually decode.
>  The first 128 bytes of each 2048 byte DVD stream is unencrypted, and
> part of this includes the MPEG pack header.  I'm trying to understand
> what the bytes upto 0x14 and then at 0x30 actually do in the above
> code.
>
> At a guess do the bytes between 0x14 and 0x2F contain the MPEG Pack
> header (up 28 bytes), then the final byte 0x30 includes either a 00
> for no encryption - i.e no need to decode, or a 01 for CSS encryption.
>  Does the IF statement basically check that there is an MPEG header -
> i.e actual data, and also check that it is encrypted?
>
> Just to add to the confusion, I'm also a little unsure what the 0x8F
> byte represents (see next bit of above code).  It represents 143 bytes
> into the stream? (0x8F in decimal is 143).
>
> Any help would be fantastic.
>
> Kind Regards,
> Scott