Cyber Forensics using FTK Imager. Indexing and deleted files recovery.
Learn how files are indexed in the MFT and how to search the NTFS file system. Discover how to recover deleted files.
In my previous article I discussed the interface of the FTK Imager tool and talked about various files of NTFS, a widely used tool in Cyber Forensics.
In this guide I will show how the files are indexed and the various important offset numbers in $MFT file. Also, I will show how we can combine the fragments of a file (e.g., mp4, mp3, exe, apk, txt, ppt, etc.) to reassemble the source file.
1.Various offset in $MFT file
What is offset?
Offset is just a position of the hexadecimal values in FTK Imager. Let’s see an example:
The above snapshot is the snapshot of 1st sector of the MFT file, which is of 512 bytes. The size of the sector is always 512 bytes. The size of the cluster changes, according to what you have chosen at the time of formatting the disk (min size of a cluster is 4096 bytes, also known as allocation unit size). That we have discussed in the previous article. Above snap is the $MFT file’s 1st sector, and it will be same in everyone’s disk which is having NTFS file system.
IMPORTANT: The $MFT file is an index that stores information about all the files and folders on its respective volume. This information is organized in the form of records. Every file of that volume is having a record in $MFT file and these records are of 1024 bytes which are sequentially stored in the sectors of the volume. Remember that this $MFT is a file, stored sequentially and not broken into fragments unlike other files. It occupies all the clusters and doesn’t leave any RAM slack. 1024 bytes (2 sectors) are used to store the records as a safeguard, allowing the record to be extended if the size of the file in the record increases in the future.
Now your question would be if the file is of 2GB then how its record would fit in 1024 bytes?
The answer is simple, the records of the files are stored in hexadecimal form, which contains the addresses of the clusters where each particular file is located. So, if a 2GB file is fragmented into four parts and those fragments are stored in different clusters, the record will store the addresses of those four clusters in hexadecimal format. I will demonstrate all of this practically in this blog.
The above two snapshots show the 1024-byte record (equivalent to 2 sectors) of the $MFT file. In the $MFT file, the first record always corresponds to the $MFT file itself. The second sector is empty because there aren't enough files in my logical volume to fill more of the $MFT records. However, the record will extend to another sector if I add more files to the volume, making it impossible to map everything within 512 bytes.
2. Let’s see the record of another file in the volume
The above two snapshots are showing the record of one of the tools of from Microsoft pslist.exe. If I search for this name in FTK imager like shown below:
There might be more than one entry, depending on whether the file is located in a folder or not. If the file is in a folder, then during search you will likely find one of the entries within the folder, since the folder is also indexed in the $MFT file. Therefore, the same name could appear in that record. However, we are looking for the record specific to this file, so make sure that at the beginning of its record, there is 'File0'. As you can see in the snapshot below:
IMPORTANT: Offset number always starts with 0 in a record and therefore goes to 511 in a sector. Also, the Hexadecimal values might be changed in you device, so take the reference from the example I am using only for this blog and use it accordingly in your device. Also, the word Attribute will be used a lot in the table below, which means that the information regarding the file is stored in various sections of record. Each section shows different information regarding the file. And these sections is known as Attributes.
Record begins
Now let’s see the various offsets (the position), their hexadecimal values (what hexadecimal value is present at that position) and what does it means with respect to record:
Let’s discuss the Serial no. 14 of above table
64th offset of attribute 0x80 00 00 00 is 0x41 2C AB CA EC 04 00 00 |
In our case, we have 0x41. The first part will contain only one hexadecimal value (0x2C), and the second part will contain four hexadecimal values (0xAB CA EC 04). Interpreting the first part gives us 44 in an unsigned integer. Interpreting the second part gives us 82,627,243 as a signed integer. We use a signed integer for the second part because, if the file is fragmented, the relative cluster position is given by the second part. If it is negative, it means that the fragment of the file is present in that number of clusters before the current cluster position. If it is positive, it means the fragment of the file is present in that number of clusters after the current cluster position.
However, this file is not fragmented since it is not that large. So, we have the position of only one cluster. If there were fragments, you would repeat the same process with the hexadecimal values, breaking them down into two parts, and so on.
The value of the first part is 44, but this is not the actual length. We need to convert this 44 into bytes. My cluster is 4,096 bytes, so I will multiply 4,096 by 44: 4,096 x 44 = 180,224 bytes. From the second part, you infer that the starting cluster of the file is 82,627,243 from the beginning of the volume cluster. From the first part, you infer that 180,224 bytes from that cluster position belong to this file (pslist.exe).
3. How to find the file in the cluster?
Click on NONAME[NTFS] you will be able to see the 0th cluster and 0th sector.
Click on 0th offset and press Ctrl+S to open Go to sector/cluster dialogue box. In the input box of cluster type 82627243 and press ok then type 180224 as shown in below snapshot. Then your cursor will be positioned at the beginning of the cluster.
There press right click and select the option Set selection length. Then type 180224 as shown in below snapshot and press ok.
Right Click on the selected part and select the option Save Selection. As shown in below snapshot:
Fill the File Name with extension. In this case I will write the name pslist.exe in filename, choose the path where you want to store. Press enter. The same file will be saved there. Now I can run the file through command prompt. There will be no error, because the file is same. If your file is fragmented then save the fragments in one directory and then run the command copy /b [fragments name separated by spaces] filename.extension. The fragments will be combined together and the same file will be ready to use again there.
4. Retrieving permanently deleted file from FTK Imager
To retrieve the deleted file, do the following:
- Attach the logical volume/image of any drive as evidence item.
- From the Evidence Tree, open the directory from where the file got deleted.
- Check the File List, you would be able to see the file marked with “cross” in front of it.
- Right click on it and chose Export Files option.
- Select the path where you want to save.
- Click OK. The file is retrieved.
In the snapshot below the file pslist.exe is deleted permanently from my logical volume. Click on it and export it to retrieve.
The file can only be retrieved until you have not written anything in that volume. Once you re-write that volume the deleted file cannot be retrieved again from FTK Imager.
Conclusion
In this blog, we've explored the intricacies of file indexing and cluster allocation in NTFS through the use of FTK Imager, a vital tool in cyber forensics. We explored into how files, including fragmented ones, are stored and retrieved by interpreting hexadecimal values and cluster addresses from the $MFT file. By understanding the offset positions and utilizing appropriate calculations, we've shown how to reassemble fragmented files and recover deleted files, even after they've been marked for deletion.
The processes detailed in this guide—whether for reconstructing large, fragmented files or recovering permanently deleted files—demonstrate the powerful capabilities of FTK Imager in forensic investigations. However, it's crucial to act swiftly, as overwriting data on the volume can render file recovery impossible. By applying these techniques, forensic investigators can efficiently piece together digital evidence and restore crucial data in cases involving fragmented or deleted files.