Daily Blog #378: Automating DFIR with dfVFS part 5

Hello Reader,

Wondering where yesterdays post is? Well, there was no winner of last weekends Sunday Funday.
That's ok though because I am going to post the same challenge this Sunday so you have a whole week to figure it out!

-- Now back to our regularly scheduled series --

              I use Komodo from Activestate as my IDE of choice when writing perl and python. I bring this up because one of the things I really like about it is the debugger it comes with that allows you to view all of the objects you have made and their current assignments. I was thinking about the layer cake example I crudely drew in ascii in a prior post when I realized I could show this much better from the Activestate Debugger.

So here is what the path spec object we made to access the $MFT in a VHD looks like.

I've underlined in red the important things to draw your attention to when you are trying to understand how that file path specification object we built can access the MFT and all the other layers involved.

So if you look you can see from the top down its:

• TSK Type with a Location of /$MFT
• With a parent of TSK Partition type with a location of /p1
• With a parent of VHDI type 
• With a parent of OS type with a location of the full path to where the vhd I'm working with sits.

Let's look at the same object with with an e01 loaded.

Notice what I highlighted, the image type has changed from VHDI to EWF. Otherwise the object, its properties and the methods are the same. 

Let's do this one more time to really reinforce this with a raw/dd image.

Everything else is the same, except for the type changing to RAW. 

So no matter what type of image we are working with dfVFS allows us to build an object in layers that permits the code that follows not to have to worry about the code behind. It is normalizing all the different image types access libraries so we can prevent things like the work around we do in pytsk.

Tomorrow, more code!

This is a 6-part series and here's link to all the parts:

Automating DFIR with dfVFS Part 6
Automating DFIR with dfVFS Part 5
Automating DFIR with dfVFS Part 4
Automating DFIR with dfVFS Part 3
Automating DFIR with dfVFS Part 2
Automating DFIR with dfVFS Part 1

Read More

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: https://forensic4cast.com/forensic-4cast-awards/

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'/',
        parent=source_path_spec)

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 here:

https://github.com/log2timeline/dfvfs/wiki/Internals

Tomorrow I will explain how we access raw images and then Thursday we will extract a file from an image.

This is a 6-part series and here's link to all the parts:

Automating DFIR with dfVFS Part 6
Automating DFIR with dfVFS Part 5
Automating DFIR with dfVFS Part 4
Automating DFIR with dfVFS Part 3
Automating DFIR with dfVFS Part 2
Automating DFIR with dfVFS Part 1

Read More