Recovering Deleted Files on Linux with The Sleuth Kit and an ext4 Disk Image
Deleted does not always mean gone, and that is exactly what makes filesystem forensics so useful for Linux users, lab builders, and anyone trying to better understand how data actually lives on disk.
The demo here focuses on a safe, practical workflow using The Sleuth Kit on Parrot OS to inspect an ext4 disk image and work through deleted file recovery in a way that is methodical instead of reckless. This is not about poking around blindly or mounting a disk image and hoping for the best. The real value is in understanding the sequence of tools, what each one tells you, and how to avoid contaminating evidence or confusing yourself halfway through the process.
What this workflow is really about
The lab shown is centered on recovering deleted files from an ext4 image using The Sleuth Kit, often shortened to TSK. The approach is hands-on and aimed at Linux users and hobbyist forensics work, so the emphasis is on learning the process.
A big theme in the demo is that recovery is not just about getting bytes back. It is also about:
- verifying what you downloaded
- documenting what you are working on
- identifying the correct partition
- confirming the filesystem type
- enumerating active and deleted files
- inspecting metadata before extracting content
That order matters.
Why The Sleuth Kit fits this job
The Sleuth Kit is one of those classic forensics toolsets that keeps showing up because it is practical and script-friendly. For Linux users especially, it gives you a way to inspect disk images and filesystems without treating the evidence like a normal mounted volume.
In this demo, the point is not to use every feature TSK has. The point is to use the right tools in the right order so you can answer basic but important questions:
- What kind of image am I dealing with?
- Where is the partition I care about?
- Is the filesystem actually ext4?
- What files can I enumerate, including deleted ones?
- What does the inode metadata tell me?
- Can I carve out file content safely for review?
That is a much better workflow than skipping straight to recovery and hoping your assumptions were correct.
Why Parrot OS was part of the setup
The environment used for the demo is Parrot OS, along with an install note for The Sleuth Kit. The source material does not go deep into distro comparisons, so the safe takeaway is simply that Parrot OS was used as a practical platform for the exercise.
That matters because one of the easiest ways to derail a lab is inconsistency in your environment. If you are following a similar process, using a system where your forensic tooling is readily available can save time and cut down on troubleshooting.
Start with a workspace, not with recovery
One of the smartest parts of the process is the early focus on creating a workspace and downloading the image before doing any analysis.
That sounds basic, but it is a habit worth keeping. Recovery work gets messy fast if you do not have a dedicated working directory for:
- the downloaded archive
- the extracted disk image
- recovered output
- notes and case documentation
- checksums and verification results
Keeping everything organized from the beginning makes it easier to reproduce your steps later and easier to explain what you did if you are documenting a case or even just learning for yourself.
Verify the archive before you touch the image
This is one of those steps newer Linux users skip all the time, and they really should not. The demo explicitly includes verifying the archive with a checksum and then extracting the image.
That verification step matters because if your archive is corrupted, incomplete, or altered, every conclusion you draw later becomes questionable. You do not want to spend time chasing weird filesystem behavior only to discover the image itself was bad.
Gotcha: do not skip checksum verification
This is the first big mistake to avoid.
If you download a forensic image and skip checksum verification, you are trusting that the file is intact before you even begin. In a lab, that can waste your time. In real work, that can undermine your documentation.
The video also reinforces documentation and case notes later on, which ties directly back to this point. Verification is not just a technical step. It is part of your chain of confidence.
Inspect the image before assuming anything
Once the image is extracted, the next step in the workflow is to inspect image metadata with img_stat.
This is a good example of disciplined analysis. Instead of immediately trying to list files, you first ask the image what it is. That gives you a baseline understanding of the evidence container you are about to examine.
From there, the process moves to mmls to review the partition table and identify the correct offset.
The partition offset matters more than people think
If there is one place where beginners get tripped up in disk image work, it is the partition offset.
The demo specifically calls out using mmls to inspect the partition table and pick the offset. That is critical because many later commands depend on you targeting the correct filesystem location inside the image.
If you aim tools at the wrong place, you can end up with confusing output, invalid filesystem interpretation, or what looks like missing data when the real problem is simply that you pointed the tool at the wrong offset.
Gotcha: the wrong offset makes good tools look broken
This is probably the most practical mistake in the whole workflow.
If mmls shows you where the partition starts and you ignore that detail, your later fsstat, fls, istat, or icat results may not make sense. That does not automatically mean the image is damaged or the recovery failed. It may just mean you are not working from the right partition boundary.
When a tool gives strange or empty results, double check the offset before assuming anything else.
Confirm the filesystem with fsstat
After identifying the partition, the workflow uses fsstat to verify the filesystem and confirm it is ext4.
This is another example of doing the quiet foundational work first. File recovery gets easier when you stop guessing and confirm exactly what filesystem logic you are dealing with.
That matters because deleted file behavior can differ depending on filesystem structure and how metadata is maintained. The demo is specifically about ext4, so staying grounded in that filesystem context is important.
Enumerate files, including deleted entries
Once the image and partition are understood, the process moves into file listing with fls, including both full and deleted file enumeration.
This is where the lab starts to feel more tangible. You are no longer just confirming structure. You are discovering what the filesystem still knows about files that were deleted.
For hobbyist forensics and learning labs, this is a very useful moment because it shows that deletion is often a metadata event before it becomes complete physical loss. Depending on filesystem state, some information may still be available for review.
Inspect metadata first with istat
A really important boundary in the demo is the use of istat to inspect inode metadata.
That fits the caution note included with the video. The process highlighted there was metadata inspection and documentation, not opening or viewing potentially illegal content. That distinction matters.
Metadata can still tell you a lot:
- inode details
- allocation state
- timestamps and file characteristics
- clues about whether content recovery is still possible
This is a good reminder that not every investigation starts with opening a file. Sometimes the metadata is the safer and more appropriate first step.
Recover content with icat when appropriate
After inode inspection, the workflow demonstrates carving content with icat.
That gives you a direct way to extract file content associated with a specific inode, which is especially useful when you have already identified a target through file listing and metadata review.
The key thing here is sequence. The process does not start with indiscriminate extraction. It starts with understanding the image, the partition, the filesystem, the file listing, and the inode. That makes the extraction more deliberate and easier to explain.
ext4 deleted inode behavior is part of the lesson
One section of the demo specifically demonstrates deleted inode behavior on ext4. Even without line-by-line transcript detail, the important takeaway is clear: deleted file recovery on ext4 is tied closely to how inode metadata behaves after deletion.
That is one reason this kind of lab is so valuable. It helps you see that recovery is not magic. It depends on what metadata remains available and whether the underlying data blocks have been reused or altered.
If you are learning file recovery, this is the kind of practical concept that sticks much better when you see it demonstrated against a real image.
Use tsk_recover for triage
The workflow also includes tsk_recover for folder-style triage.
That is useful when you need a broader recovery pass instead of targeting one inode at a time. It gives you another angle on the image and can help build out a recovered working set for review and documentation.
The word triage is important here. This is not presented like a magic one-click solution. It is part of a larger process. You still need to know what you are recovering, from where, and how you are recording your steps.
Documentation is not optional
One of the final sections focuses on documentation and case notes, including checksums.
Honestly, this is where a lot of home lab work can level up. It is easy to think note-taking is only for formal investigations, but even in personal labs it pays off.
Good notes help you remember:
- where the image came from
- how it was verified
- which partition offset you selected
- what tools you used
- what files or inodes you examined
- what you recovered and where you saved it
If you ever revisit the exercise later, you will be glad you wrote it down.
A practical and responsible reminder
The safety note attached to the demo is worth repeating in plain terms: metadata inspection and documentation are very different from browsing potentially illegal material.
That is an important line to keep in mind if you are exploring forensic tooling. Preserve evidence. Be careful. And if you are doing real-world work involving potentially criminal material, handle it appropriately and involve legal authorities where necessary.
What this demo teaches Linux users
The biggest value here is not just that deleted files can sometimes be recovered from ext4. It is that Linux users can approach the problem in a structured way.
The flow shown is practical:
- create a workspace
- download the image
- verify the archive with a checksum
- extract the image
- inspect image metadata with img_stat
- examine the partition table with mmls
- select the correct offset
- verify the filesystem with fsstat
- enumerate files with fls
- inspect inode metadata with istat
- carve content with icat when appropriate
- triage with tsk_recover
- document everything
That is a solid mental model for beginners and a good refresher for anyone who has not touched forensic tooling in a while.
If you are working through your own Linux labs, the biggest lessons to keep are simple: do not skip verification, do not guess the partition offset, and do not treat recovery like a random fishing expedition. A little structure goes a long way.
Catch you in the next one.
~ KeepItTechie