Slashdot Mirror
DVD CCA Emergency Hearing to seal DeCSS
Anonymous Coward writes "The DVD CCA notified the defense lawyers on Tuesday that they
are seeking an emergency ex parte motion to seal Hoy Exhibit
B, which has been up at John
Young's Cryptome for days, and was mentioned on Slashdot on
Monday. This will be heard at an emergency hearing at 8:30 a.m. Wednesday, Jan. 26, at
the usual Santa Clara County Courthouse in San Jose, in Judge
Elfving's court. If you're reading Slashdot before breakfast
and you're near San Jose, it's time to come on down!"
It should be fairly easy to make a RAW rom for the DVD reader, read raw data, and create a new one in exactly the same way.
No, No, NO, It is not 'fairly easy' to do that. The DVD drives you buy for home use cannot read the tracks that store the keys in a 'normal' way. Only when playing back a movie, and only the key that corrisponds with the only player. Also, DVD-writers will not be able to write to those sectors. It *isn't* posible, and it never has been. Why do you people persist I stating this? Just beacuse some guy on TV couldn't articulate it dosn't mean it isn't true... *gah*.
[ c h a d o k e r e ]
ReadThe ReflectionEngine, a cyberpunk style n
You're thinking of trademark law, not trade secret law. IANAL, but as far as I know, the only trade secret laws apply to employees and other people or entities that have legitimate access to the secret. They can be prosecuted for revealing the secret. In this case, trade secret law could possibly be applied to Xing, since they were not careful and left their key unencrypted which made DeCSS possible (or at least easier). That probably violated an NDA or three. Other than that, once the secret is out, it's not a secret anymore. The DeCSS guys didn't reveal any trade secret, Xing did. They just took advantage of Xing's mistake, and they did it in a legal way since even the DMCA allows you bypass security measures in order to achieve interoperability. That's why this whole case is such a crock. But that won't stop it from happening. There's too much money behind it for it to stop.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
The code of DeCSS is all over the net now and even the MPAA can't hope to put it out of the world again. AFAIK it is planned to implement a new encryption scheme anyway, so the question is what they are trying to achieve by going to court:
Obviously the MPAA wants to intimidate others so there will be no DeCSS for their next encryption. I don't think that they will succeed though, because so many people have to know how to implement decrytion to build a player that the information will leak sooner or later, because of some carelesness. So the question is only via which channels the next DeCSS will be distributed. The decision to sell some Linux player for DVD's would probably help more, since then there is much less motivation to implement and distribute such a program.
The second reason for going to court is probably to test the leagal grounds and set some precedent. In my opinion this makes the current case very important, because many other cases might be influenced by the outcome of this one.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
It seems like part of the strategy here is to keep the community off-balance by scheduling everything too fast for us to keep up. Why does our legal system allow for this?
I'll stand by my previous statement that the present motion is both routine and not unconcionable. In a legal action disputing whether subject matter is trade secret, it is routine and proper that publicly availalbe files containing the subject matter of the lawsuit be redacted to exclude the subject matter of the suit. When this is overlooked, for whatever reason, it is common to make an emergency motion to seal it -- and such motions are commonly granted.
You may choose to take the position that anything that is done by MPAA concerning the lawsuit is unconcionable -- this is a common view in this community. However, going ballistic over routine motions will simply get you ignored as one who "always cries wolf" when you go ballistic over the real ones.
Assume for the sake of the argument that the subject matter *WAS* a trade secret. If so, having the court files containing the subject matter (if indeed it did contain the subject matter) laid open to the public is a grievous technical error that should be immediately corrected.
The motion was routinely made and probably will be routinely granted. I can't think of any meaningful defense to this motion(particularly since a P.I. was already granted) except, perhaps, that the declaration does not contain subject matter claimed to be secret. In that case, no more than a few hours notice is necessary to prepare the appropriate papers and to appear for hearing.
And no, I'm not defending the plaintiff's position. I'm not fond of what they are doing either. I'm just saying it would be best for the credibility of the committee to call a spade a spade and save their vitreol for the really bad stuff.
There is an amazing power in the advocacy of making concessions. If you give to others what is theirs, particularly before the Court, then when you do ask for things, the Court sits at attention. If you oppose EVERY motion, and gainsay EVERY argument, you will eventually get tuned out. This is particularly true when, looking at things practically and objectively, you can't win the motion.
Unless facts and California public records and trade secret law is substantially different from the reports, it is time to say, "Your honor, assuming their allegations were true, of course this motion must be granted -- the fact that they let this happen is proof, indeed an admission, that this plaintiff doesn't take reasonable precautions to preserve secrecy of that information, and that is why we must ultimately prevail on the merits. But for the record, we do not oppose this emergency motion."
To win in disputes like these, you have to stay very cool, you have to judge the judge, and you have to stay credible. I am reminded of an excellent story about the New York case in which West Publications tried to keep others from making a database with citations to legal materials in West Reporters, using page numbers. After West's lawyer argued at length (well over the allotted hour), the exhausted Judge turned to the defendant and a hero lawyer said something like the following:
"Your honor, the plaintiff claims copyright protection of the numbers 1, 2, 3 and so forth in sequence. We find this an astonishing position and have nothing to add to our briefs."
He then did the most important thing a lawyer can do -- "he sat down." He knew when it was important to speak, and when to shut up. Interestingly, that lawyer won that case with that brief argument, when several other lawyers (including a friend of mine who handled a case in Minnesota on the same issues with a different defendant) failed on the same issue.
Stay cool! Direct your rage appropriately. Ignore the silliness when they overreach and it doesn't matter, or look for ways to use your advantage at another time. Then, when it is right, use it to best effect. Advocacy is much more effective that way.
A Norwegian Linux web site, have started a petition against the treatment of Jon Johanson Sign the petition against the treatment received by Jon Johanson! http://linuxguiden.linpro.no/protesteng.php
No, if the records are sealed, it's not legal to distribute the info. That's why they're having the hearing. The judge will likely seal the records as a matter of course.
People outside of the US are not affected in any way.
YOU CAN'T STOP ME!!!!!!!!!!!!!!!!!
/*
/*
/* This shuffles the bits in varient to make perm_varient such that
/* This shuffles the bits in varient to make perm_varient such that
/*
/* In order to ensure that the LFSR works we need to ensure that the
/*
/* Feed the secret into the input values such that
/* This term is used throughout the following to
/* Now the actual blocks doing the encryption. Each
css-auth.h
----------
typedef unsigned char byte;
struct block {
byte b[5];
};
extern void CryptKey1(int varient, byte const *challenge, struct block *key);
extern void CryptKey2(int varient, byte const *challenge, struct block *key);
extern void CryptBusKey(int varient, byte const *challenge, struct block *key);
css-auth.c
----------
* Copyright (C) 1999 Derek Fawcus
*
* This code may be used under the terms of Version 2 of the GPL,
* read the file COPYING for details.
*
*/
* These routines do some reordering of the supplied data before
* calling engine() to do the main work.
*
* The reordering seems similar to that done by the initial stages of
* the DES algorithm, in that it looks like it's just been done to
* try and make software decoding slower. I'm not sure that it
* actually adds anything to the security.
*
* The nature of the shuffling is that the bits of the supplied
* parameter 'varient' are reorganised (and some inverted), and
* the bytes of the parameter 'challenge' are reorganised.
*
* The reorganisation in each routine is different, and the first
* (CryptKey1) does not bother of play with the 'varient' parameter.
*
* Since this code is only run once per disk change, I've made the
* code table driven in order to improve readability.
*
* Since these routines are so similar to each other, one could even
* abstract them all to one routine supplied a parameter determining
* the nature of the reordering it has to do.
*/
#include "css-auth.h"
typedef unsigned long u32;
static void engine(int varient, byte const *input, struct block *output);
void CryptKey1(int varient, byte const *challenge, struct block *key)
{
static byte perm_challenge[] = {1,3,0,7,5, 2,9,6,4,8};
byte scratch[10];
int i;
for (i = 9; i >= 0; --i)
scratch[i] = challenge[perm_challenge[i]];
engine(varient, scratch, key);
}
* 4 -> !3
* 3 -> 4
* varient bits: 2 -> 0 perm_varient bits
* 1 -> 2
* 0 -> !1
*/
void CryptKey2(int varient, byte const *challenge, struct block *key)
{
static byte perm_challenge[] = {6,1,9,3,8, 5,7,4,0,2};
static byte perm_varient[] = {
0x0a, 0x08, 0x0e, 0x0c, 0x0b, 0x09, 0x0f, 0x0d,
0x1a, 0x18, 0x1e, 0x1c, 0x1b, 0x19, 0x1f, 0x1d,
0x02, 0x00, 0x06, 0x04, 0x03, 0x01, 0x07, 0x05,
0x12, 0x10, 0x16, 0x14, 0x13, 0x11, 0x17, 0x15};
byte scratch[10];
int i;
for (i = 9; i >= 0; --i)
scratch[i] = challenge[perm_challenge[i]];
engine(perm_varient[varient], scratch, key);
}
* 4 -> 0
* 3 -> !1
* varient bits: 2 -> !4 perm_varient bits
* 1 -> 2
* 0 -> 3
*/
void CryptBusKey(int varient, byte const *challenge, struct block *key)
{
static byte perm_challenge[] = {4,0,3,5,7, 2,8,6,1,9};
static byte perm_varient[] = {
0x12, 0x1a, 0x16, 0x1e, 0x02, 0x0a, 0x06, 0x0e,
0x10, 0x18, 0x14, 0x1c, 0x00, 0x08, 0x04, 0x0c,
0x13, 0x1b, 0x17, 0x1f, 0x03, 0x0b, 0x07, 0x0f,
0x11, 0x19, 0x15, 0x1d, 0x01, 0x09, 0x05, 0x0d};
byte scratch[10];
int i;
for (i = 9; i >= 0; --i)
scratch[i] = challenge[perm_challenge[i]];
engine(perm_varient[varient], scratch, key);
}
* We use two LFSR's (seeded from some of the input data bytes) to
* generate two streams of pseudo-random bits. These two bit streams
* are then combined by simply adding with carry to generate a final
* sequence of pseudo-random bits which is stored in the buffer that
* 'output' points to the end of - len is the size of this buffer.
*
* The first LFSR is of degree 25, and has a polynomial of:
* x^13 + x^5 + x^4 + x^1 + 1
*
* The second LSFR is of degree 17, and has a (primitive) polynomial of:
* x^15 + x^1 + 1
*
* I don't know if these polynomials are primitive modulo 2, and thus
* represent maximal-period LFSR's.
*
*
* Note that we take the output of each LFSR from the new shifted in
* bit, not the old shifted out bit. Thus for ease of use the LFSR's
* are implemented in bit reversed order.
*
*/
static void generate_bits(byte *output, int len, struct block const *s)
{
u32 lfsr0, lfsr1;
byte carry;
* initial values are non-zero. Thus when we initialise them from
* the seed, we ensure that a bit is set.
*/
lfsr0 = (s->b[0] b[1] b[2] & ~7) b[2] & 7);
lfsr1 = (s->b[3] b[4];
++output;
carry = 0;
do {
int bit;
byte val;
for (bit = 0, val = 0; bit > 24) ^ (lfsr0 >> 21) ^ (lfsr0 >> 20) ^ (lfsr0 >> 12)) & 1;
lfsr0 = (lfsr0 > 16) ^ (lfsr1 >> 2)) & 1;
lfsr1 = (lfsr1 > 1) & 1)
combined = !o_lfsr1 + carry + !o_lfsr0;
carry = BIT1(combined);
val |= BIT0(combined) 0);
}
static byte Secret[];
static byte Varients[];
static byte Table0[];
static byte Table1[];
static byte Table2[];
static byte Table3[];
* This encryption engine implements one of 32 variations
* one the same theme depending upon the choice in the
* varient parameter (0 - 31).
*
* The algorithm itself manipulates a 40 bit input into
* a 40 bit output.
* The parameter 'input' is 80 bits. It consists of
* the 40 bit input value that is to be encrypted followed
* by a 40 bit seed value for the pseudo random number
* generators.
*/
static void engine(int varient, byte const *input, struct block *output)
{
byte cse, term, index;
struct block temp1;
struct block temp2;
byte bits[30];
int i;
* we alter the seed to the LFSR's used above, then
* generate the bits to play with.
*/
for (i = 5; --i >= 0; )
temp1.b[i] = input[5 + i] ^ Secret[i] ^ Table2[i];
generate_bits(&bits[29], sizeof bits, &temp1);
* select one of 32 different variations on the
* algorithm.
*/
cse = Varients[varient] ^ Table2[varient];
* of these works on 40 bits at a time and are quite
* similar.
*/
for (i = 5, term = 0; --i >= 0; term = input[i]) {
index = bits[25 + i] ^ input[i];
index = Table1[index] ^ ~Table2[index] ^ cse;
temp1.b[i] = Table2[index] ^ Table3[index] ^ term;
}
temp1.b[4] ^= temp1.b[0];
for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
index = bits[20 + i] ^ temp1.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;
temp2.b[i] = Table2[index] ^ Table3[index] ^ term;
}
temp2.b[4] ^= temp2.b[0];
for (i = 5, term = 0; --i >= 0; term = temp2.b[i]) {
index = bits[15 + i] ^ temp2.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;
index = Table2[index] ^ Table3[index] ^ term;
temp1.b[i] = Table0[index] ^ Table2[index];
}
temp1.b[4] ^= temp1.b[0];
for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
index = bits[10 + i] ^ temp1.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;
index = Table2[index] ^ Table3[index] ^ term;
temp2.b[i] = Table0[index] ^ Table2[index];
}
temp2.b[4] ^= temp2.b[0];
for (i = 5, term = 0; --i >= 0; term = temp2.b[i]) {
index = bits[5 + i] ^ temp2.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;
temp1.b[i] = Table2[index] ^ Table3[index] ^ term;
}
temp1.b[4] ^= temp1.b[0];
for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
index = bits[i] ^ temp1.b[i];
index = Table1[index] ^ ~Table2[index] ^ cse;
output->b[i] = Table2[index] ^ Table3[index] ^ term;
}
}
static byte Varients[] = {
0xB7, 0x74, 0x85, 0xD0, 0xCC, 0xDB, 0xCA, 0x73,
0x03, 0xFE, 0x31, 0x03, 0x52, 0xE0, 0xB7, 0x42,
0x63, 0x16, 0xF2, 0x2A, 0x79, 0x52, 0xFF, 0x1B,
0x7A, 0x11, 0xCA, 0x1A, 0x9B, 0x40, 0xAD, 0x01};
static byte Secret[] = {0x55, 0xD6, 0xC4, 0xC5, 0x28};
static byte Table0[] = {
0xB7, 0xF4, 0x82, 0x57, 0xDA, 0x4D, 0xDB, 0xE2,
0x2F, 0x52, 0x1A, 0xA8, 0x68, 0x5A, 0x8A, 0xFF,
0xFB, 0x0E, 0x6D, 0x35, 0xF7, 0x5C, 0x76, 0x12,
0xCE, 0x25, 0x79, 0x29, 0x39, 0x62, 0x08, 0x24,
0xA5, 0x85, 0x7B, 0x56, 0x01, 0x23, 0x68, 0xCF,
0x0A, 0xE2, 0x5A, 0xED, 0x3D, 0x59, 0xB0, 0xA9,
0xB0, 0x2C, 0xF2, 0xB8, 0xEF, 0x32, 0xA9, 0x40,
0x80, 0x71, 0xAF, 0x1E, 0xDE, 0x8F, 0x58, 0x88,
0xB8, 0x3A, 0xD0, 0xFC, 0xC4, 0x1E, 0xB5, 0xA0,
0xBB, 0x3B, 0x0F, 0x01, 0x7E, 0x1F, 0x9F, 0xD9,
0xAA, 0xB8, 0x3D, 0x9D, 0x74, 0x1E, 0x25, 0xDB,
0x37, 0x56, 0x8F, 0x16, 0xBA, 0x49, 0x2B, 0xAC,
0xD0, 0xBD, 0x95, 0x20, 0xBE, 0x7A, 0x28, 0xD0,
0x51, 0x64, 0x63, 0x1C, 0x7F, 0x66, 0x10, 0xBB,
0xC4, 0x56, 0x1A, 0x04, 0x6E, 0x0A, 0xEC, 0x9C,
0xD6, 0xE8, 0x9A, 0x7A, 0xCF, 0x8C, 0xDB, 0xB1,
0xEF, 0x71, 0xDE, 0x31, 0xFF, 0x54, 0x3E, 0x5E,
0x07, 0x69, 0x96, 0xB0, 0xCF, 0xDD, 0x9E, 0x47,
0xC7, 0x96, 0x8F, 0xE4, 0x2B, 0x59, 0xC6, 0xEE,
0xB9, 0x86, 0x9A, 0x64, 0x84, 0x72, 0xE2, 0x5B,
0xA2, 0x96, 0x58, 0x99, 0x50, 0x03, 0xF5, 0x38,
0x4D, 0x02, 0x7D, 0xE7, 0x7D, 0x75, 0xA7, 0xB8,
0x67, 0x87, 0x84, 0x3F, 0x1D, 0x11, 0xE5, 0xFC,
0x1E, 0xD3, 0x83, 0x16, 0xA5, 0x29, 0xF6, 0xC7,
0x15, 0x61, 0x29, 0x1A, 0x43, 0x4F, 0x9B, 0xAF,
0xC5, 0x87, 0x34, 0x6C, 0x0F, 0x3B, 0xA8, 0x1D,
0x45, 0x58, 0x25, 0xDC, 0xA8, 0xA3, 0x3B, 0xD1,
0x79, 0x1B, 0x48, 0xF2, 0xE9, 0x93, 0x1F, 0xFC,
0xDB, 0x2A, 0x90, 0xA9, 0x8A, 0x3D, 0x39, 0x18,
0xA3, 0x8E, 0x58, 0x6C, 0xE0, 0x12, 0xBB, 0x25,
0xCD, 0x71, 0x22, 0xA2, 0x64, 0xC6, 0xE7, 0xFB,
0xAD, 0x94, 0x77, 0x04, 0x9A, 0x39, 0xCF, 0x7C};
static byte Table1[] = {
0x8C, 0x47, 0xB0, 0xE1, 0xEB, 0xFC, 0xEB, 0x56,
0x10, 0xE5, 0x2C, 0x1A, 0x5D, 0xEF, 0xBE, 0x4F,
0x08, 0x75, 0x97, 0x4B, 0x0E, 0x25, 0x8E, 0x6E,
0x39, 0x5A, 0x87, 0x53, 0xC4, 0x1F, 0xF4, 0x5C,
0x4E, 0xE6, 0x99, 0x30, 0xE0, 0x42, 0x88, 0xAB,
0xE5, 0x85, 0xBC, 0x8F, 0xD8, 0x3C, 0x54, 0xC9,
0x53, 0x47, 0x18, 0xD6, 0x06, 0x5B, 0x41, 0x2C,
0x67, 0x1E, 0x41, 0x74, 0x33, 0xE2, 0xB4, 0xE0,
0x23, 0x29, 0x42, 0xEA, 0x55, 0x0F, 0x25, 0xB4,
0x24, 0x2C, 0x99, 0x13, 0xEB, 0x0A, 0x0B, 0xC9,
0xF9, 0x63, 0x67, 0x43, 0x2D, 0xC7, 0x7D, 0x07,
0x60, 0x89, 0xD1, 0xCC, 0xE7, 0x94, 0x77, 0x74,
0x9B, 0x7E, 0xD7, 0xE6, 0xFF, 0xBB, 0x68, 0x14,
0x1E, 0xA3, 0x25, 0xDE, 0x3A, 0xA3, 0x54, 0x7B,
0x87, 0x9D, 0x50, 0xCA, 0x27, 0xC3, 0xA4, 0x50,
0x91, 0x27, 0xD4, 0xB0, 0x82, 0x41, 0x97, 0x79,
0x94, 0x82, 0xAC, 0xC7, 0x8E, 0xA5, 0x4E, 0xAA,
0x78, 0x9E, 0xE0, 0x42, 0xBA, 0x28, 0xEA, 0xB7,
0x74, 0xAD, 0x35, 0xDA, 0x92, 0x60, 0x7E, 0xD2,
0x0E, 0xB9, 0x24, 0x5E, 0x39, 0x4F, 0x5E, 0x63,
0x09, 0xB5, 0xFA, 0xBF, 0xF1, 0x22, 0x55, 0x1C,
0xE2, 0x25, 0xDB, 0xC5, 0xD8, 0x50, 0x03, 0x98,
0xC4, 0xAC, 0x2E, 0x11, 0xB4, 0x38, 0x4D, 0xD0,
0xB9, 0xFC, 0x2D, 0x3C, 0x08, 0x04, 0x5A, 0xEF,
0xCE, 0x32, 0xFB, 0x4C, 0x92, 0x1E, 0x4B, 0xFB,
0x1A, 0xD0, 0xE2, 0x3E, 0xDA, 0x6E, 0x7C, 0x4D,
0x56, 0xC3, 0x3F, 0x42, 0xB1, 0x3A, 0x23, 0x4D,
0x6E, 0x84, 0x56, 0x68, 0xF4, 0x0E, 0x03, 0x64,
0xD0, 0xA9, 0x92, 0x2F, 0x8B, 0xBC, 0x39, 0x9C,
0xAC, 0x09, 0x5E, 0xEE, 0xE5, 0x97, 0xBF, 0xA5,
0xCE, 0xFA, 0x28, 0x2C, 0x6D, 0x4F, 0xEF, 0x77,
0xAA, 0x1B, 0x79, 0x8E, 0x97, 0xB4, 0xC3, 0xF4};
static byte Table2[] = {
0xB7, 0x75, 0x81, 0xD5, 0xDC, 0xCA, 0xDE, 0x66,
0x23, 0xDF, 0x15, 0x26, 0x62, 0xD1, 0x83, 0x77,
0xE3, 0x97, 0x76, 0xAF, 0xE9, 0xC3, 0x6B, 0x8E,
0xDA, 0xB0, 0x6E, 0xBF, 0x2B, 0xF1, 0x19, 0xB4,
0x95, 0x34, 0x48, 0xE4, 0x37, 0x94, 0x5D, 0x7B,
0x36, 0x5F, 0x65, 0x53, 0x07, 0xE2, 0x89, 0x11,
0x98, 0x85, 0xD9, 0x12, 0xC1, 0x9D, 0x84, 0xEC,
0xA4, 0xD4, 0x88, 0xB8, 0xFC, 0x2C, 0x79, 0x28,
0xD8, 0xDB, 0xB3, 0x1E, 0xA2, 0xF9, 0xD0, 0x44,
0xD7, 0xD6, 0x60, 0xEF, 0x14, 0xF4, 0xF6, 0x31,
0xD2, 0x41, 0x46, 0x67, 0x0A, 0xE1, 0x58, 0x27,
0x43, 0xA3, 0xF8, 0xE0, 0xC8, 0xBA, 0x5A, 0x5C,
0x80, 0x6C, 0xC6, 0xF2, 0xE8, 0xAD, 0x7D, 0x04,
0x0D, 0xB9, 0x3C, 0xC2, 0x25, 0xBD, 0x49, 0x63,
0x8C, 0x9F, 0x51, 0xCE, 0x20, 0xC5, 0xA1, 0x50,
0x92, 0x2D, 0xDD, 0xBC, 0x8D, 0x4F, 0x9A, 0x71,
0x2F, 0x30, 0x1D, 0x73, 0x39, 0x13, 0xFB, 0x1A,
0xCB, 0x24, 0x59, 0xFE, 0x05, 0x96, 0x57, 0x0F,
0x1F, 0xCF, 0x54, 0xBE, 0xF5, 0x06, 0x1B, 0xB2,
0x6D, 0xD3, 0x4D, 0x32, 0x56, 0x21, 0x33, 0x0B,
0x52, 0xE7, 0xAB, 0xEB, 0xA6, 0x74, 0x00, 0x4C,
0xB1, 0x7F, 0x82, 0x99, 0x87, 0x0E, 0x5E, 0xC0,
0x8F, 0xEE, 0x6F, 0x55, 0xF3, 0x7E, 0x08, 0x90,
0xFA, 0xB6, 0x64, 0x70, 0x47, 0x4A, 0x17, 0xA7,
0xB5, 0x40, 0x8A, 0x38, 0xE5, 0x68, 0x3E, 0x8B,
0x69, 0xAA, 0x9B, 0x42, 0xA5, 0x10, 0x01, 0x35,
0xFD, 0x61, 0x9E, 0xE6, 0x16, 0x9C, 0x86, 0xED,
0xCD, 0x2E, 0xFF, 0xC4, 0x5B, 0xA0, 0xAE, 0xCC,
0x4B, 0x3B, 0x03, 0xBB, 0x1C, 0x2A, 0xAC, 0x0C,
0x3F, 0x93, 0xC7, 0x72, 0x7A, 0x09, 0x22, 0x3D,
0x45, 0x78, 0xA9, 0xA8, 0xEA, 0xC9, 0x6A, 0xF7,
0x29, 0x91, 0xF0, 0x02, 0x18, 0x3A, 0x4E, 0x7C};
static byte Table3[] = {
0x73, 0x51, 0x95, 0xE1, 0x12, 0xE4, 0xC0, 0x58,
0xEE, 0xF2, 0x08, 0x1B, 0xA9, 0xFA, 0x98, 0x4C,
0xA7, 0x33, 0xE2, 0x1B, 0xA7, 0x6D, 0xF5, 0x30,
0x97, 0x1D, 0xF3, 0x02, 0x60, 0x5A, 0x82, 0x0F,
0x91, 0xD0, 0x9C, 0x10, 0x39, 0x7A, 0x83, 0x85,
0x3B, 0xB2, 0xB8, 0xAE, 0x0C, 0x09, 0x52, 0xEA,
0x1C, 0xE1, 0x8D, 0x66, 0x4F, 0xF3, 0xDA, 0x92,
0x29, 0xB9, 0xD5, 0xC5, 0x77, 0x47, 0x22, 0x53,
0x14, 0xF7, 0xAF, 0x22, 0x64, 0xDF, 0xC6, 0x72,
0x12, 0xF3, 0x75, 0xDA, 0xD7, 0xD7, 0xE5, 0x02,
0x9E, 0xED, 0xDA, 0xDB, 0x4C, 0x47, 0xCE, 0x91,
0x06, 0x06, 0x6D, 0x55, 0x8B, 0x19, 0xC9, 0xEF,
0x8C, 0x80, 0x1A, 0x0E, 0xEE, 0x4B, 0xAB, 0xF2,
0x08, 0x5C, 0xE9, 0x37, 0x26, 0x5E, 0x9A, 0x90,
0x00, 0xF3, 0x0D, 0xB2, 0xA6, 0xA3, 0xF7, 0x26,
0x17, 0x48, 0x88, 0xC9, 0x0E, 0x2C, 0xC9, 0x02,
0xE7, 0x18, 0x05, 0x4B, 0xF3, 0x39, 0xE1, 0x20,
0x02, 0x0D, 0x40, 0xC7, 0xCA, 0xB9, 0x48, 0x30,
0x57, 0x67, 0xCC, 0x06, 0xBF, 0xAC, 0x81, 0x08,
0x24, 0x7A, 0xD4, 0x8B, 0x19, 0x8E, 0xAC, 0xB4,
0x5A, 0x0F, 0x73, 0x13, 0xAC, 0x9E, 0xDA, 0xB6,
0xB8, 0x96, 0x5B, 0x60, 0x88, 0xE1, 0x81, 0x3F,
0x07, 0x86, 0x37, 0x2D, 0x79, 0x14, 0x52, 0xEA,
0x73, 0xDF, 0x3D, 0x09, 0xC8, 0x25, 0x48, 0xD8,
0x75, 0x60, 0x9A, 0x08, 0x27, 0x4A, 0x2C, 0xB9,
0xA8, 0x8B, 0x8A, 0x73, 0x62, 0x37, 0x16, 0x02,
0xBD, 0xC1, 0x0E, 0x56, 0x54, 0x3E, 0x14, 0x5F,
0x8C, 0x8F, 0x6E, 0x75, 0x1C, 0x07, 0x39, 0x7B,
0x4B, 0xDB, 0xD3, 0x4B, 0x1E, 0xC8, 0x7E, 0xFE,
0x3E, 0x72, 0x16, 0x83, 0x7D, 0xEE, 0xF5, 0xCA,
0xC5, 0x18, 0xF9, 0xD8, 0x68, 0xAB, 0x38, 0x85,
0xA8, 0xF0, 0xA1, 0x73, 0x9F, 0x5D, 0x19, 0x0B,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x33, 0x72, 0x39, 0x25, 0x67, 0x26, 0x6D, 0x71,
0x36, 0x77, 0x3C, 0x20, 0x62, 0x23, 0x68, 0x74,
0xC3, 0x82, 0xC9, 0x15, 0x57, 0x16, 0x5D, 0x81};
Who says that the authorities don't have a sense of humour. Surely, packaging the source code that is contested in a case into public court documents so they can be spread freely around the whole world is one of the funniest hacks going.
:-)
I nominate this for Slashdot's Greatest Hacks of the 21st Century competition that will probably show up in 999 years or so
Thank you "SUPERIOR COURT OF THE STATE OF CALIFORNIA COUNTY OF SANTA CLARA "
A little planning goes a long way...
> Most of the kids I'm contacted by think DVD's should be played using dedicated appliances and
> hardware decoders only.
Think about it. This doesn't solve anything. First of all, there are very few true hardware DVD cards for computers. Most are really just hardware MPEG encoders, so the issue of CSS is just as relevant if you have a hardware card than if you don't. Secondly, we won't ever get specifications for these cards anyway, because the manufacturers signed agreements with Macrovision not to reveal anything to prevent the Macrovision from being turned off. (of course, people have already worked around this for all the cards anyway)
And most of all, we'll still be stuck with the obnoxious practice of region coding if we use somebody else's secret hardware system.
> The biggest argument is that deCSS was written to allow playback on Linux yet the defending
> lawyer emphatically denies the existance of any player for DVD files on Linux.
The defendents' lawyers argued that was WAS no DVD player for Linux before DeCSS. As a matter of fact, there now is one, and I am sure it will be publicly demonstrated at the trial.
> The public interest in this case has not been about playing DVD's on Linux but individual
> freedom. That makes the argument as credible as wanting to drink under the age of 21.
What, are you saying you shouldn't be allowed to buy DVDs and watch them until you're 21?
> So without any credibility behind the DVD argument, no DVD player,
The argument is that it is immoral for the MPAA or DVDCCA to tell us what we can or cannot do in our own homes, with the movies we paid them for. And see above, there is a DVD player for Linux. You know this because you've posted on the mailing list for it, so stop being facetious.
> we can only expect a repeat of the Fraunhoffer Gmbh fiasco.
This is where you are most wrong. Fraunhofer claimed to own the patent rights "essential" to the MP3 format. Moreover, no one could argue with them, because none of the people making free encoders bothered to really understand MPEG audio and know if the claim was valid or not. They were just copying the ISO source code and hacking it.
This is a case of legal reverse engineering, and CSS is not covered by any patent. And before you talk about the Xing license agreement, don't forget that U.S. courts have declared such licenses invalid in numerous cases already directly involving reverse engineering. (see the EFF web site for references) The MPAA is treading on thin legal justification for their actions.
And what makes you think we are going to lose? Have you looked at the press coverage recently? The headlines are "Linux DVD player denied", not "pirates arrested". There is strong public support for Johansen in Norway. The movie companies are going to end up tarnishing their imagine more than they ever could have possibly imagines.
IANAL, but to the people who are listed in all of these lawsuits, make backups of everything you need and keep them in someplace secure, like a safe deposit box somewhere.
Even here in the good free USA, the government can and probably will barge into your homes, confiscate everything that looks technical, including your computers, CD's, discs, manuals, CD players, DVD players, etc. etc. They are under no obligation to return your stuff to you, even if you are eventually found not guilty!
Make sure you have backups of important stuff and possibly a computer you can use in the mean-time if they do raid you.
And if you do get raided, don't say a word to them without your attorney there. This should be obvious, but police and government agents can be very intimidating!
________________________________
Let 'em reseal it. It's the *right* thing to do.
There is no reason to be craven about this. We don't need to argue that it might not have come from Xing, we don't need to argue that an accident in court suddenly invalidates a trade secret, we don't need to rely on cheap tricks to get our way.
It's called the Moral High Ground, folks.
Yes, the code is everywhere on the 'net. Stop for a moment and realize that this isn't a magic talisman. A horde of thieves is still composed of thieves, and that's all we're saying by saying we've all got it and you can't stop us.
But guess what, folks. We ain't thieves. Lets not fall into their trap.
(Yes, this post is conspicuously absent of my defense of DeCSS, mainly because I want to finish my main paper on the topic and release all at once. Email me if you believe in the spirit of the law, because believe me, in the end it's going to be the spirit more than the letter that will carry the day.)
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Everyone go to Copyleft.net and buy a DVD t-shirt with css_descramble.c source code on the back!
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
Most of the kids I'm contacted by think DVD's should be played using dedicated appliances and hardware decoders only. CmdrTaco uses a DVD appliance. VALinux uses WinNT.
The biggest argument is that deCSS was written to allow playback
on Linux yet the defending lawyer emphatically denies the existance of any player for DVD files on Linux.
The public interest in this case has not been about playing DVD's on Linux but individual freedom. That makes the argument as credible as wanting to drink under the age of 21. Face it. When you're a teenager you have no rights, but when you graduate from college you'll inevitably have more rights. How many Linux hackers do you run into who have graduated from college? So without any credibility behind the DVD argument, no DVD player, and no interest we can only expect a repeat of the Fraunhoffer Gmbh fiasco.
The legal system is an administrative nightmare in many respects, and can never move with adequate speed, except when things are moving at a breakneck rate. As a practicing lawyer, I can say that the vast majority of practice is to diligently work following the Boy Scout Motto, so that when the SHTF, you can flurry out a vast amount of work product, appearing to have been superhumanly quick.
To a layperson, the law seems to move glacially (and it generally does). Nothing ever gets decided, and when it does, only a little bit at a time.
There are some exceptions, however, and good agressive lawyers can use them to achieve partial results with remarkable speed. One is the preliminary inunction/TRO -- which by rule must be decided promptly. The other are these administrative emergency motions. The court is highly likely to seal this initially, and promptly, on the theory that it can always be unsealed, but that if not sealed, the toothpaste cannot be put back in the tube. (cat-out-of-bag, genie-bottle, pick the cliche of your choosing).
It certainly *DOES* seem unfair when you represent defendants (as we seem to be doing a lot of these days), and a plaintiff who has had months to prepare a complaint and preliminary injunction/TRO papers just files, serves, and gives you just days to rally (usually just hours, since the client has spent days shopping for a lawyer). In practice, though, this is often enough time to address the status quo questions.
I cannot defend the conduct of MPAA, but I note that the results obtained so far, and the tactics used, are not unusual or surprising. Such tactics are regularly used by plaintiffs representing not only corporate monsters but also individuals. (I presently have a case where an individual unwealthy single mom who sued a corporation for copyright infringement. Her lawyers used precisely the same tactics.)
In other words, cool your jets. This is not the unconcionable part -- it is in fact routine and expected legal stuff. The unconcionable part comes on the bringing of the case and the results on the merits.
In just a few weeks, the opportunities for breakneck nasties are over, and we will be communally criticizing the system for being so onerously slow at being able to finally resolve these questions.
I know its not as much fun as presuming that the judges are cowtowing to wealthy powers-that-be in whose pockets they reside, giving opportunities to the monied not available to mere mortals. But this just isn't the case as to *THIS MOTION* -- it is a fairly routine matter, and one that doesn't require much effort for which to prepare a response.
The MPA (Motion Picture Association) is an American organization that
has trouble with the fact that the DVD "code" mechanism has been broken.
They still don't realize some facts of life.
When recordable cassette decks became common, they were feared as a
means of breaking the back of the music industry -- one person would
buy an album, and then distribute copies.
This happened with videotapes.
With CDs.
Will happen with DVDs.
(Just buy a Phillips DVD recorder and make bit-wise copies of a DVD for an
exact copy.)
The majority of people (the market) will still buy original copies.
This is not a theory or hypothesis but a simple truth. It is easier
for a person to go to the local MediaShop to buy a movie, or music, or
anything else than to find Joe "Jon Johansen" Hacker to burn them a copy
of Titanic.
Sure some people copy their work and distribute the copies. There is always
going to be a "grey" (I think chartreuse, but that's me) area surrounding
the profit zone. Grow up and live with it.
Focus on the profitable area and be satisfied with it.
This post encoded with ROT26. If you can read it, you've violated the DMCA. Handcuffs please, sergeant.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It's called prosecution by proxy.
I have said it before and I will say it again. This hasn't got squat to do with weather you or I have LiViD. It's actually about making sure Diamond Multimedia can't use it. It's so RedHot and Mandrake can't distribute it to the next generation of Linux users.
What's the deference between us and them ? They have money, wide distribution channels, deep pockets and the will to sell DVD players ( software and hardware ) for less than they cost now.
The aim of this lawsuit is to get a court to rule that DeCSS is outlawed. This is why http://www.2600.com was one of the defendants in each and every case. They have been protesting about Kevin M. for like 5 years. They have a bad rep to judges and the like ( "how dare you say he is being held unjustly" ).
Once such a ruling exists DeCSS and LiViD will remain things a technically savvy user downloads and installs on his own to play DVDs. Without the ruling it becomes something smaller electronics companies use to avoid forking over a few bucks for ever DVD player they ship. The big companies ( Sony ) will follow suite and the DVD-CCA will seas to exist.
So the fact is distributing it far and wide doesn't mean squat. What we need now is to win in court. We need to make a *Judge* say that these people are talking out of there asses and the stuff was revers engineered fair and square.
This is also why they went after that kid so brutally. They don't so much want him to stop distributing it since he did that months ago when they asked the 1st time. They want to pressure him into signing an Affidavit to the effect that "I stole this data illegally and apologize for letting it get out."
That last point explains why his father was also taken. It's all an attempt to scare his mother into making him "confess". Some of the Linux hackers in Norway need to be at that family's house today. Comfort them, tell them you care and most importantly be prepared to fight for them as much as possible. That way you keep the kid in the fight and we can't afford to have him quit. Ever.
BTW : Somebody loan him a new PC for me.
--= Isn't it surprising how badly I spell ?
Folks.. let's think rationally for a second.
Judge already granted prelimenaty injunctions agatinst TONS of sources of the DeCSS code. It follows that he most likely seal this as well, for the exact same reasons. He would have done it at the same time as the previous one, had they asked.
Having court records sealed until the trial is over is *not* a violation of your rights.
We all know the CCA is *evil*... me included.. but, hey.. they *are* *LAWS* that the CCA thinks should apply here, and they have gone to court to have the court decide. *IF* the CCA is correct, and they can have their work protected by the acts in question, then it follows that the court record will be sealed.
Rather.. if the Judge doesn't seal the record, it makes his other injuncions useless anyway.
Defendant #2 here... Yes, this hearing really is about to happen.
Let's presume for a second that the DVD CCA prevails in every suit -- what are they going to collect, some judgement leveled against a 16-year-old kid in Norway? That might be worth almost as much as the judgement in favor of the U.S. Football league in USFL vs. NFL ($1). What good is that going to do?
In a different vein, I have what I think is an important question related to the public documentation part 'though: If we downloaded the "exhibit a", part of the document while it was "open" (which is the DeCSS source in question), and then they seal it, what is the legal status of those copies we downloaded?
The closest analogy I can think of is this: if I went to the courthouse and made xerox copies of a public document which was later "sealed" by the court, would I somehow be in violation of the law? If so, it seems like it would be an "ex post facto" law (a law passed making a crime out of an act which had not previously been legislated against). At least in the US of A, "ex post facto" prosecution is against our constitutional rights. IANAL and this has me very very concerned.
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
Could someone please point out to me where it states on my DVD discs (or associated containers/sleeves/whatnot) that I have "no right" to view them on my Linux system?
Looking at the back of my "Blade" case I can see the following warning:
WARNING: This digital video disc is sold on the condition it is not offered for sale or hire outside Australia (Fine with me.. I'm Australian and live there)
The copyright proprietor has licensed the film (including the soundtrack) comprised in this digital video disc for home use only (Fine also, my computer is indeed in my home) All other rights are reserved. Any unauthorised copying, editing, exhibition, renting, exchanging, hiring, lending, public performances and/or broadcasts of this digital video disc or any part thereof is strictly prohibited.
Did you see any mention of Linux there? Me neither.
In my opinion, it is becoming more and more obvious that this case is not about DeCSS; it is about the DVD CCA's right to charge exorbitant amounts of money for their beloved "licenses", along with imposing restrictions on said licenses that would be prohibitive of Linux development (which would most likely be under the GPL).
Just think of what could happen if we win this case. Suddenly, all the developers who have agreed to licenses for using CSS code can bypass those licenses and save some dough in the process. A new breed of players could crop up, designed by people/groups who have the programming ability but not the cash to afford a license. All of this would lead to one thing: reduced income for the CCA. Indeed, is CSS not the CCA's main asset (if not the only one)? If so, then the CCA could stand to lose their entire reason to exist if this case fails..
In any case, I think it is appalling that the CCA can openly suggest that Linux users have no "right" to view movies that they have legally purchased. Isn't this called product tying? I hope they get what they deserve.. a solid beating
As a side note, does this mean they will be adding the court to their list of defendants, thus effectively suing the entire United States of America? Maybe the US Govt. will be able to put up some cash towards the war effort
Disclaimer: I'm not a lawyer. (how typical) I'm posting this from Australia (of course), so I apologise in advance if the records are resealed before this was posted - I'm not entirely sure what the time is in the US
-- That which does not kill us has made its last mistake..
The exclusions are below:
(b) This section does not apply to matters that are--
(1)(A) specifically authorized under criteria established by an Executive order to be kept secret in the interest of national defense or foreign policy and
(B) are in fact properly classified pursuant to such Executive order;
(2) related solely to the internal personnel rules and practices of an agency;
(3) specifically exempted from disclosure by statute (other than section 552b of this title), provided that such statute (A) requires that the matters be withheld from the public in such a manner as to leave no discretion on the issue, or (B) establishes particular criteria for withholding or refers to particular types of matters to be withheld;
(4) trade secrets and commercial or financial information obtained from a person and privileged or confidential;
(5) inter-agency or intra-agency memorandums or letters which would not be available by law to a party other than an agency in litigation with the agency;
(6) personnel and medical files and similar files the disclosure of which would constitute a clearly unwarranted invasion of personal privacy;
(7) records or information compiled for law enforcement purposes, but only to the extent that the production of such law enforcement records or information (A) could reasonably be expected to interfere with enforcement proceedings, (B) would deprive a person of a right to a fair trial or an impartial adjudication, (C) could reasonably be expected to constitute an unwarranted invasion of personal privacy, (D) could reasonably be expected to disclose the identity of a confidential source, including a State, local, or foreign agency or authority or any private institution which furnished information on a confidential basis, and, in the case of a record or information compiled by a criminal law enforcement authority in the course of a criminal investigation or by an agency conducting a lawful national security intelligence investigation, information furnished by a confidential source, (E) would disclose techniques and procedures for law enforcement investigations or prosecutions, or would disclose guidelines for law enforcement investigations or prosecutions if such disclosure could reasonably be expected to risk circumvention of the law, or (F) could reasonably be expected to endanger the life or physical safety of any individual;
(8) contained in or related to examination, operating, or condition reports prepared by, on behalf of, or for the use of an agency responsible for the regulation or supervision of financial institutions; or
(9) geological and geophysical information and data, including maps, concerning wells.
penguinicide... when jumping out a window just won't do.
Truly, there are some of us who have no desire to use DeCSS (or more accurately, derivitives thereof) to pirate movies. Currently I own a modified Pioneer DV-09 which plays all regions and does not output macrovision. The perfect machine to make copies on my DV recorder. I own approximately 150 DVDs and how many copies have I made? zero. exactly zero.
I'd love to have a DVD player available for FreeBSD/Linux/etc. Hell, I'd even like to see open source software on the windows platform. Without the technology in DeCSS, that just isn't possible. Much luck to those who fight this fight.
As to the video industry, as one of your more active consumers, I have to say, chill. One-way cable systems everywhere are vulnerable to descrambling, yet most people pay for their premium channels. DirecTV is vulnerable to card reprogramming with the older smart cards... free everything... yet most of us still pay our monthly fees.
And most importantly, those of us who know anything about DVD production know that you don't have to decrypt the DVD to clone it.