Re: [sleuthkit-users] fiwalk hashing and cluster runs

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

Hi Jason,

This is a weird coincidence.  I just talked with Dave Ferguson yesterday at a conference, about a paper he had authored years ago on a couple different ways NTFS reports file content length.  There is apparently a "Valid data length" field that is separate from the space actually allocated for file content.  From discussion with Dave, at the time the FSFA book was published, the book acknowledged the "Valid data length" field, but said it had never been observed to be different from the other file content length recorded in the MFT.  I haven't scoured TSK's code for the field yet, but I suspect it's part of your problem.  

So, sorry to nitpick, but when you say "actual size," what do you mean?  What is your source for that number, a field of the standard info. attribute?  (I'd look through FSFA, but I'm still at the conference.)

--Alex

PS Dave's article is here, paywalled:
http://www.tandfonline.com/doi/abs/10.1080/15567280802587965#.UwTnWkJdWK8


On Feb 19, 2014, at 07:57 , Simson Garfinkel <si...@ac...> wrote:

> Do you see the same behavior with other tools? What happens when you try to get the file content via icat?
> 
> 
> On Feb 19, 2014, at 9:46 AM, Jason Wright <jwr...@gm...> wrote:
> 
>> All,
>> 
>> Recently when examining a number of drives and running fiwalk (sleuthkit 4.1.2 and libewf 20130416) on each of the files, I've noticed that there are a few files that don't get hashed by fiwalk. The files are allocated and do have a size and a file signature, but no hash, I've also noticed that the files that are not getting hashed are similar in that the initialized size from the data attribute is smaller than the actual size. Has anyone come across this situation and is there a way to tell fiwalk to hash them anyway?
>> 
>> As a footnote, the istat of the files shows the clusters at the end to be zero. In other words, they don't have a cluster assignment. The clusters assigned and listed for these files are as many needed for the initialized size. The remaining clusters that would be needed for the size above initialized and to the actual size have no assignments. This makes sense since when parsing the data attribute, the first byte run is described as expected and followed by 0x00, which would indicate an end of the cluster contents of the file. I am wondering if this has some effect on how fiwalk hashes and results in these files not getting hashed. 
>> 
>> R/
>> 
>> Jason Wright
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
>> sleuthkit-users mailing list
>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>> http://www.sleuthkit.org
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
> sleuthkit-users mailing list
> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> http://www.sleuthkit.org