Extended File System

From Digital Forensics Framework

Jump to: navigation, search

This module purpose is to analyse Linux Extended File Systems. It is able to recover deleted files and put some hidden data in evidence.

Contents

Brief history of EXT

Historically, Extfs was designed in 1992 by the French developer Remy Card. It is the first file system specifically developed for Linux, after limitations on the Minix file system, also called Minixfs, were observed.

Among them we can cite :

  • The size of partitions was limited to 64 MB.
  • File names could not be longer than 14 bytes.

Indeed, Minixfs had been conceived in an educational purpose, by Andrew S. Tanenbaum. From the very beginning it was not meant to be used on large systems.

Extfs found his inspiration in the traditional UFS (Unix File System) and consequently uses the same kind of meta-data, called inodes, which can be considered as the heart of the file system. It was simplified though, and all obsolete UFS structures kept only for backward compatibility were removed. The 64MB size of partition limits of MinixFs didn't exist any more and file names could now be 255 characters long. It was the first Extended File System.

Remy Card was not completely satisfied with Ext, which was rapidly superseded by Ext2 (also conceived by the French developer) and Xiafs file systems. Between them was a competition loosed by Xiafs due to a low viability on short and mid term. Since those events, who occurred in 1993, two other versions of Extfs are born :

  • Ext3 (2001), which is an ext2 file system with a journal and some other features, in particular support for bigger files.
  • Ext4 (experimental in 2006) using extents, thanks to which I/Os speed is significantly improved.

During years, Extfs became the most successful file system within the Linux community. In 2008 the first stable version of Ext4 was released but a lot of users still have an operating system running with the third version of Ext. Ext4 is seen by its designers as an intermediate step to migrate from the Ext family to the for now experimental Brtfs (pronounced Butter-FS) file system (currently developed by Oracle).

Launching the module

There are two ways to launch extfs module. The first one is the simplest : you just have to double-click on an extfs dump or partition and the module will automatically starts. Default options will be used and should be appropriate in most of the case.

You also can use the Open with -> File system -> extfs menu accessible by right-clicking on the dump or partition you want to analyze.

A pop-up will spawn, offering the user to select or enter several options. Default options should be enough to do the job so you only should have to click on the OK button at the bottom of the window.

While the module is running you can see its advancement state in the task manager.

Default behaviour

The first thing the extfs driver does is trying to locate the super block at offset 1024 of the partition. The drivers performs some verifications to insure that the super block and file system are consistent.

If the super block is considered as invalid (rare), the driver will exit. Using the --check_SB option, the driver will try to locate a backup by carving the signature 0xeaf3 every 1024 bytes. Several backups should be found, so the driver will use the most recent of them. If no valid backups are found, the driver exits.

Then, the driver read the group descriptor table and checks if CRCs (if there are any) are correct. Even if some errors are encountered, the driver will to try to parse the FS.

Finally, the driver recursively parse the file system by starting with the inode 2, which should be the root directory.

Extfs options

The default behavior can be changed by modifying one or several options.

--parent

  • Type : node
  • Synopsis : --parent path
  • path : the path to the node on which you want to run the extfs module.

--ils

  • Type : string
  • Synopsis : --ils x[-y]
  • Description : this option displays a brief overview of the status of inodes x to y, or only x if y is not specified. The displayed informations are in order :
    • The inode number
    • The allocation status ('Allocated' or 'Not allocated')
    • The file type and mode (Unix-like notation).
    • The access time.
    • The modification time.
    • The change time.
    • the deletion time (if any)
    • the size of the file (in bytes)
  • Example :
dff> extfs --ils 15-16
15 | Allocated | lrwxrwxrwx | A : Mon Mar 15 18:08:41 2010 | M : Mon Mar 15 18:08:41 2010 | C : Mon Mar 15  8:08:41 2010 | UID / GID : 0/0 | 7B
16 | Allocated | lrwxrwxrwx | A : Mon Jun 28 18:15:01 2010 | M : Mon Mar 15 18:08:54 2010 | C : Mon Mar 15 18:08:54 2010 | UID / GID : 0/0 | 4B

--blk

  • Type : string
  • Synopsis : --blk x[-y]
  • Description : this option displays a brief overview of the status of file system blocks x to y, or only x if y is not specified. The displayed informations are in order :
    • The block number
    • The allocation status ('Allocated' or 'Not allocated')
    • The group number of the block
    • The address of the byte indicating the allocation status of the block (located in the block bitmap table).
    • The bit of the byte indicating the allocation status of the block.
  • Example :
dff> extfs --blk 15-16
15 | Allocated | Group : 0 | Bit addr : 4198401 | Bit shift : 7
16 | Allocated | Group : 0 | Bit addr : 4198402 | Bit shift : 0

--SB_check

Try to locate a super-block backup if the main one is seen as corrupted. This operation can be slow.

--fsstat

  • Type : boolean
  • Description : this option is useful only in command line. It will always automatically be used when using the GUI. Fsstat displays the file system configuration and the layout of the different block groups.

In command line, results of the fsstat options are displayed under the following format :

