Re: CPRM copy protection for ATA drives

Re: CPRM copy protection for ATA drives

[Rob Landley]

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: CPRM copy protection for ATA drives

[Andre Hedrick]

On Tue, 2 Jan 2001, Rob Landley wrote:

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

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

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

> 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: CPRM copy protection for ATA drives

[Rob Landley]

Andre Hedrick wrote:
> 
> On Tue, 2 Jan 2001, Rob Landley wrote:
> 
> > 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.

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

> > 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:

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

> Cheers,

LeChiem.

> Andre Hedrick

Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: CPRM copy protection for ATA drives

[Andre Hedrick]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: CPRM copy protection for ATA drives

[Erik Mouw]

On Tue, Jan 02, 2001 at 04:15:02PM -0800, Andre Hedrick wrote:
> 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.

> I have to kill this timeout bug or people will scream bloody murder.

Heh, please do ;-)


Erik

-- 
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: J.A.K.Mouw@its.tudelft.nl
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: CPRM copy protection for ATA drives

[Andre Hedrick]

READ and reply to CPRM Account <cprm@linux-ide.org> Only...
It is not worth the kernel traffic to blow appart the issue.

On Thu, 21 Dec 2000, Alan Cox wrote:

> > Does anyone have any details on this? I presume that the drive
> > firmware is capable of identifying copy-protected data during
> > a write. I also presume that nobody on lkml would condone
> 
> It seems to be very similar to the DVD stuff, including ideas for play once
> only blocks and the like. Pay per read hard disk...

That is part of the potentially hidden issue is the usage counters.

> > such a terrible idea. I imagine that this system is pretty
> > easy to defeat if you can modify the filesystem. Perhaps even
> 
> 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.

No.  Just blame the MPA (Motion Picture Association) for this level of
paranoia.  The object is to follow the money and the fronts that are
hiding real issues.

> > The consequences of being able to corrupt other people's backups
> > by introducing "copy-protected" data are intriguing...
> 
> I'm just waiting for a few class action law suits against drive manufacturers
> when people's backup tools cannot cope

Oh, this is one of the issues that I brought up along with many others
during the December Plenary Meeting.  For the record, I was able to
intensify the issue by my objections to postpone the adoption for 60 days.
This subject will come up again in February.  Since I can only represent
my interest as a counsultant to the T13 Committee, because there is not
organization offically known as "Linux".

I do expect to take a lot of heat on CPRM, but everyone here knows that I
can take as much as I dish it!  If you wish to send a note to complain
about the issue, I will carry your points to the meeting.

CPRM Account <cprm@linux-ide.org>

Do not blow torch me or the issue.
Explain why you have issues.
Explain what is a better solution.

For the next point of record, I will be supporting Microsoft's proposal.
It is the only one that will not effect us in a way that could be harmful.
ftp://fission.dt.wdc.com/pub/standards/x3t13/technical/e00163r0.pdf

Additionally, Linux will have to deploy a command filter driver to force
block the use of CPRM taskfile calls by browsers, which is the suspected
method of performing this protected mode of access.  The option will be
submitted/included in the next rev of the kernel for v2.5.0 at the time of
its annoucement.  The default will be to block the is command set and you
will have to compile the option in to allow the technically correct
command to be accepted.

Lastly, I may end up losing my position on the Committee but hey it is for
a good cause ;-)

Regards,

Andre Hedrick
Linux ATA Development



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: CPRM copy protection for ATA drives

[Alan Cox]

> Does anyone have any details on this? I presume that the drive
> firmware is capable of identifying copy-protected data during
> a write. I also presume that nobody on lkml would condone

It seems to be very similar to the DVD stuff, including ideas for play once
only blocks and the like. Pay per read hard disk...

> such a terrible idea. I imagine that this system is pretty
> easy to defeat if you can modify the filesystem. Perhaps even

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.

> The consequences of being able to corrupt other people's backups
> by introducing "copy-protected" data are intriguing...

I'm just waiting for a few class action law suits against drive manufacturers
when people's backup tools cannot cope

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

CPRM copy protection for ATA drives

[lk]

I read this article on theregister today:
http://www.theregister.co.uk/content/2/15620.html
Does anyone have any details on this? I presume that the drive
firmware is capable of identifying copy-protected data during
a write. I also presume that nobody on lkml would condone
such a terrible idea. I imagine that this system is pretty
easy to defeat if you can modify the filesystem. Perhaps even
a ROT13 modification to ext2 would be sufficient?

The consequences of being able to corrupt other people's backups
by introducing "copy-protected" data are intriguing...

Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/