[sleuthkit-developers] Bug with sleuthkit parsing recursive images.

[Michael C. <scu...@gm...>]

I have hit this unusual bug using the attached test image. This ext2
image contains a second ext2 image inside it. I was calling libtsk3's
tsk_fs_file_open() with the following path:  /home/image2.img/home/
and it returned to me inode 13. (i.e. I was trying to recurse into the
image file). I then verified this with fls (which does not seem to
accept a path, only inodes):

$ fls recursive.img
d/d 11:	lost+found
r/- * 0:	fs2
d/- * 0:	f2
d/d 14:	home
d/d 129:	$OrphanFiles

$ fls recursive.img 14
r/r 12:	image2.img
d/- * 0:	t

# image2.img is a dd image (i.e. a file). I do not expect to be able
to list it at all since its a file. But this kind of looks like the
contents of the second image but not exactly:
$ fls recursive.img 12
d/d 11:	lost+found
r/- * 0:	a.txt
d/d 13:	home
r/r 12:	a.txt

# But if TSK was actually recursively opening the filesystem I would
expect to be able to list inode 13 - but this does not work.
$ fls recursive.img 13
$

Also note that the recursive fls is incorrect, since the a.txt file is
inside the home directory on image2.img:

$ fls /tmp/image2.img
d/d 11:	lost+found
r/- * 0:	a.txt
d/d 13:	home
d/d 65:	$OrphanFiles

$ fls /tmp/image2.img 13
r/r 12:	a.txt

Now I realize that it is incorrect to try to list a directory when the
file type of inode 12 is definitely not a directory but a file. But
when using the  tsk_fs_file_open() API i really dont know this unless
I try to open every intermediate inode along the way (i.e. /home/,
/home/image2.img, /home/image2.img/home).   Is it possible that TSK is
opening the file and trying to parse it as a list of inodes, so the
content of the embedded image is confused?

Should the tsk_fs_file_open() api fail to recurse into something which
is not a directory type?

Thanks,
Michael