Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
The Media

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.
This discussion has been archived. No new comments can be posted.

Activist Defends DVD Hack

Comments Filter:
  • 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.
  • It may not work great now, but the strength of open source will fix that eventually. By getting DVD opened it gives developers more time to make a reliable player.
  • 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 [134.173.94.44] and binary [134.173.94.44]
  • The biggest problem is a lack of support for decoder cards.

    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
  • Was when the DVD consortium (the DVD Mafioso?) just outright called the program "illegal", even though it was produced in Norway, where reverse-engineering is fully legal. Companies will say any old stupid thing, though, when a threat to their bottom line, real or imagined, is perceived. At any rate, I hope everyone manages to grab the source code for it off the mirror posted above; Linux shouldn't be denied the ability to play DVD movies!

    - A.P.
    --


    "One World, one Web, one Program" - Microsoft promotional ad

  • 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 [videodiscovery.com] for a lot of good info.
  • by Eric Smith ( 4379 ) on Sunday November 14, 1999 @10:11PM (#1533421) Homepage Journal
    CSS can be licensed "for free" IF they like you AND you sign a very nasty NDA.

    They don't just give it out to anyone who wants it.

  • Is it possible to make an encryption system that supports one-way transmission (broadcast) to a hostile client?
    If the client device is somehow protected against reverse-engineering (by burying the decryption hardware inside a tamper-proof chip), and you don't want to charge pay-per-view, it's basically possible.

    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.

  • Suppose that I master my own DVD and loose my copy protection code.
    If you use "your own copy protection code", your disc won't be compatible with standard DVD players.
  • Apparently the weak encryption standards are at least partly to be blamed for the hack. IMHO it is really ridiculous to still insist on export restrictions when you can get PGP anywhere in the world.

    ________________________________
    If encryption is outlawed, only

  • Creative did release drivers.

    See http://opensource.creative.com [creative.com].
  • by Dacta ( 24628 ) on Sunday November 14, 1999 @10:35PM (#1533427)

    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]

  • Alan Cox mentioned in his diary [linux.org.uk] that a preliminary driver for the scaler on Matrox G200/G400 cards is out there, so we may see some advances in the next few weeks/months.
  • BTW, Matsushita is the Japanese name for the company that outside of Japan is know as Panasonic - just in case you want to know who to blame.

    Chilli

  • Note that there's really no such thing as "tamper-proof" hardware.

    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. ;)

  • 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.
  • No one has broken the smart cards yet.

    I take that back.. Too my knowedge, no one in the black market has broken these things yet. If someone has let me know. ;) I was talking to the guys from cryptography.com who break smart cards for a living, and they were saying several of the new sat decoder systems are very secure.
  • CNN has posted a pleasantly Linux biased story about the DVD hack

    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 agree that bias and prejudice should be fought at any level. But an article biased towards linux is a nice for a change in mainstream press.
  • 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.

  • by kdart ( 574 )
    This article is dated November 8th, and has been linked from here in an earlier DVD thread.

    --
  • by Sir_Winston ( 107378 ) on Monday November 15, 1999 @12:11AM (#1533440)
    ...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...
  • > 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.

  • It's quite amusing really - the US/Japanese governments are really to blame for this, with their frankly pathetic attempts to control encryption technology.

    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 .VOB file, you might as well buy yourself a home-cinema DVD player and a handful of titles, and watch DVD the way God intended - on a TV. DVD playback quality on a PC frankly sucks, even on a hardware-accelerated machine; and you could buy a 36-inch TV for the cost of a 21" monitor!
  • Every so often, someone comes along who does something to some free software that is allowed by the license, but clearly against the wishes of the author.

    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.

  • Quite simply nobody has any respect for those who setup DVD encryption. The official reason from encryption is to stop duplication. This hasn't worked. Other 'unofficial' but blatantly obvious reasons are:

    - 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.
  • If Hollywood produces a shit movie, is it any wonder people don't see it?

    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

  • I'm really confused about this entire fiasco. As far as I understand things:

    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.

  • You're saying that, as human beings, we should assume a set of morals which dictate that we tacitly submit to the whims of (in this case) an industry? How on earth can you consider *this* any more moral than what the people who cracked DVD did?

    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

  • heh. It's impossible, for the near future, to physically extract significant information from the human brain
    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.
  • 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.
  • Interesting to note how these Companies are concerned on legalities. As in Norway, Russia has legislation regulating the right to reverse engineer software. For purposes of adding or adapting software to more specific purposes. Note that this does not mean that piracy is allowed, as some people try to interpret. In the law this stuff is well remarked and distribution of cracked soft is considered a copyright violation.

    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..."
  • I think it goes as follows: You have 400 encryption/decryption keys/keypairs. You have one key you use to encode the movie with. After this you encode this key with all of the 400 encryption keys and write it on to the disk 400 times. Now, when a player wants to play the movie it uses its decoding key to get the key that decodes the movie and can then start playing.

    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.

  • If you look on www.2600.com, I think that they have the files and an image of the site.
  • About 10 years are so the computer industry made a stab at copy protection and quickly found out that it didn't work. People would quickly hack it out and there were quite a few products on the market to help defeat it (Anyone remember Copy II+ for the Apple Mac?) The products that didn't incorporate copy protection often did better in the market than those that did simply because they were more convienent to the honest consumers who usually didn't want to mess with some obscure copy protection scheme.

    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.

  • 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.
  • 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 this is incorrect on CNN's part (more's the pity).

    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
  • by Anonymous Coward
    No, the ethical condemnation comes when people disrespect the wishes of the author *without consulting him first*.

    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.
  • use nist, grab it from the livid cvs archive. (livid.on.openprojects.net)
    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.

    ----

  • 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.

    I'm not going to defend the DVD consortium. However, the situations are not fully analogical. One of the reasons for creating free software is that information is not a natural property, but only an artificial one. This is due to the fact that making additional copies has little cost. The maximum benefit that society can get from a piece of information is obtained if it is free.

    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.

  • So DES, at 56 bits, is secure?

    I don't think so, and I don't think the DES keyspace is sparse.
  • Actually, I was trying to be ironic. Having a bias seems to be unavoidable to we mere mortals. At least this article was biased to the Right and Good instead of the dark forces of corporate badness.
  • 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).
  • by Anonymous Coward
    Oh yeah

    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)

    1. http://www.humpin.org/decss/DeCSS.zip [humpin.org] and http://www.humpin.org/decss/decss.tar.gz [humpin.org]

    2. http://home.worldonline.dk/~ andersa/download/DeCSS.zip [worldonline.dk]
    3. http://douglas.min.net/~drw/css-auth/ [min.net]
    4. http://www.devzero.org/freecss.html [devzero.org]
    5. http://home.t-online.de/home/skinn er01/decss.zip [t-online.de]
    6. http://www.chello.nl/~f .vanwaveren/css-auth/css-auth.tar.gz [chello.nl]
    7. http://www.geociti es.com/ResearchTriangle/Campus/8877/index.html [geocities.com]
    8. http://www.angelfire.com/mt/popefelix/ [angelfire.com]
    9. http://www.vexed.net/CSS [vexed.net]
    10. http://members.brabant.chello.nl/~j.vr eeken/ [chello.nl]
    11. http://gullii.stu.rpi.edu/dvd/files/D eCSS.zip [rpi.edu] and http://gullii.stu.rpi.edu/dvd/f iles/css-auth.tar.gz [rpi.edu]
    12. http://www.dvd.eavy.de/css-auth.tar.gz [dvd.eavy.de] and http://www.dvd.eavy.de/DeCSS.zip [dvd.eavy.de]
    13. http://www.eavy.net/stuff/dvd/css-aut h.tar.gz [eavy.net] and http://www.eavy.net/stuff/dvd/DeCSS.zip [eavy.net]
    14. http://www.dynamsol.com/satanix/DeCSS.zip [dynamsol.com]
    15. http://frozenlinux.com/civ/decss/ [frozenlinux.com]
    16. http://www.unitycode.org/ [unitycode.org]
    17. http://dirtass.beyatch.net/decss.zip [beyatch.net]
    18. http://sharedlib.org/decss.zip [sharedlib.org]
    19. http://decss.tripod.com/index.html [tripod.com]
    20. http://www.free-dvd.org.lu/ [free-dvd.org.lu]
    21. http://www.angelfire.com/in2/mirror/ [angelfire.com]
    22. http://mclaughlin.orange.ca.us/~andrew/ [orange.ca.us]
    23. http://www.dynamsol.com/satanix/css -auth.tar.gz [dynamsol.com]
    24. http://batman.jytol.fi/~vuori/dvd/ [jytol.fi]
    25. http://www.zpok.demon.co.uk/deCSS/CSS.ht ml [demon.co.uk]
    26. http://plato.nebulanet.net:88/css/ [nebulanet.net]
    27. ftp://alma.dhs.org/pub/DVD/ [dhs.org]
    28. http://www.d.umn.edu/~dchan/css/ [umn.edu]
    29. http://www.logorrhea.com/main.html [logorrhea.com]
    30. http://people.delphi.com/salfter/LiVi d.tar.gz [delphi.com]
    31. http://www.theresistance.net/files.html [theresistance.net]
    32. ftp://193.219.56.32/pub/dvd/LiVi d.CVS-11.06.tar.gz [193.219.56.32] and ftp://193.219.56. 32/pub/dvd/LiVid.CVS-11.06.css-stuff-only.tar.gz [193.219.56.32]
    33. http://merlin.keble.ox.ac.uk/~a drian/css/index.html [ox.ac.uk]
    34. http://www.dvd-copy.com/ [dvd-copy.com]
    35. http://www.zip.com.au/~cs/dvd/css /css-auth.tar.gz [zip.com.au] and http://www.zip.com.au/~cs/dvd/css/DeCSS .zip [zip.com.au]
    36. http://www.sent.freeserve.co.uk/css -auth.tar.gz [freeserve.co.uk] and http://www.sent.freeserve.co.uk/DeCSS.zip [freeserve.co.uk]
    37. http://members.tripod.lycos.nl/jvz/ [lycos.nl]
    38. http://joe.to/storage/files/decss.zip [joe.to]
    39. ftp://ftp.firehead.org/pub/ [firehead.org]
    40. http://www.lemuria.org/DeCSS/ [lemuria.org]
    41. http://members.theglobe.com/avoiderm an/dvd.htm [theglobe.com]
    42. http://remco.xgov.net/dvd/ [xgov.net]
    43. http://www.able-towers.com/~flow/ [able-towers.com]
    44. ftp://dvd:dvd@206.98.63.136 [206.98.63.136]
    45. http://www.twistedlogic.com/htm l/tl_archive_map.htm [twistedlogic.com]
    46. ftp://mikpos.dyndns.org/pub/cssdvd.zip [dyndns.org]
    47. http://mu nitions.vipul.net/software/algorithms/streamcipher s/decss.tar.gz [vipul.net]
    48. http:/ /munitions.polkaroo.net/software/algorithms/stream ciphers/decss.tar.gz [polkaroo.net]
    49. http://muni tions.dyn.org/software/algorithms/streamciphers/de css.tar.gz [dyn.org]
    50. http://mun itions.cifs.org/software/algorithms/streamciphers/ decss.tar.gz [cifs.org]
    51. http://uk1. munitions.net/software/algorithms/streamciphers/de css.tar.gz [munitions.net]
    52. http://209.68.37.134/decss/ [209.68.37.134]
    53. http://muni tions.firenze.linux.it/algorithms/streamciphers/de css.tar.gz [linux.it]

    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.ta r.gz

    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
  • by Anonymous Coward
    /*
    *
    * This code may be used under the terms of Version 2 of the GPL,
    * read the file COPYING for details.
    *
    */

    /*
    * These routines do some reordering of the supplied data before
    * calling engine() to do the main work.
    *
    * The reordering seems similar to that done by the initial stages of
    * the DES algorithm, in that it looks like it's just been done to
    * try and make software decoding slower. I'm not sure that it
    * actually adds anything to the security.
    *
    * The nature of the shuffling is that the bits of the supplied
    * parameter 'varient' are reorganised (and some inverted), and
    * the bytes of the parameter 'challenge' are reorganised.
    *
    * The reorganisation in each routine is different, and the first
    * (CryptKey1) does not bother of play with the 'varient' parameter.
    *
    * Since this code is only run once per disk change, I've made the
    * code table driven in order to improve readability.
    *
    * Since these routines are so similar to each other, one could even
    * abstract them all to one routine supplied a parameter determining
    * the nature of the reordering it has to do.
    */

    #include "css-auth.h"

    typedef unsigned long u32;

    static void engine(int varient, byte const *input, struct block *output);

    void CryptKey1(int varient, byte const *challenge, struct block *key)
    {
    static byte perm_challenge[] = {1,3,0,7,5, 2,9,6,4,8};

    byte scratch[10];
    int i;

    for (i = 9; i >= 0; --i)
    scratch[i] = challenge[perm_challenge[i]];

    engine(varient, scratch, key);
    }

    /* This shuffles the bits in varient to make perm_varient such that
    * 4 -> !3
    * 3 -> 4
    * varient bits: 2 -> 0 perm_varient bits
    * 1 -> 2
    * 0 -> !1
    */
    void CryptKey2(int varient, byte const *challenge, struct block *key)
    {
    static byte perm_challenge[] = {6,1,9,3,8, 5,7,4,0,2};

    static byte perm_varient[] = {
    0x0a, 0x08, 0x0e, 0x0c, 0x0b, 0x09, 0x0f, 0x0d,
    0x1a, 0x18, 0x1e, 0x1c, 0x1b, 0x19, 0x1f, 0x1d,
    0x02, 0x00, 0x06, 0x04, 0x03, 0x01, 0x07, 0x05,
    0x12, 0x10, 0x16, 0x14, 0x13, 0x11, 0x17, 0x15};

    byte scratch[10];
    int i;

    for (i = 9; i >= 0; --i)
    scratch[i] = challenge[perm_challenge[i]];

    engine(perm_varient[varient], scratch, key);
    }

    /* This shuffles the bits in varient to make perm_varient such that
    * 4 -> 0
    * 3 -> !1
    * varient bits: 2 -> !4 perm_varient bits
    * 1 -> 2
    * 0 -> 3
    */
    void CryptBusKey(int varient, byte const *challenge, struct block *key)
    {
    static byte perm_challenge[] = {4,0,3,5,7, 2,8,6,1,9};
    static byte perm_varient[] = {
    0x12, 0x1a, 0x16, 0x1e, 0x02, 0x0a, 0x06, 0x0e,
    0x10, 0x18, 0x14, 0x1c, 0x00, 0x08, 0x04, 0x0c,
    0x13, 0x1b, 0x17, 0x1f, 0x03, 0x0b, 0x07, 0x0f,
    0x11, 0x19, 0x15, 0x1d, 0x01, 0x09, 0x05, 0x0d};

    byte scratch[10];
    int i;

    for (i = 9; i >= 0; --i)
    scratch[i] = challenge[perm_challenge[i]];

    engine(perm_varient[varient], scratch, key);
    }

    /*
    * We use two LFSR's (seeded from some of the input data bytes) to
    * generate two streams of pseudo-random bits. These two bit streams
    * are then combined by simply adding with carry to generate a final
    * sequence of pseudo-random bits which is stored in the buffer that
    * 'output' points to the end of - len is the size of this buffer.
    *
    * The first LFSR is of degree 25, and has a polynomial of:
    * x^13 + x^5 + x^4 + x^1 + 1
    *
    * The second LSFR is of degree 17, and has a (primitive) polynomial of:
    * x^15 + x^1 + 1
    *
    * I don't know if these polynomials are primitive modulo 2, and thus
    * represent maximal-period LFSR's.
    *
    *
    * Note that we take the output of each LFSR from the new shifted in
    * bit, not the old shifted out bit. Thus for ease of use the LFSR's
    * are implemented in bit reversed order.
    *
    */
    static void generate_bits(byte *output, int len, struct block const *s)
    {
    u32 lfsr0, lfsr1;
    byte carry;

    /* In order to ensure that the LFSR works we need to ensure that the
    * initial values are non-zero. Thus when we initialise them from
    * the seed, we ensure that a bit is set.
    */
    lfsr0 = (s->b[0] b[1] b[2] & ~7) b[2] & 7);
    lfsr1 = (s->b[3] b[4];

    ++output;

    carry = 0;
    do {
    int bit;
    byte val;

    for (bit = 0, val = 0; bit > 24) ^ (lfsr0 >> 21) ^ (lfsr0 >> 20) ^ (lfsr0 >> 12)) & 1;
    lfsr0 = (lfsr0 > 16) ^ (lfsr1 >> 2)) & 1;
    lfsr1 = (lfsr1 > 1) & 1)

    combined = !o_lfsr1 + carry + !o_lfsr0;
    carry = BIT1(combined);
    val |= BIT0(combined) 0);
    }

    static byte Secret[];
    static byte Varients[];
    static byte Table0[];
    static byte Table1[];
    static byte Table2[];
    static byte Table3[];

    /*
    * This encryption engine implements one of 32 variations
    * one the same theme depending upon the choice in the
    * varient parameter (0 - 31).
    *
    * The algorithm itself manipulates a 40 bit input into
    * a 40 bit output.
    * The parameter 'input' is 80 bits. It consists of
    * the 40 bit input value that is to be encrypted followed
    * by a 40 bit seed value for the pseudo random number
    * generators.
    */
    static void engine(int varient, byte const *input, struct block *output)
    {
    byte cse, term, index;
    struct block temp1;
    struct block temp2;
    byte bits[30];

    int i;

    /* Feed the secret into the input values such that
    * we alter the seed to the LFSR's used above, then
    * generate the bits to play with.
    */
    for (i = 5; --i >= 0; )
    temp1.b[i] = input[5 + i] ^ Secret[i] ^ Table2[i];

    generate_bits(&bits[29], sizeof bits, &temp1);

    /* This term is used throughout the following to
    * select one of 32 different variations on the
    * algorithm.
    */
    cse = Varients[varient] ^ Table2[varient];

    /* Now the actual blocks doing the encryption. Each
    * of these works on 40 bits at a time and are quite
    * similar.
    */
    for (i = 5, term = 0; --i >= 0; term = input[i]) {
    index = bits[25 + i] ^ input[i];
    index = Table1[index] ^ ~Table2[index] ^ cse;

    temp1.b[i] = Table2[index] ^ Table3[index] ^ term;
    }
    temp1.b[4] ^= temp1.b[0];

    for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
    index = bits[20 + i] ^ temp1.b[i];
    index = Table1[index] ^ ~Table2[index] ^ cse;

    temp2.b[i] = Table2[index] ^ Table3[index] ^ term;
    }
    temp2.b[4] ^= temp2.b[0];

    for (i = 5, term = 0; --i >= 0; term = temp2.b[i]) {
    index = bits[15 + i] ^ temp2.b[i];
    index = Table1[index] ^ ~Table2[index] ^ cse;
    index = Table2[index] ^ Table3[index] ^ term;

    temp1.b[i] = Table0[index] ^ Table2[index];
    }
    temp1.b[4] ^= temp1.b[0];

    for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
    index = bits[10 + i] ^ temp1.b[i];
    index = Table1[index] ^ ~Table2[index] ^ cse;

    index = Table2[index] ^ Table3[index] ^ term;

    temp2.b[i] = Table0[index] ^ Table2[index];
    }
    temp2.b[4] ^= temp2.b[0];

    for (i = 5, term = 0; --i >= 0; term = temp2.b[i]) {
    index = bits[5 + i] ^ temp2.b[i];
    index = Table1[index] ^ ~Table2[index] ^ cse;

    temp1.b[i] = Table2[index] ^ Table3[index] ^ term;
    }
    temp1.b[4] ^= temp1.b[0];

    for (i = 5, term = 0; --i >= 0; term = temp1.b[i]) {
    index = bits[i] ^ temp1.b[i];
    index = Table1[index] ^ ~Table2[index] ^ cse;

    output->b[i] = Table2[index] ^ Table3[index] ^ term;
    }
    }

    static byte Varients[] = {
    0xB7, 0x74, 0x85, 0xD0, 0xCC, 0xDB, 0xCA, 0x73,
    0x03, 0xFE, 0x31, 0x03, 0x52, 0xE0, 0xB7, 0x42,
    0x63, 0x16, 0xF2, 0x2A, 0x79, 0x52, 0xFF, 0x1B,
    0x7A, 0x11, 0xCA, 0x1A, 0x9B, 0x40, 0xAD, 0x01};

    static byte Secret[] = {0x55, 0xD6, 0xC4, 0xC5, 0x28};

    static byte Table0[] = {
    0xB7, 0xF4, 0x82, 0x57, 0xDA, 0x4D, 0xDB, 0xE2,
    0x2F, 0x52, 0x1A, 0xA8, 0x68, 0x5A, 0x8A, 0xFF,
    0xFB, 0x0E, 0x6D, 0x35, 0xF7, 0x5C, 0x76, 0x12,
    0xCE, 0x25, 0x79, 0x29, 0x39, 0x62, 0x08, 0x24,
    0xA5, 0x85, 0x7B, 0x56, 0x01, 0x23, 0x68, 0xCF,
    0x0A, 0xE2, 0x5A, 0xED, 0x3D, 0x59, 0xB0, 0xA9,
    0xB0, 0x2C, 0xF2, 0xB8, 0xEF, 0x32, 0xA9, 0x40,
    0x80, 0x71, 0xAF, 0x1E, 0xDE, 0x8F, 0x58, 0x88,
    0xB8, 0x3A, 0xD0, 0xFC, 0xC4, 0x1E, 0xB5, 0xA0,
    0xBB, 0x3B, 0x0F, 0x01, 0x7E, 0x1F, 0x9F, 0xD9,
    0xAA, 0xB8, 0x3D, 0x9D, 0x74, 0x1E, 0x25, 0xDB,
    0x37, 0x56, 0x8F, 0x16, 0xBA, 0x49, 0x2B, 0xAC,
    0xD0, 0xBD, 0x95, 0x20, 0xBE, 0x7A, 0x28, 0xD0,
    0x51, 0x64, 0x63, 0x1C, 0x7F, 0x66, 0x10, 0xBB,
    0xC4, 0x56, 0x1A, 0x04, 0x6E, 0x0A, 0xEC, 0x9C,
    0xD6, 0xE8, 0x9A, 0x7A, 0xCF, 0x8C, 0xDB, 0xB1,
    0xEF, 0x71, 0xDE, 0x31, 0xFF, 0x54, 0x3E, 0x5E,
    0x07, 0x69, 0x96, 0xB0, 0xCF, 0xDD, 0x9E, 0x47,
    0xC7, 0x96, 0x8F, 0xE4, 0x2B, 0x59, 0xC6, 0xEE,
    0xB9, 0x86, 0x9A, 0x64, 0x84, 0x72, 0xE2, 0x5B,
    0xA2, 0x96, 0x58, 0x99, 0x50, 0x03, 0xF5, 0x38,
    0x4D, 0x02, 0x7D, 0xE7, 0x7D, 0x75, 0xA7, 0xB8,
    0x67, 0x87, 0x84, 0x3F, 0x1D, 0x11, 0xE5, 0xFC,
    0x1E, 0xD3, 0x83, 0x16, 0xA5, 0x29, 0xF6, 0xC7,
    0x15, 0x61, 0x29, 0x1A, 0x43, 0x4F, 0x9B, 0xAF,
    0xC5, 0x87, 0x34, 0x6C, 0x0F, 0x3B, 0xA8, 0x1D,
    0x45, 0x58, 0x25, 0xDC, 0xA8, 0xA3, 0x3B, 0xD1,
    0x79, 0x1B, 0x48, 0xF2, 0xE9, 0x93, 0x1F, 0xFC,
    0xDB, 0x2A, 0x90, 0xA9, 0x8A, 0x3D, 0x39, 0x18,
    0xA3, 0x8E, 0x58, 0x6C, 0xE0, 0x12, 0xBB, 0x25,
    0xCD, 0x71, 0x22, 0xA2, 0x64, 0xC6, 0xE7, 0xFB,
    0xAD, 0x94, 0x77, 0x04, 0x9A, 0x39, 0xCF, 0x7C};

    static byte Table1[] = {
    0x8C, 0x47, 0xB0, 0xE1, 0xEB, 0xFC, 0xEB, 0x56,
    0x10, 0xE5, 0x2C, 0x1A, 0x5D, 0xEF, 0xBE, 0x4F,
    0x08, 0x75, 0x97, 0x4B, 0x0E, 0x25, 0x8E, 0x6E,
    0x39, 0x5A, 0x87, 0x53, 0xC4, 0x1F, 0xF4, 0x5C,
    0x4E, 0xE6, 0x99, 0x30, 0xE0, 0x42, 0x88, 0xAB,
    0xE5, 0x85, 0xBC, 0x8F, 0xD8, 0x3C, 0x54, 0xC9,
    0x53, 0x47, 0x18, 0xD6, 0x06, 0x5B, 0x41, 0x2C,
    0x67, 0x1E, 0x41, 0x74, 0x33, 0xE2, 0xB4, 0xE0,
    0x23, 0x29, 0x42, 0xEA, 0x55, 0x0F, 0x25, 0xB4,
    0x24, 0x2C, 0x99, 0x13, 0xEB, 0x0A, 0x0B, 0xC9,
    0xF9, 0x63, 0x67, 0x43, 0x2D, 0xC7, 0x7D, 0x07,
    0x60, 0x89, 0xD1, 0xCC, 0xE7, 0x94, 0x77, 0x74,
    0x9B, 0x7E, 0xD7, 0xE6, 0xFF, 0xBB, 0x68, 0x14,
    0x1E, 0xA3, 0x25, 0xDE, 0x3A, 0xA3, 0x54, 0x7B,
    0x87, 0x9D, 0x50, 0xCA, 0x27, 0xC3, 0xA4, 0x50,
    0x91, 0x27, 0xD4, 0xB0, 0x82, 0x41, 0x97, 0x79,
    0x94, 0x82, 0xAC, 0xC7, 0x8E, 0xA5, 0x4E, 0xAA,
    0x78, 0x9E, 0xE0, 0x42, 0xBA, 0x28, 0xEA, 0xB7,
    0x74, 0xAD, 0x35, 0xDA, 0x92, 0x60, 0x7E, 0xD2,
    0x0E, 0xB9, 0x24, 0x5E, 0x39, 0x4F, 0x5E, 0x63,
    0x09, 0xB5, 0xFA, 0xBF, 0xF1, 0x22, 0x55, 0x1C,
    0xE2, 0x25, 0xDB, 0xC5, 0xD8, 0x50, 0x03, 0x98,
    0xC4, 0xAC, 0x2E, 0x11, 0xB4, 0x38, 0x4D, 0xD0,
    0xB9, 0xFC, 0x2D, 0x3C, 0x08, 0x04, 0x5A, 0xEF,
    0xCE, 0x32, 0xFB, 0x4C, 0x92, 0x1E, 0x4B, 0xFB,
    0x1A, 0xD0, 0xE2, 0x3E, 0xDA, 0x6E, 0x7C, 0x4D,
    0x56, 0xC3, 0x3F, 0x42, 0xB1, 0x3A, 0x23, 0x4D,
    0x6E, 0x84, 0x56, 0x68, 0xF4, 0x0E, 0x03, 0x64,
    0xD0, 0xA9, 0x92, 0x2F, 0x8B, 0xBC, 0x39, 0x9C,
    0xAC, 0x09, 0x5E, 0xEE, 0xE5, 0x97, 0xBF, 0xA5,
    0xCE, 0xFA, 0x28, 0x2C, 0x6D, 0x4F, 0xEF, 0x77,
    0xAA, 0x1B, 0x79, 0x8E, 0x97, 0xB4, 0xC3, 0xF4};

    static byte Table2[] = {
    0xB7, 0x75, 0x81, 0xD5, 0xDC, 0xCA, 0xDE, 0x66,
    0x23, 0xDF, 0x15, 0x26, 0x62, 0xD1, 0x83, 0x77,
    0xE3, 0x97, 0x76, 0xAF, 0xE9, 0xC3, 0x6B, 0x8E,
    0xDA, 0xB0, 0x6E, 0xBF, 0x2B, 0xF1, 0x19, 0xB4,
    0x95, 0x34, 0x48, 0xE4, 0x37, 0x94, 0x5D, 0x7B,
    0x36, 0x5F, 0x65, 0x53, 0x07, 0xE2, 0x89, 0x11,
    0x98, 0x85, 0xD9, 0x12, 0xC1, 0x9D, 0x84, 0xEC,
    0xA4, 0xD4, 0x88, 0xB8, 0xFC, 0x2C, 0x79, 0x28,
    0xD8, 0xDB, 0xB3, 0x1E, 0xA2, 0xF9, 0xD0, 0x44,
    0xD7, 0xD6, 0x60, 0xEF, 0x14, 0xF4, 0xF6, 0x31,
    0xD2, 0x41, 0x46, 0x67, 0x0A, 0xE1, 0x58, 0x27,
    0x43, 0xA3, 0xF8, 0xE0, 0xC8, 0xBA, 0x5A, 0x5C,
    0x80, 0x6C, 0xC6, 0xF2, 0xE8, 0xAD, 0x7D, 0x04,
    0x0D, 0xB9, 0x3C, 0xC2, 0x25, 0xBD, 0x49, 0x63,
    0x8C, 0x9F, 0x51, 0xCE, 0x20, 0xC5, 0xA1, 0x50,
    0x92, 0x2D, 0xDD, 0xBC, 0x8D, 0x4F, 0x9A, 0x71,
    0x2F, 0x30, 0x1D, 0x73, 0x39, 0x13, 0xFB, 0x1A,
    0xCB, 0x24, 0x59, 0xFE, 0x05, 0x96, 0x57, 0x0F,
    0x1F, 0xCF, 0x54, 0xBE, 0xF5, 0x06, 0x1B, 0xB2,
    0x6D, 0xD3, 0x4D, 0x32, 0x56, 0x21, 0x33, 0x0B,
    0x52, 0xE7, 0xAB, 0xEB, 0xA6, 0x74, 0x00, 0x4C,
    0xB1, 0x7F, 0x82, 0x99, 0x87, 0x0E, 0x5E, 0xC0,
    0x8F, 0xEE, 0x6F, 0x55, 0xF3, 0x7E, 0x08, 0x90,
    0xFA, 0xB6, 0x64, 0x70, 0x47, 0x4A, 0x17, 0xA7,
    0xB5, 0x40, 0x8A, 0x38, 0xE5, 0x68, 0x3E, 0x8B,
    0x69, 0xAA, 0x9B, 0x42, 0xA5, 0x10, 0x01, 0x35,
    0xFD, 0x61, 0x9E, 0xE6, 0x16, 0x9C, 0x86, 0xED,
    0xCD, 0x2E, 0xFF, 0xC4, 0x5B, 0xA0, 0xAE, 0xCC,
    0x4B, 0x3B, 0x03, 0xBB, 0x1C, 0x2A, 0xAC, 0x0C,
    0x3F, 0x93, 0xC7, 0x72, 0x7A, 0x09, 0x22, 0x3D,
    0x45, 0x78, 0xA9, 0xA8, 0xEA, 0xC9, 0x6A, 0xF7,
    0x29, 0x91, 0xF0, 0x02, 0x18, 0x3A, 0x4E, 0x7C};

    static byte Table3[] = {
    0x73, 0x51, 0x95, 0xE1, 0x12, 0xE4, 0xC0, 0x58,
    0xEE, 0xF2, 0x08, 0x1B, 0xA9, 0xFA, 0x98, 0x4C,
    0xA7, 0x33, 0xE2, 0x1B, 0xA7, 0x6D, 0xF5, 0x30,
    0x97, 0x1D, 0xF3, 0x02, 0x60, 0x5A, 0x82, 0x0F,
    0x91, 0xD0, 0x9C, 0x10, 0x39, 0x7A, 0x83, 0x85,
    0x3B, 0xB2, 0xB8, 0xAE, 0x0C, 0x09, 0x52, 0xEA,
    0x1C, 0xE1, 0x8D, 0x66, 0x4F, 0xF3, 0xDA, 0x92,
    0x29, 0xB9, 0xD5, 0xC5, 0x77, 0x47, 0x22, 0x53,
    0x14, 0xF7, 0xAF, 0x22, 0x64, 0xDF, 0xC6, 0x72,
    0x12, 0xF3, 0x75, 0xDA, 0xD7, 0xD7, 0xE5, 0x02,
    0x9E, 0xED, 0xDA, 0xDB, 0x4C, 0x47, 0xCE, 0x91,
    0x06, 0x06, 0x6D, 0x55, 0x8B, 0x19, 0xC9, 0xEF,
    0x8C, 0x80, 0x1A, 0x0E, 0xEE, 0x4B, 0xAB, 0xF2,
    0x08, 0x5C, 0xE9, 0x37, 0x26, 0x5E, 0x9A, 0x90,
    0x00, 0xF3, 0x0D, 0xB2, 0xA6, 0xA3, 0xF7, 0x26,
    0x17, 0x48, 0x88, 0xC9, 0x0E, 0x2C, 0xC9, 0x02,
    0xE7, 0x18, 0x05, 0x4B, 0xF3, 0x39, 0xE1, 0x20,
    0x02, 0x0D, 0x40, 0xC7, 0xCA, 0xB9, 0x48, 0x30,
    0x57, 0x67, 0xCC, 0x06, 0xBF, 0xAC, 0x81, 0x08,
    0x24, 0x7A, 0xD4, 0x8B, 0x19, 0x8E, 0xAC, 0xB4,
    0x5A, 0x0F, 0x73, 0x13, 0xAC, 0x9E, 0xDA, 0xB6,
    0xB8, 0x96, 0x5B, 0x60, 0x88, 0xE1, 0x81, 0x3F,
    0x07, 0x86, 0x37, 0x2D, 0x79, 0x14, 0x52, 0xEA,
    0x73, 0xDF, 0x3D, 0x09, 0xC8, 0x25, 0x48, 0xD8,
    0x75, 0x60, 0x9A, 0x08, 0x27, 0x4A, 0x2C, 0xB9,
    0xA8, 0x8B, 0x8A, 0x73, 0x62, 0x37, 0x16, 0x02,
    0xBD, 0xC1, 0x0E, 0x56, 0x54, 0x3E, 0x14, 0x5F,
    0x8C, 0x8F, 0x6E, 0x75, 0x1C, 0x07, 0x39, 0x7B,
    0x4B, 0xDB, 0xD3, 0x4B, 0x1E, 0xC8, 0x7E, 0xFE,
    0x3E, 0x72, 0x16, 0x83, 0x7D, 0xEE, 0xF5, 0xCA,
    0xC5, 0x18, 0xF9, 0xD8, 0x68, 0xAB, 0x38, 0x85,
    0xA8, 0xF0, 0xA1, 0x73, 0x9F, 0x5D, 0x19, 0x0B,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x33, 0x72, 0x39, 0x25, 0x67, 0x26, 0x6D, 0x71,
    0x36, 0x77, 0x3C, 0x20, 0x62, 0x23, 0x68, 0x74,
    0xC3, 0x82, 0xC9, 0x15, 0x57, 0x16, 0x5D, 0x81};
  • 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.

    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.

  • 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!

    E
  • 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!

    E
  • 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. 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 .1 cent more per unit, but didn't. I just wanted to set the record straight. -C
  • 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.
  • 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.

    - 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...
  • Well, it will increase the markedt in terms of the number of potential viewers. But if illegal copying becomes widespread, it reduces the markets value - which is what most companies are interested in. Given that nearly all other media are copyable already, and that e.g. the CD market is alive and well, I doubt that this will happen. But this is due to other factors - primarily copyright enforcement by legal and moral (as opposed to technical) means.
  • Actually, they "released" someone elses driver. They didn't write it and they gave no support to the person writing it. (This was argued on the LiVid [openprojects.net] mailing list.)
  • Depending on configuration and phase of the moon, there have been reports of 2-8% increase in performance by using the backend scaler in the G-series cards from Matrox.

    Matrox cards may suck royally for playing most games, but this is one place where they rule.
  • 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.
  • heh. It's impossible, for the near future, to physically extract significant information from the human brain (such as a PIN or password).

    Handcuffs and club will do the trick -- technology is several thousands years old %)

  • I don't know about Japanese laws, but the US export restriction is on ENCRYPTION technology, NOT decryption. (Distributed.net has been doing this for several years.)

    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 ... legally.
  • I don't think so. Stand alone units don't have to go through the same CSS song-and-dance to get the decryption keys -- it can read them directly from the disk in a "secure" fashion. (unlike passing over the IDE bus and around a computer's memory where anything can see them.)
  • 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.

    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 .1 cent more per unit, but didn't.

    I just wanted to set the record straight.

    -C

  • Except that most DVD piracy is from exact duplicates of the master disk. They didn't have to crack anything to do that.

    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.
  • 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
  • "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). "

    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. :-) I'm working on that.

    bye

  • Don't mess with my nostalgia...

    Copy II+ was out for the Apple // 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.

    Oregon Trail Forever!
  • 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

Life is cheap, but the accessories can kill you.

Working...