Re: [sleuthkit-users] Autopsy 3 - file offset information

[Sam K <sku...@gm...>]

Thanks Brian, and to Alex, Atila, & Stumpy for your feedback.

Perhaps I should have included more background in my initial e-mail: my
organization has decided to use the DCFL Control Standard (
http://www.cfreds.nist.gov/Controlv1_0/DCFL_Control_Standard_V1_0.html) for
baseline validation of forensic software.  DCFL includes hex offsets for
the various artifacts that are included in the control image.

I am creating an Autopsy report module that will output the details of all
of these artifacts after ingest of the DCFL image.  Based on the feedback
from this list, I was able to find the info from Autopsy by using the
getMetaDataText() method of an FsContent object, and parsing down to the
data run information that starts at the end of the attributes section.  At
least for the DCFL image, this gives me the offset info that corresponds to
the DCFL standard (after converting from decimal to hex).

Thanks again to all who responded from the list.  I will upload the module
for others to critique when it's finished, if anyone else is using this
particular method for validating their tools.

-Sam


On Tue, Apr 7, 2015 at 11:52 AM, Brian Carrier <ca...@sl...>
wrote:

> Hi Sam,
>
> The data below is created “in real time” by calling the TSK code.  It
> isn’t stored anywhere in the Autopsy DB.  It is the same info that you get
> from running the ‘stat’ command in TSK.
>
> Autopsy doesn’t store any file info for speed reasons. It would take A LOT
> longer to add a data source into Autopsy if we did that (we did in the very
> early days) and there aren’t that many use cases (in Autopsy at least) that
> need it.  The theory was that we would expose an API to the data via TSK if
> a use case ever presented itself.  And perhaps one now has.
>
> Are you looking for a method that returns the list of blocks for a given
> file?
>
> As Alex pointed out, NTFS further complicates this because of resident
> files that have data that are not on sector boundaries.  So, to be truly
> generic, the API would need to be starting byte of a file.
>
> brian
>
>
>
> > On Apr 1, 2015, at 11:17 AM, Sam K <sku...@gm...> wrote:
> >
> > Good morning:
> >
> > Can anyone shed light on where Autopsy 3.1.2 would store the starting
> physical sector for a file, if that information is not contained in the
> tsk_file_layout table? I'm guessing it must be stored somewhere (and not
> re-parsed from the MFT every time I view the file), but have been
> unsuccessful in finding it.
> >
> > Based on the output in the Metadata tab, Autopsy does store the
> information.  I've confirmed with another tool that 118341 is indeed the
> starting physical sector.  I want this information included with a report
> module I'm working on, and can't seem to reference it anywhere in the API
> or database (there's no entry for the file in tsk_file_layout, perhaps
> because it's contiguous and not fragmented).
> > Attributes:
> > Type: ? (16-0)   Name: N/A   Resident   size: 72
> > Type: ? (48-6)   Name: N/A   Resident   size: 90
> > Type: ? (48-5)   Name: N/A   Resident   size: 110
> > Type: ? (128-4)   Name: N/A   Non-Resident   size: 25600  init_size:
> 25600
> > 118341 118342 118343 118344 118345 118346 118347 118348
> > 118349 118350 118351 118352 118353 118354 118355 118356
> > 118357 118358 118359 118360 118361 118362 118363 118364
> > 118365 118366 118367 118368 118369 118370 118371 118372
> > 118373 118374 118375 118376 118377 118378 118379 118380
> > 118381 118382 118383 118384 118385 118386 118387 118388
> > 118389 118390
> > Thanks in advance for any feedback.
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> > things parallel software development, from weekly thought leadership
> blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now.
> http://goparallel.sourceforge.net/_______________________________________________
> > sleuthkit-users mailing list
> > https://lists.sourceforge.net/lists/listinfo/sleuthkit-users
> > http://www.sleuthkit.org
>
>