School of Informatics & IT

Lecture 3

Android file systems & data structures

DIGITALMEDIA
FORENSICS
( CDF2C02)
 2

Acknowledgement
• Contents are taught in conjunction with Internet
resources from:
• Hoog, A. (2011). Android Forensics: Investigation, Analysis, and Mobile
Security for Google Android. Syngress Publishing.
• Available as hardcopy book at TP library and softcopy on 24x7 at TP library web
portal
• Cellebrite. (2014). Participant Guide: Cellebrite Certified Logical
Operator. Cellebrite USA Inc.
• Cellebrite. (2014). Participant Guide: Cellebrite Certified Physical
Analyst. Cellebrite USA Inc.
• Android Forensics: Exploring Android Internals and Android Apps
(source: www.slideshare.net)
 3

Slides Resources
• Slide resource credits:
• Hoog, A. (2011). Android Forensics: Investigation, Analysis, and Mobile
Security for Google Android. Syngress Publishing.

• Available in TP library
• Hardcopy
• eBook (7 days loan availability)
 4

Android Data Storage

 5

How Data is stored in Android Devices?

• Persistent data are stored to
• NAND flash
• SD card
• Network
• Five methods:
1. Shared preferences
2. Internal storage
3. External storage
4. SQLite
5. Network
• Beyond application data that developers store, the Linux kernel
and Android stack provide information through logs, debugging,
and other standard information services.
 6

Shared Preferences
• Shared preferences
• Allow a developer to store key-value pairs of primitive
data types in a lightweight XML format.
• Primitive data types that can be stored in a
preferences file include the following:
1. boolean: true or false
2. float: single-precision 32-bit IEEE 754 floating point
3. int: 32-bit signed two’s complement integer
4. long: 64-bit signed two’s complement integer
5. strings: string value, typically as a UTF-8
 7

shared_prefs folder
• Typically stored in an application’s data directory in the
shared_pref folder and end with .xml.
• E.g. On HTC Incredible, the Android phone shared
preferences directory contains five XML files:
root@ubuntu:~/data/data/com.android.phone/shared_prefs$ ls -l
total 20
-rw-r----- 1 root root 104 2011-01-23 18:05 cdma_msg_id.xml
-rw-r----- 1 root root 214 2011-01-20 09:34 com.android.phone_preferences.xml
-rw-r----- 1 root root 126 1980-01-06 09:42 _has_set_default_values.xml
-rw-r----- 1 root root 152 2010-09-10 09:46 htc_cdma_settings.xml
-rw-r----- 1 root root 102 2010-09-10 09:48 updateAreaCode.xml

• The com.android.phone_preferences.xml preferences file

has examples of int, boolean, and string preferences:
root@ubuntu:~/data/data/com.android.phone/shared_prefs$ cat com.android.phone_preferences.xml
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<int name="vm_count_key_cdma" value="0" />
<boolean name="pref_key_save_contact" value="true" />
<string name="vm_number_key_cdma">*86</string>
</map>
 8

Mobile Directory Number (MDN)

• The latest mobile directory number (MDN) can be queried from
updateAreaCode.xml.
root@ubuntu:~/data/data/com.android.phone/shared_prefs$ cat updateAreaCode.xml
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<string name="MDN">312</string>
</map>

• MDN = area code for the device

• Presumably to allow IDD dialling option in areas supporting that feature.
• Many applications take advantage of the lightweight Shared
Preferences method for storing key-value pairs
• Rich source of forensic data, especially true when examiners can
recover older or deleted versions of the XML preferences file.
 9

Internal Storage
• Files allow storage of complicated data structures.
• Stored in the app’s /data/data subdirectory.
• Developer has control over the file type, name, and
location.
• By default, the files can only be read by the application
and even the device owner is prevented from viewing the
files unless they have root access.
• Developer can override security settings to allow other
processes to read / update app files.
• App-created files may be of forensic value.
• E.g. Google Maps’ cache may give away location history.
 10

External Storage
• Files on external storage devices have far fewer security and
location constraints compared to files on internal storage
• E.g. SD cards or emulated SD cards stored directly on NAND
• To facilitate mounting SD card on desktop computers to share
files, SD cards are generally FAT32-formatted.
• While FAT32 is widely supported, it lacks the fine grained
security mechanism built into file systems such as ext3, ext4,
yaffs2, hfsplus, and more. Thus, by default, the files cannot
enforce permissions.
• App developers have greater control over the name, format,
and location of files on external and emulated SD cards.
 11

SQLite
• SQLite database - another NAND/SD card-based storage that developers leverage on.
• Popular database format appearing in many mobile systems as well as traditional operating systems.
• Entire code base is of high quality, open source, and released to the public domain.
• File format and program itself are very compact and pack significant functionality in less than a few hundred KBs.
• Entire database is contained in a single cross-platform file.
• Android provides dedicated APIs that allow developers to use SQLite DBs in their apps.
• SQLite files are generally stored on the internal storage under /data/data/<packageName>/databases. But
there are no restrictions on creating databases elsewhere.
• SQLite databases are a rich source of forensic data.

