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:
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 6Automating DFIR with dfVFS Part 5Automating DFIR with dfVFS Part 4Automating DFIR with dfVFS Part 3Automating DFIR with dfVFS Part 2Automating DFIR with dfVFS Part 1
Post a Comment