bug-xorriso
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-xorriso] driver and disc ID acquiring, hidden track


From: Thomas Schmitt
Subject: Re: [Bug-xorriso] driver and disc ID acquiring, hidden track
Date: Sat, 17 Oct 2015 09:21:28 +0200

Hi,

Ri-Ping YU wrote:
> I have subscribed on Oct. 15th 2015 with email address
> "address@hidden", but haven't recieved confirmation email.

I'll have to investigate why this request did not reach me.


> > The drive might support the Drive Serial Number feature (108h)
> > which tells the serial number, and the Media Serial Number
> > feature (109h) which indicates that SCSI command ABh READ MEDIA

> You said "might support", did you mean this feature depends on drive. That
> is some drive has this feature to tell those serial number while some others
> has not, so we can not retrieve

Yes. That's how MMC features work. They announce a capability
of drive and medium together. In some cases like 108h the info
of interest is directly contained in the feature descriptor.
In others the feature descriptor tells whether the feature
might be available in principle and whether it is available
currently with the given medium in the drive.

I made some experiments meanwhile. 

All my drives support 108h. I.e. they tell a serial number.
Suspiciously they resemble parts of the file names in
/dev/disk/by-id/ of my Linux system, but some are not completely
shown there and have some altered characters. E.g:

  /dev/disk/by-id/ata-HL-DT-ST_DVDRAM_GH24NSC0_K8AF33A3528
versus
  Drive id     : 'K8AF33A3528     '

  /dev/disk/by-id/usb-HL-DT-ST_BD-RE_BH16NS40_58AD11E28502-0:0
versus
  Drive id     : 'K8AD1QE2850 '

It seems that USB drives get slightly refurbished names in Linux.

The drives also support feature 109h, but i could not find
a medium with which it would be reported as "current".
So the drives announce that command ABh will not work with the
given media.
If i send it nevertheless, i get an unexpected transport error
from Linux. I.e. the command did not make it to the drive.
I'll have to investigate this.

Whatever, i did not yet succeed in getting a Media Serial Number
and the drives did not promise it to me yet.
Obviously i lack of suitable media.


> We will burn one disc live, named 0#, if someone copy another disc named 1#
> from 0#, it can be detected that 1# is a replica.
> I want to write some info. into disc 0#, and these info. cannot be
> duplicated while copying,

That's roughly how some copy protection schemes worked for
the old CD media. Other than with DVD or BD media, it is
possible to specify more than the data content of disc sectors
(called "raw" writing).
These extra data officially had to comply to certain
constraints, but it was possible to violate those rules in the
hope that copy programs would not be able to do the same.
Of course they soon were able to copy the mad stuff too.

This concept has been disabled for DVD and BD in normal
burner drives. It might be still possible if you can manipulate
the drive firmware or if you get a drive with special firmware.

  https://en.wikipedia.org/wiki/Compact_Disc_and_DVD_copy_protection
mentions a technique named "Data position measurement" which could
apply to DVD and BD, too.
But the problem is to make that measurement. The official command
set for drive firmware (SCSI volumes SPC and MMC) does not offer
the opportunity to get the physical address of a logical block.
(Well, maybe i did not read deep enough ...)

For ideas of others see:
  
https://en.wikipedia.org/wiki/List_of_Compact_Disc_and_DVD_copy_protection_schemes
  
https://en.wikipedia.org/wiki/List_of_copy_protection_schemes#Commercial_Blu-ray_Disc_protection_schemes
  http://www.miraizon.com/support/info_copyprotection.html
Many of them are ridiculously naive. None of the good looking
ones is in reach of libburn or unaltered commercial drives.

In general i would say that everything you can do with a normal
drive can be copied in a way that a normal drive cannot distinguish
it from the original medium.

It seems that DVD and BD industry finally turned to encryption.
Not that they would be very successful in protecting their
assets. The overal problem is that the medium is out there on
its own and prone to attacks by experts and modified hardware.
You sit at home and cannot help it defending itself.

AACS of Blu-ray is in theory able to exclude cracked player
hardware by revoking its decryption key. But according to
my rough analysis, this revocation will also disable lots
of harmless and legal recorders which use neighboring keys of
the revoked one.
I.e. you buy a new Blu-ray video and it does not play, whereas
older Blu-rays still do play. Then you have to get a new key
installed on your player.


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]