Yes. But consumer DVD readers (including DVD-ROM drives) will not deliver data without first receiving the requisite decryption key via the established protocol. If you have a DVD-ROM drive, you can verify this by trying to copy one of the large (1GB).VOB files to your hard disk; you'll get an error message as soon as you hit encrypted data within the file, since you haven't obtained "authorized" access to the data.
So the protection ("lock") is indeed done in hardware; the key to this lock, however, exists in software, which of course is the weak link in the chain.
When the DVD standard was being developed, I don't know if they failed to foresee that DVD decoders would eventually be implemented in software, or if they did foresee it, and simply accepted the eventual "cracking" of the protection as an inevitable reality. If I were they, I would have fought against allowing software DVD decoders to be produced at all -- at least it would have further delayed the inevitable.
The Wired article states that the DVD copy protection was easily cracked because Xing had inadvertently neglected to encrypt its decryption key.
I may be completely mistaken about this (in which case, please don't hesitate to set me straight), but I just don't see why it's so important to encrypt the decryption key in the first place.
I mean, at some point during the DVD player software's execution, the decryption key is going to have to be decrypted anyway (so that it can be applied to the ciphertext). A hacker need only load the player into a debugger and trace it up to this critical point, and then simply capture the naked decryption key from memory as soon as it surfaces.
Thus, encrypting the decryption key serves as only a minor annoyance, making it only incrementally more difficult for a competent hacker to retrieve the key. Such "protection by obfuscation" is widely known to be one of the worst ways to "encrypt" or otherwise protect one's data.
In this light, how much more difficult would it have been to "hack" any of the other software DVD players out there, by simply debugging them and waiting for the player to decrypt (and expose) its own decryption key for all to see? I'd wager: not much more difficult at all.
He was talking about back in the early 80's when you had a choice of MGA (IBM Monochrome Graphics Adapter) or a Herc Mono card. If I remember correctly the Herc went up to 720x480.
The Hercules monochrome graphics adapter had only one graphics mode: 720x348, monochrome. Its memory buffer in both text and graphics mode was mapped to the same location as that of the IBM MDA (Monochrome Display Adapter -- it didn't do graphics): B000:0.
The "killer app" described on the Touch Mouse Web page is the ability to "simplify & reduce screen clutter". This is accomplished by removing mouse-oriented UI elements, such as toolbars, whenever the user isn't touching the mouse. Well and good -- except for two things:
1. Almost the same thing is easily accomplished with a non-Touch-Mouse by simply monitoring the time since the last mouse movement. If the user hasn't moved the mouse in, say, five seconds, remove the "extraneous" toolbars. As soon as the user moves the mouse again, fade the toolbars back in. I believe that this is sufficiently similar to the behavior of the Touch Mouse to render the Touch Mouse not really worth the trouble (at least for this purpose).
2. The toolbars aren't necessarily extraneous at all. Many toolbar buttons provide useful visual feedback. For example, in Microsoft Word, one can easily tell whether the current insertion point is in "bold" mode by glancing at the "B" button on the style toolbar, and checking if it's depressed or not.
Comclusion: The Touch Mouse, as presented on the Microsoft Web page, is an interesting idea, but not exactly compelling at this stage.
The Bible, if translated correctly, says "thou shalt not commit murder," not "thou shalt not kill." Not quite the same thing.
"Correctly"? Let's see.
First of all, how about translating to today's English (does anyone speak King James' English anymore?):
You shall not commit murder.
That's better. But those among us who still know the difference between "shall" and "will" might object to the use of "shall" in a commandment. Use the correct implied imperative "will" instead:
You will not commit murder.
That's better still. But why stop there? Use the direct imperative:
Do not commit murder.
Ah. Much better. Direct, forceful, and to the point.
That's not playing fair. If the question is assumed to be in decimal, then the answer would have to be in decimal too -- unless explicitly specified.
With that in mind, here's a sneakier solution: Use C-style octal notation. Seventeen would be 021, which is ambiguous enough to be read either as octal 21, or (to non-C-programmers) as decimal 21 with a superfluous leading zero.
What you describe sounds just like iMuse, which was developed around a decade ago by LucasArts for its own line of adventure games. I first heard it used in Monkey Island 2, and it really blew me away. The background musical score truly changed dynamically, seamlessly, and continuously to suit the action.
iMuse has since been used in (AFAIK) every LucasArts adventure game, including Day of the Tentacle, Indiana Jones and the Fate of Atlantis, and Sam and Max Hit the Road.
Newer LucasArts adventures, such as Full Throttle, Monkey Island 3, and Grim Fandango, use a digital-sample-based version of iMuse (as opposed to the original MIDI-based iMuse). Using digital samples increases the audio quality and fidelity of the music, while decreasing flexibility somewhat, since the musical repertiore is limited to a library of prerecorded phrases and segments. Still, it's a terrific, innovative system that's been put to great use over the years.
Does anyone know if there any downloadable samples (say, in MP3 format) of Sibelius' work? I for one would love to hear for myself if Sibelius is really as good as its developers claim.
Slashdot Mirror
Yes. But consumer DVD readers (including DVD-ROM drives) will not deliver data without first receiving the requisite decryption key via the established protocol. If you have a DVD-ROM drive, you can verify this by trying to copy one of the large (1GB) .VOB files to your hard disk; you'll get an error message as soon as you hit encrypted data within the file, since you haven't obtained "authorized" access to the data.
So the protection ("lock") is indeed done in hardware; the key to this lock, however, exists in software, which of course is the weak link in the chain.
When the DVD standard was being developed, I don't know if they failed to foresee that DVD decoders would eventually be implemented in software, or if they did foresee it, and simply accepted the eventual "cracking" of the protection as an inevitable reality. If I were they, I would have fought against allowing software DVD decoders to be produced at all -- at least it would have further delayed the inevitable.
The Wired article states that the DVD copy protection was easily cracked because Xing had inadvertently neglected to encrypt its decryption key.
I may be completely mistaken about this (in which case, please don't hesitate to set me straight), but I just don't see why it's so important to encrypt the decryption key in the first place.
I mean, at some point during the DVD player software's execution, the decryption key is going to have to be decrypted anyway (so that it can be applied to the ciphertext). A hacker need only load the player into a debugger and trace it up to this critical point, and then simply capture the naked decryption key from memory as soon as it surfaces.
Thus, encrypting the decryption key serves as only a minor annoyance, making it only incrementally more difficult for a competent hacker to retrieve the key. Such "protection by obfuscation" is widely known to be one of the worst ways to "encrypt" or otherwise protect one's data.
In this light, how much more difficult would it have been to "hack" any of the other software DVD players out there, by simply debugging them and waiting for the player to decrypt (and expose) its own decryption key for all to see? I'd wager: not much more difficult at all.
He was talking about back in the early 80's when you had a choice of MGA (IBM Monochrome Graphics Adapter) or a Herc Mono card. If I remember correctly the Herc went up to 720x480.
The Hercules monochrome graphics adapter had only one graphics mode: 720x348, monochrome. Its memory buffer in both text and graphics mode was mapped to the same location as that of the IBM MDA (Monochrome Display Adapter -- it didn't do graphics): B000:0.
The "killer app" described on the Touch Mouse Web page is the ability to "simplify & reduce screen clutter". This is accomplished by removing mouse-oriented UI elements, such as toolbars, whenever the user isn't touching the mouse. Well and good -- except for two things:
1. Almost the same thing is easily accomplished with a non-Touch-Mouse by simply monitoring the time since the last mouse movement. If the user hasn't moved the mouse in, say, five seconds, remove the "extraneous" toolbars. As soon as the user moves the mouse again, fade the toolbars back in. I believe that this is sufficiently similar to the behavior of the Touch Mouse to render the Touch Mouse not really worth the trouble (at least for this purpose).
2. The toolbars aren't necessarily extraneous at all. Many toolbar buttons provide useful visual feedback. For example, in Microsoft Word, one can easily tell whether the current insertion point is in "bold" mode by glancing at the "B" button on the style toolbar, and checking if it's depressed or not.
Comclusion: The Touch Mouse, as presented on the Microsoft Web page, is an interesting idea, but not exactly compelling at this stage.
The Bible, if translated correctly, says "thou shalt not commit murder," not "thou shalt not kill." Not quite the same thing.
"Correctly"? Let's see.
First of all, how about translating to today's English (does anyone speak King James' English anymore?):
That's better. But those among us who still know the difference between "shall" and "will" might object to the use of "shall" in a commandment. Use the correct implied imperative "will" instead:
That's better still. But why stop there? Use the direct imperative:
Ah. Much better. Direct, forceful, and to the point.
Death?
That's not playing fair. If the question is assumed to be in decimal, then the answer would have to be in decimal too -- unless explicitly specified.
With that in mind, here's a sneakier solution: Use C-style octal notation. Seventeen would be 021, which is ambiguous enough to be read either as octal 21, or (to non-C-programmers) as decimal 21 with a superfluous leading zero.
What you describe sounds just like iMuse, which was developed around a decade ago by LucasArts for its own line of adventure games. I first heard it used in Monkey Island 2, and it really blew me away. The background musical score truly changed dynamically, seamlessly, and continuously to suit the action.
iMuse has since been used in (AFAIK) every LucasArts adventure game, including Day of the Tentacle, Indiana Jones and the Fate of Atlantis, and Sam and Max Hit the Road.
Newer LucasArts adventures, such as Full Throttle, Monkey Island 3, and Grim Fandango, use a digital-sample-based version of iMuse (as opposed to the original MIDI-based iMuse). Using digital samples increases the audio quality and fidelity of the music, while decreasing flexibility somewhat, since the musical repertiore is limited to a library of prerecorded phrases and segments. Still, it's a terrific, innovative system that's been put to great use over the years.
Does anyone know if there any downloadable samples (say, in MP3 format) of Sibelius' work? I for one would love to hear for myself if Sibelius is really as good as its developers claim.
Isn't this really old news?
For security reasons. It prevents the casual eavesdropper (say, on an extension phone) from continuing your transaction after you've hung up.