-------- GENERAL INFORMATIONS --------
Volume name : 
Number of blocks : 5012272
Groups number : 153
Number of inodes : 1253376
Number of free inodes : 1114585
Inodes per groups : 8192
Block size : 4096
Journal inode : 8
Orphans inode : 0
Descriptor size : 0

---- FEATURES ---- 
Compatible features : Journal - Ext attr - Resize - Hash index
Incompatible features : File type in dir entries - Support for extents - Flex block group - 
Read only features : Sparse superblock - Large file - Huge files - Group descriptor checksum - Directory nlink - Extra inode size

-------- GROUPS --------
Group 0
Inode range : 1 -> 8192
Blocks range : 0 -> 32767
	SuperBlock : 0
	Group descriptor : 1
	Block bitmap : 1025
	Inode bitmap : 1041
	Inode table : 1057 -> 1568
	Data range : 1569 -> 32767
Directories number : 3
387(4%)
21349 (65%)

[REMOVED to save place]


In graphical mode, the fsstat results will be stored in the extended attributes of the node Extfs created by the driver, representing the root of the file system. The informations displayed in this mode are the same are their equivalent in command line.

Fsstat3.png

--blockpointers

If activated, the driver will store content block number in nodes extended attributes. It is not activated by default because this option can significantly slow the GUI when there are a lot of block pointers (for big files).

--istat

  • Type : boolean
  • Synopsis : --istat x[;y;z; ... n]
  • Description : this option is useful only in command line. It will always automatically be used when using the GUI. Istat displays information on one or several inodes.

In command line, results of the istat option is displayed under the following format :

Address : 4339968
	Extended attribute header : 0
	Fragment block : 0
	Fragment index : 0
	Fragment size : 0
	Group : 0
	Inode number : 42
	Link number : 208
	NFS generation number : 1495699837
	Size (in Bytes) : 105552
	Inode uses extents : yes
	Set UID / GID ? :  No / No
 	UID / GID : 0/0
	mode : -rwxr-xr-x
	accessed : 0xb03cfc0
	changed : 0xb09ce00
	modified : 0xb09d8a8

In graphical mode, the istat informations are stored within the extended attributes of each nodes.

Gui istat.png

--jstat

  • Type : boolean
  • Description : display informations on the different transactions in the journal. If there are no journal, this option does nothing.
  • Example :
dff> extfs --jstat
Journal stat :
	Journal inode : 8
	Super block version : 2
	Block size : 4096
	Number of blocks : 32768
	Block first transaction : 0
0 : Unknown block. 
1 : Descriptor block (Seq 1867)
2: Fs block	524633
3: Fs block	1048579
4: Fs block	1
6: Fs block	524304
[ REMOVED ]

In graphical mode, if there is a journal, a Journal node is created in the Metadata directory, located in the Extfs directory.

Journal node.png

--i_orphans

  • Type : string
  • Synopsis : --i_orphans yes|no
  • Description : this option will parse the orphans inodes and create nodes for each of them. By default, the option is set to no because this command significantly slows the execution of the driver. Inodes are considered as orphans only when they are marked as

--SB_addr

  • Type : string
  • Synopsis : --SB_addr superblock_addr
  • Description : force the address of the superblock. By default, the superblock is located at offset 1024, but users can force the use of a backup by manually specifying the address for the superblock.

--root_inode

  • Type : string
  • Synopsis : --root_inode inode_nb
  • Description : by default, the inode number of the root directory is 2. If you want only to parse a part of the file system you can manually select the inode number of the inode where you want to start the parsing (for example, only the 'etc' directory).

Results

Extfs driver create a specific tree, as represented on the following screen-shot :

Extfs tree.png

File system

The File system directory, as we saw above, contains the tree view of the analysed file system, including deleted data.

Metadata

The Metadata directory contains nodes for important file system structure :

  • The superblock
  • The group descriptor table
  • The boot code area
  • The journal if any

Metadata.png

Suspicious inodes

The Suspicious inode directory contains a list of inodes containing suspicious data within their body (i.e. within the padding of the inode structure which should be empty).

Suspicious inode.png

We can see in this example that the inode 123 appear as suspicious. We can visualise its content with the hex viewer to see what is wrong with this inode. We can launch the hex-viewer by double clicking on inode 123 or by right clicking on it and going to Open with -> Viewer -> Hexedit.

I dirty.png

In conclusion, the inode 123 contains an odd string .ELFhidden dirty stuff which has nothing to do here. In this case this is of course only an "home made" example but anything could be hidden in there.

Suspicious directories

The Suspicious directories directory contains a list of directories containing suspicious data in areas which should be set to 0.

Suspicious dir.png

Reserved inodes

The Reserved inodes directory contains a the list of inodes reserved by the operating system. Indeed, Linux typically reserved inodes with a number inferior to 10. Logically, the first free inode on Linux is the inode 11. Some of these reserved inodes can sometimes be used to hide data.

Reserved inode.png

Orphan inodes

The Orphan inodes directory contains a list of inodes which are not part of the file system (i.e. which have no father) ONLY if they are marked as allocated or contain data in their padding.

Orphan inodes.png