Linux File System Analysis and Linux File Recovery: EXT2/3/4 Techniques Using Debugfs, Ext4magic & Sleuth Kit

When you're digging into Linux systems, especially during live forensics or incident response, understanding file system behavior is crucial. The ext4 file system is commonly used, and knowing how to read file timestamps properly can give you a solid edge in an investigation.

Let's break it down in a very real-world,

🔹 1. Basic ls -l — Let’s Start Simple

When you run:

ls -l

You get a list of files along with a timestamp. That timestamp? It’s the modification time (mtime). That’s the default.

If you're like me and wondering,

"What if I want to see when a file was last accessed or changed in metadata?", then you’ve got options.

🔹 2. Customize the Time Display (atime, ctime, etc.)

Use --time= to get the info you care about:

ls -l --time=atime   # Shows last access time
ls -l --time=ctime   # Shows inode change time

Note: ctime is not "creation time" (confusing, I know). It's the time when metadata (permissions, ownership, etc.) changed.

Want to know what time options ls supports? Just check:

man ls

🔹 3. Can We See File Creation Time on ext4?

Now here’s where it gets interesting — and a bit annoying.

ext4 can support birth time (aka creation time), but not all Linux distros expose it by default via normal tools. Some versions of ls, stat, or even the filesystem itself may not record it.

So how do we go deeper? That’s where the magic of debugfs comes in.

🔹 4. stat Command — Detailed File Info

Quick and handy:

stat <filename>

You’ll see Access, Modify, Change times and creation time as well . But again, Sometimes no creation time. Sad life 😅.

🔹 5. Using debugfs to Dig Deeper (Finding Birth Time or Inode Info)

When you’re doing live response and the system won’t give you birth/creation time using stat, this is your go-to:

sudo debugfs -R "stat <file path>" /dev/<device>

⚠️ You need the device name where the file system is mounted.

How to find the device name?

Use:

df or df -h

Sometimes you might find something like /dev/sdc or /dev/mapper/ubuntu--vg-root if LVM is used.

Also check /etc/fstab:

cat /etc/fstab

This shows all persistently mounted devices, useful when the system uses LVM or /dev/mapper.

Sometimes it’ll look like:

/dev/disk/by-id/dm-uuid-LVM-...

✅ Example Use Case:

Let’s say I want to check creation time for /var/log/syslog.

Run:

sudo debugfs -R "stat /var/log/syslog" /dev/sdc

Boom! You'll now see:

• Inode

• Size

• Access time

• Modify time

• Change time

• Creation time (if available!)

This is not the same stat command we used earlier. This one is a debugfs internal command.

🔹 6. Using debugfs in Interactive Mode

You can drop directly into debugfs with:

sudo debugfs /dev/sdc

Once inside, you’re in a shell-like environment. Just run:

stat /home/akashpatel/arkme

No need for -R here — you're already inside.

🔹 7. Want Inode Number First?

Sometimes, you want to grab the inode of a file before using debugfs. You can do this:

ls -i /home/akashpatel/arkme

Now if you’ve got an inode like 123456, and you're inside debugfs, just run:

stat <123456>

Or even:

cat <123456>

(Yeah, cat also works in debugfs!)

🔹 Pro Tips:

• Always double-check you’re using the right device — especially with forensic images or LVM setups.

• debugfs is super powerful, but read-only usage is safest in live forensics (avoid writing to the file system!).

• If you get errors running debugfs, make sure the device isn't actively in use or try accessing a mounted image instead.

In a nutshell:

Command	What It Shows
ls -l	mtime (default)
ls -l --time=atime	Access time
ls -l --time=ctime	Metadata change time
stat	mtime, atime, ctime, crtime(sometimes)
debugfs -R "stat <file>" /dev/...	Shows all 4 timestamps including birth time (if supported)
debugfs (interactive)	Explore with inode numbers, use stat, cat, etc.

-------------------------------------------------------------------------------------------------------------

Lets Suppose

You accidentally delete a super important file on a Linux system running an ext2/ext3/ext4 filesystem.

The panic hits, right? But don’t worry—I’ll walk you through how to recover it using a mix of tools like debugfs, ext4magic, and Sleuth Kit.

🧰 1. Recover Deleted Files Using debugfs (Works Best on EXT2)

If the filesystem is ext2, then debugfs is your best buddy.

