Examining the file system of Android devices: implications for digital forensics

As smartphones increasingly integrate into our daily lives, the need for effective digital forensics has grown significantly. Android devices, which dominate the global smartphone market with over 70% share [1], present unique challenges and opportunities for forensic investigators. A key element of successful forensic analysis is a thorough understanding of the Android file system, which directly influences data storage, retrieval, and the overall investigation process. This article delves into the architecture of the Android file system, its implications for digital forensics, and a case study demonstrating its application in identifying a port scan attack.

Android File System Overview

Android primarily utilizes the ext4 file system, although newer devices may employ the FlashFriendly File System (F2FS) to optimize performance on flash storage [2]. Understanding the file system structure is essential for forensic analysis as it dictates how data is stored, accessed, and potentially recovered.

Key Partitions

Android devices are structured into several key partitions, each serving distinct functions:

• -    Boot Partition: Contains the kernel and bootloader necessary for the device to start. This partition is critical for understanding the device's startup process and can provide insights into potential tampering.

• -    System Partition: Houses the Android operating system and pre-installed applications. Analyzing this partition helps investigators understand the baseline functionality of the device and identify any potential malware or unauthorized applications.

• -    Data Partition: This partition is crucial as it stores user data, including app data, settings, and personal files. It is the primary focus of forensic investigations, containing valuable information such as text messages, call logs, and photos.

• -    Cache Partition: Used for temporary files, the cache partition can provide insights into user activity and app usage, revealing recently accessed files.

• -    Recovery Partition: Contains recovery tools that can be used to restore the system. Understanding this partition is important for investigators looking to recover data or restore a device to its factory settings during an investigation.

File System Structure

The file system is organized hierarchically, resembling traditional UNIX-like systems. Key directories include:

• -    /data: Contains user and app-specific data, holding a wealth of information crucial for forensic analysis, such as SQLite databases for app data and shared preferences for user settings.

• -    /system: Houses the Android OS files and pre-installed applications. Changes in this parti-

• tion can indicate unauthorized modifications or malware presence.

• -    /cache: Stores temporary files, which can be useful for tracking user activity, as it may contain remnants of recently accessed data.

• -    /sdcard: Represents external storage, containing user files like photos and documents that may serve as critical evidence during investigations.

Data Storage in Android

Data storage in Android is complex and varies by application. Common storage methods include:

• -    SQLite Databases: Many applications utilize SQLite for data storage, allowing structured data management. Investigators must be proficient in SQL to extract and analyze this data effectively. Data stored in SQLite databases can include user profiles, messages, and transaction histories.

• -    Shared Preferences: Lightweight storage for key-value pairs used to save user settings. This can be significant in understanding user behavior, preferences, and application configurations.

• -    Internal and External Storage: Applications can store data in internal (private) or external (shared) storage, impacting data accessibility during forensic analysis. External storage may contain user files that are more readily accessible during investigations.

Forensic Implications of Android File Systems

The intricacies of the Android file system have significant forensic implications, particularly concerning data recovery:

• 1 ) Data Recovery Challenges: Investigators often face challenges in recovering data due to the nature of the file system:

• -    Deleted Data: When a file is deleted, the data may not be immediately removed; instead, the system marks the space as available for new data. As a result, forensic tools can often recover deleted files unless overwritten.

• -    Fragmentation: The nature of file allocation can lead to fragmentation, complicating recovery efforts. Understanding how data is stored and organized can improve the chances of successful recovery.

• 2 ) Encryption Impact: Android devices increasingly implement full-disk encryption, which significantly impacts forensic investigations. When a device is encrypted, accessing user data without the decryption key becomes nearly impossible. Investigators must often rely on the us-

• er’s credentials to unlock the device, presenting a considerable hurdle in many cases.

Tools for Analyzing Android File Systems

Numerous tools assist in forensic analysis of Android file systems, both open-source and commercial. Key tools include:

