Re: [sleuthkit-users] fiwalk output

[Jason W. <jwr...@gm...>]

unfortunately, no. i wish, but it's not shareable.

istat for the entry only gives me metadata for the allocated file. i'm
going to write something up to see if I can't determine how the framework
tags the deleted entry. i'll pass on anything interesting that i find.

Thanks for the help.
Jason


On Fri, Oct 11, 2013 at 2:40 PM, Alex Nelson <ajn...@cs...> wrote:

> Oh, that's exciting.  You've found a bug.  Correcting the bug will
> unfortunately probably require access to the metadata structures on the
> disk image, best dumpable with istat and icat.
>
> Does this happen to be a shareable disk image?  (Long shot, I know.)
>
> --Alex
>
>
> On Oct 11, 2013, at 14:36 , Jason Wright <jwr...@gm...> wrote:
>
> Yes, it does normally, but in this case it did not. For both entries in
> the dfxml, the alloc field is 1.
>
>
> On Fri, Oct 11, 2013 at 2:34 PM, Simson Garfinkel <si...@ac...> wrote:
>
>> The XML indicates whether the file is allocated or not.
>>
>> On Oct 11, 2013, at 2:32 PM, Jason Wright <jwr...@gm...> wrote:
>>
>> I don't have the exact fiwalk output accessible here, so sorry that I
>> can't paste it in for more clarity, but at present the only difference in
>> the fileobjects for both inodes in the dfxml, is the filename. After
>> researching I think found that one was for a deleted entry based off of
>> some fls output I obtained. That cleared things up. My next thought was
>> then, how can I use fiwalk to help differentiate between the allocated and
>> deleted entries for two files referencing the same inode from the same
>> partition on a drive.
>>
>> I'm not sure there is anything at present and wanted to find out before
>> creating something on my own.
>>
>> Thanks again,
>>
>> Jason
>>
>>
>> On Fri, Oct 11, 2013 at 2:19 PM, Alex Nelson <ajn...@cs...>wrote:
>>
>>> Whoops, looks like you beat me to a response.  But yes, that clarifies
>>> your question.
>>>
>>> I think your question boils down to recording allocation status.  Do you
>>> have DFXML output from Fiwalk?  Are there <alloc> or <unalloc> elements for
>>> the fileobjects that you're looking at?
>>>
>>> --Alex
>>>
>>>
>>> On Oct 11, 2013, at 14:16 , Jason Wright <jwr...@gm...> wrote:
>>>
>>> Thanks, Alex. What I've come across is two references for the same inode
>>> in the fiwalk output for a particular drive. Both are on the same
>>> partition. One is for the allocated file the other is for the unallocated
>>> state for the filename of the file that previously used the inode.
>>>
>>> If running fls and looking for inode 79456, for example, you may get
>>> these two outputs
>>> +++ r/r 79456-128-3: filename1.ext
>>> ++++++++ r/r 79456-128-3(realloc): filename2.ext
>>>
>>> So, in this case filename2.ext is a reference for a file that once used
>>> inode 79456 and the file that currently uses the inode is filename1.ext.
>>>
>>> What I'm interested in is a possible reference in the dfxml fiwalk
>>> output that would differentiate the two references?
>>>
>>> Hopefully, that helps explain it a little better.
>>>
>>> R/
>>>
>>> Jason
>>>
>>>
>>>
>>>
>>> On Fri, Oct 11, 2013 at 1:46 PM, Alex Nelson <ajn...@cs...>wrote:
>>>
>>>> That's interesting.  It might, but I don't understand the whole
>>>> situation you're describing.  What are indicators of reallocation for a
>>>> disk image at a single point in time?  Do you mean multiple hard-links to
>>>> the same file exist and are legitimate files?  Or do you mean a file was
>>>> unlinked somewhere and reallocated, but the file system was imaged in an
>>>> inconsistent state?
>>>>
>>>> --Alex
>>>>
>>>>
>>>> On Oct 11, 2013, at 13:36 , Jason Wright <jwr...@gm...> wrote:
>>>>
>>>> All,
>>>>
>>>>
>>>> Does the dfxml output of fiwalk report whether a file object has been
>>>> reallocated? Fls will (indicated by realloc), but will fiwalk do the same?
>>>> I've come across this situation for a particular ntfs partition and have
>>>> found two references for the same inode in fiwalk. In know which one is the
>>>> allocated entry based off of fls, but I'm not sure of how that can be
>>>> identified in fiwalk. Does anyone have any suggestions?
>>>>
>>>> Thanks,
>>>>
>>>> Jason Wright
>>>>
>>>> ------------------------------------------------------------------------------
>>>> October Webinars: Code for Performance
>>>> Free Intel webinars can help you accelerate application performance.
>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> most from
>>>> the latest Intel processors and coprocessors. See abstracts and
>>>> register >
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk_______________________________________________
>>>> sleuthkit-users mailing list
>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>> http://www.sleuthkit.org
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk_______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>>
>>
>>
>
>