Introduction to Forensic Data Recovery
by Paradox
Recently while traveling in Cuba, I had the unfortunate luck of having an entire week's worth of photos inadvertently deleted from my digital camera's memory card.
These photos were obviously not something I could have recreated and I hadn't yet been able to copy them off of the card onto the computer. Was all lost? No! By employing some basic computer forensics skills and some Linux kung-fu I was able to recover all of the lost photos.
First things first, we need to learn about what happens when you "delete" a file from a digital system like a computer, cellphone, camera, etc. While many hold the naive notion that a delete is final and that the bits go to the big /dev/null in the sky, it probably won't come as a surprise to many of you that this isn't the case at all.
While each filesystem handles deletion differently in technical implementation, the concept they utilize is the same. When you delete a file from the storage medium where your filesystem is located, the bits that your data is stored in are simply marked as "unused."
Deletion by the definition of the word tends to imply an "overwriting" or "zeroing" procedure, i.e. actually getting rid of the data. Actually zeroing the bits that hold your to-be-deleted data would be a time intensive procedure; especially when you start to consider deletion of large files.
The "mark as unused" solution accomplishes the same thing as far as the operating system is concerned; the data will eventually be overwritten by new data that is written to disk. This "eventually" clause is what we can exploit to save our data.
The first, and arguably, most important thing to take away from this over-simplified lesson on file deletion is that you must immediately disable writing to the device you wish to recover from. Operating systems and device firmware are complex and very large programs. They are constantly writing things to disk without your intervention. Background processes are swapped to disk, log files are being written to, and all sorts of data is being persisted. This all happens without your express desire!
As mentioned, after deleting a file, the space it occupies is free game for anything that comes along needing disk space. Therefore, if a log file happens to be created immediately after you delete your file, there is a chance that some of that log file's data will end up overwriting your deleted file.
Thus the only way to be sure that your deleted data will remain in an uncorrupted and recoverable form is to immediately exit the operating system, shut down the device, pull the plug, eject the disk, and otherwise ensure that the device remains in a read-only state for the rest of this tutorial.
Now that we have the device in a state where we feel confident that no new data can be written to it, it would be wise to make an exact copy instead of working with the original. Since our deleted files are marked as free space at this point, we can't just mount the device as read only and use trusty old cp to copy our deleted files off. Instead, we need to create a byte-for-byte copy of the device including all of the free space, since our deleted data is tucked away somewhere in there.
To do this, we'll use the Linux dd command. This command comes installed with every modern distribution of Linux I have ever encountered, and will surely be installed on yours. My recommended procedure is to download and burn the Knoppix Linux Live CD. This has several benefits, most importantly: Knoppix will mount any applicable filesystems it finds on the computer as read-only by default. This is prefect for our purposes since we don't want to accidentally write any data to the device.
Once you have booted into the Knoppix environment we need to find the Linux device name of our target device and the partition number. In the case of my camera it was /dev/sdb1. Serial device B, partition 1.
I found this by running:
Obviously if you are searching for a non-USB device you would exclude the usb* section of the command that filters the results.
Once we have the Linux device name we can begin creating an image of the disk.
First, make sure you have enough free space on a write-enabled device to store the disk image. The disk image will be the same size as the total capacity of the device we are trying to recover from. Since I was recovering images from a 1 GB Memory card, I needed to make sure I had ~1 GB free on my computer's hard drive.
To begin the imaging process enter the command:
In my case, I ran:
This imaging process may take awhile depending on the size of the disk partition you are imaging.
In my case, it took approximately 15 minutes. Once the image process is complete, you can safely remove the device from your system and store it in a safe place. With our disk image in hand we can perform the recovery from any Linux machine.
Now while the tool we are planning to use to recover our data can work out-of-box with a dd image, some tools can't. If you are planning to use a tool that wants to work with the filesystem itself then you'll want to mount this dd image as a "loopback" device.
To do that you would run:
In my case, I ran:
Make sure that your mount location exists before running this command.
In my case if the diskfiles folder didn't exist, the mount will fail.
We can now run our recovery tool to scrape out as many files as we can from the free (i.e. deleted) space of our device.
The tool we are going to use is called Foremost.
It is a very simple to use tool that was originally created by the U.S. Air Force and later made open-source and public. It has the ability to recover a few common filetypes automatically. These types include images, executables, documents, movies, etc.
It supports EXT3, FAT, and NTFS filesystems, so chances are that your device will be supported.
More information on the tool can be found at the website provided at the end of this tutorial.
On a Debian system it was just a matter of running the following command to install Foremost.
We are now ready to recover our files.
If you know the specific type of file you wish to recover you can save time by telling Foremost to only recover that type.
In my case I knew my camera saved the images as JPEG files. So I ran:
If you wanted Foremost to try and recover all types of files it could (this may take a long time) you would run:
The -t argument is what tells Foremost which kind of files you want to recover. For instance if you wanted to recover Office-type documents such as PPT and DOC you would use -t ole.
Consult the documentation to find out which file-type flags are supported.
Again, it is important that the output folder exists before you run Foremost.
Once it has finished you will have hopefully recovered the data you were looking for to the recovery folder you specified. There is however one more hurdle to jump before you can find out. Foremost (like most of the tools we've used so far) can only operate as root. As such the output files it generated are also owned by root.
To fix this we'll chown them to our user:
In my case, that meant running:
You can now change directories into your recovered folder.
You'll find an audit text file in the root of your recovered folder outlining what Foremost was able to recover. Most importantly though, you will find all of the recovered files organized into folders by type.
In my case I found all 75 of my missing JPEGs in the /home/daniel/recovered/jpg/ folder. Hopefully you found your files too!
This tutorial should serve as a good starting point for your journey into understanding computer forensics. Advanced topics exist to supplement your knowledge.
For instance, Foremost is limited to specific filetypes. If you want to recover other files you may have to resort to using advanced software like Autopsy and The Sleuth Kit, but these require a deeper understanding of computer forensics.
Undoubtedly you will find that the concepts you learned in this tutorial will serve you well if you attempt to further your knowledge.
Resources