Activist Defends DVD Hack 84
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.
DVD under linux (Score:1)
Re:DVD under linux (Score:1)
Protection possible? (Score:1)
tsrif ?
Can I legaly recover my own copy protection code? (Score:1)
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!
The requisite mirrors (Score:1)
Re:DVD under linux (Score:2)
After Creative's recent support for several of their soundcards (which isn't too big of a deal anyway, as their soundcards were among the best supported anyway) makes me hope they will release drivers for their dxr2 card.
Anyway, DVD support and mpeg decoder support goes hand in hand. If linux can read encrypted dvd's, then there is an incentive to have drivers for decoder cards. Alternately, the best use for supported decoder cards is to play DVD movies.
Either way, as linux moves towards the mainstream, this type of hardware will by necessity be better supported.
Doug
The funniest part of the article... (Score:2)
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
css key and decoder hardware (Score:1)
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 [videodiscovery.com] for a lot of good info.
Re:css key and decoder hardware (Score:3)
They don't just give it out to anyone who wants it.
Re:Protection possible? (Score:2)
DIVX only needs the phone line because of its pay-per-view nature. The player has to report back the serial numbers of the discs you watch, so that they can bill your credit card.
Note that there's really no such thing as "tamper-proof" hardware. It's all a matter of how difficult you make it. And naturally, the more valuable the content is, the more money people will be willing to spend to try to crack the system.
I've always thought that the best way to advance research into factoring very large numbers would be to adopt a digital cash system based on the RSA cryptosystem.
Re:Can I legaly recover my own copy protection cod (Score:1)
Ridiculous export restrictions (Score:1)
________________________________
If encryption is outlawed, only
dxr2 drivers (Score:2)
See http://opensource.creative.com [creative.com].
Message to Media Outlets (Score:3)
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 [thehungersite.com]
Re:DVD under linux (Score:1)
Matsushita (Score:1)
Chilli
Re:Protection possible? (Score:2)
heh. It's impossible, for the near future, to physically extract significant information from the human brain (such as a PIN or password). Some work has been done in biological computing to use the "brains" of smaller insects to store information - because it shows promise to being 100% tamper resistant. Though, nothing working has any practical use yet - as far as I'm aware.
But actually what the newer sat decoder boxes do is have a slow smart card that decrypts a new key every second or so. The smart card is "tamper-resistant" to a large degree and passes the key to the decoder hardware which is not tamper-resistant.
No one has broken the smart cards yet... but that's not to say it can't be done with a lot of money. Getting a key for 1 second doesn't do much for you. However, if you can buffer your transmission data and delay it for a few seconds, you can have someone else continously send you the decoded keys over the internet. Having to send data continously makes the operation risker because there is a way to trace you... though you can send "almost untraceable" data by using ICMP to ping-with-data to a remote host and a forged return address. With all that money flying around, I'm sure someone will give it a try.
Weaknesses in the algorithm. (Score:1)
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.
Re:Protection possible? (Score:1)
I take that back.. Too my knowedge, no one in the black market has broken these things yet. If someone has let me know.
bias? (Score:2)
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.
Better, but not quite (Score:1)
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.
Re:bias? (Score:1)
Illegality. (Score:1)
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.
Old news (Score:1)
--
The real story is why Sony et. al. want encryption (Score:3)
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...
Re: Movies & profits (Score:1)
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.
Re:Weaknesses in the algorithm. (Score:1)
If a mere user like myself can encrypt at 4096 bits using PGP, it's laughable that DVD was limited to 40 bits (or whatever).
No-one *really* loses out over DeCSS until DVD recorders hit the marketplace. I mean, the hardware you need to store and playback a 9Gb
Ethical Contradiction? (Score:1)
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.
Re:Ethical Contradiction? (Score:2)
- To promote differential pricing between regions.
- To create a closed group of manufacturers who are capable of producing DVD.
- To have the ability to remove manufacturers from the allowed group.
- To create a closed group of manufacturers capable of producing DVD players (and remove them at will).
What they have actually suceeded in doing is:
- Creating an industry in player chipping.
- Creating an industry which sells massive amounts of region 1 discs to the rest of the world.
- Ruined sales in countries not in region 1.
If it weren't for this encryption nonsense, we would have had DVD years earlier. In region 2, we get DVDs with barely any features, sometimes in the old dual sided (not dual layer) format and for double the cost of a region 1 disc. Not to mention the players are about 50-100% more expensive too.
No, I don't have any respect for the people who brought about DVD encryption, nor should anyone else.
Yeah, but whose fault is that? (Score:1)
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
Can Someone Enlighten Me? (Score:1)
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.
What the hell? (Score:2)
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
Re:Protection possible? (Score:1)
Bribes or force will often do the trick.
(such as a PIN or password). Some work has been done in biological computing to use the "brains" of smaller insects to store information - because it shows promise to being 100% tamper resistant.
We need a way to extract the info from the insect, or it would be useless as a storage device. What would stop a cracker from using exactly the same method after stealing the insects and the interface hardware?
Though,
nothing working has any practical use yet - as far as I'm aware.
Re:The real story is why Sony et. al. want encrypt (Score:1)
Re:The funniest part of the article... (Score:2)
However many well known western companies and even russian ones hunt down hackers for reverse engineering their soft. Any reverse engineer btw.
Most commercial licenses try to "forbid" users doing this.
What they are? The Law? Is Microsoft a company or the Holy Redmond Empire, with sovereignity over the whole world? They don't even seem to care that such statements on their licenses may void them in face of the laws of sovereign countries.
Frankly if there is someone to blame for illegalities in software, blame 90% of copyright holders...
"The ignorance of the law oes not free a person from responsability..."
Re:Can Someone Enlighten Me? (Score:1)
About copying dvd-discs.. It is currently not possible to make copies of dvd-video discs. The only thing you can do with it (now) is extract the video information (decrypted) and place it on a different media. After this incident, i doubt that the future dvd-writers will support writing dvd-video discs(and why would they anyway - due to the proprietary format and the encryption algorithm). Only way I could imagine making a copy is a raw copy of all of the data but i'm pretty sure they have thought of this before deploing any dvd-video products. And what would you do with a decrypted movie written to a dvd? Watch it on your computer at the most (sure you could deprive your local movie rental place of few bucks like this, but you can already with normal vhs). Regular dvd-players will expect all the data on a disc to be encrypted anyway.
I think that the biggest concern with the encryption was to prevent unauthorized distribution via internet. Yes, those are big movies but still feasible to transfer anywhere in the world(thus btw. circumventing the area restrictions) where people can then, for instance, make regular vhs-copies of very high quality very easily. Of course there is the issue of different tv-standards (still, even with fully digital media!!!) but that is considerably easier to deal with than the encryption.
DVD miorrs (Score:1)
Copy Protection has Never Worked (Score:2)
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.
Let my VOBs go free (Score:1)
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 ?
Exactly my point! (Score:1)
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.
As far as I can tell... (Score:2)
Re:Ridiculous export restrictions (Score:1)
The reason it was broken so (relatively) easily was that the encryption algorithm was basically flawed, and hence one (unencrypted) key lead to the discovery of others (ask someone else for details, I know nothing about the subject...)
And the Japanese (IIRC) are allowed really strong encryption as a right. Maybe they're allowed them, but can't export them, or maybe CNN, as a US news service, was feeling patriotic?
Either way, it wasn't down to US encrytion export laws, which is a pity, as having big guns like Sony, etc, lobbying strongly for stronger encryption exports would quickly change the US export laws. Or am I just being cynical?
Paul
Re:Ethical Contradiction? (Score:2)
XEmacs is the classic example of a "moral fork". The XEmacs people enhanced Emacs and contributed the changes back. The FSF wasn't interested, and XEmacs forked. No problem there; just different goals.
The same is true here. People have been asking for DVD support in Linux for a while now, but the big manufacturers didn't want to talk. (Probably a "not enough money in it" argument.) So, after getting rebuffed by the official channels, the Linux community went to the next step: do it ourselves.
If the manufacturers are sore, they have only themselves to blame. A free-beer (or really cheap) software decoder would have gone a long way towards preventing this outcome. Too bad for them; I agree that I should be able to play my legal DVDs on my legal hardware, no matter what the pointy-hairs at Sony say.
Re:Let my VOBs go free (Score:1)
you'll have to compile it though. Don't be scared. If you're too lazy to figure it out, go play the damn thing in Windows.
Also, the framerates are pretty low right now.
----
Re:Message to Media Outlets (Score:1)
The same argument works the other way. If I believe in IP, I have to protect it adequatly. Reverse engineering a panel means I still have to be competitive in producing and marketing it - there are significant real costs. Breaking the DVD protection means that (barring other copying problems) the market for content breaks down.
Re:Weaknesses in the algorithm. (Score:1)
I don't think so, and I don't think the DES keyspace is sparse.
Re:bias? (Score:1)
The ability to remove manufacturers (Score:1)
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).
mirrors (Score:1)
Visit Humpin [humpin.org]! (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 [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 [2600.com] 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/ [crypto.gq.nu]
Semi-broken Mirrors
(These mirrors sometimes work and sometimes don't)
ftp://134.173.94.44/ [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
css-auth.c (Score:1)
*
* 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};
Re:Message to Media Outlets (Score:1)
Surely in this case the opposite is true. Breaking the protection enables the DVD to be viewed on systems which would otherwise be unable to do so. This will increase the market for content in DVD format.
Japanese crypto export controls? (Score:1)
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!
EJapanese crypto export controls? (Score:1)
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!
ERe:Can Someone Enlighten Me? (Score:1)
thank goodness for export laws (Score:1)
Re:Message to Media Outlets (Score:1)
- Yes, that's right. When misinformed people choose the redefine the language, we should all immediately change our ways in order to make them correct. Public opinion is so important...
Re:Message to Media Outlets (Score:1)
Re:dxr2 drivers (Score:1)
Re:DVD under linux (Score:1)
Matrox cards may suck royally for playing most games, but this is one place where they rule.
Nitpick (Score:2)
Re:Protection possible? (Score:1)
Handcuffs and club will do the trick -- technology is several thousands years old %)
Re:Weaknesses in the algorithm. (Score:1)
This would only prove to be a roadblock for US companies making DVD recording hardware. That hardware would have to be made outside the US for non-US users. Those made in the US would not be exportable. Plus, if the encryption technology were developed on US soil, then it could never leave the US
Re:The ability to remove manufacturers (Score:1)
What CSS was intended for. (Score:1)
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
Re:Message to Media Outlets (Score:1)
As long as movies are too big to easily upload and store on the HD, I can't see mass piracy being a problem when user copying is considered.
pleasantly and biased in same sentence ok by me (Score:2)
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
Re:The real story is why Sony et. al. want encrypt (Score:1)
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
Apple ][ Forever! (Score:1)
Copy II+ was out for the Apple
Oregon Trail Forever!
Re:DVD under linux (Score:1)
The performance increase is actually more like 25-50% from the feedback I have gotten (I wrote some of the backend scaler code for the G200/G400).
The main part is that the driver relieves the X server from copying the data to the framebuffer on the graphics card and also handles scaling of the image. I have fullscreen DVD running as my desktop background with ~25fps (w/o sound) on my Celeron 400, and that's with a software mpeg2 player that is not very optimized. :-)
I think we will see some interesting stuff in the coming weeks...
Check out the LiViD homepage [openprojects.net] and the mailing list for more info.
Fredrik