Re: [sleuthkit-users] TSK-4.4 and SlackFiles

[Luís F. N. <lfc...@gm...>]

Thank you, Brian, for the change! I think VSC file content will be
accessible now!

And to clarify, I was a bit confused about the slack size of 2.026.496
bytes, because the allocated size of the system.LOG file was not shown in
istat output. But I confirmed with another tool that the allocated size of
system.LOG is 2.027.520 bytes and with only 1024 bytes of logical size that
give us 2.026.496 bytes for the slack size. So everything was ok!

Thanks again!
Luis

2017-02-01 15:06 GMT-02:00 Brian Carrier <ca...@sl...>:

> This fix is now in the develop-4.4 branch. We'll merge it into develop
> after we do a few other minor things on this branch.
>
>
> On Wed, Feb 1, 2017 at 11:38 AM, Brian Carrier <ca...@sl...>
> wrote:
>
>> Ughh.  I need to better start documenting these scenarios because I
>> always get confused by them too.
>>
>> I think you've found an issue and I created #756 (
>> https://github.com/sleuthkit/sleuthkit/issues/756) to address this.
>>
>> The summary of your specific questions are:
>> - VSC is strange because WIndows seems to treat it differently and lies
>> about initsize.  It has initsize of 0, but a file size that is equal to the
>> allocsize.
>> - In the log file case, 4096 has been initialized, but the allocated size
>> of the file is 2MB.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 31, 2017 at 7:26 PM, Luís Filipe Nassif <lfc...@gm...>
>> wrote:
>>
>>> Thank you, Brian, for your explanation! No problem for our application,
>>> just curious to know if it was a bug or, if not, why it is there.
>>>
>>> But, currently, no slack files are created for VSC files and other files
>>> with initsize smaller than allocated size. I thought slack is created only
>>> when allocated > logical size (based on line 1001 of db_sqlite.cpp)
>>>
>>> And is the allocated size 4096 from istat output? I do not know where
>>> the slack size of 2.026.496 bytes came from...
>>>
>>> 2017-01-31 18:05 GMT-02:00 Brian Carrier <ca...@sl...>:
>>>
>>>> Actually, making this decision could incur some significant overhead
>>>> for a step that (at least in Autopsy) we try to keep as fast as possible.
>>>> Is your application impacted by the fact that there is a large and empty
>>>> slack file or were you just curious if it was a bug?
>>>>
>>>>
>>>>
>>>> On Tue, Jan 31, 2017 at 2:54 PM, Brian Carrier <ca...@sl...>
>>>> wrote:
>>>>
>>>>> Yea, this looks like "VDL Slack".  Same general idea as in Issue 466 (
>>>>> https://github.com/sleuthkit/sleuthkit/issues/466), but in this case
>>>>> the file has 1K of initialized size.
>>>>>
>>>>> I suppose this "slack" file is a bit wasted though because no blocks
>>>>> were allocated to it. So, there will be no real content for it.
>>>>>
>>>>> I'll make an internal story to keep track of this and maybe Ann will
>>>>> be able to take a look at not making these if they are going to be all for
>>>>> address 0.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 31, 2017 at 10:55 AM, Luís Filipe Nassif <
>>>>> lfc...@gm...> wrote:
>>>>>
>>>>>> Hi Brian,
>>>>>>
>>>>>> Thank you very much for your attention. The output of
>>>>>> FsContent.getMetaDataText() (equals to istat right?) is below. The
>>>>>> system.LOG-slack size is 2.026.496 bytes and system.LOG size is 1024 bytes.
>>>>>>
>>>>>> details of /img_PC-HP.dd/vol_vol2/WINDOWS
>>>>>> /system32/config/system.LOG-slack
>>>>>>
>>>>>> MFT Entry Header Values:
>>>>>> Entry: 4106        Sequence: 1
>>>>>> $LogFile Sequence Number: 79246281526
>>>>>> Allocated File
>>>>>> Links: 1
>>>>>>
>>>>>> $STANDARD_INFORMATION Attribute Values:
>>>>>> Flags: Hidden, Archive
>>>>>> Owner ID: 0
>>>>>> Security ID: 281  (S-1-5-32-544)
>>>>>> Last User Journal Update Sequence Number: 105272096
>>>>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil)
>>>>>> File Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil)
>>>>>> MFT Modified: 2011-09-16 14:33:38.375000000 (Hora oficial do Brasil)
>>>>>> Accessed: 2011-09-16 14:33:38.187500000 (Hora oficial do Brasil)
>>>>>>
>>>>>> $FILE_NAME Attribute Values:
>>>>>> Flags: Hidden, Archive
>>>>>> Name: system.LOG
>>>>>> Parent MFT Entry: 3982 Sequence: 2
>>>>>> Allocated Size: 4096   Actual Size: 1024
>>>>>> Created: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil)
>>>>>> File Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil)
>>>>>> MFT Modified: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil)
>>>>>> Accessed: 2004-09-02 08:00:12.000000000 (Hora oficial do Brasil)
>>>>>>
>>>>>> $ATTRIBUTE_LIST Attribute Values:
>>>>>> Type: 16-0 MFT Entry: 4106 VCN: 0
>>>>>> Type: 48-4 MFT Entry: 4106 VCN: 0
>>>>>> Type: 128-0 MFT Entry: 40678 VCN: 0
>>>>>>
>>>>>> Attributes:
>>>>>> Type: $STANDARD_INFORMATION (16-0)   Name: N/A   Resident   size: 72
>>>>>> Type: $ATTRIBUTE_LIST (32-5)   Name: N/A   Resident   size: 96
>>>>>> Type: $FILE_NAME (48-4)   Name: N/A   Resident   size: 86
>>>>>> Type: $DATA (128-6)   Name: N/A   Non-Resident   size: 1024
>>>>>>  init_size: 1024
>>>>>> 847844 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0 0
>>>>>> 0 0 0 0 0 0 0
>>>>>>
>>>>>> 2017-01-31 12:56 GMT-02:00 Brian Carrier <ca...@sl...>:
>>>>>>
>>>>>>> Hi Luis,
>>>>>>>
>>>>>>> My guess is that it's a file that has preallocated a large amount of
>>>>>>> space, but that has not fully used it yet. NTFS allows this.  If you read
>>>>>>> the file, TSK will only show you the space that is used.  Reading the
>>>>>>> slack, gives you the rest.
>>>>>>>
>>>>>>> If you run 'istat' on one of these files and send it along, we can
>>>>>>> confirm.
>>>>>>>
>>>>>>> thanks,
>>>>>>> brian
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 31, 2017 at 7:04 AM, Luís Filipe Nassif <
>>>>>>> lfc...@gm...> wrote:
>>>>>>>
>>>>>>>> Hi folks,
>>>>>>>>
>>>>>>>> I am upgrading to tsk-4.4 to benefit from the new support to
>>>>>>>> slackfiles from java bindings. But I noticed some slackfiles larger than
>>>>>>>> the cluster size (4k) are created in database. Some of them have megabytes
>>>>>>>> of size and its contents are accessible. Is it expected to have slackfiles
>>>>>>>> larger than cluster size? Could someone explain?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Luis Nassif
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ------------------
>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>>>>> _______________________________________________
>>>>>>>> sleuthkit-users mailing list
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
>>>>>>>> http://www.sleuthkit.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>