Welcome!

Linux Authors: Greg Akers, Liz McMillan, Michelle Drolet, Elizabeth White, Richard Moulds

Related Topics: Linux

Linux: Article

Why Recovering a Deleted Ext3 File Is Difficult . . .

and why you should back up important files

The file we are trying to recover is /home/carrier/oops.dat and we can see it previously allocated to inode 415,926. The "(28)" shows us that the directory entry structure is 28 bytes long, but we don't care about that.

File Carving Recovery
The first recovery technique, called file carving, uses signatures from the deleted file. Many file types have standard values in the first bytes of the file header, and this recovery technique looks for the header value of the deleted file to determine where the file may have started. For example, JPEG files start with 0xffd8 and end with 0xffd9. To recover a deleted JPEG file, we would look at the first two bytes of each block and look for one with 0xffd8 in the first two bytes. When we find such a block, we look for a block that has 0xffd9 in it. The data in between are assumed to be the file. Unfortunately, not all file types have a standard footer signature, so determining where to end is difficult. An example of an open source tool that does file carving is foremost and there are several commercial options as well.

We can run a tool like foremost on the full file system, but we'll probably end up with way too many files, including allocated ones. We therefore want to run it on as little data as possible. The first way we can restrict the data size is to examine only the block group where the file was located. Remember that inodes and blocks for a file are allocated to the same block group, if there is room. In our case, we know which inode the file used and therefore we can examine only the blocks in the same group. The imap command in debugfs will tell us to which block group an inode belongs:

debugfs: imap <415926>
Inode 415926 is part of block group 25
    located at block 819426, offset 0x0a80

The output of the fsstat command in TSK would also tell us this:

# fsstat /dev/hda5
[...]
Group: 25:
   Inode Range: 408801 - 425152
   Block Range: 819200 - 851967

We next need to determine the blocks that are in the block group of the deleted file. We can see them in the previous fsstat output, but if we're using debugfs , we'll need to calculate the range. The stats command gives us the number of blocks in each group:

debugfs: stats
[...]
Blocks per group: 32768
[...]

Since we are looking at block group 25, then the block range is from 819,200 (25 * 32,768) to 851,967 (26 * 32,768 - 1). By focusing on only these blocks, we are looking at 128MB instead of the full file system. Although if we can't find the file in these blocks, we'll still need to search the full file system.

The next step to reduce the data we analyze is to extract the unallocated blocks from the file system because that is where our deleted file will be located. debugfs does not currently allow us to extract the unallocated space from only a specific block group, so we will need to use the dls tool from TSK.

# dls /dev/hda5 819200-851867 > /mnt/unalloc.dat

The above command will save the unallocated blocks in block group 25 to a file named /mnt/unalloc.dat. Make sure that this file is on a different file system because otherwise you may end up overwriting your deleted file.

Now we can run the foremost tool on the unallocated data. foremost can recover only file types for which it has been configured. If foremost doesn't have the header signature for the type of the deleted file, you'll need to examine some similar files and customize the configuration file. We can run it as follows:

# foremost -d -i /mnt/unalloc.dat -o /mnt/output/

The -d option will try to detect which blocks are indirect blocks and won't include them in the final output file. The /mnt/output/ directory will contain the files that could be recovered. If your file is not in there, you can expand your search to all unallocated blocks in the file system instead of only the blocks in the block group.

Journal-Based Recovery
The second method for trying to recover the files is to use the journal. We already saw that inode updates are first recorded in the journal, but the important concept here is that the entire block in which an inode is located is recorded in the journal. Therefore, when one inode is updated, the journal will contain copies of other inodes stored in the same block. The previous version of our deleted file's inode may exist in the journal because another file was updated before the deletion.

The easiest way to look for previous versions of the inode is by using the logdump -i command in debugfs:

