Welcome!

Linux Containers Authors: Zakia Bouachraoui, Elizabeth White, Liz McMillan, Yeshim Deniz, Pat Romanski

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
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
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...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...