Re: [sleuthkit-users] fiwalk output

[Alex N. <ajn...@cs...>]

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
> 
>