c - UDF 文件系统读取、蓝光元数据分区、带有 ISO 镜像的 libdvdread

Question

所以这可能有点太具体了，太多了，任何人都无法阅读，任何人都无法提供帮助。但也许有人以前做过这件事。

我目前正在使用可靠但不是很准确的 libdvdread 库来读取 ISO 文件/设备。但是具体的实现在这种情况下并不是那么重要。更多关于如何阅读 UDF 文件系统。我已经阅读了很多 Ecma-167 和 udf260 PDF 文件。

因此，首先，让我们看一下来自 IMGBURN 的 ISO 图像，它似乎可以工作，就像从零售蓝光复制的图像一样。

block 的布局如下:

Block  32 TagID:    1 TAGID_PRI_VOL
Block  33 TagID:    4 TAGID_IMP_VOL
Block  34 TagID:    5 TAGID_PARTITION
Block  35 TagID:    6 TAGID_LOGVOL
Block  36 TagID:    7 TAGID_UNALLOC_SPACE
Block  37 TagID:    8 TAGID_TERM
Block  64 TagID:    9 TAGID_LOGVOL_INTEGRITY
Block  65 TagID:    8 TAGID_TERM
Block 256 TagID:    2 TAGID_ANCHOR
Block 288 TagID:  266 TAGID_EXTFENTRY
Block 320 TagID:  256 TAGID_FSD
Block 321 TagID:    8 TAGID_TERM
Block 322 TagID:  266 TAGID_EXTFENTRY
Block 323 TagID:  257 TAGID_FID
Block 324 TagID:  266 TAGID_EXTFENTRY
Block 325 TagID:  266 TAGID_EXTFENTRY
Block 326 TagID:  257 TAGID_FID
Block 327 TagID:  266 TAGID_EXTFENTRY

于是我们开始读取ISO镜像；

* Read Block 256 which is    2 TAGID_ANCHOR
* Read Block  32 which is    1 TAGID_PRI_VOL
* Read Block  33 which is    4 TAGID_IMP_VOL
* Read Block  34 which is    5 TAGID_PARTITION
Partiton: number 0, start 288, length 2291200, AccessType 1
* Read Block  35 which is    6 TAGID_LOGVOL
LogVolume 2048:70:2
Volume 0 type 01 (len 6) Seq 0001 Part 0000
Volume 1 type 02:
Partition identifier: '*UDF Metadata Partition'
 Metadata Partition MainLoc 00000000, MirrorLoc 0022F5A9, BitmapLoc FFFFFFFF, AllocSize 00000020, AlignSize 0020, Flags 1.
returning Start 288
Found partition at 288 length 2291200
Starting scan from 288 (metadata adjusted)

到目前为止一切顺利。你可以看到我取了“元数据主文件位置”，在这个例子中是 0，并将它添加到分区开始，去寻找 FSD。即使对于“元数据主文件位置”不为 0 的示例，这似乎也适用。稍后会详细介绍。

现在寻找FSD，我们找到的第一项是:

* Read Block 288 which is  266 TAGID_EXTFENTRY
TagID 266 with filetype 250
   Metadata Main at location 32 (+partition.start 320)

Ecma-167 定义 filetype=250 有“元数据主文件”，AD.Location 指向元数据。还有可能找到一个filetype=251(元数据镜像文件)

我使用“元数据主文件”位置(此处为 32)作为间接指针，指向“真正”查找 FSD 的位置。出于某种原因，这是 partition.Start + Location (288 + 32) = 320。

在 block 320，我们找到了 FSD。所以也许我走在正确的轨道上。

Now Scanning from 320
* Read Block 320 which is  256 TAGID_FSD
RootICB at 2 length 2048
MapICB starting at 320,2 -> 322

太好了，我们读取了 FSD，它的 RootICB 位于“+2”。现在我希望这是“partition.Start + 2”(288 + 2)，但这不起作用。起作用的是“FSD_Location + 2”(320+2)。真的可以这样吗？

在 DVD ISO 中，FSD_Location=0(分区上的第一个 block ，因为途中没有 EXTFileInfo+250)，因此使用此逻辑仍然有效。

假设它是正确的；

* Read Block 322 which is  266 TAGID_EXTFENTRY
libdvdread: reading AD chain 0
UDFMapICB TagID 266 ExtFile with filetype 4
Part.Start 288 FSD loc 320 RootICB 2 (len 2048) File has loc 3

因此，位于 322 的 block 确实是一个 ExtFileInfo，文件类型 ==4(目录)并且位于位置 = +3。同样，这似乎是“fsd_location + 3”= 323。

Found '/' at 323 (size 152).
* Read Block 323 which is  257 TAGID_FID
DVDReadDir(.)
DVDReadDir(BDMV)
etc

成功。它列出了所有内容。

这是我感到困惑的地方。我使用 OSX“newfs_udf”为自己创建一个 UDF 测试图像；

