Forensic analysis of Flash-Friendly File System (F2FS)

If you are performing digital forensics examinations of Android mobile devices often enough, you must know that there are so many different file systems which can be found on such smartphone or tablet.

Android file systems classification

These file systems can be classified as flash memory file systems and media based file systems.

Here is flash memory file systems list:

YAFFS2 or Yet Another Flash File System 2 – the default AOSP (Android Open Source Project) file system for kernel version 2.6.32., which is not supported in its newer versions.

JFFS2 or Journal Flash File System 2 – the default file system for AOSP kernels since Android 4.0.

F2FS or Flash-Friendly File System – an open source flash file system developed by Samsung.

exFAT or extended File Allocation Table – a proprietary Microsoft file system.

And here is media based file systems list:

EXT 4 or Extended File System 4 – a standard Linux file system which is used very often in modern Android mobile devices.

FAT or File Allocation Table – a file system introduced by Microsoft in 1977, it has three main variants: FAT 12, FAT 16 and FAT 32.

In this article we are going to talk about forensic analysis of Motorola Moto G smartphone the “userdata” partition of which is formatted with F2FS file system.

F2FS brief overview

F2FS is based on the log-structured file system (LFS) design, it means that:

• data is always written to previously unused space;
• free space is managed in large regions which are written to sequentially.

To describe F2FS design and some forensically interesting information we will use file system abstraction model introduced in Brian Carrier’s File System Forensic Analysis (2005).

File system layer.

F2FS has six components that make up its file system layer: Superblock, Checkpoint, Segment Information Table (SIT), Node Address Table (NAT), Segment Summary Area (SSA) and Main area.

The partition begins from Superblock. There are two copies of it to avoid file system crash. It includes basic partition information and some default parameters.

Checkpoint contains file system information, bitmaps for valid NAT/SIT sets, orphan inode lists, and summary entries of current active segments.

SIT includes segment information such as valid block count and bitmap for the validity of all the blocks stored in Main area.

NAT contains block address table for all the node blocks.

SSA includes summary entries which contain the owner information of all the data and node blocks.

Main area contains file and directory data.

File Name Layer

File names in F2FS are stored in dentry blocks. Each dentry block is 4 K in size and consists of 214 dentries and file names.

A dentry occupies 11 bytes and has four attributes:

• hash – file name’s hash value;
• ino – inode number;
• len – file name length;
• type – file type (directory, symlink, etc).

A dentry block has the following structure: bitmap (27 bytes) – reserved (3 bytes) – 214 dentries (11 bytes each) – 214 file names (8 bytes each). Dentry blocks form buckets.

Metadata layer

F2FS, like traditional file systems, has three types of node: inode, direct node, indirect node. An inode contains lots of forensically important information, such as file size, allocated blocks, ownership (including UID and GID) and MAC times (Modified, Accessed, Changed).

The Modified timestamp is updated when the file or directory is written.

The Accessed timestamp is updated when the file or directory is read.

The Changed timestamp is updated when the inode is modified.

Data Unit Layer

Like many other file systems, F2FS is comprised of blocks. Each block is 4K in size.

Blocks are collected into segments. Each segment contains 512 blocks and is 2MB in size. Each segment has segment summary block (file plus offset of each block in the segment).

Segments are collected into sections. Sections have flexible size (power of two). There are always six sections “open” for writing at any time. This allows the data to be kept separate from indexing information (nodes).

Sections are collected into zones. These zones make up the main area of the filesystem.

The case

Recently we received a Motorola Moto G smartphone for a digital forensic examination. The smartphone was damaged, so we decided to use the chip-off data extraction technique.

The circuit board was removed from the phone (fig. 1).

Figure 1. Phone’s circuit board

There is a MICRON eMCP chip on the board (fig. 2).

Figure 2. MICRON eMCP chip

The chip contains both DDR3 and eMMC memory. The most difficult part was to find proper pinout configuration, because where was no datasheet in public access.

Finally, we had found the pinout and the chip was removed from the board. Than EMMC ROM1 (Main User Data) was imaged.

We tried to use PC 3000 Data Extractor and Oxygen Forensic Analyst to analyze the image, but no tool could read the “userdata” partition. The thing is – the partition was formatted with F2FS.

For further analysis we used Santoku Linux. At first, we copied our image (emmc.img) to the Desktop. We started from “mmls” command (from the Sleuth kit) and got the following output:

As you could see, the “userdata” partition was 10485504 in length. To mount the partition we used “kpartx”. To create device-mappings for each partition in the image we used the following command:

sudo kpartx -v -a /home/santoku/Desktop/emmc.img

And got the following output:

So, the “userdata” partition was mapped to /dev/mapper/loop0p44. How did we guess? Look at the length!

Santoku had “f2fs_tools” installed, so we could mount the partition. The following command was used:

sudo mount -t f2fs /dev/mapper/loop0p44 /media/userdata -o ro

The “userdata” partition was successfully mounted at /media/userdata and all the files could be copied out of it and analyzed (fig. 3).

Figure 3. The “userdata” partition contents

Extacted files were analyzed with UFED Physical Analyzer, Oxygen Forensic Analyst, Internet Evidence Finder and Belkasoft Evidence Center – we got similar results.

In this particular case we needed to recover deleted images. To do it we used classic carving technique. The tool we used was “scalpel”. Using it we successfully recovered lots of images, both taken with the mobile device’s camera and downloaded by the user.

As you can see, forensic analysis of F2FS is not an impossible task, even if you are armed with only open source digital forensic tools.

About the authors:

Igor Mikhaylov

Interests: Computer, Cell Phone & Chip-Off Forensics

Oleg Skulkin

Interests: iOS forensics, Android forensics, Mac OS X forensics, Windows forensics, Linux forensics