working with ISO disk images in FTK or BitCurator

[kta...@berkeley.edu]

Hello Group,

I'm hoping to gather a little of your collective wisdom here on working with ISO disk images created from optical media.

It's been the practice here to create ISO images of CDs and DVDs, for preservation and for secure file transfer. Currently I'm looking at about 115 image files which I'd like to be able to mount, process, and extract files from for access.

With some graduate intern help this summer, we started examining 7 ISO images from 7 CD-Rs in Forensic Toolkit (FTK) 5.0. We found that the content of each disk appeared four times in the FTK Evidence Tree, under four different file systems: HFS, HFS+, ISO-9660, and Joliet. Each set of files understandably had varying characteristics - for example, the files displayed under Joliet had longer and more complete file names, and the files under HFS and HFS+ were accompanied by .rsrc resource forks (the CD-Rs were originally created on a Mac).

We also tried mounting the images in BitCurator, where they only appeared under an ISO-9660 file system (the images were not created in BC).

When attempting to export HFS+ files from FTK (on a PC), we realized that the .rsrc files remained separate from their corresponding Photoshop PSD files and that we had no way to access the metadata they contained. 

When we exported JPG files under the ISO-9660 or Joliet systems, the export included 3 elements for every file: the original file (myphoto.jpg), a new folder labeled with the original file title in brackets ([myphoto.jpg]), and within that folder, an EXIF file with the original filename and a .exif.html extension (myphoto.exif.html).

All of which has left me with some questions! I'd like to figure out what's going on and how our data is affected. Can anyone weigh in?

1. Is disk imaging your preferred capture/preservation method for optical media?
   
2. Are you using FTK to mount and review ISO disk images?
   
3. If you are using FTK, could you share the analysis functions ("processing profile" options) you run? (I'm wondering if we are using a setting which causes this result, although I've checked that out pretty closely.)
   
4. If you are using FTK, and are presented with multiple file systems, do you prefer one over the others?
   
5. If you export files from an ISO disk image using FTK, are you concerned with reuniting files and "hidden" metadata files?
   
6. And finally, would I avoid all these complications if I just used BitCurator? :)
   

Thanks greatly for any advice! (And please feel free to simply refer me to recommended readings which I've very likely missed).

Best,

-Kate

--

Kate Tasker

Digital Archivist

The Bancroft Library, UC Berkeley

[Kam Woods]

Hi Kate,

I'm sure others will answer with equivalent or (probably better) comments, but to start:

When you open an image like this in FTK (or FTK imager), you're effectively seeing the base file system (ISO 9660) that has been written out with a range of extensions to accommodate various metadata requirements of the originating system.

The FTK evidence tree shows these extensions - in your case the Joliet extensions (to accommodate Unicode characters beyond plain ASCII), and the Apple HFS/HFS+ extensions (beyond the scope of this email, but see here for the details - https://web.archive.org/web/20081226015418/http://developer.apple.com/technotes/fl/fl_36.html) - as "separate" file systems.

Ultimately, though, they're just *metadata extensions* to that basic ISO 9660 file system; that is, there's only one copy of the underlying files on the disk. (I imagine you probably already know this, but there may be others who find this simplified description of what's going on helpful).

Regarding mounting the image in BitCurator: BitCurator is just Ubuntu (14.04.3LTS, currently), really, so it will happily mount any ISO just as Ubuntu does, as a basic ISO 9660 image. It won't mount the image with the HFS+ extensions, currently, as the hfsplus module is not loaded into the kernel. However, the necessary package to support reading and writing HFS+ file systems (hfsprogs) *is* installed, and you can override the default behavior in BitCurator by making sure the HFS+ module is loaded into the kernel by typing the following command in a terminal:

sudo modprobe hfsplus

You can then create a relevant mount point:

sudo mkdir /media/your-mount-point-name
and mount the image with hfsplus extensions:

sudo mount -t hfsplus -o loop /path/to/image.iso /media/your-mount-point-name

This is, admittedly, a PITA, probably doesn't fit well into your workflow, and requires familiarity with a range of additional command-line tools (not discussed here) to properly export associated metadata from the relevant resource forks (if that's part of your plan), so until there's a better documented method for exposing and manipulating this metadata when working with these kinds of images in the BitCurator environment, you're probably better off just sticking with FTK if you're interested in identifying their presence as a baseline.

Regarding the exported resource fork materials (.rsrc files). Others may have better suggestions, but there are several open source options for viewing the contents of resource forks in modern OS X environments, including the project at https://github.com/IGRSoft/RSRCManager. I'm not familiar with any Windows tools that can process these files in a useful way, but I bet someone else on this list is.

I'll leave questions 1-5 to others, except to say that in most cases creating disk images of CD-ROM media is often a great way to support a wide range of potential future access scenarios (since you're not interfering with original order or throwing anything away). There are some provisos, and certain types of content that need additional attention (see this paper - www.ijdc.net/index.php/ijdc/article/download/216/285 - for some discussion of weird CD-ROM types that require additional attention and different imaging methods). There are obviously a lot of cases where the reasonable curatorial decision may be to not create a disk image; I'm not arguing on hard lines here.

As the person who built and maintains BitCurator, I can answer 6 easily: Don't rely on on the default behaviors in BitCurator when working with legacy media created by Macs. The forensics and reporting tools can only talk to those file systems (HFS+ and HFS-wrapped HFS+) that The Sleuth Kit understands, and will not process legacy HFS file systems at all (well, except for the HFSExplorer tool). Also, as described above, default mounting behaviors may not always reference or expose the metadata you may be interested in.

Regards,

Kam

--
You received this message because you are subscribed to the Google Groups "Digital Curation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digital-curati...@googlegroups.com.
To post to this group, send email to digital-...@googlegroups.com.
Visit this group at http://groups.google.com/group/digital-curation.
For more options, visit https://groups.google.com/d/optout.

[kta...@berkeley.edu]

Hi Kam,

Thank you very much for your detailed comments! This gives me a much clearer picture. We are planning to continue disk imaging CDs and CD-ROMs and I'm grateful to have a better understanding of how to work with Mac legacy media. I'm looking forward to testing out these suggestions and tools.

Best,

Kate