Page 2 of 2   « previous page

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

• Carrier, B. "The Sleuth Kit": www.sleuthkit.org
• Carrier, C. (2005). File System Forensic Analysis. Addison-Wesley.
• Crane, A. "Linux Ext2fs Undeletion mini-HOWTO." February 1999: http://tldp.org/HOWTO/Ext2fs-Undeletion.html
• Diedrich, O. "e2undel": http://e2undel.sourceforge.net/
• Farmer, D., and Venema, W. (2004). Forensic Discovery. Addison-Wesley.
• Heavner, S.D. "Linux Disk Editor": http://lde.sourceforge.net/
• Kendall, K.; Kornblum, J.; and Mikus, N. "Foremost": http://foremost.sourceforge.net/
• Ts'o, T. "E2fsprogs": http://e2fsprogs.sourceforge.net/
• Tweedie, S. "EXT3, Journaling Filesystem." July 2000: http://olstrans.sourceforge.net/release/ OLS2000-ext3/OLS2000-ext3.html

Page 2 of 2   « previous page