• SQLite DBs can be forensically rich.

• E.g. Referencing the built-in Android browser, based on WebKit Open Source Project (http://webkit.org/), on a HTC
Incredible Android device, there were 28 SQLite databases located in subdirectories of
/data/data/com.android.webkit.
• The five subdirectories were as follows:
• app_icons: 1 database of web page icons
• app_cache: 1 database containing web application data cache
• app_geolocation: 2 databases relating to GPS position and permissions
• app_databases: 21 databases providing local database storage for supporting web sites
• databases: 3 databases for the browser and browser cache
• Location, web history and web cache can be extracted.
 12

Network
• Apps can use the network (when it is available) to store
and retrieve data on your own web-based services. To do
network operations, use classes in the following packages:
• java.net.*
• android.net.*
• Packages referenced in the documentation essentially
provide developers with the low-level APIs needed to
interact with the network, web servers, and more.
• While all of the forensically interesting data may not be
stored on the device, often important configuration and
database files are recoverable.
 13

Android Memory
 14

Types of Memory
• Android devices have two primary types of memory:
• Volatile (RAM)
• Non-volatile (NAND flash)
 15

Volatile (RAM) memory

• RAM is used by the system to load, execute, and manipulate key
parts of the OS, apps, or data, and is not saved on reboot (i.e.
volatile).
• Like traditional computers, RAM can contain very important
information which applications use to process data. E.g.:
• Passwords
• Encryption keys
• Usernames
• App data
• Data from system processes and services
• Analysis of app’s memory contents can provide deep insight into
the app’s internal structure as well as key information about the
device owner.
 16

Non-volatile (NAND Flash)

memory
• NAND flash is non-volatile and thus the data are
preserved even when the device is without power
or rebooted.
• NAND flash is used to store not only system files but
also significant portions of the user’s data.
• First, NAND flash has no mechanically moving parts
like the spinning platters and arms found in
traditional magnetic hard drives.
• Improves the durability and reduces both the size and
power consumption of the device.
 17

Non-volatile (NAND Flash)

memory
• NAND flash also has very high density and is cost effective to
manufacture.
• One side effect of the manufacturing process: NAND flash
literally ships with bad blocks directly from the manufacturer.
• So while NAND flash is more physically durable than spinning
platters, its error rate is much higher and must be accounted for in
development and use.
• NAND flash has a very limited write/erase life span before
the block is no longer capable of storing data.
• The life span varies by device and is largely impacted by the
amount of data stored per NAND flash cell, the central building
block for storing the 1 or 0 bit(s).
 18

Non-volatile (NAND Flash)

memory
• Unlike RAM and NOR flash used in a computer’s Basic Input
Output System(BIOS), NAND flash cannot be accessed randomly.
• Access to data is achieved via an allocation unit, called a page or
chunk, which is typically between 512 and 2048 bytes, but
generally increases as the overall size of NAND flash increases.
• Page and Chunk are synonymously used to refer to the low-level data
allocation unit referenced in NAND flash.
• Allocation unit is usually referred to as a page, but YAFFS2 file system, a
key component of Android, refers to the allocation unit as a chunk.
• NAND flash does not provide the fast random access like RAM,
but access time is still quite fast
• Does not require the mechanical platter and arm movements used in
traditional spinning hard drives.
 19

Non-volatile (NAND Flash)

memory
• Chunks are organized into a larger logical unit called a block.
• Typically much larger than a traditional 512B hard drive sector.
• In most Android devices, the NAND flash blocks contain 64 chunks of data
and each chunk is 2048 bytes. Taking 64 X 2 KB yields a block size of 128 KB
(may change over time and is controlled by the NAND flash manufacturers).
• When a block is allocated for writing, the chunks inside the block are written
sequentially.
• Important characteristic of NAND flash is the operations available for reading
and writing:
• Read (page)
• Write (page)
• Erase (block)
• While individual chunks can be read or written, the erase operation only
functions at the block level. When a block is erased, the entire block is
written over with 1’s or 0xFF (hex).
 20

NAND flash erase operation

• The erase operation is the only mechanism by which a 0 can be
changed to a 1 in NAND flash.
• In a traditional hard drive, if a value is changed from a 0 to a 1
(or vice versa), the program would simply seek to the value on
the hard drive and apply the appropriate voltage to change and
store the new value.
• The fundamental architecture of NAND flash provides only one
mechanism to change a 0 to a 1 and that is via the erase function
that is applied at the block level, not an individual page level.
• For this reason, a page can only be written once, and if the value
of the page needs to change, the entire block must be erased
and then the page can be written.
 21

Management of NAND flash

• All management of the memory must be implemented in software interfacing
with the NAND flash.
• Two important techniques deployed are error correcting code (ECC) and
wear-leveling. Both have significant implications for forensics and data
recovery.
• ECC is a technique where an algorithm is used to detect data errors on read
or write operations and correct some errors on the fly. Since NAND flash
degrades over time through usage, the system must be able to detect when a
page or block is going bad and recover the data stored there. After a number
of errors or failed operations is exceeded (typically three failed operations),
the page or block will be marked bad and added to the bad block table.
• Wear-levelling is the second important technique to effectively manage
NAND flash on Android. Wear-leveling code spreads the writing of data across
the entire NAND flash to avoid overutilization of a single area, thus wearing
those blocks out more quickly.
 22

Management of NAND flash

• Android devices were designed to integrate the NAND flash components directly, and thus
a software management layer was needed to provide these important functions.
• The layer selected to manage the NAND flash was the Memory Technology Device (MTD)
system.
• By leveraging MTD, Android had the necessary Flash Transition Layer (FTL) needed to
effectively interact with the NAND flash.
• In Android, the MTD provides not only the block interface to the NAND flash but also the ECC, wear-
leveling, and other critical functions.
• The ECC and other chunk metadata are stored in a reserved area called the out of band
(OOB) or spare area.
• OOB is located directly after each chunk on the NAND flash.
• While the chunk, block, and OOB layout is configurable, most Android devices to date have a 128 KB
block consisting of 64 2,048 byte (2k) chunks each with a 64 byte OOB.
• The OOB stores information managed by MTD, and can also store metadata critical to the
file system, provided the file system is NAND flash aware.
• The system presents a block as 128 KB
• But when you add in the 64 OOB, each 64 bytes in size, there is an additional 4096 bytes (4 KB)
bringing the total bytes used on the NAND flash to 132 KB.
 23

YAFFS2
• What is YAFFS2? (Yet Another Flash File System v2).
• Log Structured
• Data is never written to the same place twice.
• Data is strictly sequential.
 24

YAFFS2
• YAFFS2 was built specifically for the growing NAND
flash devices and has a number of important
features that address the stringent needs of this
medium:
• a log-structured file system (which protects data even
through unexpected power outages)
• provides built in wear-leveling and error correction
• capable of handling bad blocks
• fast and has a small footprint in RAM
• Android uses YAFFS2 prior to Android v2.3.
• EXT4 is adopted for NAND storage from v2.3 onwards.
 25

YAFFS2
• In the 64-byte OOB/spare area, YAFFS2 not only stores critical
information about the chunk but also shares the area with
the MTD subsystem. The critical YAFFS2 tags are as follows:
• 1 byte: block state (0xFF if block is good, any other value for a bad
block)
• 4 bytes: 32-bit chunk ID (0 indicates that chunk is storing a
yaffs_ObjectHeader, else data)
• 4 bytes: 32-bit Object ID (similar to traditional Unix inode)
• 2 bytes: number of data blocks in this chunk (all but final chunk will
be fully allocated)
• 4 bytes: sequence number for this block
• 3 bytes: ECC for tags (in Android, handled by MTD)
• 12 bytes: ECC for data (in Android, handled by MTD)
 26

YAFFS2
Only ever sequential writes within a block
Data is never written in the same place but
appended.
 27

YAFFS explained

• Chunk or Page – Typically 2Kb (2048bytes).

• Followed by the OOB (Out of Band)(64 bytes)
• A Block (Arbitrary number between 32 – 128
Pages/Chunks).
 28

Quiz 1
I have a text file, file A and I update the contents of file A and save it.
What happens in YAFFS2?

• File is updated with changes and saved to the same page

• Only the updates are saved to a new Page/Chunk

• Current information and updates are saved to a new page/Chunk

• Old Page/Chunk is deleted immediately from NAND flash and new

page/chunk is used to store File A + updates
 29

YAFFS2 in Forensics
• Data written in Pages but deleted in blocks during
garbage collection.
• Magnetic Disks vs NAND flash
• Does YAFFS2 hinder or help in forensics
investigation?
 30

Quiz 2
Does YAFFS2 hind or help with Digital Forensics?

• Hinders - Garbage collection causes Blocks to be deleted and that

makes data acquisition harder.

• Helps - Because YAFFS2 is a log structured OS, it contains the

history of the file.
 31

OOB (Out of Band)

64 bytes. Written in little endian

• Block state. Typically FF
• Block sequence Block sequence is used to track which block the chunk is written to. As each new block is
allocated, the block sequence number is incremented by 1.
• Object ID – Contains unique object number of the object a chunk is associated with.
• Chunk ID – Defines Chunk position within an object.
• nBytes- Number of data bytes in a chunk.