Welcome!

Linux Containers Authors: Pat Romanski, Carmen Gonzalez, Elizabeth White, Yeshim Deniz, Zakia Bouachraoui

Related Topics: Linux Containers

Linux Containers: 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)

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.


IoT & Smart Cities Stories
Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust tha...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Where many organizations get into trouble, however, is that they try to have a broad and deep knowledge in each of these areas. This is a huge blow to an organization's productivity. By automating or outsourcing some of these pieces, such as databases, infrastructure, and networks, your team can instead focus on development, testing, and deployment. Further, organizations that focus their attention on these areas can eventually move to a test-driven development structure that condenses several l...
The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...
Over the course of two days, in addition to insightful conversations and presentations delving into the industry's current pressing challenges, there was considerable buzz about digital transformation and how it is enabling global enterprises to accelerate business growth. Blockchain has been a term that people hear but don't quite understand. The most common myths about blockchain include the assumption that it is private, or that there is only one blockchain, and the idea that blockchain is...
Never mind that we might not know what the future holds for cryptocurrencies and how much values will fluctuate or even how the process of mining a coin could cost as much as the value of the coin itself - cryptocurrency mining is a hot industry and shows no signs of slowing down. However, energy consumption to mine cryptocurrency is one of the biggest issues facing this industry. Burning huge amounts of electricity isn't incidental to cryptocurrency, it's basically embedded in the core of "mini...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
The term "digital transformation" (DX) is being used by everyone for just about any company initiative that involves technology, the web, ecommerce, software, or even customer experience. While the term has certainly turned into a buzzword with a lot of hype, the transition to a more connected, digital world is real and comes with real challenges. In his opening keynote, Four Essentials To Become DX Hero Status Now, Jonathan Hoppe, Co-Founder and CTO of Total Uptime Technologies, shared that ...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Every organization is facing their own Digital Transformation as they attempt to stay ahead of the competition, or worse, just keep up. Each new opportunity, whether embracing machine learning, IoT, or a cloud migration, seems to bring new development, deployment, and management models. The results are more diverse and federated computing models than any time in our history.