How to Recover Deleted Files with Linux using Sleuth Kit

I think that everyone has at least once delete a file that they shouldn’t have, either from a USB stick or from the recycle bin of their operating system, finding themselves in the unpleasant situation of no longer being able to undo the deletion.

What not everyone knows is that this is an operation that can be recovered within certain limits. If we deleted the file not long ago and the file system inode has not yet been reused by the operating system, we can get back the file.

In this post we assume you already know the notions about File System structure and files structures that we treat in a Command line image reader post.

I’ll consider a Linux environment but I think this is valid in Mac or also Windows if you use the same commands in WLS. If you need to restore files from a computer you can also consider to create a live USB key with Linux and Sleuth Kit installed.

Recover deleted files with Sleuth Kit

The magic can be done using The Sleuth Kit, a powerful collection of command line commands thought for investigate disk images. In particular we can use the commands fls to list deleted files of an image and icat to try to extract the desired file.

Let’s start installing the tools. In Debian or Ubuntu it can be done easily with:

apt-get install sleuthkit

and you can easily find the proceeding for other distros.

Now the interesting part. You may already know that in Linux, disks and partitions are accessible at the byte level as files. Typically, disks are represented by files like /dev/sda or /dev/sdb, while partitions appear as /dev/sda1, /dev/sda2, and so forth.

You can easily copy a disk or a partition using dd, which is included in the default set of Linux utilities, with a command like

dd if=/dev/sda of=/path/to/my/file bs=16MB

Here if is the input file, of the output file and bs the block size (to speed up the copy, otherwise the default is quite slow). Now we can work on this copy (but if you want you can work directly in the /dev/sdX file).

We can list the files marked as deleted in the allocation table using:

fls -d -r -p -l DEVICE > list.txt

where -d lists only deleted file, -r recursively list the directories, -p and -l give us useful information about files. In particular we also have the path of deleted file (that will allow us to recognize it) and the inode (the position of file in file system) that is fundamental to recover it with icat. Please note that you shouldn’t write the list in the disk or image where you are searching your deleted file to avoid to override it.

A tipical output of fls is similar to:

r/r 1234-128-1: /path/to/not/deleted/file01.jpg
r/- 1235-128-1: /path/to/deleted/file02.jpg

The r/r o r/- indicate ordinary and deleted files, the numbers like 1234-128-1 are the inode number of the file, let’s say its id number in the file system. If you delete the file, you are searching for r/- files (with the -d option you already see only r/- files).

Now with the inode of the file just try to extract it with icat. Since it write in the standard output you need to redirect its output:

icat -r DEVICE INODE > myfile.jpg

These commands can be put together in a script to make their usage easy. The script could take an image, an output directory and a file with a list of patterns to match, and use them in this way:

• take the list of deleted file in the image with fls and put it in a file
• for each file, if it match one of the desired patterns, recover with icat the file in the target directory

I did something similar during my PhD, but the script has some problems, so in this article I just propose the key commands.

File restore with damaged allocation table

In the previous paragraph we had a disk with a valid partition table. Sometimes it can be damaged and the previous commands would be ineffective. In this case you have to know exactly what you are searching for (e.g. JPG images, XML files) and a possible approach is to search the files using pattern matching in the images.

Each file has a specific header and footer. For example JPG header is 0xFF 0xD8 0xFF 0xE0 and JPG footer is 0xFF 0xD9. The idea is to search for the header and save the data between header and footer in a file. This is not easy, because a file is not necessarily saved in consecutive clusters, so the program can find the begin of an image but then part of it is stored somewhere else in the disk. This method is probably going to fail for large file, however for small files it should work well.

Conclusion

If you are reading this post probably you are trying to recover some important files so I hope you’ll manage to get them back from the limbo in which they fell. So far you should have come to the same mine conclusion: recovering files is not so easy, so pay attention to your actions and use good backup practices. If you have some problems and lose some file you can try the above methods, but in general it is better to prevent these situations.

Hope this help!