Re: [sleuthkit-users] mmls and sparse images

[RB <ao...@gm...>]

On Wed, Mar 17, 2010 at 16:26, J. Aaron Restivo
<aa...@ac...> wrote:
> If sleuthkit tools are calling any libntfs function, such action is being
> proxied by sleuthkit and should have the benefit of having been reviewed
> (the function code) before implementation.

I generally agree, but the problem with that is future development -
what may be safe today can inadvertently be altered tomorrow to
provide functionality X that is important to the libntfs developers
but not forensically sound.

> The other alternative, aside from doing nothing and leaving SK with a blindspot

I don't see where the blind spot is; perhaps I have one of my own.  SK
does not support the special libntfs format that encodes unallocated
blocks with control codes instead of making a sparse image,
ntfsclone's recommended mode of operation and what I originally
assumed you had used.

It does, however, support partition images, sparse or not, as 'sparse'
images are a function of the filesystem on which they reside - if you
try to read in a 'sparsed' area, it'll return 0x0.  Again - please
make sure you're not using mmls against a partition image (/dev/sda1)
as opposed to a disk image (/dev/sda).

This is akin to not supporting the proprietary NRG format while
supporting the iso9660 format.  Having support for every synthetic
image type possible is a quick path to pain, especially when it's more
efficient (and encourages the forensically sound process of using
copies) to have users convert nonstandard images to a standard format.