Re: [Bug-xorriso] libisofs: unsupported ECMA-119 feature (interleaved mode)

[Thomas Schmitt]

Hi,

i wrote:
> > So even if you are willing to send me the whole image of 6 GB, [...]

Jonathan Dowland wrote:
> I will have to look carefully at what is likely on the disc but if I can
> share it with you, I will. It's possible it has confidential stuff on it
> which would prevent me from doing so unfortunately.

If the DVD still can be mounted and the files
  /HMT/RD 2009/My Settings/Application Data/Microsoft/Speech
  /HMT/RD 2009/My Settings/Application Data/Microsoft/CLR Security 
Config/v1.1.4322
are listed by ls -ldi, then we can guess the position of their directory
records with an accuracy of 32 bytes. The Linux kernel derives the inode
number from the record's byte address divided by 32.
E.g

  # mount debian-10.0.0-amd64-netinst.iso /mnt/iso
  $ ls -ldi /mnt/iso/.disk/mkisofs
  31253 -r--r--r-- 1 root root 1049 Jul  6 12:25 /mnt/iso/.disk/mkisofs
  $ dd if=debian-10.0.0-amd64-netinst.iso bs=32 skip=31253 count=9 
>/tmp/dir_rec.img

The file /tmp/dir_rec.img will be 288 bytes large. It might expose data from
the next directory records.
If
  floor(inode_number / 64) != floor((inode-number + 9 - 1) / 64)
then also some file content data could be in the file. In this case you may
reduce the number 9 enough to avoid this inequality.

Best is to inspect the file by a hex dumper for any private looking text.
You will probably see the dull ISO 9660 names "SPEECH" or "V1.1.4322" within
the first 64 bytes of dir_rec.img. 33 bytes before the first letter of the
name is a byte which tells the real size of the directory record. (So you
could trim the file beginning at that byte up to the given number of bytes.)

If i see the record, i could next ask you for data content samples from
those files, then knowing the block address and the interleave parameters.


> I just double-checked and they are DVD+R DLs.

Ah. This eliminates the possibility of layer jump recording. So the bad spot
is in the middle of the second layer.


> I would like to support xorriso's .map file format too, if it differs.

Reading
  
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Mapfile-structure
it seems that the formats differ deeply.
Mine is described in
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/xorriso/README_gnu_xorriso
----------------------------------------------------------------------------
Sector maps describe the valid and invalid blocks on a media or a disk copy of
a media. xorriso creates and reads these file with its option -check_media.

The file begins with 32 bytes of cleartext of which the last one is a
newline character. The first 25 say "xorriso sector bitmap v2 ", the
remaining six characters give the size of the info text as decimal number.
This number of bytes follows the first 32 and will not be interpreted
by xorriso. They are rather to inform a human reader about the media type
and its track layout.
After the info text there are two 4 byte signed integers, most significant
byte first. The first one, N, gives the number of bits in the following bitmap
and the second number S gives the number of 2 KiB blocks governed by a single
bit in the map. Then come the bits in form of 8-bit bytes.
Data block M is covered by bit B=M/S in the map, bit number B is stored in
byte B/8 as bit B%8. A valid readable data block has its bit set to 1.
----------------------------------------------------------------------------

The main technical differences between both programs is that ddrescue
most probably reads via buffered POSIX i/o, in contrast to xorriso
which reads by directly sending SCSI READ commands to the drive.
You can get POSIX i/o with xorriso by drive address "stdio:/dev/sr0".

But wow, ddrescue_manual.html#Optical-media is the first occurence of
the correct diagnosis of the Linux TAO Read-Ahead bug i ever read in the web.
(2 non-data blocks at the end spoil the whole last read chunk.)
Somebody should tell linux-scsi. {:o)


Have a nice day :)

Thomas