Use the Hexdump tool to track a file in the EXT4 file system

Yesterday, the process of tracking EXT4 file system A bit of a problem, is to find the file, so try to trace the FAT32 file system, after success has a bit of confidence, today continue to take EXT4 file system, finally found, record a bit.

• Operating system: Linux (CentOS 6.5)
• File system: EXT4
• Tools: Hexdump,windows with Calculator
• Bibliography: "Data reproduction-best practices for Document System principles and data Recovery" (Marin), a series of blogs titled "EXT4 File System Architecture Analysis", does not know who the original is.

EXT4 File System Architecture:

　　

Additional note: The location of the Super block and block group descriptor of block No. 0 in the EXT4 file system is fixed, and the other is not fixed. Where the Super block always starts at an offset position of 1024 (bytes), occupies 1024 bytes, the Block group descriptor is followed by the Super block and occupies a variable size.

Steps:

1, check the basic situation of the file system, new subdirectories and files

　　

You can see that the file system type mounted in the/boot directory is EXT4, so create a new subdirectory and file under the directory:

The contents of the file are: "This test was belong to Boot folder!" The basic information of the file is as follows:

2, look at the Super block, find the block number No. 0, block size, the number of blocks per block, each block I nodes, the first non-reserved i node, each i node size.

Command: hexdump-s 1024-n 1024-c/dev/sda1

View results:

First you can see that 0x38-0x39 is the signature sign of the EXT series file system: "The EF"

0x14-0x17 is the NO. 0 block group starting block number: 0x01, which indicates that a block in front of the super block is a reserved block, which is used to store the bootstrapper.

0X18-0X1B is a block size: 0x00, where the value refers to the number of bits shifted to the left of the 1024 byte, moving 0 bits is 1024 bytes, moving one is the equivalent of multiplying by 2, or 2048 bytes.

0x20-0x23 is the number of blocks per block: 0x2000 (decimal 8192)

0X28-0X2B is the number of I nodes per block: 0x07f0 (decimal 2032)

0X54-0X57 is the first non-reserved i node number: 0x0b (11), typically Lost+found directory

0x58-0x59 is the size of each I-node structure: 0x80 (decimal 128), which means that each I-node table entry occupies 128 bytes.

3. View Block Group Descriptor table, find block bitmap block, I-node bitmap block, I node tables starting block number, block group directory number.

Command: hexdump-s 2048-n 1024-c/dev/sda1

View results:

Each block group in a block descriptor table is described by 32 bytes, so the first 32 bytes are described as Block No. 0.

0X00-0X04 is block bitmap block starting block number: 0x0104

0X05-0X07 is the I-node bitmap block starting block number: 0x0114

0X08-0X0B is the I node table starting block number: 0x0124

0x10-0x11 is the number of directories for this block group: 0x02

The starting block number obtained here is the logical block number (incrementing all blocks of the file system from 0), so you can multiply the offset by the number of bytes per block (0x400, which is the decimal 1024).

3. Find subdirectories from the root directory

In the first step we mentioned the first non-reserved i node number is 11, then the previous 10 Reserved I node function is what is (I node number starting from 1 number), here only the node 2nd is stored is the root directory I node number, so we read the table of I node 2nd table key value can be found in the root directory block number.

The offset of the calculated I node table entry involves the I node table starting block number in the Block Group Descriptor table: 0x0124.

　　An I node table entry start byte =i node start block number * Bytes per block + (the I node number-1) * Number of bytes per I node table entry

　0x0124*0x400+ (0X02-0X01) *0x80=0x49080

The root I node table key value can be read below.

Command: hexdump-s 0x49080-n 128-c/dev/sda1

View results:

0xa8-0xd7 is a 12 direct block pointer, where four bytes is a unit representing a block number.

The figure shows that the root directory occupies only one block, the block number is: 0x1104

The starting offset byte of the root directory is the block number that contains the root directory * The number of bytes per block

The starting offset byte of the root directory: 0x1104*0x400=0x441000

Use the command: Hexdump-s 0x441000-n 1024-c/dev/sda1 to view the contents of the root directory:

View the files in the/boot directory:

We can see that the content of the two matches, which means we are looking for the right one. The Bootdir entries in the root directory are marked with black shading.

0X6C-0X6F is the content of the file I node number: 0x7f01

0X70-0X71 is this catalog item length: 0x10 (16 bytes)

0X72 is this directory item name length 0x07 (7 bytes)

0x73 is this file type: 0x02 (for Table of contents)

0x74 start is the filename of the Ascci code: "4f 4f 54 44 49 52 00"

In this step there are two differences from the FAT32 file system:

　　One is how to find the root directory. FAT32 in the root directory at the beginning of the data area, so we can go directly to the data area to read, and EXT4 file system, we need to find the root directory by the 2nd I node table in the block number, in order to see the root directory content, here can be seen EXT4 file system directory also as a file, Because his reading and ordinary files are the same, but ordinary files need to get the I node number from the directory, and the root directory is the first set up the I node number.

The second is the size of the directory. The size of the directory in FAT32 is fixed (the short file name directory occupies 32 bytes, the long file name directory occupies more than 32 bytes), so when the file name is too long, the long file name mechanism is used to solve, and the EXT4 file system's directory item size is flexible in the directory entry. For example, in this step we look at the root of the results, the beginning of the 12 bytes is this directory entry, followed by 12 bytes is the root entry, and we are looking for the length of the target directory entry is 16 bytes, where the description section (I node number, this directory item length of bytes, name length, file type) occupies the same, The difference is in the file name section. But we also see that there is always a "00" after the file name, because the length of the catalog item is always a multiple of 4, so it is not enough to use 0 to complete.

4. Find the block number of the subdirectory from the I node table

In the third step we find that the I node number that points to the subdirectory is 0X7F01, which is also the logical I node number, so we first find out which block group the 0X7F01 is in:

　　Block group of an i node = the i node number/number of nodes per block I

0x7f01/0x7f0=0x10 (decimal 16)

　　I node of an I node table number = The I node number% per block I node number

0x7f01%0x7f0=0x01

So 0x7f01 is in table 16th of the I node of block group, in table 1th of the table of I node changed.

Next we will find the starting block number of the I node table for block 16th in the Block Group Descriptor table to find the block number of the subdirectory.

　　A block group in the Block Group Descriptor Table Offset byte = Block Group Descriptor start byte + block Group number * per block descriptor number of bytes

2048+16*32=2560 bytes

We read 2560 offset bytes starting at 32 bytes:

You can see: 0x08-0x0b is the I node table starting block number: 0x020021

Read the number 1th I node table entry value in block 16th I node table:

From 0x28-0x57 is 12 direct block pointers, read in 4 bytes, some of which point to the Super Block (0x01). The block that the 0x21002 points to stores the subdirectory contents.

Offset byte of the BLOCK: 0x8400800

5. Get the target file block number from the I node corresponding to the sub-directory

View the results of the 4th step sub-Directory block content:

The black shading is in this catalogue (".") ) and root directory ("..") Next is the target file: BOOTTEXT.txt, whose i node number is: 0x7f04

To view the I node table, locate the block number of the target file:

The offset byte for the I node table entry is: 0x020021*0x400+ (0x7f04%0x7f0-1) *0x80=0x8008580

Read the 128-byte content starting at the offset byte:

The resulting target file contains the block number 0x024005 (the offset byte is 0x9001400) and the block content is read:

I got it! and the contents of the file viewed in the first step using the Cat command.

Use the Hexdump tool to track a file in the EXT4 file system