Recovery

Introduction#

Deleting a 4 GB file takes exactly the same time as deleting a 4-byte one.

This should make you suspicious.

If the system really overwrote the bits, a large file would take much longer than a small one.

The file system#

An ext4 file system separates two things.

The inode table stores each file’s metadata: the owner, the permissions, the dates, and the list of blocks where the data is.

The data blocks store the content.

When you delete a file, the system doesn’t touch the data blocks: it just marks the inode and the blocks as free.

That’s why deleting is instantaneous.

And that’s why the blocks still hold the file’s content until another file reuses them.

Since the inode has been lost, nobody knows which blocks belonged to that file.

Recovery tools solve this differently: they read the whole disk looking for patterns.

A JPEG starts with FF D8 FF and ends with FF D9, a PDF starts with %PDF.

This is called file carving, and it’s what photorec does.

Work environment#

Create an Ubuntu 24.04 Server virtual machine in Desktop.

You won’t work with the system disk: there’s too much activity and the result wouldn’t be repeatable.

Instead, you’ll make a fake disk — a 1 GB file that the kernel will treat as if it were a disk:

sudo fallocate -l 1G /disk.img
sudo mkfs.ext4 -L drive /disk.img
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 123e42a9-bf44-44c8-9895-0d269bc7c854
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376

mkfs.ext4 has written inside the file exactly the same structures it would write on a real disk.

Mount it:

sudo mkdir /drive
sudo mount -o loop /disk.img /drive
sudo chmod 777 /drive
df -h /drive
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop1      974M   24K  907M   1% /drive

Notice the name: /dev/loop1.

The kernel has created a loop device, a disk that’s actually a file:

losetup -a
/dev/loop1: [0041]:14231024 (/disk.img)