Most resident byte run metadata lost #379

Open
ajnelson opened this Issue Nov 21, 2014 · 0 comments

Projects

None yet

1 participant

@ajnelson
Contributor

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) bt
(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:

  • Why is the "Resident address" hard-coded to 0? I don't quite know how to interpret the variable or its type here.
  • Is this a bug in Fiwalk, or a bug in the core TSK library?
  • Should the correction for this be in Fiwalk, or in the core TSK library?

And of course:

  • What should the fix be?
@ajnelson ajnelson changed the title from All resident byte run metadata lost to Most resident byte run metadata lost Nov 21, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment