Re: [sleuthkit-users] hashing a file system

[Jon S. <jo...@li...>]

Cool, thanks for clarifying.


Jon


On Wed, Sep 10, 2014 at 12:05 PM, Brian Carrier <ca...@sl...> wrote:
> If all goes well, you'll never see them.  The caller to the API never sees the attribute until it has been fully populated and for good files all of the filler entries will have been pushed out.  The only times that you will see them are if:
> - The file system is corrupt and you don't have all of the run info.  This can occur in NTFS if the run list is stored across multiple MFT entries and some of them have been re-used.
> - There is a bug in TSK.
>
> You won't need to wait.  There is nothing to wait for.
>
>
>
> On Sep 10, 2014, at 8:46 AM, Jon Stewart <jo...@li...> wrote:
>
>> Sorry to veer off-topic with this thread (stupid gmail won't let me
>> change the subject), but I'm now more confused/concerned by this
>> explanation regarding FILLER entries.
>>
>> 1. Under what circumstances can you get a FILLER ATTR_RUN?
>>
>> 2. What can you do about it? How does one wait on TSK to go find the
>> missing run?
>>
>> Thanks,
>>
>> Jon
>>
>> On Tue, Sep 9, 2014 at 10:13 PM, Brian Carrier <ca...@sl...> wrote:
>>> The FILLER entries are there for basic record keeping because NTFS makes not guarantees that the runs will be stored in consecutive order. TSK adds the FILLER entries when it gets runs out of order and pops them out as it finds them.
>>>
>>> Is the data you are describing below from the same Ext4 image you mentioned before?
>>>
>>> brian
>>>
>>>
>>>
>>> On Sep 5, 2014, at 1:46 PM, Stuart Maclean <st...@ap...> wrote:
>>>
>>>> Hi all, I'm glad to have provoked some conversation on the merits (or
>>>> otherwise!) of md5 sums as useful representations of the state of a file
>>>> system.
>>>>
>>>> Can anyone enlighten me as to the meaning of the 'flags' member in a
>>>> TSK_FS_ATTR_RUN?  Specifically, what does this comment mean?
>>>>
>>>> TSK_FS_ATTR_RUN_FLAG_FILLER = 0x01,     ///< Entry is a filler for a run
>>>> that has not been seen yet in the processing (or has been lost)
>>>>
>>>> In a fs I am walking and inspecting the runs for, I am seeing run
>>>> structs with addr 0 and flags 1.  I was under the impression that any
>>>> run address of 0 represented a 'missing run' i.e. that this part of the
>>>> file content is N zeros, where N = run.length * fs.blocksize.  I presume
>>>> that would be the case were the run flags value 2:
>>>>
>>>> TSK_FS_ATTR_RUN_FLAG_SPARSE = 0x02      ///< Entry is a sparse run where
>>>> all data in the run is zeros
>>>>
>>>> If I use istat, I can see inodes which have certain 'Direct Blocks' of
>>>> value 0, and when I see M consecutive 0 blocks that matches up to a
>>>> 'missing run' when inspecting the runs using the tsk lib (actually my
>>>> tsk4jJava binding, which is now finally showing its worth since I can do
>>>> all data structure manipulation in Java, nicer than in C, for me at least).
>>>>
>>>> I am worried at being 'filler' and not 'sparse', the partial file
>>>> content represented by the run(s) with addr 0 is not necessarily a
>>>> sequence of zeros.
>>>>
>>>> Anyone shed light on this?  Brian?
>>>>
>>>> Thanks
>>>>
>>>> Stuart
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Slashdot TV.
>>>> Video for Nerds.  Stuff that matters.
>>>> http://tv.slashdot.org/
>>>> _______________________________________________
>>>> sleuthkit-users mailing list
>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>> http://www.sleuthkit.org
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want excitement?
>>> Manually upgrade your production database.
>>> When you want reliability, choose Perforce
>>> Perforce version control. Predictably reliable.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> sleuthkit-users mailing list
>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>> http://www.sleuthkit.org
>>
>>
>>
>> --
>> Jon Stewart, Principal
>> (646) 719-0317 | jo...@li... | Arlington, VA
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
>



-- 
Jon Stewart, Principal
(646) 719-0317 | jo...@li... | Arlington, VA