Fiwalk reports byte runs for files that are resident in NTFS's MFT - that is, files small enough that their contents can just live in the MFT entry, instead of allocating an entire cluster. However, the byte runs are incorrect: They report the image offset as the beginning of the partition, and the file system offset as 0.
There may also be a limitation in tsk_loaddb due to this issue - the tsk_file_layout table doesn't seem to be storing byte runs for files with the "resident" flag.
The current effect of this is it is impossible to use the byte runs alone to retrieve file content. (I am aware that a workaround, for the sake of getting file contents, is to use icat instead of the byte runs.) For a task I am currently working on, this hampers my ability to reproduce the checksums of small files as Fiwalk found them. I need to be able to reproduce checksums to show that I am reading the same data for a file from multiple points in my workflow.
I have identified the code point where the issue arises, but I do not know how to interpret the code. I would appreciate help from someone with more experience.
I was able to find the code point with these steps in a gdb session (I used the CFREDS "Hacking case" image, but any realistic NTFS image should do):
$ gdb fiwalk
(gdb) b src/content.cpp:500
(gdb) condition 1 flags & TSK_FS_BLOCK_FLAG_RES
(gdb) run -X test.xml test.aff
(gdb) p img_offset
(gdb) p fs_offset
(gdb) p addr
Here are the annotations for today's develop branch head:
There is a hard-coded 3rd argument of 0, at this line of the function tsk_fs_attr_walk_res:
That value trickles down to the function file_act:
content::file_act then takes the 0, setting fs_offset to 0, rendering moot fs_offset and img_offset:
My questions for whomever would know:
And of course: