From derek@spider.com Sat, 2 Oct 1999 20:30:37 +0100
Date: Sat, 2 Oct 1999 20:30:37 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] CSS Stream Decoding
As I said earlier I've got the descrption working under Linux. I'm still
working through the code so as to understand the algorithm, and will publish
it when done. However I intend to hold back one vital bit of information.
More on that below.
I've not read the c't article (I had a look at the web site, but it
appears to only have old articles), but from the follows mentioned here
I've got the jist of what it said. From what I understand aboyt the
decryption algorith at the moment, the c't article is accurate.
The decryption is roughtly:
typedef unsigned char key40bits[5];
typedef unsigned char sector[2048];
sector disk_key;
key40bits title_key;
struct player_key {
int disk_key_offset;
key40bits key;
}
struct player_key player_key = {1234, {5, 6, 7, 8, 9}};
void decrypt_key(key40bits value, const key40bits key);
/* value is descrypted using key - value is modified */
void decrypt_sector(sector sec, const key40bits key);
key40bits key;
memcpy(key, disk_key + player_key.offset, 5);
decrypt_key(key, player_key.key);
decrypt_key(title_key, key);
for (each encrypted sector)
decrypt_sector(sec, key);
Where decrypt_sector and decypt_key are basically using the same algorithm.
The keys supplied simply seed a couple of PRNG's (they may be LFSRs - I've
not yet checked), these generate a bit sequence to ultimatly XOR against
and have a bit of bit shuffling.
Now given the above algorithm, there is room in the disk key burned onto
each disk for a number of player specific encrypted keys. I'd guess - as
someone else mentioned - that all of the keys were generated in advance,
and that they are simply allocated as needed.
The DVD generation plants will have special sortware, together with a
list of valid player keys, and title keys. From this they will generate
the disk keys when the disks are pressed. Thus if a key is invalidated,
then it will simply not be used in future. So I guess there will only
ever be ~ 400 PC decoders in the market at one time.
The reason I say PC decoders is that the consumer DVD players read
long sectors, with the keys appended. Now I don't know if these keys
will also be encrypted or if they are the ultimate decryption key passed
to decrypt_sector() above. However they could be the latter, or even
given that the players should be uncrackable, all players may have this
key encrypted with one shared key.
Thus it seems perfectly feasible to prevent specific software decryption
keys from being valid for future DVD pressings, or even (speculation on
my behalf) to prevent any future DVD pressings from playing on PC based
systems.
So we get to me having a valid key, offset and working code. Now I'll
publish the code, but don't intend to publish the key or offset yet. This
is for a few reasons:
1) dodsrip is out there - it will be reverse engineered and eventually
it's key obsoleted. I'd like to have this reverse engineered and
use it's key with the code I've got for the interim.
2) The key I've got may actually be the same as the key for dodsrip.
If it is then I'll simply release it. If not, then I'll release
it when dodsrip's key has been invalidated.
3) We don't yet have a player app. I'd like to delay releasing the key
until we have a working player, so that the range of titles available
when my key is published is increased.
4) It should be possible to brute force the keys that are valid for a
given disk. This would take some time, but would release a large
number of keys at once.
Anyway, that's all for now. Off for the weekend.
BTW: What I'll release on Monday are:
a patch to the NIST player to read from stdin.
an updated tstdvd program that gets the encrypted title key for a
specified file.
the stream decoding _algorithm_
So - anyone want to try cracking dodsrip.exe - I've had a quick look
and it's been obfuscated.
DF
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034
From derek@spider.com Sat, 2 Oct 1999 21:27:12 +0100
Date: Sat, 2 Oct 1999 21:27:12 +0100
From: Derek Fawcus derek@spider.com
Subject: [Livid-dev] Re: CSS Stream Decoding
On Sat, Oct 02, 1999 at 08:30:37PM +0100, Derek Fawcus wrote:
> So we get to me having a valid key, offset and working code. Now I'll
> publish the code, but don't intend to publish the key or offset yet. This
> is for a few reasons:
> 1) dodsrip is out there - it will be reverse engineered and eventually
> it's key obsoleted. I'd like to have this reverse engineered and
> use it's key with the code I've got for the interim.
> 2) The key I've got may actually be the same as the key for dodsrip.
> If it is then I'll simply release it. If not, then I'll release
> it when dodsrip's key has been invalidated.
Hmm. I've just heard from my supplier. It seems that this is the same
key as used by dodsrip. If I do release the key it makes the job of the
people trying to find out which key to disable easier.
However I speculated that I could crack dodsrip in a week, and it's been
out since 24th Sept. So I think I may just release the key at the end of
the month - TPTB should have figured it out by then.
Comments?
DF.
--
Derek Fawcus derek@spider.com
Spider Software Ltd. +44 (0) 131 475 7034