# mkfile 1G roger.iso
# newfs_udf -eu -r 2.60 -v HIGHLANDER roger.iso
# hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount roger.iso
# hdiutil mount -nobrowse roger.iso
# mkdir /Volumes/HIGHLANDER/A.DIRECTORY.ENTRY

block 是:

Block  20 TagID:    1 TAGID_PRI_VOL
Block  21 TagID:    4 TAGID_IMP_VOL
Block  22 TagID:    5 TAGID_PARTITION
Block  23 TagID:    6 TAGID_LOGVOL
Block  24 TagID:    7 TAGID_UNALLOC_SPACE
Block  25 TagID:    8 TAGID_TERM
Block  36 TagID:    9 TAGID_LOGVOL_INTEGRITY
Block  37 TagID:    8 TAGID_TERM
Block 256 TagID:    2 TAGID_ANCHOR
Block 257 TagID:  264 TAGID_SPACE_BITMAP
Block 289 TagID:  266 TAGID_EXTFENTRY
Block 290 TagID:  266 TAGID_EXTFENTRY
Block 291 TagID:  256 TAGID_FSD
Block 292 TagID:  266 TAGID_EXTFENTRY
Block 293 TagID:  266 TAGID_EXTFENTRY
Block 294 TagID:  266 TAGID_EXTFENTRY
Block 295 TagID:  266 TAGID_EXTFENTRY
Block 296 TagID:  266 TAGID_EXTFENTRY
Block 323 TagID:  264 TAGID_SPACE_BITMAP
Block 449 TagID:  259 TAGID_INDIRECTENTRY

阅读这个 ISO 也很有效，至少在开始时是这样；

* Read Block 256 which is    2 TAGID_ANCHOR
* Read Block  20 which is    1 TAGID_PRI_VOL
* Read Block  21 which is    4 TAGID_IMP_VOL
* Read Block  22 which is    5 TAGID_PARTITION
Partiton: number 0, start 257, length 523774, AccessType 4
* Read Block  23 which is    6 TAGID_LOGVOL
LogVolume 2048:70:2
Volume 0 type 01 (len 6) Seq 0001 Part 0000
Volume 1 type 02:
Partition identifier: '*UDF Metadata Partition'
 Metadata Partition MainLoc 00000020, MirrorLoc 0007FDFD, BitmapLoc 00000021, AllocSize 00000020, AlignSize 0001, Flags 0.
returning Start 257
Found partition at 257 length 523774
Starting scan from 289 (metadata adjusted)

* Read Block 289 which is  266 TAGID_EXTFENTRY
TagID 266 with filetype 250
   Metadata Main at location 34 (+partition.start 291)

* Read Block 291 which is  256 TAGID_FSD
RootICB at 1 length 2048

* Read Block 292 which is  266 TAGID_EXTFENTRY
UDFMapICB TagID 266 ExtFile with filetype 4
Part.Start 257 FSD loc 291 RootICB 1 (len 2048) File has loc 34

注意这里的元数据分区是 +32，通过添加我们正确地找到了 ExtFileInfo+Filetype=250。这就是 +34，它正确地为我们提供了 FSD!

FSD 的 RootICB 位于 +34，同样来自 FSD，即 291+34 = 325。

它丢失了。我猜它应该是 292，但是；

...在阻止列表中，您可以看到根本没有 FID。查看此 ISO 镜像的 hexdump，可以在 block 292 中找到“A.DIRECTORY.ENTRY”。这是一个 ExtFileEntry。就是让我们去寻找元数据主文件位置的那个。

我以为 ExtFileInfo 只包含一 (1) 个文件描述符，ICB 指向它的数据。然而，在这个 block 内偏移量为 +380 左右的位置，我们有根(空)、“A.DIRECTORY.ENTRY”和“.Trashes”。

我想我的问题是，OSX 是否以某种方式将 FID 压缩到 ExtFileEntry 中？并且没有 FID block 。这是“有效的”吗？我如何检测这种情况？此 ExtFileInfo 中是否有某些内容指示我“不应按照位置查找 FID”和“继续解析此 block 以获取更多条目”。

在计算 ICB 时，我必须对目录使用“fsd_location + icb.location”，但对于文件(读取实际文件数据)我必须使用“partition.Start + icb.location”。这按预期工作(目录列表和文件没有差异)但它似乎不正确。

如果您阅读了所有这些内容，那您真是太棒了 :) 现在，如果您能给我一些线索...

Answer 1

好吧，我觉得我掌握了这一切，包括 ECMA 167 和 BSD UDF 源代码。缺少的魔法是 ICBTAG.Flags=3 类型，它不是在 block 的末尾有一个“AD”列表，而是将实际的“文件内容”放在 AD 空间中。如果文件数据小于 2048 字节，则采用某种“节省空间”的方式。

如果存在元数据，它还清除了使用 FSD 作为偏移量。所有目录内容都将包含在元数据文件(主文件和镜像文件)中。