It's got this neat command called lsdel that lists recently deleted files.

🔧 Basic Workflow

• Launch debugfs:

sudo debugfs /dev/sdX
Replace /dev/sdX with your actual device (e.g., /dev/sdc).

• List deleted files:

lsdel
Or:
list_deleted_inodes

You’ll get inode numbers of deleted files. Pick the one you want.

• View inode details:

stat <inode_number>

• Preview content (yes, you can peek!):

cat <inode_number>

• Recover the file:

dump <inode_number> /desired/output/path/

💡 Heads-up: This method is mostly for ext2 filesystems.

Why? Because ext3 and ext4 clean up the data blocks after deletion, which makes recovery harder directly.

-------------------------------------------------------------------------------------------------------------

🧠 2. Recovery on EXT3 and EXT4 (Using Journal + ext4magic Tool)

Now here’s where it gets a bit more interesting. With ext3/ext4, things aren’t that simple because once a file is deleted, the inode is wiped out.

But all hope isn’t lost—we go after the journal.

🔒 Journal’s Inode is Always 8

Yup. To grab the journal:

debugfs /dev/sdc
dump <8> /path/to/save/journal.dump

🚀 Use ext4magic for Real Recovery

This tool is specially made to deal with journal-based recovery.

Install it if you haven’t:

sudo apt install ext4magic

🛠️ Basic Command:

sudo ext4magic /dev/sdc -j /path/to/journal.dump -m -d /path/to/recovery_folder

Flags explained:

• -j: Path to journal dump file

• -m: Recover ALL deleted files

• -d: Where to store recovered files

• -a or -b: Time-based filtering (after/before a specific time)

🎯 Example: Recover files deleted in the last 6 hours

ext4magic /dev/sdc -a "$(date -d "-6hours or -7days" +%s)" -j journal.dump -m -d ./recovered

💬 This gives you super fine control over what to recover. It’s way better than randomly guessing.

Recovered Files

-------------------------------------------------------------------------------------------------------------

🔍 3. Sleuth Kit Magic – Inspect and Recover Like a Forensics Expert

If you’re digging into a disk image, maybe from a compromised system or raw forensic capture, you’ll want to mount it and go deeper.

🧱 Mount the Image (Linux or WSL)

sudo mkdir /mnt/test
sudo mount -o ro,loop /path/to/linux.raw /mnt/test

Now run:

df

Note down the mounted device name (e.g., /dev/loop0 or /dev/sdc).

🔎 Key Sleuth Kit Commands

1. fsstat – Filesystem Overview

sudo fsstat /dev/sdc

2. fls – List Deleted Files (and More!)

sudo fls -r -d -p /dev/sdc

• -r: Recursive

• -d: Deleted entries

• -p: Show full path

3. istat – Inode Metadata

sudo istat /dev/sdc <inode_number>

4. icat – View File Content by Inode

sudo icat /dev/sdc <inode_number>

Perfect for checking the content of deleted files even if they don’t show up in the normal file tree.

🌀 Filesystem Journal Analysis with Sleuth Kit

Sometimes, you want to peek into journal entries directly. Here’s how:

1. jls – List Journal Blocks

sudo jls /dev/sdc | more

2. jcat – View Journal Block Content

sudo jcat /dev/sdc <block_number>

This is raw, low-level stuff—but crucial when traditional recovery methods fall short.

-------------------------------------------------------------------------------------------------------------

📦 Bonus: File Carving with photorec

If you’re like “Just give me all the lost files!”, then photorec is your hero.

Install it:

sudo apt install testdisk

Run it:

sudo photorec

Just point it to your image or device, choose the file types you want to recover, and it does the rest. It’ll carve out all files it finds—even if directory info is gone. (Very Simple just follow the commands it shows)

🔍 Final Tip: Search Within Recovered Files

Once you recover everything, you might want to search for a specific string, like an IP address or username:

grep -Rail -a "192.168.1.10" ./recovered

The -a treats binary files as text, which is super helpful during deep dives.

✅ Wrapping Up

So, whether you’re on a forensic case or just accidentally nuked your presentation file, these tools have your back.

Just remember:

• Use debugfs for ext2.

• Use ext4magic + journal for ext3/ext4.

• Use Sleuth Kit for image-based investigation.

• And photorec when you’re ready to say “Recover ALL the things!”

-------------------------------------Dean---------------------------------------------------