________________________________________________________________________________ ================================================================================ Subject: FC: DVD hackers -- and web publishers -- hit with lawsuit From: Declan McCullagh Date: Tue, 28 Dec 1999 14:28:18 -0500 ================================================================================ I am on vacation this week -- in part in NYC, though I shall escape the Times Square rush by midday Thursday -- so I'm not writing about this case. But it is one of the most important ones to come along in a while. It raises the very interesting question of what kind of information a reporter or web publisher can legally distribute. The DVD trade association plaintiffs even say *linking* to supposedly reverse-engineered info should be illegal: "Defendants knew or should have known when they posted or 'linked' to the DeCSS program that they were misusing confidential, proprietary nformation..." The DVD association and motion picture industry says their lawsuit is necessary for their business to succeed: "the wholesale copying and distribution of copyrighted motion pictures destroys the motion picture industry's ability to protect its intellectual property and destroys the market for the computer and consumer electronics industries?' DVD-based products." Journalists should pay attention. In a previous article on the controversy (http://www.wired.com/news/politics/0,1283,32449,00.html), I linked to one of the mirror sites at issue. deja.com was sued in this case for linking *automatically* to the site -- perhaps news organizations will be sued for linking *intentionally* to the same place. Excellent collection of links: http://www.dibona.com/social/dvd/index.shtml Text of complaint: http://www.dibona.com/social/dvd/text/index.shtml Wired article from this morning: http://www.wired.com/news/business/0,1367,33303,00.html Slashdot thread: http://slashdot.org/articles/99/12/27/194216.shtml Some sites that were listed as defendants: www.deja.com/getdoc.xp?AN=547600297 cryptome.org/dvd-free.htm slashdot.org/articles/99/11/09/1342207.shtml cryptome.org/dvd-css.htm -Declan -------------------------------------------------------------------------- POLITECH -- the moderated mailing list of politics and technology To subscribe: send a message to majordomo@vorlon.mit.edu with this text: subscribe politech More information is at http://www.well.com/~declan/politech/ -------------------------------------------------------------------------- ================================================================================ Subject: DVD-CSS analysis + remarks From: t byfield Date: Tue, 28 Dec 1999 17:22:49 -0500 ================================================================================ [the legal analyses below may be very US-centric, but the issue --a lawsuit filed in California by the DVD Copy Control Associ- ation, Inc., against defendents scattered throughout the US as well as in AU, FR, DK, DE, UK, FU, NL, and IT--might encourage people to think twice about dismissing it as 'more US rubbish.' it is that; but it still has serious repercussions. since this case crosses so many borders, enforcing any ruling would be al- most impossible, at least in the terms that most people now un- derstand 'enforcement' to mean. but the 'intellectual property' lobbies aren't about to call it quits that fast, so it's worth thinking about new mechanisms for enforcing rulings across bor- ders. one obvious mechanism is the ability to shut down access to any domain that fails to comply with a court order. this is what ICANN's 'uniform dispute resolution policy' does, because it's not limited to domain/trademark issues: it includes vague, open-ended language about suspending a domain used for any 'il- legal' purpose. and that doesn't merely mean breaking an exist- ing rule--it can mean not complying with an interim/ad hoc rul- ing like the order in the Etoys/etoy case. ICANN has two major groups of domain registrars to deal with, and they're very dif- ferent. on the one hand, there are the commercial/'competitive' registrars that handle global top-level domains ('gTLDs'); any gTLD registrar that disregards ICANN's 'uniform dispute resolu- tion policy' can have its accreditation yanked and lose access to the registration database. on the other hand, there are the registrars that handle country-code domains (ccTLDs); it'll be much harder for ICANN to control them, because they tend to be state monopolies. the 'intellectual property' lobbies were, of course, very supportive of ICANN's efforts to pass this policy, for obvious reasons. anyway, now that these enforcement mechan- isms are in place, the kind of actions that we've witnessed in the past few weeks--Etoys/etoy, Leonardo and now this--will be- come *much* more common. some will be handled very publicly in order to make a point; others will be handled very quietly, be- cause the main goal is just to solve a specific 'problem.' for example, the first case filed under the ICANN policy was given to the World Intellectual Property Organization (WIPO) for 'ar- bitration,' because WIPO was the first 'dispute resolution pro- vider' accredited by ICANN. under the rules that ICANN imposed on WIPO, WIPO is not allowed to reveal *any* information about the dispute; given how pwerful etoy's public campaign has been, it's no mystery why the 'intellectual property' lobbies wanted these disputes to be settled in secret. (WIPO has said it'd be happy to release basic details about the disputes.) so, please think about whether you want to see domain names turned into a 'single chokepoint' for regulating resources on the net; or if you don't want that, think about what you can do to stop it in its tracks. *it is happening now* and *it will continue unless people start organizing against it*. cheers, t] 28 December 1999 See also Slashdot's massive thread: http://slashdot.org/articles/99/12/27/194216.shtml _________________________________________________________________ [Thanks to anonymous.] Date: Tue, 28 Dec 1999 10:41:46 -0500 To: John Young Subject: CSS Petard I note that the lawsuits from the motion picture industry are going after web sites where only LINKS to the CSS information is located. I am curious about the lawyer's attack on reverse engineering per the new digital copyright law. For example, if you posted the links but protected them using ROT-13, wouldn't the lawyers be unable to decrypt them without "reverse engineering" your copyrighted web page, thereby providing evidence of their own violation the law they seek to enforce on others? Secondly, one of the CSS decryption keys was provided by the manufacturer in a totally unencrypted form, requiring no "decryption hacking" whatsoever. Are we to understand that reading literal, non-motion picture data directly from a DVD and telling others those few bytes, or using them to decode copyrighted content, is now illegal or a tort? If so, then a copyrighted web page with encrypted links to CSS information could provide the unencrypted decryption key on the copyrighted web page itself, couldn't it? And if the lawyers use that unencrypted key to read the data you have there, they would be providing evidence of their own reverse engineering and copyright violation, wouldn't they? If you provide the unencrypted key thusly: "LAWYERSBCDFGHIJKMNOPQTUVXZ" and then you have: "CQQL://VVV.XPPDJSK.XKI" they wouldn't violate your copyright and reverse engineer that, discovering that your algorithm of "monoalphabetic substitution using ordered English alphabet with key=LAWYERS; minus one position", discovering that the plaintext is "http://www.cssinfo.com", would they? [non-existent URL, as far as I know.] Of course, providing a link to their legal filing, which lists the URLs of those they allege to be posting the URLs of the CSS information, would be legitimate, wouldn't it? If not, since their public legal filing lists the URLs that are links to the CSS information, or to the CSS information directly, aren't they violating the law and equity themselves for which they seek legal remedy? "For 'tis the sport to have the engineer Hoisted with his own petard." Hamlet, Act 3, Scene 4. _________________________________________________________________ Date: Tue, 28 Dec 1999 11:05:39 -0500 From: "Peter D. Junger" Subject: The DVD litigation To: CYBERIA-L@LISTSERV.AOL.COM I sent the following message to Chris DiBona , following Michael Sims's suggestion. It seems to me that, if plaintiff does not abandon its claims, this could become an extremely important precedent. Has EFF taken any action so far? Is there any chance of getting the ACLU interested? -- Peter D. Junger--Case Western Reserve University Law School--Cleveland, OH EMAIL: junger@samsara.law.cwru.edu URL: http://samsara.law.cwru.edu NOTE: junger@pdj2-ra.f-remote.cwru.edu no longer exists ------- Forwarded Message Date: Tue, 28 Dec 1999 10:34:14 -0500 To: chris@dibona.com From: junger@samsara.law.cwru.edu Subject: DVD litigation Just a couple of quick points. First, a problem. Those who posted the source (or other) code of the encryption program may---at least in theory---have violated the Export Administration Regulations forbidding the export of encryption software without a license, if the posters were in the United States. On the other hand posting links to a foreign site that has the code is not a violation according to a ruling that my lawyers obtained for me that is on my web site. (The web site is ; the materials relating to my case challenging the export regulations are at . The web pages are not up to date, but there should be enough information there to get you started.) Because of the Bernstein case which is now pending in the 9th Circuit the status those export regulations, at least in your circuit, would seem to be in limbo. I doubt that the Department of Commerce or the Justice Department would want to challenge anyone who posted the DVD code right now, especially when they are revising the regulations so as, or so they seem to claim, to make the posting of open source code OK. Still I, because I am the plaintiff in a case challenging those export regulations, that is now pending before the 6th Circuit, don't feel that I should post the code, though I will post a link to some foreign site where the code is available. Second, an argument. For the court to enjoin the publication of the source code of the DVD program would be a violation of the First Amendment. Although the 9th Circuit has withdrawn its opinion in Bernstein, there is still the District Court's holding that source code is speech protected by the First Amendment. There is also quite a bit of discussion of this point in the archives of a list that I maintain---now gone inactive---at . Third, another argument. The plaintiffs rely on their licensing agreement's ``no reverse engineering'' clause to claim that their no longer secret algorithm should be protected as a secret. The claim that such a clause is enforceable is extremely dubious under U.S. law, especially as it conflicts with the federal copyright act, and especially when it is applied to third parties, as appears to be the case here. Since the original disclosure of the former secret took place in Denmark or Norway or wherever, it would seem that the plaintiff will have to prove that the disclosure was not ``legal'' under the laws of that foreign jurisdiction. This is pretty much off the top of my head, but I wanted to get my thoughts to you promptly. If you have any questions about them, please let me know. Thank you for stepping in and helping with this matter. If the plaintiff really continues to push the issues it could turn into an extremely important case on the free speech and intellectual property status of open software, in particular, and of any publication in general. And the idea that they can get an injunction against links to other sites is all by itself an extremely important issue. Ciao, Peter - -- Peter D. Junger--Case Western Reserve University Law School--Cleveland, OH EMAIL: junger@samsara.law.cwru.edu URL: http://samsara.law.cwru.edu NOTE: junger@pdj2-ra.f-remote.cwru.edu no longer exists ------- End of Forwarded Message _________________________________________________________________ Date: Tue, 28 Dec 1999 09:02:36 -0800 From: "Carl M. Kadie" Subject: Re: DVD encryption To: CYBERIA-L@LISTSERV.AOL.COM So, according the complaint, The information should be banned. Links to the information should be banned. Does the complaint say if Links to links to the information should be banned? If so, then the complaint itself should be banned (as should this note and any injunction the judge issues that mentions the URLs). > Doe > Defendant [...] > quintessenzs.at/q/mirrors.html [...] > www.ceraton.com/decss/ [...] > slashdot.org/articles/99/11/09/1342207.shtml [...] > cryptome.org/dvd-css.htm [...] > ftp://dvd:dvd@206.98.63.136/ [...] > www.deja.com/getdoc.xp?AN=547600297 [...] - Carl # distributed via : no commercial use without permission # is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body # archive: http://www.nettime.org contact: nettime@bbs.thing.net ================================================================================ http://www.dibona.com/social/dvd/code/index.shtml ================================================================================ 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); } /* This shuffles the bits in varient to make perm_varient such that * 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); } /* This shuffles the bits in varient to make perm_varient such that * 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; /* In order to ensure that the LFSR works we need to ensure that the * 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; /* Feed the secret into the input values such that * 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); /* This term is used throughout the following to * select one of 32 different variations on the * algorithm. */ cse = Varients[varient] ^ Table2[varient]; /* Now the actual blocks doing the encryption. Each * 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}; ================================================================================ http://slashdot.org/articles/99/11/09/1342207.shtml ================================================================================ http://www.angelfire.com/mt/popefelix/ http://www.vexed.net/CSS http://members.brabant.chello.nl/~j.vreeken/ http://gullii.stu.rpi.edu/dvd/files/DeCSS.zip http://gullii.stu.rpi.edu/dvd/files/css-auth.tar.gz http://www.dvd.eavy.de/css-auth.tar.gz http://www.eavy.net/stuff/dvd/css-auth.tar.gz http://www.eavy.net/stuff/dvd/DeCSS.zip http://www.dynamsol.com/satanix/DeCSS.zip http://www.dvd.eavy.de/DeCSS.zip http://frozenlinux.com/civ/decss/ http://www.humpin.org/decss/ http://www.unitycode.org/ http://dirtass.beyatch.net/decss.zip http://sharedlib.org/decss.zip http://decss.tripod.com/index.html http://www.free-dvd.org.lu/ ftp://134.173.94.44/ http://www.angelfire.com/in2/mirror/ http://mclaughlin.orange.ca.us/~andrew/ http://www.dynamsol.com/satanix/css-auth.tar.gz http://batman.jytol.fi/~vuori/dvd/ http://www.zpok.demon.co.uk/deCSS/CSS.html http://plato.nebulanet.net:88/css/ ftp://alma.dhs.org/pub/DVD/ http://www.d.umn.edu/~dchan/css/ http://www.logorrhea.com/main.html http://people.delphi.com/salfter/LiVid.tar.gz http://www.theresistance.net/files.html ftp://193.219.56.32/pub/dvd/LiVid.CVS-11.06.tar.gz ftp://193.219.56.32/pub/dvd/LiVid.CVS-11.06.css-stuff-only.tar.gz http://merlin.keble.ox.ac.uk/~adrian/css/index.html http://www.dvd-copy.com/ http://www.zip.com.au/~cs/dvd/css/css-auth.tar.gz http://www.zip.com.au/~cs/dvd/css/DeCSS.zip http://www.sent.freeserve.co.uk/css-auth.tar.gz http://www.sent.freeserve.co.uk/DeCSS.zip http://members.tripod.lycos.nl/jvz/ http://joe.to/storage/files/decss.zip ftp://ftp.firehead.org/pub/ http://www.lemuria.org/DeCSS/ http://members.theglobe.com/avoiderman/dvd.htm http://remco.xgov.net/dvd/ http://www.able-towers.com/~flow/ ftp://dvd:dvd@206.98.63.136 http://www.twistedlogic.com/html/tl_archive_map.htm http://dvdcracked.tvheaven.com/index.html http://crypto.gq.nu/ http://www.rhythm.cx/dvd/crypto.gq.nu ________________________________________________________________________________ no copyright 1999 rolux.org - no commercial use without permission. is a moderated mailing list for the advancement of minor criticism. more information: mail to: majordomo@rolux.org, subject line: , message body: info. further questions: mail to: rolux-owner@rolux.org. archive: http://www.rolux.org