CPRM copy protection for ATA drives
Quoted 3 lines
Its probably very hard to defeat. It also in its current form means you can throw disk defragmenting tools out. Dead, gone. Welcome to the United Police State Of America.
Doesn't anybody remember the days of "dongle keys" on the Commodore 64? Plug a special circuit into the joystick port in order to use this program?
And we all remember how the pirates got around this, don't we? The easy
way: crack the program.
This is yet another hardware based copy protection tool like floppy disks with strategically placed holes burned into them by lasers (leaving a bad sector you can't reformat away), or cartridge-based programs that tried to overwrite their own memory address ranges. Or forcing people to the third word from paragraph two on page ten of the instruction manual (since the manual is, more or less, hardware.) Welcome back to the 1980's, they never learn...
There's nothing new under the sun, and the "zero day warez" people never even broke stride dealing with this sort of thing. All it WILL do is annoy people who try to legitimately use the system. And, of coruse, make a lot more people buy SCSI if they sabotage the ATA spec this way...
What are they going to do installing one of these programs on a non-compliant drive? (A modern 74 gig drive is likely to last me a while, you know.) Refuse and limit their potential installed base to only systems manufactured after 2002? Yeah, people do that kind of thing all the time (requires MMX), and the products don't last that long on the shelves, do they?
Has anybody brought up the LEVELS of nested stupidity in this particular proposal to the committe? (Committee iq: average intelligence of members, divide by headcount. Nice to see that holds true.)
I'm not particularly alarmed by it, though. Disappointed, yes. But a market that refused to buy micro-channel architecture, refused to buy rambus memory, and outright laughed at Microsoft BOB, isn't likely to let this get shoved down its throat even if it DOES pass as an official spec. And another advantage Open Source has over proprietary software (we provide what the users actually WANT, if only 'cause we're the users. A GPLed program isn't likely to depend on this "feature", is it? Or the Intel CPU ID...).
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Rob Landley
And we all remember how the pirates got around this, don't we? The easy
way: crack the program.
Nope...it is embedded to the vender portion of the media.
Quoted 5 lines
There's nothing new under the sun, and the "zero day warez" people never even broke stride dealing with this sort of thing. All it WILL do is annoy people who try to legitimately use the system. And, of coruse, make a lot more people buy SCSI if they sabotage the ATA spec this way...
You were not listening, SCSI/MMC grabbed their ankles already!
Quoted 3 lines
Has anybody brought up the LEVELS of nested stupidity in this particular proposal to the committe? (Committee iq: average intelligence of members, divide by headcount. Nice to see that holds true.)
Yes, it is not part of the STANDARD because I successfully stopped it for now until February. Oh and I sit and vote on that committee.
Quoted 2 lines
users. A GPLed program isn't likely to depend on this "feature", is it? Or the Intel CPU ID...).
It requires a licensed HOST/Application like a JAVA-thingy, or a real-local one.
If you want to kill it somebody create a GNU-CPRM and open-source it. License it for FREE.
Cheers,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · Andre Hedrick
Quoted 2 lines · Rob Landley
And we all remember how the pirates got around this, don't we? The easy
way: crack the program.Nope...it is embedded to the vender portion of the media.
My point was that using this kind of thing to protect applications is just as pointless as any other kind of copy protection in a debuggable and editable binary. (And if it's not debuggable and editable, it's kind of hard to make it runnable. Even if you encrypt it, it has to decrypt itself in memory to run.)
If it's protecting content (DVD css again), the actual PIRATES will do what they did before decss: put their non-interfering interception layer between the program and the media so that the program unlocks the media for them and they snoop and record the data going by as part of normal operation. And if the data goes into the binary in encrypted form, the binary must be able to encrypt it. Then they convert it to whatever other form they like (mp3, mpeg 4, etc) before throwing it on irq and bragging about it to their other 14 year old friends. Before decss, the pirates hacked some software dvd player to do this, or wrote their own video/audio driver that intercepted the data that thought it was going to the display.
A combination of the two (interactive game like Dragon's Lair, for example) could be cracked with a combination of the approaches. Might take a month or two, but there honestly are people with nothing better to do with their time. (A decande or so back I actually knew some of them.)
So it's not even going to dent ACTUAL piracy.
Quoted 1 line
You were not listening, SCSI/MMC grabbed their ankles already!
Missed that part. (Mostly read the zdnet stuff, serves me right.) Read read read... Fun.
So are applications expected to bare metal talk to the hardware straight from user space like the days of DOS, or are people going to hack device drivers to emulate and undermine this magic extra storage space? (Read the read-only data, and then supply the same data for another drive? You don't HAVE to crack if your intention is simply to copy verbatim, or fake a verbatim copy anyway...) Sheesh, you could do that sort of thing with a hacked version of plex86 or something even if they DO read the bare metal. And yes, somebody WILL do that eventually if this actually ships.
Quoted 6 lines
Quoted 3 lines
Has anybody brought up the LEVELS of nested stupidity in this particular proposal to the committe? (Committee iq: average intelligence of members, divide by headcount. Nice to see that holds true.)
Yes, it is not part of the STANDARD because I successfully stopped it for now until February. Oh and I sit and vote on that committee.
I've since read your message on that, yes. (As I said, the individuals are smarter than the committee. :)
Quoted 8 lines
Quoted 2 lines
users. A GPLed program isn't likely to depend on this "feature", is it? Or the Intel CPU ID...).
It requires a licensed HOST/Application like a JAVA-thingy, or a real-local one.
If you want to kill it somebody create a GNU-CPRM and open-source it. License it for FREE.
Or, for the pirates, hack somebody else's CPRM into a pesudo-generic tool to read the data, and/or intercept an application's "here's my key, now give me the data" requests.
The register thing IS a bit vague on what this proposal actually DOES. (Okay, read-only key space initialized by manufacturer. Got it. Compliant application required to read (unlock/decrypt?) the data. Okaaay... Is the application providing a decryption key (er, not writing it into the read-only space... Ummm... "Not usually accessed by the end user", oh yeah like that's going to true for longer than 15 minutes once it ships...)
How does it actually WORK? (Is there some kind of one-time write into one of these slots? What happens when you run out of slots? It says it makes use of the physical location of the info on the drive, but doesn't say HOW... (These slot thingies? Sector address of the file being read?))
I've read the register's "how it works" section, and I'm not sure I'm much more informed than I started...
Here's from The Register article that started this thread:
Quoted 3 lines
But for home users, the party's over. CRPM paves the way for CPRM-compliant audio CDs, and the free exchange of digital recordings will be limited to non-CPRM media.
Play the thing using an "approved" player into an audio driver of my own devising which records the data, then make a normal MP3 out of it. How does the system intend to stop this? (Even if the "approved" player has to be some kind of boom box, stick the headphone jack into the sound card's "in" jack, reducing the "how many mathematicians" light bulb joke to an earlier joke.)
I'm still unclear on exactly what they're trying to DO. Either the "protected" data cannot be used from software at ALL, or the software designed to use the data legitimately can be compromised by a determined 14 year old in croatia with a hex editor/debugger, thus extracting the data and allowing its conversion to a more conveniently portable format. (I.E. decss isn't necessary to PIRATE -anything-. Just to conveniently use the original format in a different context WITHOUT converting it first using, ahem, "impolite" tools.)
Where's the middle ground here? What did I miss? I'm confused.
Quoted 1 line
Cheers,
LeChiem.
Quoted 1 line
Andre Hedrick
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
I will explain later...
However each key is to broadcasts its identity for the authorized host/application. This every license that uses CPRM is trackable. Since the method is exotic enough and you can only get the matrix pillars from the LC4 people, crack will be tough. There is a 1Meg hidden CPRM space for key tracking and other services that are unknown.
How it works is still a fuzzy thought, even for the LC4 people.
I have to kill this timeout bug or people will scream bloody murder.
Cheers,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · Andre Hedrick
However each key is to broadcasts its identity for the authorized host/application. This every license that uses CPRM is trackable. Since the method is exotic enough and you can only get the matrix pillars from the LC4 people, crack will be tough. There is a 1Meg hidden CPRM space for key tracking and other services that are unknown.
How it works is still a fuzzy thought, even for the LC4 people.
[Don't read this as a personal attack. I know you're on the T13 committee and that you are against CPRM.]
Hmm... "every license is trackable"... "method is exotic"... "crack will be tough"... I have a slight deja vu feeling: CSS.
I hope the T13 committee learned from the past. No amount of hardware is going to help you to protect your data: once a backdoor is found, the protection is useless. See region free DVD players, macrovision decoders that allow you to make copies of VHS tapes, copy bit removers for SPDIF audio streams. All these examples have one thing in common:
they were invented by the recording industry.
Why would the T13 committee try to be smart and think they can invent a method that is guaranteed to be broken in a couple of months of time? Once the method is broken nobody will use it anymore and the hardware is just bloated with crap that the recording industy wants to be there, at the same time unneccesary increasing the price for the hardware. I really don't think it's worth the effort.
The recording industry has to realise that they already lost the game:
once you release your stuff on an open platform (the PC), there is no way you're going to protect it.
Quoted 1 line
I have to kill this timeout bug or people will scream bloody murder.
Heh, please do ;-)
Erik
Signature · 9 lines
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/