Top Ad unit 728 × 90

Latest News


Daily Blog #372: Automating DFIR with dfVFS part 2

Hello Reader,
        In this short post I want to get more into the idea of the path specification object we made in the prior part. If this post had a catch title it would be zen and the art of path specification.

If you want to show your support for my efforts, there is an easy way to do that. 

Vote for me for Digital Forensic Investigator of the Year here:

In the prior post, part 1 of the series, we made three path specification objects. I described path specification objects as the corner stone in understand dfVFS which I believe to be true. What I didn't point out is that the path specification objects in that first example code where building on top of themselves like a layer cake.

Let's take a look at the three objects we created again.
path_spec = path_spec_factory.Factory.NewPathSpec(
          definitions.TYPE_INDICATOR_OS, location=source_path)

source_path_spec = path_spec_factory.Factory.NewPathSpec(
            type_indicators[0], parent=path_spec)

volume_system_path_spec = path_spec_factory.Factory.NewPathSpec(
        definitions.TYPE_INDICATOR_TSK_PARTITION, location=u'/',

If you were to look carefully you would notice there are a couple of differences between the calls to the NewPathSpec function. the calls to the NewPathSpec function.

1. The type of path specification we are making is changing. We start with a operating system
file, then an image (which is being set by the return of our indicator query) and lastly
we are working with a partition.
2. Two of our path specifications declare a location, one does not
3. Most importantly, source_path_spec and volume_System_path_spec have parents. Those parents
are the path specification objects created prior.

So if you were to look at it like one single object with multiple layers it would look
something like this.

|  OS File Path Spec       |
|  TSK Image Type Path Spec |
|  TSK Partition Path Spec  |
The lowest layer in the object can reference the upper layers. This is why we don't just
create one path specification object. Instead we are initializing each layer of the object
one call at a time as we determine the type of image, directory, archive, etc.. we are
working with to allow our path specification object to reflect the data we are trying
to get dfVFS to work with.

Depending on what part of the dfVFS framework you are working with will determine how many
of these layers need to exist prior to calling that function with your fully developed
path specification object.

As we go father into the series I will show you how to interact with the files stored in the
partitions we listed in part 1. Doing that will create yet another layer to our object,
the file system layer. This is very similar to how we built our objects in pyTSK.

If you want to read how Metz explains Path Specification objects you can read about them

Tomorrow I will explain how we access raw images and then Thursday we will extract a file
from an image.
Daily Blog #372: Automating DFIR with dfVFS part 2 Reviewed by David Cowen on April 12, 2016 Rating: 5

No comments:

All Rights Reserved by Hacking Exposed Computer Forensics Blog © 2014 - 2020
Powered By Blogger, Designed by Sweetheme

Contact Form


Email *

Message *

Powered by Blogger.