sleuthkit-developers

[sleuthkit-developers] ifind issue and library stuff.

[David C. <da...@in...>]

Hi Brian,

I've attached a patch to check for a null pointer before free in
fs_inode.c.  Michael Cohen added this. He can't remember if it
definitely caused a crash or was just added while debugging something,
nevertheless it doesnt hurt.

The main reason for this email was to discuss an issue I found in ifind.

I have found an issue wherby if you have a file which has an allocated
and an unallocated dent, ifind will often find the unallocated entry
first and print '0' for the inode and return, even though there is an
allocated inode with that filename, which is almost certainly what you
want to see in this situation.

This happens because fs_ifind_path issues a dent walk with ALLOC and
UNALLOC flags set and the callback (ifind_path_act) stops walking as
soon as it finds a name match, even if it is a realloc'd dent.

A solution which seems to work is that when you find a name match, check
if you are alloc or unalloc (e.g. fs_inode->fsi == NULL seems to
indicate unalloc), if unalloc, set found=1, record the inode (is it
always 0?) but return WALK_CONT. This gives you another chance to
find the real (alloc) file. If you then get to the end of the
function without finding another one, you can print the details you
have recorded (i.e. the unalloc entry). Does that make sense?

On the topic of fs_ifind_path, I wanted to use this funtionallity in
pyflag, but unfortunately if is very library unfriendly as it printf's
the inode rather than returning it. What I did was rename this function,
modify it to return the matched inum, and then wrote a small wrapper
version of fs_ifind_path which used the new function and printed the
result in order to maintain the API. I think there are other places
where this technique will be useful to me as I am writing a python
sleuthkit module (for pyflag) and wish to employ sk in a library
context. Would you me interested in patches for these changes? There
have already been some great changes to help lib'ise sk (for example
tsk_error stuff) I'd like to continue this effort.

Finally, I have unfortunately not had time to revisit the NTFS
compression bug which I encountered as I have been mostly out of the
office. I hope to look at it again later this week. Have you made any
progress with it?

Thanks,

Dave

Re: [sleuthkit-developers] ifind issue and library stuff.

[Brian C. <ca...@sl...>]

On Nov 28, 2006, at 6:34 AM, David Collett wrote:

> Hi Brian,
>
> I've attached a patch to check for a null pointer before free in
> fs_inode.c.  Michael Cohen added this. He can't remember if it
> definitely caused a crash or was just added while debugging something,
> nevertheless it doesnt hurt.

Thanks.  I'll add that in.

> The main reason for this email was to discuss an issue I found in  
> ifind.
>
> I have found an issue wherby if you have a file which has an allocated
> and an unallocated dent, ifind will often find the unallocated entry
> first and print '0' for the inode and return, even though there is an
> allocated inode with that filename, which is almost certainly what you
> want to see in this situation.
>
> This happens because fs_ifind_path issues a dent walk with ALLOC and
> UNALLOC flags set and the callback (ifind_path_act) stops walking as
> soon as it finds a name match, even if it is a realloc'd dent.
>
> A solution which seems to work is that when you find a name match,  
> check
> if you are alloc or unalloc (e.g. fs_inode->fsi == NULL seems to
> indicate unalloc), if unalloc, set found=1, record the inode (is it
> always 0?) but return WALK_CONT. This gives you another chance to
> find the real (alloc) file. If you then get to the end of the
> function without finding another one, you can print the details you
> have recorded (i.e. the unalloc entry). Does that make sense?

Yea. I'll make that change.
> On the topic of fs_ifind_path, I wanted to use this funtionallity in
> pyflag, but unfortunately if is very library unfriendly as it printf's
> the inode rather than returning it. What I did was rename this  
> function,
> modify it to return the matched inum, and then wrote a small wrapper
> version of fs_ifind_path which used the new function and printed the
> result in order to maintain the API. I think there are other places
> where this technique will be useful to me as I am writing a python
> sleuthkit module (for pyflag) and wish to employ sk in a library
> context. Would you me interested in patches for these changes? There
> have already been some great changes to help lib'ise sk (for example
> tsk_error stuff) I'd like to continue this effort.

Would it be easier if there was a callback design?

> Finally, I have unfortunately not had time to revisit the NTFS
> compression bug which I encountered as I have been mostly out of the
> office. I hope to look at it again later this week. Have you made any
> progress with it?

No.  I was waiting for someone to run a special version with verbose  
text output, but have not heard back.

thanks,
brian

Re: [sleuthkit-developers] ifind issue and library stuff.

[David C. <da...@in...>]

On Tue, Nov 28, 2006 at 09:13:36AM -0500, Brian Carrier wrote:
> >On the topic of fs_ifind_path, I wanted to use this funtionallity in
> >pyflag, but unfortunately if is very library unfriendly as it printf's
> >the inode rather than returning it. What I did was rename this  
> >function,
> >modify it to return the matched inum, and then wrote a small wrapper
> >version of fs_ifind_path which used the new function and printed the
> >result in order to maintain the API. I think there are other places
> >where this technique will be useful to me as I am writing a python
> >sleuthkit module (for pyflag) and wish to employ sk in a library
> >context. Would you me interested in patches for these changes? There
> >have already been some great changes to help lib'ise sk (for example
> >tsk_error stuff) I'd like to continue this effort.
> 
> Would it be easier if there was a callback design?

Forgot to answer this last time...

On the one hand a callback seems overkill, but on the other hand it's
the only way to return multiple records, so I guess that could be
useful.

Having said that, do we ever actually want to return multiple records? 

A given path can only have one directory entry on most filesystems
(either allocated or deleted/unused), or two on NTFS where the second is
an artifact of b-tree balancing and is 'unused'. (is this correct?)

So the function should work as follows I think:
1. if an allocated dent is found, return its inode
2. if a deleted/unused dent is found, keep looking for an allocated dent
with the same name (which can occur in NTFS as described above). If
found, return that, otherwise return the (former) inode or 0 (filesystem
dependant) from the deleted/unused dent.

There is little value in returning both inodes in the second case as
this only occurs in NTFS (AFAIK), and the inode number is always 0 for
the 'unused' entry anyway.

Does that make sense?

Dave