debugfs: logdump -i <415926>
Inode 415926 is at group 25, block 819426, offset 2688
Journal starts at block 1, transaction 104588
  FS block 819426 logged at sequence 104940, journal block 2687
   (inode block for inode 415926):
   Inode: 415926 Type: regular Mode: 0664 Flags: 0x0
   User: 500 Group: 500 Size: 2048000
   [...]
   Blocks: (0+12): 843274 (IND): 843286
[...]

In this case, we found a previous copy of the inode and the file content blocks are listed on the last line. The last line shows that the first block of the file is 843,274 and the next 12 blocks in the file system are the next 12 blocks in the file. The file is large and requires an indirect block, which is located in block 843,286. So far, all blocks are consecutive and there was no fragmentation. Block 843,286 contains the rest of the block addresses, so we should try to look at a previous version to learn where the rest of the file is located. We can see if there is a copy in the journal using logdump -b:

debugfs: logdump -b 843286 -c

Unfortunately, we don't find a copy of the block that contains the original list of block pointers so, if we want to recover the file, we need to assume that the remaining file content is stored in block 843,287 and onward. A more advanced approach would also consider which blocks are currently allocated and skip over those. The data can be extracted with tools such as dd or the Linux Disk Editor. The journal can also be searched using the jls and jcat tools from TSK.

Conclusion
File recovery with Ext3 is not a trivial matter, which reinforces the concept of making backups of important files. If the file was not fragmented, then searching for its header signature can be useful, but the tool needs to know to ignore the indirect blocks and where to stop copying (not all files have a standard footer signature). Restricting the search to the local block group can help save time. The journal could be useful if files near the deleted file were recently updated and a previous version of the inode existed, but this is not always guaranteed and the file's indirect block may not exist.

References and Bibliography

More Stories By Brian Carrier

Brian Carrier has authored several leading computer forensic tools, including The Sleuth Kit (formerly The @stake Sleuth Kit) and the Autopsy Forensic Browser. He has authored several peer-reviewed conference and journal papers and has created publicly available testing images for forensic tools. Currently pursuing a Ph.D. in Computer Science and Digital Forensics at Purdue University, he is also a research assistant at the Center for Education and Research in Information Assurance and Security
(CERIAS) there. He formerly served as a research scientist at @stake and as the lead for the @stake Response Team and Digital Forensic Labs. Carrier has taught forensics, incident response, and file systems at SANS, FIRST, the @stake Academy, and SEARCH. He is the author of File System Forensic Analysis (Addison-Wesley, ISBN 0321268172).

Comments (6) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
theusr 07/09/09 09:29:00 AM EDT

The figure 2 maybe misleading: the links between the address blocks and the file content are still there (though the address blocks are unallocated), that what's make the recovery possible.

Mike Kay 01/15/08 03:57:07 PM EST

Excellent article. Followed it step by step and successfully recovered a .XLS spreadsheet that had been deleted from the /tmp folder on Ubuntu Gutsy. It also found an associated .jpg that I wasn't looking for!

Saved me hours of retyping. Thanks a lot.

Jahangir 10/22/07 05:26:36 PM EDT

This was really the best article i could find inspite of 3 hrs of googling.

But what if you are trying to recover a 6GB VM.
Since VMware files are not recognized by foremost, how can we get the magic number to get the header for the VM files ??

ruintower 04/23/06 09:07:29 PM EDT

Trackback Added: ext3 undelete;   I “mis-deleted” a big file several days ago. So I umount the the partition immediately and searched the recovery method because I knew (but forgot) some methods to recovery file in Linux. However, the result is disappointed. Alt...

marco 03/13/06 08:04:20 AM EST

U have saved my life.
I had lost all my application files under tomcat with de deploy command... no backup ..gulp
now I have a 128MB ascii file with my lost files, it's great.

U are a GURU,
thanx

marco 03/13/06 08:04:04 AM EST

U have saved my life.
I had lost all my application files under tomcat with de deploy command... no backup ..gulp
now I have a 128MB ascii file with my lost files, it's great.

U are a GURU,
thanx