We're in course 9.
We're talking about the NTFS file system.
In this module, we're going to be
talking about data runs.
In our last module,
we took a look at the data attribute in a file record.
The one we looked at was resident.
We saw the attribute type.
We talked that hexadecimal 80 is a data attribute.
We find this within a file record.
Right after that, we see the length of the attribute.
Hexadecimal 48 is the number of bytes in the attribute.
Next, we see the resident, non-resident flag.
It's technically called the non-resident flag
and we can see here is
00 so the flag is not
flying so this would be a resident data attribute.
Then we can move over to hexadecimal 1C over here.
We can see the offset to
the data from the start of
the attribute and that would be 18.
We go down one line and over
eight bytes and that would take us
to the start of our data.
We can see this is
an example of a resident data
attribute written in the ASCII.
This is how we would read
a resident data attributes within a file record entry.
Now, for a non-resident data attribute,
you're going to have the same thing in the header.
You're going to have the attribute type.
You're going to have the length of the attribute.
When we get to the non-resident flag,
we see that that flag is up.
It's a 01.
This indicates to us that this is
a non-resident data attribute
and that the data for this file is
located not within the MFT record itself,
but somewhere out on the drive.
Next, we need to find the offset to
the data from the start of the attribute.
We can see right here,
we go down two lines and we can see that this offset,
we have a hexadecimal 40.
That tells us that our data run,
or where we can find the location for the data out on
the drive is going to be
four lines down from the start of the attribute.
We count four lines down, 1, 2,
3, 4, and this takes us to our data run.
Now, our data run contains a run list.
We're going to take a very good look
at the data run itself.
The first byte in
the data run is what's called a run header.
We interpret that by splitting it
into two nibbles and then adding it
together to get the total number
of bytes in our data run.
If we add two and one,
we come up with three.
That tells us our data run is three bytes long.
The first right here, the one,
our left nibble represents
this number one right here represents hexadecimal 55.
This is the length in clusters of our data run.
The decimal, the nibble 2,
the far left nibble represents the starting cluster.
The starting cluster is going to be over here,
and it's going to be 8B,
05, but it will be read little-endian so it'd be 05, 8B.
Tells us our starting cluster.
Then when you get to all zeros,
you're at the end of your data run.
Here, we have a visual of what I was talking about.
We have our run list header split into two nibbles.
The two and the one, we add 2 plus 1, we get 3.
The one, the right nibble
represents the size, how many clusters?
The left nibble represents what's
called the starting extent or the starting cluster.
That represents these two bytes here.
The 8B and the 05 tell us the starting cluster.
We split it into two nibbles.
The right nibble represents the size;
the first byte in the data run.
The left nibble is two so we know we need two bytes.
That represents the next two bytes in our data run,
and that tells us the starting cluster.
We're going to go ahead and take a look at
this in Active Disk Editor.
The items we're going to need for this walk-through,
we're going to need active disk editor,
we're going to need our NTFS VHD,
and we're going to need a Windows calculator,
or any type of calculator will work just fine.
The first thing we're going to need to do for
our walk-through is attach our VHD.
We're going to bring up Disk Management.
We're going to go to Actions.
Attach VHD, navigate out to where our NTFS.vhd stored.
Select it and click "Open".
Then click "Okay" and our VHD will mount.
As before, make sure you know the disk number,
the volume that we're going to be working with
is the second volume in on the drive,
the first NTFS volume
on my computer it's B on yours it may be different,
and the size is 200 megabytes,
and the volume label is NTFS.
Let's go ahead and start Active Disk Editor.
We're going to select "Open Disk".
We're going to select "Volumes",
and then we're going to select
our NTFS volume then we're going to click "Open".
Again we're going to be brought to
the volume boot record.
Let's take a quick look in the volume boot record
at our sectors per cluster,
which is eight in our bytes per sector, which are 512.
If we multiply 8 times 512,
we get 4,096 bytes in a cluster.
Let's go to Browse File Records.
Scroll down and let's take a look
at this resident.txt first.
We looked at this file record before,
we noticed the header.
We see it says file,
so we know we're looking at MFT file record.
We see the ASCII file.
Now we can see our attributes within the file record.
We have our standard information attribute,
and we parse that in the last module.
We have our filename attribute, hexadecimal 30.
We talked about our object ID attribute,
and now we have our data attribute.
The first part of our attribute is
actually called an attribute header.
It tells us the type of attribute we have.
It tells us the size,
the length of the attribute,
and right here is our non-resident flag.
In this particular file,
we see that our non-resident flag is not up,
so this indicates to us that this is flat resident file,
because the non-resident flag is not set.
This will tell us our offset to the attribute data.
Right here outlined in pink,
this is the offset to the attribute data.
You go down one line and over eight bytes,
and that will take us to the start of our attribute data.
We can see this file is resident.
It's a very small file and it's able to fit right inside
the master file table record
and that would be a resident file.
Now let's go back up to the top and
take a look at Non_Resident.pdf.
Again, we have our attribute header
which starts with the ASCII Word file.
We can see file that tells you
you're looking at MFT file record.
The first attribute will
be the standard information attribute,
and this is what gives us all our times created,
modified, record changed, and last access.
Then we have our filename attribute,
and hexadecimal 30 indicates
a file name attribute has the length of the attribute.
The non-resident flag and this will be resident.
Then we have the data.
The start of our attribute.
We can see the file name down
here and it is Non_Resident.pdf.
Now we do have an attribute 40,
which is an object ID attribute,
which will give us right here
that globally unique identifier,
that GUID for the file.
That's an object ID attribute.
Just below that, working our way down,
we have our hexadecimal 80 attribute,
which is our data attribute.
Now this will either contain the data like
it did in our resident.txt,
or it'll tell us where the data is out on the drive.
We have the type of attribute,
the length of the attribute,
and our non-resident flag.
We can see our non-resident flag is 01,
that means our flag is flying and this is
a non-resident data attribute.
The data for this file is going to be out on the drive.
Just keep in mind, we're looking at file records.
These give us information about the file.
The data can be resident,
but most likely the data attribute will be non-resident,
unless you have a very small file that will fit.
Now we have to navigate
this attribute and find our data run.
We go two lines down to find
the location of our offset to the data run.
From the beginning of the attribute,
you go down two lines,
and that will tell you where the data run is located.
This gives us the offset to
the data run as hexadecimal 40.
That means four lines down from the start of
the attribute will give us our data run.
You count down one, two, three, four.
This is our first data run.
We can see it is a 2 and a 1.
Remember the data run header,
we have to split this byte into two nibbles.
The 1, the right side,
relates to the byte directly next to it,
directly to the right of it.
This indicates the size,
and in this case, it is one cluster.
It gives us the cluster count.
The 2 represents where the starting cluster is,
and we know it's two bytes long because it's a 2.
We knew the size was one byte long because it's a 1.
The 2 represents the next two bytes in the data run list.
These two bytes indicate where
the first cluster for this file is.
They're read little-endian.
I'm going to swipe them right to left,
and I'm going to look at my Data Interpreter.
I have a 16-bit,
and remember these are signed values.
It's a 16-bit signed value.
We have a number of 17,065.
Now I'm going to need my Windows calculator,
and I'm going to put in 17,065.
I'm just going to leave that be for now.
That's where it starts and it's one cluster long.
This is a part of it.
This file is fragmented.
We have four data runs here,
one, two, three, four.
This is our next data run.
The first byte is the data run header.
It tells us the length of the run.
We split it into two nibbles,
and 2 and 1 is 3,
so my data run is three bytes long.
The right nibble is a 1 that tells me
the size in clusters of my data run,
and that 1 refers to
the bytes directly to the right of it.
I have a 09 for a cluster count,
so this data run is nine clusters long.
Now let me look at the left nibble, it's a 2.
It tells me my starting cluster is two bytes long.
I look to the next two bytes in my data run,
and I read them little-endian.
I read it BF, BF.
That is a 16-bit signed integer.
When you have a signed integer,
it is possible to have a negative number if
the most significant bit is on.
With a B, the most significant bit
will be on because it's greater than eight.
My 16-bit signed value is negative 16,449.
I'm going to bring my calculator,
and I'm going to subtract 16,449.
That's going to give me 616.
When I look at my data run,
I can see, yes,
it is telling me the first part is in cluster 17,065,
and the second part is in cluster 616,
which is what I got when I translate it by data run.
That is where the second chunk of our file would
be and this run is nine clusters long.
Let's look at the next piece of our data run.
Again, I have my data run
header and again it is a two and a one.
The one represents the size and clusters
and it refers to the byte or bytes,
if that was a two, we will refer
to the two bytes to the right,
but it's a one so it refers to the one byte to the right,
which is the cluster count.
Just hexadecimal 10.
The two refers to
the starting extent where
I have to go next to find the piece of this file.
It says it's two bytes in length and I
know it's to the right of the length.
It's red little endian so this is 01, 5A.
When I translate 01,
5A is a 16-bit signed integer, I get 346.
We're going to bring our calculator and we're going to
add 346 to 616,
plus 346 equals 962.
Let's look at our tool.
Yes, it says 962 is where our next cluster is.
When you're reading a data run,
these values are relevant to the last piece of the file.
We started at cluster 17,065 for our first piece,
and we jumped backwards to 616.
Now we're jumping forward to 962,
and these are cluster numbers.
Each piece of the file is relevant to the last piece.
Now we go to our next and final piece of
our data run here and I have again a two and a one.
Split them into two nibbles,
add them together, I get a three.
I know my data run is three bytes long.
I know the one, the right nibble
refers to the size in clusters.
It is a one and it refers to
the byte directly to the right of it.
The cluster count here is 1D.
I need to translate 1D,
and I could see that it is 29,
so it's 29 clusters in my final chunk.
Now the two refers to
the two bytes to the right of the size in clusters.
Refer to these two bytes the CF and
the EE and they're red little-endian.
When I translate that to
a 16 bit because there are two bytes,
16 bit signed integer,
I get negative 305.
I bring up my calculator
again and we're going from the point we left
off at and we're going to minus 305.
[NOISE] That gives us 657.
We look at our last cluster,
cluster 657, and remember the length
was 29 clusters long.
Now, this is how we read the data runs.
If we were going to carve this file,
which we're going to do file carving in a later module,
we would need to find the beginning and
the end of each of these runs so that we
could carve each part of this file
out and put it back together,
because if you found
an unallocated MFT file record
and the data was not overwritten on the drive,
you could follow the data run and reconstruct your file,
and recover it that way.
We will do this one when we cover file carving.