Linux Incident Response - EXT4 superblock basics

Overview

In EXT4 filesystems, the superblock is a fundamental component that contains the metadata needed for the filesystem to function.

The metadata includes details such as the filesystem's size, its configuration parameters including block size and the total number of blocks, and inode allocation information.

Essentially, the superblock enables the operating system to efficiently navigate, access, and manage the filesystem, acting as the blueprint from which the entire filesystem's structure is comprehended and interacted with. It is similar to a master index in a vast library system, offering immediate access to the whereabouts and specifics of every file and directory housed within.

Location

The primary superblock is located at offset 0x400 (1024 bytes) into the filesystem.

In addition, because the superblock is so important to how the filesystem works, there are backup superblocks. In the early days, there was a backup copy in every block group, but this changed a long time ago. In EXT4, it does depend on how the filesystem is created, but the most common is to use the sparse_super parameter which will create backups in block groups 0, 1 and each block group that is a power of 3, 5 and 7.

Layout

The superblock is 1024 bytes long.

Key elements

There are lots of interesting fields in a superblock, but for this article, I will highlight some of the ones we review most often during incident response.

Offset 0x00-0x04, Inodes Count. This is the total number of inodes (index nodes) available in the filesystem. This creates a hard limit to the maximum number of files that can exist.

In the example Superblock above, the inode count is shown as 0x00000200. This is in little endian, so the number is 0x00020000. This converts into 131072 using decimal notation.

Offset 0x05-0x08, Blocks Count. This is the total number of blocks available to the filesystem. This gives you an idea of how much space on the physical disk the filesystem occupies. EXT4 typically uses 4kb blocks, but this can be validated at offset 0x18.

In the example above, the block count is shown as 0x00000800 (little endian hex) which is 524288 blocks. This calculation can be confirmed with tools like fsstat:

Offset 0x18-0x0B, Block Size. This records the size of the blocks. This isn't in a simple integer (why should anything be simple?), rather it is a value that is used to calculate the block size.

There are a few approaches you can use to determine the blocksize value in bytes:

• Block size is 2 ^ (10 + [value])
• Bitwise "left shift", 1024 << [value]

In our example, the block size is 0x02000000 (little endian), or 0x2, which converts to a block size of 4096 bytes (4kb blocks).

Offset 0x58-0x59, Inode Size. This records the size of the inodes, in bytes. This is a simple translation as it is stored in little endian.

In the example image, the inode size is 0x0001 (little endian) or 0x0100 which is 256 in decimal.

Offset 0x78-0x87, Volume Name. This is the volume label assigned to the files system. It is important for things like maintaining chain of custody and validating that you have the correct object.

The contents are hex-encoded ASCII characters.

In the example evidence, the volume name is "Partition 3".

Offset 0x88-0xC7, Last Mount Point. The last field we will discuss here is the record of the last location where this filesystem was mounted. Again, this is a useful record of where the filesystem was last used and should be recorded in any evidence logs.

In the example used for this article, the filesystem was last mounted as /evidence somewhere.

Wrap up

This is a really quick look at a very few, basic, components of the EXT4 superblock. There is way more stuff than we can cover in this article but these are some of the areas we look at most often during DFIR.

It is important that any incident responders looking at a modern Linux system have an understanding of this, although it is worth noting that XFS has a very different structure.

Hopefully, you will simply use tools like TSK for most of your analysis but it is also good to be able to drop into the source and validate things. This also helps if you need to work in a constrained environment.