7.1 Linux File Systems: ext2/ext3/ext4 Inode Architecture, Superblocks & Journaling Forensics

7.1 Linux File Systems: ext2/ext3/ext4 Inode Architecture, Superblocks & Journaling Forensics

Quick Answer: The Linux extended file system family (ext2, ext3, ext4) organizes disk partitions into Block Groups to minimize drive head movement and fragmentation. Every file system is governed by a Superblock located at byte offset 1024 (holding the magic number 0xEF53 at offset 0x38), replicated across select block groups for redundancy. In ext2/ext3, file metadata is stored in 128-byte inodes using 15 direct and indirect block pointers. In ext4, the default inode size expands to 256 bytes, introducing nanosecond timestamps (i_crtime/creation time) and an extent tree structure (magic 0xF30A) that maps up to 128 MB of contiguous blocks per extent. Journaling (ext3/ext4) uses the JBD2 subsystem across three modes: data=journal (both metadata and data logged), data=ordered (default, metadata logged after data write), and data=writeback (metadata logged without ordering). Deletion in ext4 wipes the extent records inside the inode, making journal parsing (jls/jcat/ext4magic) and raw carving vital for evidence recovery.

---

Extended File Systems Evolution (ext2, ext3, ext4)

The Second, Third, and Fourth Extended File Systems represent the dominant non-Windows storage architectures encountered during Linux endpoint and server forensic investigations.

---

Block Group Geometry and Physical Volume Layout

To prevent the severe disk fragmentation common in older monolithic Unix file systems, ext2/3/4 partitions are segmented into self-contained units known as Block Groups. Each block group manages its own data blocks, allocation tracking, and metadata structures.

+---------------------------------------------------------------------------------------------------+
|                                 EXT4 FILE SYSTEM LAYOUT                                           |
+---------------------------------------------------------------------------------------------------+
| Boot Block | Block Group 0         | Block Group 1         | Block Group 2         | Block Group N |
| 1024 Bytes | (Superblock + GDT...) | (Backup / Data ...)   | (Data / Inodes ...)   | (...)         |
+---------------------------------------------------------------------------------------------------+

The Boot Block (Offset 0 to 1023)

The first 1024 bytes of any ext2/3/4 partition are reserved for the x86 PC Master Boot Record (MBR) bootstrap code or bootloaders such as GRUB Stage 1. Even if the file system uses 4096-byte blocks, Block 0 contains this 1024-byte reserved space, and the primary Superblock begins immediately at byte offset 1024.

Internal Anatomy of a Block Group

Each block group contains a standardized series of control blocks followed by general data cluster storage:

+---------------------------------------------------------------------------------------------------+
|                                BLOCK GROUP INTERNAL STRUCTURE                                     |
+-------------------+--------------------+--------------+--------------+-------------+--------------+
| Superblock Backup | Group Descriptors  | Block Bitmap | Inode Bitmap | Inode Table | Data Blocks  |
| 1 Block (if pres) | GDT Blocks         | 1 Block      | 1 Block      | N Blocks    | N Blocks     |
+-------------------+--------------------+--------------+--------------+-------------+--------------+

1. Superblock: 1024 bytes holding global volume metadata. Stored in Block Group 0, with redundant backup copies in select groups.
2. Group Descriptor Table (GDT): An array of descriptors defining the exact starting block addresses of the Block Bitmap, Inode Bitmap, and Inode Table for every block group across the entire volume.
3. Block Bitmap: Exactly 1 block in size. Each bit represents one physical data block in the current block group: 0 = free / unallocated, 1 = allocated.
4. Inode Bitmap: Exactly 1 block in size. Each bit tracks the allocation status of an entry in the group's Inode Table: 0 = free inode, 1 = active/allocated inode.
5. Inode Table: A contiguous array of data blocks containing the fixed-size inode structures (typically 256 bytes each in ext4) allocated to this group.
6. Data Blocks: The remaining physical storage space in the block group, holding user file content, directory entries, symbolic links, and indirect/extent tree index blocks.

---

The Superblock: Magic Bytes & Backup Locations

The Superblock is the foundational metadata structure of the Linux file system. If the superblock becomes corrupted, the operating system kernel cannot mount the partition.

Critical Superblock Fields and Offsets