• -    Autopsy: An open-source digital forensics platform that can analyze disk images, including those from Android devices. Its user-friendly interface allows investigators to parse data efficiently [3].

• -    SIFT Workstation: Developed by SANS, this open-source toolkit includes modules specifically designed for analyzing Android devices, aiding in memory analysis and data extraction [4].

• -    Android Debug Bridge (ADB): A versatile command-line tool that enables communication with Android devices, allowing investigators to run various commands to extract files and data. ADB can also be instrumental in capturing logs, which can provide insights into device usage and application behavior [5].

Extracting Logs and Other Data with ADB

Using ADB, forensic investigators can access various types of logs and data, including:

• -    System Logs: ADB can retrieve system logs (logcat), which provide real-time insights into the device’s operations. Logs can include information about application crashes, system events, and user interactions, helping investigators reconstruct user activity.

• -    Application Logs: Individual applications may maintain their own logs, which can provide further context on user actions and application behavior. Analyzing these logs can be vital in understanding how an app was used during a critical time.

• -    User Data Extraction: ADB facilitates the extraction of files and databases from the device's file system, including critical user data stored in SQLite databases. This capability allows investigators to analyze text messages, contacts, and other pertinent information.

To use ADB effectively, forensic investigators typically need to enable USB debugging on the device, which allows ADB to communicate with it. However, this requires access to the device's settings, which can be a limitation in certain scenarios.

Case Study : Identifying a Port Scan Attack Through Network Analysis

As part of our exploration into the digital forensics of Android devices, we conducted a case study focused on identifying a port scan attack using the Android Debug Bridge (ADB) and network traffic analysis. This method demon- strates how forensic investigators can leverage tools available within the Android ecosystem to uncover security incidents.

As illustrated in Figure 1, we utilized an Android emulator to simulate the target device.

Status

Battery status

Charging on AC

Battery level 81%

SIM status

I MEI information

I        IP address

I        fe80 a0027ff:fe69 a765

I        192168 43 164

• Figure 1.    The Android Emulator Device

For the attacking component, we used a separate virtual machine to perform a network scan. This setup allowed us to observe the interactions between the two systems.

' /home/kali

- nmap-p-192.168.43.164

