When I discuss my job with my detective friends or even people outside of work, they automatically assume my job solely consists of finding deleted files. While it is true my work may consist of recovering deleted files, it is but a small part. In addition to that, I don’t actually do that, my tools do. And thank goodness! But it is important as an examiner, we understand what and how our tools accomplish this. If we don’t, then we’re merely monkeys pushing buttons.
So what does happen? I like to use the analogy of a book. Deleting a file is akin to removing the entry of a table of contents. If the reader were to try and find something in the table of contents that was deleted it wouldn’t be there, yet, the information is still somewhere in the book. It didn’t go anywhere.
So then, what steps take place when you “delete” a file?
First, let’s look at a file as it exists. We have a physical drive with NTFS and a volume labeled “Deleted?”. Within that volume we have a folder labeled “Test_Files”:
Within the folder “Test_Files”, we have three files, with “Test_2.txt” being the object of our scorn:
Next, we can see the directory of the “Test_Files” folder. This is an entry in the $MFT, or Master File Table. Highlighted is the signature (FILE) showing it is in fact a file record, the name of the “file”, the index record ($I30), and the files in the index:
Next we can look at the file record of “Test_2.txt”:
There’s a lot of information packed in there. For the purposes of this post, we need to take note of two things specifically. The first is the “Sequence Number”. This is found at offset (from the beginning of the file) 0x10 for two bytes. “0x10” is hexadecimal and actually means “16” in decimal. Hexawut? We’ll get into that at a later time.
The “Sequence Number” shows as “01 00”. But, we would actually read this as “00 01” because it’s stored as Little Endian. In other words, the least significant bytes are stored first. Just put that in the back of your mind for now.
Next, we look at the “Flags” within the file record. These indicate its allocationnnessss.
This flag is located at offset 0x16, or the 22nd byte from the beginning of the file. We see that it is “01 00”. This would be read as “00 01”. In binary this would read as 00000000 00000001. The first bit isn’t referred to as the “1st” bit, but as the “0th” bit. In computers, we always start at 0, not 1. So, the “0th” bit is turned “on”. To get real technical, it’s a positive charge on a platter (HDD) or open gate (SSD). So, this “0th” bit is the flag for allocated or unallocated. In this instance, the “0th” bit is turned on, displayed as “1”, indicating is currently allocated, or in use. The “1st” bit, or second from the right, is turned off, indicating it is a file. Were it turned on, or displayed as a “1”, it would indicate this file entry represented a folder. Thus, we have an allocated file.
This allocated file contains resident data. This means, the data in the file takes up less space then is allocated for the file entry, which is 1024 bytes for NTFS. In this instance, the data is then stored in the actual $MFT entry. This is important, as were the data non-resident and resided elsewhere on the disk, there would more to discuss as it relates to the $Bitmap.
Now lets rid ourselves of this uncouth file who refers to itself as “Test_2.txt” and see the changes.
First, let’s look at $MFT entry for the folder in which the file was stored, “Test_Files”:
We can see here that the entry in the index record no longer exists. It has been overwritten. Next let’s look at the file itself:
As you can see, it’s still there. In addition, I didn’t just delete the file, I completed wiped it, created another “Test_2.txt” and then deleted it. Let’s see the differences now:
We can see the Sequence Number has been updated to “03 00” or 0x0003 because of my additional step. Had I just deleted the file as it were, it would have shown 0x0002. Also, we see the flags are set to 0x0000. This indicates the file is now unallocated. Eventually, this unallocated space will be filled with another file entry. But for the time being, the data is still there for us to recover.
So what didn’t I cover? Well, if the data was not resident in the $MFT entry, the $Bitmap would be updated. That can be a bit complicated. Thank goodness for tools.
I jumped ahead a bit in case you’re reading this and don’t even know what hexadecimal is. But, I wanted to get the whole “is it really deleted deleted” out of the way. I’ll dial it back next time and we can start with the basics.
Until next time!