[!IMPORTANT] CHFI Magic Signature Rule: The 2-byte magic identifier for all Second, Third, and Fourth extended file systems (ext2, ext3, ext4) is identically 0xEF53 located at byte offset 0x38 within the Superblock. When examining raw sector data in a hex editor, this appears as the byte sequence 53 EF.

Backup Superblocks & Sparse Superblock Feature (sparse_super)

In early ext2 implementations, a full copy of the Superblock and Group Descriptor Table was mirrored into every single Block Group, consuming immense storage. Modern ext3 and ext4 volumes enable the sparse_super feature by default.

• Under sparse_super, redundant backup copies of the Superblock and GDT are stored only in Block Group 0, Block Group 1, and block groups that are powers of 3, 5, and 7:
  • Group 0 (Primary Superblock, offset 1024)
  • Group 1 (First backup)
  • Group 3, 5, 7
  • Group 9 (3^2), 25 (5^2), 27 (3^3), 49 (7^2), 81 (3^4), etc.
• Forensic Recovery Scenario: If an adversary or disk corruption zeroes out Block Group 0, an investigator can recover the entire file system by executing dumpe2fs or fsstat against a backup group, or mounting the volume specifying an alternate superblock:

# Locate backup superblock positions using mke2fs dry-run
mke2fs -n /dev/sdb1

# Mount the damaged volume using an alternate superblock located at block 32768 (Group 1)
mount -o sb=32768 /dev/sdb1 /mnt/recovery

# Run e2fsck with an alternate superblock to restore metadata consistency
e2fsck -b 32768 -y /dev/sdb1

---

Inode Architecture: 128-Byte vs. 256-Byte Structures

In Linux, the file name and physical file data are completely decoupled. The file name is stored exclusively in a directory entry, while all file metadata, ownership permissions, timestamps, and data block pointers reside in an Index Node (Inode).

128-Byte Inode (ext2 / ext3) vs. 256-Byte Inode (ext4)

+---------------------------------------------------------------------------------------------------+
|                         EXT4 256-BYTE INODE STRUCTURE                                             |
+---------------------------------------------------------------------------------------------------+
| Mode, UID, Size, Timestamps | Links | i_blocks | i_block Array (60 Bytes) | Extra 128-Byte Space  |
| Bytes 0x00 - 0x27           | 2B    | 4B       | 15 Ptrs OR Extent Tree   | crtime, ns timestamps |
+---------------------------------------------------------------------------------------------------+

i_mode File Type Bitmask Decoding

Forensic investigators determine the exact nature of an artifact by masking the upper nibble of i_mode (bytes 0x00 - 0x01):

• 0x8000: Regular File (S_IFREG)
• 0x4000: Directory (S_IFDIR)
• 0xA000: Symbolic Link (S_IFLNK)
• 0x6000: Block Device (S_IFBLK)
• 0x2000: Character Device (S_IFCHR)
• 0x1000: FIFO / Named Pipe (S_IFIFO)
• 0xC000: Unix Domain Socket (S_IFSOCK)

---

Timestamps & Timestomping Analysis in Linux

Linux file systems track MACB timestamps differently than Windows NTFS:

[!TIP] Linux Timestomping Anomaly: An attacker using the touch -d "2020-01-01 00:00:00" malware.sh command can backdate atime and mtime. However, the execution of the touch command itself alters inode metadata, forcing the Linux kernel to immediately set ctime to the current system time. If an investigator observes an mtime years prior to the ctime, or discovers that crtime (birth time) is newer than mtime, timestomping is definitively proven.

---

Block Addressing: Indirect Pointers vs. Extent Trees

+---------------------------------------------------------------------------------------------------+
|                         BLOCK ADDRESSING MECHANISM COMPARISON                                     |
+---------------------------------------------------------------------------------------------------+
| ext2/ext3: 15 Pointers (60B) -> [Direct 0-11] [Single Indir 12] [Double Indir 13] [Triple Indir 14]|
| ext4:      Extent Tree (60B) -> [Header: Magic 0xF30A, Depth, Count] [Leaf Extents: Block, Len, PBN]|
+---------------------------------------------------------------------------------------------------+

1. Legacy ext2/ext3: The 15 Pointer Array (60 Bytes)