Starting Nmap 7.94SVN (     24-10-0713:05 EDT

Nmap scan re port for 192.168.43.164

Host is up (0.0072s latency).

Not shown: 65526 closed tcp ports (reset)

PORT STATE SERVICE

5555/tcp open freeciv

6379/tcp open re dis

22468/tcp open unknown

24296/tcp open unknown

24297/tcp open unknown

24800/tcp open unknown

24810/tcp open unknown

25000/tcp open icl-twobase1

30102/tcp open unknown

MAC Address: 08:00:27:69:A7:6 5 (Oracle VirtualBox virtual NIC)

• Figure 2.    The Nmap Scan on the Android Device

192.168.43.164:5555 device

We executed the command adb shell tcpdump -i any -s 0 -w /data/local/tmp/scan.pcap to capture all network traffic on the emulator in real-time, as shown in Figure 3. This command is particularly useful for digital forensics, as it enables investigators to monitor traffic across all interfaces without missing critical data.

/home/ка I i adb connect 192.168.43.164

* daemon not running; starting now at tcp:5037

* daemon started successfully connected to 192.168.43.164:5555

/home/kali adb devices

List of devices attached

• Figure 3.    Connecting to the Android Device Using ADB

After capturing the traffic, we extracted the pcap file using ADB, as illustrated in Figure 4.

।—(kali® kal}-[~]

I—(kali® kal}-[-]

• Figure 4.    Extracting the Network Traffic Capture Using ADB

Upon reviewing the generated .pcap file with Wireshark, we identified a series of distinct patterns indicative of a port scan. Specifically, we observed a rapid succession of SYN packets targeting multiple ports, suggesting an unauthorized attempt to discover open services on the device.

No.			Time	Source	Destination	Protocol	Length Info
Г		1	0.000000	192.168.43.164	192.168.43.56	TCP	181	5555	^ 49180 [PSH, ACK] Seq=l Ack=l Wi
			0.001033	192.168.43.56	192.168.43.164	TCP	68	49180 - 5555 [ACK] Seq=l Ack=114 Win=2
		3	0.O01593	192.168.43.56	192.168.43,164	TCP	92	49180   5555 [PSH, ACK] Seq=l Ack=114
		4	0.040704	192.168.43.164	192,168.43,56	TCP	68	5555	- 49180 [ACK] Seq=114 Ack=25 Win=
		51	1.051323	192.168.43.56	192,168.43,164	TCP	68	[TCP	Keep-Alive] 49180 ^ 5555 [ACK] Se
		52	1.051408	192.168.43.164	192.168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		131	2.071963	192.168.43.56	192,168.43,164	TCP	68	[TCP	Keep-Alive] 49180 ^ 5555 [ACK] Se
		132	2.072542	192.168.43.164	192,168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		179	3.O90654	192.168.43.56	192,168.43,164	TCP	68	[TCP	Keep-Alive] 49180 ^ 5555 [ACK] Se
		180	3.091084	192.168.43.164	192,168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		260	4.141338	192.168.43.56	192,168.43,164	TCP	68	[TCP	Keep-Alive] 49180 ^ 5555 [ACK] Se
		261	4.141409	192.168.43.164	192,168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		319	5.175109	192.168.43.56	192,168.43,164	TCP	68	[TCP	Keep-Alive] 49180 ^ 5555 [ACK] Se
		320	5.175244	192.168.43.164	192,168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		369	6.298404	192.168.43.56	192,168.43,164	TCP	68	[TCP	Keep-Alive] 49180 ^ 5555 [ACK] Se
		370	6.298531	192.168.43.164	192,168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		419	7.312297	192.168.43.56	192.168.43,164	TCP	68	[TCP	Keep-Alive] 49180 - 5555 [ACK] Se
		420	7.312403	192.168.43.164	192,168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		467	8.335361	192.168.43.56	192.168.43,164	TCP	68	[TCP	Keep-Alive] 49180 - 5555 [ACK] Se
		468	8.336347	192.168.43.164	192,168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		515	9.418906	192.168.43.56	192.168.43,164	TCP	68	[TCP	Keep-Alive] 49180 - 5555 [ACK] Se
		516	9.419004	192.168.43.164	192,168.43,56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK
		564	10.448902	192.168.43.56	192.168.43,164	TCP	68	[TCP	Keep-Alive] 49180 - 5555 [ACK] Se
		565	10.449121	192.168.43.164	192,168.43.56	TCP	68	[TCP	Keep-Alive ACK] 5555 - 49189 [ACK

• Figure 5.    Analysis of the Traffic Using Wireshark

The frequency of these packets-often within milliseconds of one another-aligned with known characteristics of port scanning techniques such as SYN scans and FIN scans. Further analysis of the captured data revealed that the majority of the targeted ports were non-responsive, indicating that they were likely closed or filtered.

This case study underscores the significance of ADB in digital forensics, offering valuable insights into identifying and analyzing network threats on Android devices. By capturing and scrutinizing network traffic, forensic investigators can provide a more comprehensive assessment of security incidents, thereby enhancing overall mobile device security.

Future Considerations in Android Forensics

As Android continues to evolve, so will its file systems and associated forensic challenges. Key trends include emerging file systems, the integration of AI for data analysis, and ongoing research into Android file systems and their implications for forensics.

Conclusion

A comprehensive understanding of the Android file system is vital for effective forensic investigations. The complexities of file storage, log retrieval, and data recovery present both challenges and opportunities for investigators. Forensic professionals must stay informed about file system structures, data storage methods, and emerging challenges to navigate the complexities of digital investigations successfully.