Autopsy, windows image and no data

Apr 23, 2019

I'm new to forensics and I'm performing some tests with Autopsy and a Windows dump image.

It's a challenge. I am supposed to find relevant info. That's what I have found so far:

- $Logfile, $MFT and orphaned files.
- 2 JPG images.
- 2 txt files with the same name. One of them deleted and the other undeleted. Both with a size of 0 bytes and empty.
- A MS Word document password protected.

I have analyzed all the metadata, and the hex content of every file, but I can't find a clue. I have also digged into the images to see if there is any message hidden in them.
I think that maybe the text that once existed in the txts might help, but I am not able to recover it.

The data HAS to be somewhere, as it's a challenge. But I am lost. ¿Can you point me somewhere or shed some light on this?

Many thanks in advance!


New Member
Oct 30, 2018
Well...I'm a bit rusty on this, but my suggestion is you check the $MFT for contents of your missing text files. If the txt file was small enough, the entire contents may have been stored there. Even thought the file is deleted, it may still exist in the MFT slack.

To refresh my memory, I did a quick google search and found the following which lined up with what I was thinking & is a better explanation than I would've come up with.


What is resident data? Resident data is when the data for a file is within the MFT entry, rather than out in the rest of the file system.
Non-resident data is the exact opposite.
As the MFT entry is, as standard 1024 bytes long, and the metadata about the file, name, dates, etc, takes up around 500 bytes of space this means that there is 500 bytes of space in the MFT to describe the location of the file (i.e the data run). However if the file is less than 500 bytes (common examples are cookies) then the file system will place the file inside the MFT, rather than using data runs to decribe where it is.
On a normal PC the vast majority of data is non-resident.
Resident data can be particular interesting computer forensics examiners if the file is deleted and the resident entry then becomes MFT slack
Source: Forensics: Resident Data
The MFT can have slack, though it is slightly different to file slack. As the slack is within the MFT, rather than the end.
Slack, is briefly described as the “spare bit” at the end of the file – its the difference between the logical and physical file size.
An MFT entry is allotted a fixed space of 1024 bytes, as standard. If the MFT entry is less than 1024 bytes, e.g 1000 bytes, the remaining bytes are MFT slack. The contents of this MFT slack will depend, as with file slack, on what was there before it.
Commonly the MFT slack contains the contents of the MFT entry before it was created, this can be particularly interesting for computer forensic examiners if there was resident data.
A password list text file 200 bytes long would be resident within the MFT. If the text file was deleted and a new MFT entry created in its place, with not resident data, e.g. a PST file, then the resident data from the text file would remain as file slack. This means that a detailed examination would reveal the old password list, even though it had been deleted and long gone.
Its hard to identify MFT slack as slack as tools like FTK and EnCase do not show it as slack, and as its within the MFT itself, which can look complex enough. For this reason identifying slack from the MFT entry can be difficult. Therefore caution must be taken when assigning data within the MFT to a particular file or user.
Source: Forensics: MFT Slack
Apr 23, 2019
Hello, @BIOS

First of all, many thanks for your reply.

Indeed I have found some filenames ending in "-slack", and I don't know what they mean (I have to do a deeper read to your links).

I have opened my $MFT file with a hex viewer and I have searched for the name of the original file, with no result. I don't know if I'm missing something.

Many thanks again!

About us

  • Our community began in 2004. Since this time, we have grown to have over 29,000+ members within the DFIR & Cyber Security community.

    We are happy to announce that this forum is now under new ownership with the goal to once again become the main Digital Forensics Forum on the internet for DFIR, OSINT and Cyber Security.

    If you can think of ways to help us improve, please let us know.

    We pride ourselves on offering unbiased, critical discussion among people of all different backgrounds.

    We are working every day to make sure our community is one of the best.

Quick Navigation

User Menu