The 60-byte i_block field holds fifteen 32-bit (4-byte) disk block addresses:

• Pointers 0–11 (Direct): Point directly to data blocks. For 4 KB blocks, holds files up to 48 KB (12 * 4 KB).
• Pointer 12 (Single Indirect): Points to a block containing 1,024 block pointers (4 KB / 4 B = 1,024 blocks = 4 MB).
• Pointer 13 (Double Indirect): Points to a block holding 1,024 single-indirect pointers (1,024 * 1,024 = 1,048,576 blocks = 4 GB).
• Pointer 14 (Triple Indirect): Points to a block holding 1,024 double-indirect pointers (1,024 * 1,024 * 1,024 = 1,073,741,824 blocks = 4 TB).

2. ext4: Extent Tree Architecture (0xF30A)

To eliminate the massive overhead and fragmentation of indirect block pointers for large multi-gigabyte files, ext4 replaces pointers with Extents. An extent represents a single contiguous run of physical disk blocks (up to 32,768 contiguous blocks = 128 MB per extent).

The 60-byte i_block field in ext4 begins with an Extent Header followed by up to 4 Extent Records:

struct ext4_extent_header {
    __le16  eh_magic;       // Magic number: 0xF30A
    __le16  eh_entries;     // Number of valid entries following header
    __le16  eh_max;         // Capacity of entries in this node (4 in inode body)
    __le16  eh_depth;       // Depth of tree (0 = leaf node; >0 = index node)
    __le32  eh_generation;  // Generation number
};

Extent Structures: Leaf vs. Index

• If eh_depth == 0, the header is followed by struct ext4_extent records (Leaf Nodes pointing to real data blocks):
  • ee_block (4 bytes): Logical file block number.
  • ee_len (2 bytes): Number of contiguous blocks (values <= 32768 are initialized; values > 32768 are uninitialized/preallocated).
  • ee_start_hi (2 bytes) & ee_start_lo (4 bytes): 48-bit physical block address.
• If eh_depth > 0, the header is followed by struct ext4_extent_idx records (Index Nodes pointing to external extent index blocks).

Binary Analysis of an Extent Record

Suppose raw hex analysis of an inode's i_block field (offset 0x28) yields: 0A F3 01 00 04 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 10 00 00

1. Magic Signature: 0A F3 -> In little-endian, this is 0xF30A (Ext4 Extent Header validated).
2. Entries: 01 00 -> 1 valid extent entry follows.
3. Max Entries: 04 00 -> Maximum 4 entries can fit in the inode's 60-byte space.
4. Depth: 00 00 -> Depth is 0, confirming this is a direct leaf node.
5. Leaf Extent Analysis (00 00 00 00 20 00 00 00 00 10 00 00):
   • ee_block: 00 00 00 00 -> Logical block 0 (file start).
   • ee_len: 20 00 -> Little-endian 0x0020 = 32 contiguous blocks.
   • ee_start_hi: 00 00 -> High bits 0.
   • ee_start_lo: 00 10 00 00 -> Little-endian 0x00001000 = Physical block 4,096.

• Conclusion: The file occupies 32 contiguous blocks (128 KB for 4KB blocks) starting at physical block 4,096.

---

Directory Structure & Deletion Mechanics

In ext4, directories are structured as linked lists of directory entries (ext4_dir_entry_2) contained within data blocks:

struct ext4_dir_entry_2 {
    __le32  inode;          // Inode number pointing to file metadata
    __le16  rec_len;        // Total length of this directory entry record
    __u8    name_len;       // Length of file name string
    __u8    file_type;      // File type: 1=Regular, 2=Directory, 7=Symlink
    char    name[];         // UTF-8 file name string (null-terminated/padded)
};

The Deletion Mechanics Discrepancy: ext2/3 vs. ext4

Understanding how files are deleted across Linux file systems is a high-yield CHFI exam topic:

+---------------------------------------------------------------------------------------------------+
|                         EXT3 VS. EXT4 DELETION FORENSIC ARTIFACTS                                 |
+---------------------------------------------------------------------------------------------------+
| Feature                 | ext2 / ext3                       | ext4                                |
| Inode Allocation Bit    | Cleared to 0                      | Cleared to 0                        |
| Inode Block Pointers    | Preserved in inode (Recoverable)  | Cleared to 0 (Extent header wiped)  |
| Deletion Timestamp      | i_dtime recorded                  | i_dtime usually set to 0 or unused  |
| Directory Entry Record  | rec_len expanded over entry       | rec_len expanded over entry         |
| Primary Recovery Path   | Pointer carving via TSK icat      | JBD2 Journal carving / Raw Carving  |
+---------------------------------------------------------------------------------------------------+

• In ext2 and ext3: When a file is unlinked, the OS sets the Inode Bitmap bit to 0, decrements i_links_count to 0, and logs i_dtime. Crucially, the 15 block pointers in i_block remain completely untouched. Forensic tools like TSK icat or ext3grep can immediately reconstruct deleted files.
• In ext4: When a file is unlinked, the kernel's ext4 driver deliberately zeroes out the 60-byte i_block field (destroying the 0xF30A extent header and all block mappings). As a result, standard inode-based file recovery fails completely on ext4. Recovery requires JBD2 journal analysis or raw file carving.
• Directory Slack Carving: In both ext3 and ext4, the directory entry is unlinked by increasing the rec_len of the preceding valid directory entry to absorb the deleted entry's record space. The deleted file name, length, and original inode number remain intact in directory slack space until a new file entry overwrites that specific directory block.

---

Journaling Forensics: The JBD2 Subsystem

Ext3 and ext4 implement fault-tolerant journaling using the Journaling Block Device (JBD / JBD2) driver. The journal is stored internally as a dedicated pseudo-file, almost universally assigned to Inode 8.

The Three Journaling Modes

Forensic acquisition of files depends heavily on how the Linux system administrator mounted the file system:

JBD2 Binary Block Types

The journal operates as a ring buffer. Every journal block starts with a 12-byte header holding the JBD2 Magic Number 0xC03B3998:

• JBD2_DESCRIPTOR_BLOCK (Type 1): Follows a transaction start. Contains an array of tags mapping journal blocks to their eventual physical block destinations on the root file system.
• JBD2_COMMIT_BLOCK (Type 2): Written after all transaction blocks are flushed. Validates that the atomic transaction completed successfully.
• JBD2_SUPERBLOCK_V1 / V2 (Type 3 / 4): Identifies journal geometry, block size, and head/tail transaction sequence numbers.
• JBD2_REVOKE_BLOCK (Type 5): Lists data blocks that were freed or reassigned during a transaction, instructing the replay engine to ignore older journal records for those blocks.

---

Practical DFIR Tool Workflows: The Sleuth Kit (TSK)

Forensic examiners rely on The Sleuth Kit (TSK) command-line utilities to parse raw Linux disk images without mounting them (which would risk altering metadata).

# 1. fsstat: Inspect file system geometry, block group counts, and journal inode
fsstat -o 2048 /dev/sdb1
# Output highlights: Block Size: 4096, Inode Size: 256, Magic: 0xEF53, Journal Inode: 8

# 2. istat: Inspect specific inode metadata, nanosecond timestamps, and extents
istat -o 2048 /dev/sdb1 131075
# Displays: File Type: Regular, Permissions: 0755, UID: 0, Size: 18432 bytes
# Extent Tree: Depth: 0, Entries: 1, Block: 0 -> Length: 5, PBN: 524288

# 3. fls: List directory contents recursively, displaying deleted files (*)
fls -o 2048 -r -p -d /dev/sdb1
# Output: * d/d 131080: /home/victim/.malware/payload.sh (deleted file entry in slack)

# 4. icat: Carve raw data content of an inode directly to an analysis workstation
icat -o 2048 /dev/sdb1 131075 > /cases/evidence/recovered_artifact.bin

# 5. jls: Display transaction block lists from the ext4 journal (Inode 8)
jls -o 2048 /dev/sdb1 8

# 6. jcat: Extract specific transaction blocks from the JBD2 journal
jcat -o 2048 /dev/sdb1 8 412 > /cases/evidence/journal_tx412.bin

[!NOTE] In corporate incident response, tools such as ext4magic automate the recovery of recently deleted ext4 files by cross-referencing unlinked directory entries with JBD2 journal transactions, successfully extracting file copies before journal ring buffers wrap around.