It's been 5 years, but I just did the research to write a tool for backing up my old floppies which needs to translate back and forth between offsets in disk images and filenames, so here's an answer for you.
I'm working on a disk imaged with dd
First, for the benefit of anyone wandering in off Google, I recommend always using GNU ddrescue. I remember running across talk that dd
is unreliable when it comes to detecting and reporting certain kinds of errors.
As for answering the question, I found two options:
filefrag -e /path/to/file
appears to work on any disk or -o loop
-mounted disk image and it's part of e2fsprogs
, so it should be installed by default on the vast majority of Linux machines, but it must be run as root and is incompatible with the FUSE filesystems I tested, like fuseiso.
(This answer suggested it, but I had to add -e
to get it to work reliably for the images I was testing against.)
The Sleuth Kit will do what you want and is perfectly happy working with a wide variety of image formats. (And, because it's a forensic toolkit, the tools won't introduce new ways to accidentally modify the disk image you dumped and you can also use them to undelete files if you read the manpages.)
Here's an example of how to use The Sleuth Kit:
#!/bin/bash
# For demonstration purposes, I'll start from a bad sector report culled
# from a ddrescue log file, so I can also demonstrate looking up a file
# from a byte offset within the image.
BAD_OFFSET=1234567890
IMG_PATH=/path/to/image/file
# Translate to the units TSK tools expect
BLOCK_SIZE="$(blkcat -s "$IMG_PATH" | cut -d: -f1)"
BLOCK_OFFSET="$(($BAD_OFFSET / $BLOCK_OFFSET))"
# Get the inode (or equivalent ID) for the file at that offset
FILE_INODE="$(ifind -d "$BAD_OFFSET" "$IMG_PATH")"
# Get the filename for the file at that offset (for the display/logging)
FILE_NAME="$(ffind -u "$IMG_PATH" "$FILE_INODE")"
# Get `stat` info for the file and a list of sectors it occupies
FILE_META="$(istat "$IMG_PATH" "$FILE_INODE")"
# Get the file's contents, just for the sake of completeness
FILE_DATA="$(icat "$IMG_PATH" "$FILE_INODE")"
Furthermore, it can be used as a library... however, because it's licensed under the Common Public License, which is GPL-incompatible, you'll probably want to use one of the tools they provide for dumping all of this information in machine-readable format, so you can call it as a subprocess the way Linux archive managers do with unrar
.
There are two formats it supports for machine-readable output:
- Digital Forensics XML, via the
fiwalk
command (mentioned here and here but not included in the *buntu 14.04 sleuthkit
package.)
- An SQLite database, via
tsk_loaddb /path/to/image
(It'll generate a database filename by sticking .db
onto the end of the input path but you can change the target directory with -d target_dir
.)
The SQLite schema had changed several times in the last few years to accomodate new features, so just check the Tsk_loaddb page on their wiki for a schema description for whatever version of TSK you're using.
As for supported image formats, my copy from the *buntu 14.04 repository supports these:
ssokolow@monolith ~ % lsb_release -i -r -c
Distributor ID: Ubuntu
Release: 14.04
Codename: trusty
ssokolow@monolith ~ % ifind -V
The Sleuth Kit ver 3.2.3
ssokolow@monolith ~ % ifind -i list
Supported image format types:
raw (Single raw file (dd))
aff (Advanced Forensic Format)
afd (AFF Multiple File)
afm (AFF with external metadata)
afflib (All AFFLIB image formats (including beta ones))
ewf (Expert Witness format (encase))
split (Split raw files)
ssokolow@monolith ~ % ifind -f list
Supported file system types:
ntfs (NTFS)
fat (FAT (Auto Detection))
ext (ExtX (Auto Detection))
iso9660 (ISO9660 CD)
hfs (HFS+)
ufs (UFS (Auto Detection))
raw (Raw Data)
swap (Swap Space)
fat12 (FAT12)
fat16 (FAT16)
fat32 (FAT32)
ext2 (Ext2)
ext3 (Ext3)
ufs1 (UFS1)
ufs2 (UFS2)
Wikipedia and the Sleuth Kit wiki indicate that ExFAT, ext4, and YAFFS2 support have been added since then, but UDF is still an open feature request as of 2018-04-24.
Why? You could simply mount the file if you want to access/copy it. – mdpc – 2013-03-21T01:22:29.793
This is mainly for data recovery issues. Actually, I found a solution: cd to the file system and issue hdparm --fibmap command which give the list of LBAs. But doesn't work on disk images. – supervic – 2013-03-21T09:05:45.953