Slashdot Mirror
Activist Defends DVD Hack
LordStrange writes "CNN has posted a pleasantly Linux biased story about the DVD hack." Yet another chapter in the DVD crack saga. The article makes it a point to say that specs for DVD were being withheld, and that this crack opens up the DVD market to Linux users. I just hope that when they redesign
the scheme that they decide to open up the specifications so that other OSes aside from Win32 and Mac can gain proper DVD support.
Playing DVDs in linux would be great, but how would the OS really support it. I mean, just look at mpg's, the only decent player out there is mpgtv and it really doesn't work that great.
Is it possible to make an encryption system that supports one-way transmission (broadcast) to a hostile client? DIVX machines could negotiate over a phone line. Without this ability can't the media be replayed, bit-for-bit? Is protection futile?
tsrif ?
Suppose that I master my own DVD and loose my copy protection code. Would it be illegal to make and use a program, that would recover the lost code?
If US law would forbid doing this or making writing code to do this, that would be absurd!
Here's the requisite mirrors of the source and binary
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I find all of this quite odd. From what I've read, the CSS encryption can be licensed from Matsushita for free (although the application is a lengthy process).
So, my question then is "Why has no one made a player for Linux yet?"
Licenses have been allowed for software players since may of '97. Has any Linux/DVD group tried to get a license for the CSS?
Of course, there wouldn't be a problem if any of the decoder card makers would make a Linux driver for there stuff, since the CSS is in the hardware.
Check out the DVD FAQ for a lot of good info.
The two most common things in the Universe are hydrogen and stupidity. -- Harlan Ellison
________________________________
If encryption is outlawed, only
________________________________
If encryption is outlawed, only
YIE565$FF DSDNE4!MJK XMY7*fRBVM.
Creative did release drivers.
See http://opensource.creative.com.
First, to CNN: Pretty good article - you gave a very balanced view of the issues.
However:
Why does everyone persist in calling this "hacking". Sure, it was hacking in the traditional (computer) sense of the word, but surely, now days, that word has bad overtones.
Perhaps it wouls be more appropriate to play up the reverse engineering aspect of this. Is it illegal for a non licenced manufacturer to design and sell replacement door panels for your car? Of course not! What the manufactures of those door panels do is exactly the same as what these people did.
Yes, they had to break some (pretty weak, and bungled) encryption, but is that any different from the door manufacture not releasing the specifications of a special bolt needed to attach the door to the car? Not really - and it was perfectly legal to do.
These people weren't trying to pirate movies, they weren't trying to steal national secrets, all they were trying to do was allow people to watch the movies they had legally bought, on a player they had legally bought.
This is no different from trying to get one of those programmable remotes to work with your VCR. Do you think the manufactures (originally, at least) gave out the codes for those remotes? People had to work them out by taking them to bits, checking the chip types and reverse engineering them. Does anyone complain about that? No! They just think is is stupid the manufactures didn't make it easier to do in the first place.
--Donate food by clicking: www.thehungersite.com
Chilli
-=- Just a random lambda hacker
Quote from the article:
The defeat of the algorithms, which were weak because they were designed to meet U.S. and Japanese export controls, makes it possible to build an open-source DVD player that the DVD Forum can't disable, he said.
The problem is that the public (including authors writing about this) don't understand the difference between 40 bits and 16 bits.
The encryption was weakened to 40 bits for us export restrictions, which, if a decryption operation takes a second, requires 35 thousand years to crack. Ok, so the decryption takes only a millisecond, you can brute-force it in 35 years on one computer, or in about a month on 350 computers. But that's still serious deterrent to casual copying.
This is a combination of problems: The code was weak "inside" so that with a known-plaintext, you can crack the key in 2^16 operations. Takes about a tenth of a second. Now, if the export laws hadn't been there, they might have used a 128bit key, and that's enough that leaking 24 bits is not a problem. Even if the algorithm leaks 60% of the bits, having 75 bits left is strong enough to thwart copy attempts.
So, it's the combination that's dangerous: 40 bits is enough, but in combination with an algorithm that can now execute in under a second, or with an algorithm that leaks keybits, it is NOT enough.
Roger.
I'm just having difficulty parsing pleasantly and biased in the same sentence. I hope you're not saying that bias and prejudice are ok so long as they match your views - only objective facts are worth reporting.
This media story is more positive, but still not good enough. Sony described the development as "disturbing". What wasn't mentioned was that this (currently) doesn't threaten Sony's revenue one little bit. It's financially not feasible to copy DVDs and the "hack" wasn't done for that purpose.
Maybe one day ripping will be feasible, but not any time soon. There is NO THREAT. There is basicly not two sides to this story, only one.
I think that by the spirit, if not the letter of the anti-trust law. It's more objectional that the encryption code has been given to some producers of Operating Systems, and not to others.
The DVD forum, violates the rules of good conduct by making deals with Microsoft and others, handing them the encryption code, and then not giving it to the people making linux. This kind of competitionpollution, giving one company an edge over another, is exactly the kind of thing anti-trust laws have been made against.
I think that if the DVD Forum, had made a deal with those making linux, maybe helping in creating a binary for linux, they could have kept the encryption code out of the open source. Their nearsightedness and bias is what has made other do the reverse engineering in the first place.
If you don't deal with eventualities, they will deal with you.
Beware of Wight Supremacists!
How about Segfault? Before the comments were removed, these type of messages filled the boards.
_______
Scott Jones
Newscast Director / ABC19 WKPT
Game Show Fan / C64 Coder
FC Closer
This article is dated November 8th, and has been linked from here in an earlier DVD thread.
--
--
The early bird catches the worm. The worm that sleeps late lives to see another day.
...yet no mainstream media mention this. The reason the studios want encryption isn't to reduce piracy, it's to try to move back towards the days when viewing a film required paying for it on each and every occasion. You'd have to get a local theater to schedule a showing, then the reels would have to be rented, then the audience would pay. In comes the VCR and suddenly people can record those same movies from television, uncut full-length movies in the case of pay TV. So the movie industry gives in and starts selling those video tapes instead of renting or selling expensive 35mm reels. Since people copied these movies, we got Macrovision for cutting down on it. But real pirates could eliminate Macrovision anyway, so the real purpose is just to keep the average joe from copying tapes. Then comes the chance to move to a digital medium which can be encrypted to prevent piracy--by home users, that is, since real pirates can still get equipment to get at the decrypted video stream and save it, then eliminate Macrovision. And don't forget about DIVX, which is what the companies would really love--paying for every single viewing, or to "unlock" the DIVX permanently meant that it could only be played in the same DIVX machine in the same single place.
Fortunately the public didn't buy into DIVX, but it's all very revealing. The studios--especially Sony, which is notorious for taking extreme measures to eek every last penny from film and music consumers--want to prevent any copying at all, even for backup: eventually it's going to get scratched or gnawed by the dog, and of course you have to go buy another. And heaven forfend, no you can't make a quick copy for a friend to borrow because $30 per film is a single-user license no matter how much money they've cleared from that 30-year-old classic already. Never mind that film and music are the art of our age, and the price for enjoying that art has become too steep (just consider CD prices, versus the 70 cents per CD sold an artist would be lucky to get). And of course, thanks largely to Sony, companies now want to move to a "secure" DVD-like encryped form of the CD. Wow, it's great to live in an age when so many arts are so accessible to the masses--nevermind that most musicians would be happy to give the recordings away for free and make their living off the concerts, since it takes a Madonna to make anywhere near 70 cents per CD sold--most only break-even when advertising and production costs are factored in. It's also unfortunate that Congress has seen fit to increase the length of copyright for music and film--common sense dictates that they should move into the public domain a reasonable period after the death of anyone involved and the profit margins of the studios have been inked-in, but that's not the case.
In Shakespeare's day, even the poorest could afford to see a play once or twice a week. Film is today's equivalent, and yet a theater ticket usually costs upwards of seven dollars--add popcorn and a drink, and maybe a hotdog if you're hungry, and this gets into serious cash. Nearly all movies at least break even at the box office, and most make a good profit. Then they make a mint in video rentals. You wouldn't think it would be such a big deal, then, to have sales of unencrypted digital films--copying one in digital quality is expensive anyway considering the storage space required. It's cost effective to just buy a DVD anyway instead of a bootleg unless...unless...unless the studios want to keep DVD prices at a high level even when the infrastructure is paid for and costs of production go down. Which they do, if the lesson of continually rising CD prices isn't lost on you. Consumers really ought to fight this sort of thing, and give the industry a blunt message: no encryption, you've already made millions in profit by the time DVD sales roll around anyway. No artificially high prices once the profit is there. I am a capitalist, and I hate to say it, but ideally the government would prevent such repeated gouging considering the need for art and entertainment. How much profit is enough--150% of the costs, 300% of the costs, 1000% of the costs? Enough is enough, studios and recording industries...
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
> Nearly all movies at least break even at the box office, and most make a good profit. Then they make a mint in video rentals.
I've heard that this is not true - can anyone put any figures on this ?
There is a fairly lengthy list of movies that only JUST break even or fail to do so, even with the huge number of money making outlets available now.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
When this happens, there is widespread condemnation from the community, with people saying that the morally correct thing to do is to respect the wished of the author, even when the license says you can do something else.
Why doesn't this respect for authors apply to breaking DVD encryption? If respecting the wishes of authors is a moral principle, then it should be followed even when the wishes of those authors mean that we won't get the benefit of their work. If we are only going to apply our morals when the outcome directly benefits of us, those are not morals to be proud of, it seems to me.
Of course, there are noteable exceptions - Star Wars Episode 1, Deep Blue Sea, and I hear Pokemon made $35 million over the weekend - but, for the most part, if a movie's truly *bad*, it won't make much money. This should be a lesson to Hollywood: Make movies that don't suck, and people will gladly pay to see them.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
CSS is an multi-key encryption/decryption algorithm that allows multiple parties to decode the same "message" (i.e. movie) with their own unique key.
The encryption license holders have a cache of some 400 (I think) of these keys and give a different one to each vendor that licenses the technology.
The weakness with the system is that many of the decryption keys are mathematically linked so that finding one means you can easily extract others.
Xing caused the problem by not encrypting their decrypt key and just hard-coded the key into their application.
Now comes my confusion:
What is the purpose of this encryption? Is it to prevent piracy or to prevent unlicensed vendors from writing DVD player software?
The only thing that makes sense from the above information is the latter. This scheme could never prevent piracy because anyone could copy the data and play it on another licensed player. However, this scheme does (perhaps "did" is a better word) seem to be marginally effective at preventing other software vendors from writing DVD movie applications without proper license.
Okay, if I am correct about the previous conclusion, then I have one last question: What do the DVD technology owners gain by limiting the player software? Do they get royalties/licensing fees?
I really don't understand why this situation even needed to become an issue.
I personally *applaud* the actions of MoRE and think of them as wonderful people. I think their source code should be spread far and wide. On the other hand, I wouldn't be too proud of myself if I believed what you do -- that people should be sheep, led around unthinkingly by the great cabals of industry.
Sometimes, two wrongs make a right.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
This is exactly it. Under the guise of fighting piracy, they are trying to secure control now of future digital video channels. They know better than any of us exactly how much money piracy actually costs (or makes) them, so there is no way that this is really the issue.
---The Vicar---
If you look on www.2600.com, I think that they have the files and an image of the site.
Don't call my crazy, that's what they called me back in the home!
There are lots of ways to copy DVDs even if the encryption on them hadn't been broken. You could intercept the video stream and dump it to videotape (Beta would be a good format for your masters) or even just make a binary copy of the whole DVD, encryption codes and all. The only two REAL results of encryping DVDs is that you prevent non-MS OS users from being able to play them (I wonder if MS had a hand in that) and you prevent the honest users from exercising their legal right to make a backup copy (Fair use and all.)
As an ironic sideline, this whole DVD thing broke about 2 weeks before the industry REALLY started pushing DVDs. I've seen several commercials touting the benefits of DVDs in the past week or so and all of a sudden there are a LOT of DVDs in the video store.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Once you've stripped all that nasty CSS encryption from the files, what appplications exist to play a VOB in the wild anyway ?
Everything I can see seems to require you to buy it (I'm cheap), play it from a DVD (duh) or compile it (mommy I'm scared - well, lazy anyway).
Suggestions ?
That's exactly my point! I approve of schemes that help prevent piracy but this DVD encryption is just there to milk users and establish a closed web of producers/manufacturers who control the market.
Who doesn't remember the old Nintendo (and other consoles) coming in different versions (US, Japan, Europe) and having region codes so that you couldn't use the cartridges from another region. Of course there were numerous people making money with rigging your console to circumvent this.
And what does the DVD Forum do? They put a region code into DVDs and even add encryption to make cracking DVDs harder. The result of these chicanes are of course that people just won't buy DVDs because:
a) They just hate the idea of region codes. (When I first read that I wished that DVD would be a complete failure at the expense of the industry responsible for it.)
b) They don't get the support for it that they would like. (I love my Linux box. Why would I buy a DVD drive that I can't use on it?)
I sincerely respect the guys who cracked the DVD encryption scheme in their achievement of making these harassements disappear. In the meantime I guess we can only hope that some day the industry will learn from this and stop trying to limit the consumers who pay for their products.
Sorry if this sounded flamebait. Rate it down if you feel it is inappropriate.
With the DVD hack being just one of several successful attacks on 'secure' formats, due in some part to the accessibility of data streams inside a computer, one has to wonder whether hardware manufacturers will start integrating an encrypted bus (sp? I haven't had my Coke yet) into the hardware itself. For example, the Microsoft WAM format was 'cracked' (not really, just circumvented) about a half hour after the format was released. How? Someone wrote a low-level hack that simply copied the unencrypted audio stream to a file just before it went to the sound card. But what if the bus between the CPU and the sound device was encrypted? Then, barring stupid implementations (like putting the digital to analog converter on a separate chip outside of the sound card chip), the only output from the soundcard would be an analog audio signal...and then we're thrust back into the dark ages of copying analog tapes, and progressively degenerating copies. With companies like MS getting into the media industry, and their significant pull with the hardware manufacturers, is it inconceivable to think that things might go this far? B.
Whether a movie sucks or not has almost no impact on whether or not it is successful. I have seen way too many terrible movies (Godzilla anyone?) That were quite successful and even more really great movies (Highlander anyone?) that were total flops. It seems to me that the key to making a successful film these days is to appeal to the broadest cross-section of the american public. This of course means that films cannot be too strange or clever because people will then find them inaccessible. I mean come on, do you really think that a film like 2001: A Space Odyssey would get made today?
I think Sony should learn that if you don't produce a player to play DVD movies under linux, the nerds will simply hack in and break your encyption. If they would have just come up with a player that works under linux, all this would have been avoided. Or at least pushed back. When the internet gets fast enough, and storage medium get big enough, that people can download movies for free (as fast or faster than an MP3) Hollywood will have to change their strategy. Who knows maybe they will start making good movies instead of multi-million dollar crap that has good special effects. No, I don'r see that happening.
One thing that doesn't seem to have been considered in this whole scheeme seems to be what happens if they remove a manufacturer? It has been mentioned that they planned to kill any keys that were compromised.
What would happen to all the consumers who had purchased DVD players that used that key? Is my brand new DVD player (of the home theater unit type) going to stop working on new movies if someone cracks and publishes JVC's key? I don't think they have the guts to actually do that, but it does seem to be what they are planning.
I think the manufactures will probally learn that they can't rely completely on encryption for copying, and with the failure of DIVX I doubt they will try per view marketing any time soon (They are offering $100 rebates to anyone who bought DIVX players before they anounced their failure, so it cost them big).
Visit Humpin! (No, it's not what you think!)
Explanation on legality of this information:
The software (source as well as binaries) offered on this site can be freely redistributed. It was written by authors who expressly permitted and encourage the redistribution of this software and information. The purpose of this software is not, I repeat not illegal copying of DVD disks. It is meant to provide information necessary to be able to program a DVD player for Linux. To do this, the CSS system needs to be incorporated in the player. Recently the (very weak) content scrambling system was deciphered, freeing the way for a Linux DVD player. The CSS system is not a copy protection system, since it does not prevent copying of the disk. Writing information about the way a certain protection scheme functions is completely legal. The source code and binaries on this site are completely legal too, since they contain no code from the DVD consortium or one of its members. The sources and programs on this site are purely written by 3rd parties using clean-room reverse engineering methods, which is, again, completely legal. This software and information below make it possible for people who legally obtained their DVD movies to view them on their Linux systems.
Attention
www.rhythm.cx was hosting a list of mirrors for these files. That list of mirrors has been replaced with a page reading "This site has been taken down for legal reasons." Here's what the maintainer put on the site the day it was shut down:
NOTE (Thu, Nov 11, 12:17pm EST): I've recently been informed that a law firm which is likely to be one that would try get these mirrors taken down has been visiting this mirror site as well as others. With that said, there is a possibility that I may have to remove this site in the near future because like everyone else, I can't afford to go to court to fight it. Luckly, it seems fairly unlikely that any law firm will ever be able to get rid of all these mirrors at this point (there are currently 41 in 8 different countries and this list is growing every day). However, I have only seen very few mirror _lists_ like this one anyplace. If anyone has the resources, it might be wise to mirror this list of mirrors as well so that the right people will still know that these mirrors exist.
UPDATE: Here is a 2600 story with more details on how rhythm.cx was shut down.
I have taken it upon myself to mirror the mirrors. So until such time as the hounds of hell come a-knocking at my door, I present for you this list:
Page last updated: Sun, Nov 14, 8:41pm EST
Current Mirrors
(Numbers are only for the maintainer's convenience)
This site contains some good technical documentation as well as more source code that the DVD consorium's lawyers would rather you not see:
http://crypto.gq.nu/
Semi-broken Mirrors
(These mirrors sometimes work and sometimes don't)
ftp://134.173.94.44/
Broken Mirrors
(These are listed here for the notification of the people who run them)
http://members.theglobe.com/avoiderman/css-auth.t
Mirrors shut down by The Man
(A moment of silence, please.)
http://www.rhythm.cx/dvd/css-auth.tar.gz and http://www.rhythm.cx/dvd/DeCSS.zip
http://dvdcracked.tvheaven.com/index.html
/*
/* 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
*
* 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;
* 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};
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);
This source package does two things.
/path/to/dvd/device
/path/to/dvd/device
/path/to/dvd/device /mount/path/video_ts/vts_01_1.vob
/path/to/dvd/device
/dvd/video_ts/vts_01_[1-9].vob|css-cat -v1P -|mpeg2player -vob -f -
.key in the sources to .key1/.key2
a) It contains code to perform the css authentication protocol,
allowing locked sectors on the DVD disc to be accessed.
This also allows us to read the disc key and title keys.
b) It contains an implementation of the css decryption algorithm,
so that we can watch DVD's.
Also included are some test programs to wrarp around the above code
blocks so that something usefule can be performed.
The programs included are tstdvd, reset, dvdinfo and css-cat.
tstdvd can be used to unlock the disc (saving the disk key) and
to extract the title keys. usage is:
reset
This will reset all AGIDs that the drive has given out. This
can sometimes be useful when something goes wrong.
tstdvd
This will authenticate the device and save the disk key into
a file in the current directory called "disk-key".
(mount the dvd somewhere)
tstdvd
This will reauthenticate and then read the title key for
the chosen vob file, saving it in a file in the current
directoy called "title-key".
Do the above title key extraction for each title on the disc,
renaming the title-key files to title1-key, title2-key etc.
dvdinfo
Displays some info from the physical and copyright pages. This
includes the region limits on the disc, its encryption status,
and the authentication status.
css-cat [-t title-no] [-m mpeg-audio-no ] [-vPpm12345678] vob_file
This will decrypt the selected vob file and send to stdout. It
needs the files "disk-key" and "titleX-key" to be in the current
directory. The default title-no is one, so by default it will look
for "title1-key".
The options select what will be sent to stdout. By default, nothing
will. The m option is not yet coded, the v option selects video, the
numbers select the appropriate AC3 stream.
It will normally extract the selected stream from the enclosing
Program stream, thus giving an elemental stream. However if the K option
(or more than one stream) is selected then the data will be left inside
the PES packets, allowing a subsequent demux program to determine the
data type.
I tend to use:
cat
NOTE: To use the above you need to have a kernel which incorporates the
DVD ioctls. This can either be the original patch by Andrew Veliath
or Jens Axboe's patches. If using Andrews versio of the patches,
you'll have to change the use of
(the places are quite easy to find).
Jens site is www.kernel.dk
Changes:
Patches have been applied to use the OpenBSD headers, so maybe it'll
work.
There a some more keys included. It should now be able to decrypt
all titles currently on the market. I think the last two keys can
be removed. Someone with 'The Matrix' please test and get back to
me.
Mpeg audio streams should now be extractable when filtering, this is
untested.
It now copes with System headers in the Pack layer (those 0x000001bb
start codes).
The command line options have changed between the last version and
this one - pay attention.
/*
/* Host data receive (host changes state) */
/* Host data send */
/* Returning data, let LU change state */
/* Returning data, let LU change state */
/* Init sequence, request AGID */
* tstdvd.c
*
* Example program showing usage of DVD CSS ioctls
*
* Copyright (C) 1999 Andrew T. Veliath
* See http://www.rpi.edu/~veliaa/linux-dvd for more info.
*/
/*
* If supplied with one parameter it gets the disk key and
* saves it to a file. If supplied with a second parameter
* (a LBA) then it gets the title key for the supplied LBA.
*
* When getting the disk key, only the first 10 bytes of it
* are printed. The whole key is written to the file.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#if defined(__OpenBSD__)
# include
#elif defined(__linux__)
# include
#else
# error "Need the DVD ioctls"
#endif
#include "css-auth.h"
byte Challenge[10];
struct block Key1;
struct block Key2;
struct block KeyCheck;
byte DiscKey[10];
int varient = -1;
void print_challenge(const byte *chal)
{
int i;
for (i = 0; i type) {
case DVD_LU_SEND_AGID:
printf("AGID %d\n", ai->lsa.agid);
ai->type = DVD_HOST_SEND_CHALLENGE;
break;
case DVD_LU_SEND_KEY1:
printf("LU sent key1: "); print_key(ai->lsk.key); printf("\n");
if (!authenticate_drive(ai->lsk.key)) {
ai->type = DVD_AUTH_FAILURE;
return -EINVAL;
}
ai->type = DVD_LU_SEND_CHALLENGE;
break;
case DVD_LU_SEND_CHALLENGE:
for (i = 0; i hsc.chal[9-i];
printf("LU sent challenge: "); print_challenge(Challenge); printf("\n");
CryptKey2(varient, Challenge, &Key2);
ai->type = DVD_HOST_SEND_KEY2;
break;
case DVD_HOST_SEND_CHALLENGE:
for (i = 0; i hsc.chal[9-i] = Challenge[i];
printf("Host sending challenge: "); print_challenge(Challenge); printf("\n");
break;
case DVD_HOST_SEND_KEY2:
for (i = 0; i hsk.key[4-i] = Key2.b[i];
printf("Host sending key 2: "); print_key(Key2.b); printf("\n");
break;
default:
printf("Got invalid state %d\n", ai->type);
return -EINVAL;
}
return 0;
}
int authenticate(int fd, int title, int lba)
{
dvd_authinfo ai;
dvd_struct dvds;
int i, rv, tries, agid;
memset(&ai, 0, sizeof (ai));
memset(&dvds, 0, sizeof (dvds));
GetASF(fd);
for (tries = 1, rv = -1; rv == -1 && tries [title_path]\n");
exit (1);
}
device = av[1];
fd = open(device, O_RDONLY | O_NONBLOCK);
if (fd 0) {
perror(device);
exit(1);
}
if (ac == 3) {
lba = path_to_lba(av[2]);
title = 1;
}
authenticate(fd, title, lba);
close(fd);
return 0;
}
The CNN article reads:
The defeat of the algorithms, which were weak because they were designed to meet U.S. and Japanese export controls, makes it possible to build an open-source DVD player that the DVD Forum can't disable, he said.
Is there a source of information on what are Japanese export controls on cryptographic technology?
Thanks!
Ehttp://eugeneciurana.com | http://ciurana.eu
The CNN article reads:
The defeat of the algorithms, which were weak because they were designed to meet U.S. and Japanese export controls, makes it possible to build an open-source DVD player that the DVD Forum can't disable, he said.
Is there a source of information on what are Japanese export controls on cryptographic technology?
Thanks!
Ehttp://eugeneciurana.com | http://ciurana.eu
Someone has? I can't find it. (-: echocall :-)
This is the one GOOD thing I've seen from restricting exportation of encryption. Now, thanks to Uncle Sam "Protecting" me from those pesky Terrorist Cryptologists, I can watch The Matrix.
Actually, copy protection in software started more than 10 years ago. I got my first modem for my Atari 800XL around 1985, and found a thriving pre-existing market in cracked software. I'd estimate it as being closer to 20 years old. And the abandonment of these copy protection schemes was not a quick process. People were cracking software for years before the software companies finally gave up.
-- $SIGNATURE
I used to work for Diamond Multimedia in their Hardware DVD decoder department. (They sold well in Brazil) Diamond had the internal documents as to why CSS endcryption and how it was supposed to work. It wasn't a pleasant read.
.1 cent more per unit, but didn't.
What the designers were trying to do with the encryption was to prevent Nation-States from resetting the geographic region key. This was the prime requirement and it came from the US. Department of State. The argument was that there was a "matter of National Interest" in preventing someone from resetting the region key in order to protect distribution. (?) The example was that it should not be possible to cut a wire or disable a single instruction and get unencrypted data into the memory.
If you read between the lines they were pretty clearly afraid of the following scenario: Fantastic movie is released in the U.S. Makes a fortune in DVD. Is released in zone 2 for Europe and makes a mint. Released in another zone and two people buy it, yet the same movie, poorly dubbed, is the number one seller in those regions. Some national government with access to high-tech and Nobel Laureates cracked the childishly simple older protection schemes and the national government is now engaged in wholesale piracy. A cease and desist order is issued and the response comes back "No. And we are willing to wage war to protect our right to rip you off." State thought that scenario was "likely". And they all but came out and said this in their documents.
That's where CSS came from. Why it's weak is that consumer item manufacturerers will not pay to implement anything unless they risk going to jail for not doing so. There are thousands of examples of consumer goods out there that would have been grossly superior if the manufacturer had been willing to spend
I just wanted to set the record straight.
-C
Journalistic objectivity is a complex thing.
...
There are some news sources which claim to be 'objective' but which have evident long-term biases in their coverage. You can probably think of a few on both sides of the usual "left-wing" / "right-wing" spectrum -- And that's just as Americans use the terms.
Is the New York Times unbiased? Is the Washington Post? In this context, is PC World? Is Network Computing?
There are other sources which make no bones about their editorial preferences, but which nonetheless make good news sources, because having a bias is not the same as being willing to lie or stomach distortions. In fact, it makes it easier for a reader to realize what parts of a story may have been emphasized or de-emphasized.
In the context of slashdot, an article which exhibits none of the usual FUD can be seen as pleasantly "biased" toward Linux. Think of the bias of a tape -- a known reference point based around which other information is encoded. (That's poor phrasing, but is the analogy fair?)
just thoughts
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
"Never mind that film and music are the art of our age, and the price for enjoying that art has become too steep (just consider CD prices, versus the 70 cents per CD sold an artist would be lucky to get). "
:-) I'm working on that.
Don't forget books too. I mean, an author is likely to get more than 70 cents per item sold, but how many real authors sell as many books as CD's get sold? (like Stephen King, though I respect him as a good author, he's great, but an exception)
I mean, someone like David Foster Wallace or William T. Vollmann doesn't make a shitload off their book sales.
As for the music industry.
bye
Dan
Entertain yourself! Go on, get out and make your own movie called life. Hang out with your friends and do something! Make some music, hell make a movie, but escape the sofa while you can!
Don't worry if you can't. Someone will always have some other dog and ponny show if Sony prices themselves out of the market. Spend your money as you please, but don't waste your time whining.
This isnt 1939 NAZI germany, you can do what yo ulike in your own house. The govt can go fuck it self.
Don't mess with my nostalgia...
// line well before Apple got into the Macintosh business. Of course, those of us who owned a //gs had the best of both worlds--color Mac interface, but all of the old classic games and software.
Copy II+ was out for the Apple
Oregon Trail Forever!