The Avid Coder

Well as the lengthy title of this article indicates, this will be my attempt to give an overview of how to recover deleted files from an Ext3 partition. First off let me say that it is not at all easy to recover deleted files from an Ext3 file system. If you are primarily a Microsoft Windows user you might not even know what the Ext3 file system is and if you have any file recovery experience on the Windows platform you might also be asking yourself why I am making any fuss about deleted file recovery. After all on Windows it is mostly easy. You download some piece of software, like R-Studio NTFS, and then you click here and there and its done. Some of you might recall recovering deleted files on an Ext2 file system. If so you will probably have noticed that it is not really much more complicated than recovering files on Windows. Unfortunately there is a big difference in the way files are generally deleted on the Ext3 file system when compared to other file systems.

With the FAT or NTFS (with NTFS I am speaking under correction) when files are deleted they are simply marked as deleted in whatever data structure holds the primary file entries. No actual data of the file is overwritten until the operating system decides to do so, when you are copying new files on the partition, for instance. The very important thing here is that not all of the meta data pertaining to the deleted file is removed from the file allocation table (in the case of the FAT file system). Links to the location and size of a deleted file remain behind, even after it has been deleted. In the Ext2 file system the situation is similar.

The Ext file system consists of blocks, block groups, inodes and directory entries. Blocks are generally span a couple of consecutive sectors. A bunch of consecutive blocks form a block group. When a file is created it will be allocated all of the blocks that are needed to store the file. The OS will try to allocate the blocks and block groups of the file consecutively, but this will not always be possible. The meta-data of a file, the creation and modified time, size and pointers to blocks containing the actual data are stored in inodes. Inodes are found in the inode table located at the beginning of a block group. Lastly there are directory entries for all directories, listing the names of the files, and their associated inodes, that are stored in the directory. Directories in Ext file systems are handled much like files.

The difference between Ext2 and Ext3, when it comes to file deletion, is that when a file is deleted in Ext2 it also basically only marked as deleted. Its block groups are now free to be allocated to other files. The inode of the file still contains its size and the address of its start block. In the Ext3 file system the size and address fields in the inode of a file are cleared upon deletion. Thus there is no way to no exactly where the file starts or how large it is. Note that the entry for the file is still in the directory entry of its parent directory. Thus the filename is linked to the inode. So we can find the inode of the file, but we do not now its size nor its start block and other indirection blocks used to store addresses for blocks of the file. Using a tool called debugfs can find out what the inode of a deleted file is. We can also find out to what block group the inode belongs. To actually recover the file we must use a forensic analysis tool to analyse the raw data close to where the file was located (by reading all of the blocks in the block group of the inode of the file). A program called foremost is such a tool. It can scan data looking for header or start of file patterns of known file formats, such as JPEG or AVI. The difficulty with such a tool, despite the fact that it is time consuming, is that it not all file formats have specific end-of-file patterns. Thus the tool will not be able to easily detect when the file ends. Furthermore the tool must also be able to detect indirect blocks (blocks storing continuation addresses of fragmented files) while it is reading the potential file data and skip over it.

Let us look at an example. For this example we will use Foremost and The Sleuth Kit (TSK). We will delete an existing file called ‘test.jpg’. We delete the file and start by using debufs to find the inode of the file.

# debufs /dev/sda5

debugfs 1.41.1 (01-Sep-2008)

debugfs: cd /test

debugfs: ls -d

So what we do is run debugfs on the drive that we deleted the file from. Then we change to the directory that contained the deleted file using debugfs. Finally we execute the command ls -d in debugfs. This lists everything in the folder including the deleted files with their inodes. Deleted file inodes are displayed as ‘<1234567>’. In our case the inode of the file ‘test.jpg’ is <2835097>. The next step is to find out to which block group the inodes belong. Once we have the block group number we can find the actual block range of the block group. Using the ‘imap’ command in debugfs we can get some information about an inode, including the block group it belongs to:

debugfs: imap <2835097>

Inode 2835097 is part of block group 346

located at block 11337750, offset 0x0c00

So now we know that the block group containing our deleted file is block group 346. We can now use a tool called fsstat, from TSK, to determine the range of blocks that span block group 346:

# fsstat /dev/sda5

Group: 346:

Inode Range: 2834433-2842624

Block Range: 11337728-11370495

…

Here we are interested in the block range. In this case it is 11337728-11370495. What we need to do now is write the contents of the unallocated blocks in the block range out to a file on another partition and then scan those blocks with foremost and hope it finds our file. We can write the blocks out using another tool from TSK called dls:

# dls /dev/sda5 11337728-11370495 > /temp/recovery.dat

All that remains is to run foremost on the file /temp/recovery.dat and then we must hope that it finds our file:

# foremost -vd -t jpg -i /temp/recovery.dat -o /temp/output

Here I use the ‘-vd’ flags to indicate that I want verbose output and that we are using a Unix-based file system. The next flag, ‘-t jpg’,  means that I am looking to extract JPEG files. The ‘-i /temp/recovery.dat’ specifies the input file and ‘-o /temp/output’ specifies the output file.

The process I have described works sometimes and sometimes it does not. It really depends quite a bit on if you have used the file system since you deleted the file or not, but sometimes we are just unlucky.

Luckily there is an open source set of scripts available that makes using tools like debugfs and foremost much simpler. Ext3Undel simplifies this process into two scripts: ralf and gabi. Ralf follows the process we described, it searches the local block group of an inode with a tool like foremost for a file type specified by the user. The user can give the file name and its parent directory with the file type as parameters and ralf will try and recover it. This often fails. In such situations the gabi script can be used. It is similar in that it also uses foremost to search for files of a specified type, the difference is that it searches the entire free space area of a partition and outputs all matching files to a specified target directory (must be on a different partition than the one you are trying to recover a file from).

Most of my knowledge regarding this is from the following article: Why Recovering a Deleted Ext3 File is Difficult… It is a bit more in-depth than what I discussed but the conclusion is the same: do not accidentally delete files on an Ext3 parition! If you do, do not write to the drive at all, and immediately try and recover the file. If it is a small file you should be able to get it back. If the file is large you will probably get a corrupted version back or you will not be able to get it back at all.