Unit 3: MOBILE FORENSICS

Prepared by:

Akhila B Mukundan

Assistant Professor, FoCA

 Syllabus: Mobile Forensics
• The evolution of Data extraction techniques: Analyzing an Android image:
Android • Manual data extraction • Autopsy
• The Android model • Logical data extraction • Adding an image to Autopsy
• ADB pull data extraction • Analyzing an image using
• The Android
security • Using SQLite Browser to view the Autopsy
data
• The Android file • Extracting device information Android data recovery:
hierarchy • Recovering deleted data from
• Extracting call logs, SMS/MMS,
• The Android file Browsing History, external SD card
system • Analysis of social networking/IM • Recovering data deleted from
chats internal memory
• ADB backup extraction • Recovering deleted files by
• ADB dumpsys extraction parsing SQLite files
• Using content providers • Recovering contacts using your
• Physical data extraction Google account.
• Imaging an Android Phone
• Imaging a memory (SD) card
Introduction – Mobile Forensics
• Mobile Forensics is the branch of digital forensics dealing with the recovery, analysis, and preservation of
digital evidence from mobile devices.
• This branch focuses on extracting data from mobile phones, tablets, and portable communication devices for
legal and investigative purposes.
• It involves both hardware and software analysis to retrieve deleted messages, call logs, app data, location
history, and more - even when access is restricted or tampered with.

• Mobile forensics is an essential subfield of digital forensics due to the central role mobile devices play in
communication and daily life.
• Investigators must be skilled in handling multiple tools, understand OS architecture (especially Android/iOS),
and follow proper legal procedures.
• With challenges like encryption and device fragmentation, mobile forensics continues to evolve with both
technological and investigative advancements.

*Device fragmentation refers to the wide variety of devices with different screen sizes, operating systems, hardware capabilities, and
manufacturer customizations that exist in the market.
Introduction – Mobile Forensics
Objectives of Mobile Forensics

• Identify digital evidence present on mobile devices.

• Preserve data integrity during extraction.
• Extract user data (e.g., SMS, call history, app content).
• Analyze behavioral patterns, communications, movements.
• Report findings clearly for legal admissibility.
Introduction – Mobile Forensics
Importance of Mobile Forensics

• Mobile devices are central to communication and daily activities, making them rich sources of digital
evidence.
• Smartphones store vast amounts of personal and professional information.
• Criminals often use messaging apps, GPS, social media, and encrypted services - all of which leave behind
traces on mobile devices.
• Mobile forensics helps trace criminal behavior, verify alibis, uncover deleted data, and provide timeline
evidence in both civil and criminal cases.
Introduction – Mobile Forensics
Process of Mobile Forensics

Stage Key Risks / Requirements

Lock activation, remote wipe, signal
Seizure
blocking
Screen lock, encrypted data, app-
Identification
specific locks
Cloud syncing, data volatility, proper
Acquisition
tools
Hidden/deleted files, cross-app data,
Examination
context
Legal admissibility, documentation,
Reporting
audit trail
Introduction – Mobile Forensics
Process of Mobile Forensics

1. Seizure and Isolation

• Seizing and isolating the mobile device is critical to prevent evidence tampering, remote access, or data loss.
• All evidence must be preserved, handled, and documented properly to be admissible in court.
• Seizing a mobile device introduces legal challenges, especially concerning privacy, ownership, and consent.

Two major risks during this phase:

• Lock Activation – if the screen locks or the device powers off, access may be restricted.
• Network Connectivity – if connected to cellular, Wi-Fi, or Bluetooth, data may be remotely wiped or modified.

Countermeasures:
• Place the device in Airplane Mode if unlocked.
• Use a Faraday bag to block network signals.
• Do not power off the device unless necessary.
Introduction – Mobile Forensics
Process of Mobile Forensics

2. Identification
• This step involves identifying the mobile device, user profile, and potential data of interest.
• Goal: Determine what type of data is stored and how it can be accessed.

Challenges:
• Devices may be locked with PINs, passwords, patterns, or biometrics.
• Fingerprint access is often easier to bypass than passcodes, which are legally protected in many
jurisdictions.
• Apps may include in-app locks, and data may be encrypted at the app, file system, or full-disk level.

Investigators must:
• Document the make, model, and OS version.
• Identify potential apps of interest (e.g., messaging, social media, banking).
• Check for encryption indicators that may affect acquisition.
Introduction – Mobile Forensics
Process of Mobile Forensics

3. Acquisition
• Acquisition involves creating a forensically sound copy of the data for analysis.
• Mobile data is volatile and can be moved, deleted, or synced with cloud platforms.

Key concerns:
• Remote deletion or modification if the device is online.
• Cloud synchronization (e.g., iCloud, Google Drive, OneDrive) allows data to exist beyond the physical device.

Investigators must:
• Determine if data is stored locally, externally (SD card), or in the cloud.
• Choose an appropriate extraction technique:
• Manual
• Logical
• Physical
• File system
• Maintain chain of custody during acquisition.
Tools like Cellebrite UFED, Magnet AXIOM, ADB, and Autopsy are used depending on access level and device type.
Introduction – Mobile Forensics
Process of Mobile Forensics

4. Examination and Analysis

• This stage focuses on interpreting the extracted data to reconstruct events, actions, or communications.
• Mobile data is highly dynamic and decentralized.
• A message deleted on one app may still exist on cloud backup.
• Images, videos, and metadata can reside in cached folders, thumbnail databases, or external storage.

Examiners analyze:
• Call logs, messages, contacts
• App data (e.g., WhatsApp, Telegram)
• Location history and browser artifacts
• Deleted or hidden files using SQLite parsing and carving tools
Data must be analyzed contextually and chronologically, often using timelines and keyword searches.
Introduction – Mobile Forensics
Process of Mobile Forensics

5. Reporting
• The final step documents all forensic actions and findings in a clear, legally valid format.
• The forensic report acts as the official record of:
• Seizure
• Custody
• Control and transfer
• Acquisition method
• Analysis steps
• Findings and conclusions

Reports must be:

• Clear, concise, and non-technical enough for courts.
• Include hash values, tool logs, and screenshots for validation.
• Follow standards such as Daubert or ISO/IEC 27037 for forensic reliability.
Introduction – Mobile Forensics
Types of Cases Data Recovered

Type of Data Examples

• Cyberbullying & Online
Harassment Call logs Incoming, outgoing, missed calls
• Financial Fraud & Phishing
SMS, MMS, IMs (WhatsApp,
• Drug Trafficking & Human Messages
Telegram)
Trafficking
• Espionage & Insider Threats Multimedia Photos, videos, audio recordings
• Domestic Abuse & Child Location Data GPS coordinates, Wi-Fi logs
Exploitation
• Terrorism & Organized Crime App Data Chat history, browsing activity
• Accident Analysis & Location Contacts & Calendars Names, emails, appointments
Verification
Device Information IMEI, OS version, SIM details

*Espionage: Espionage, spying, or intelligence gathering, as a subfield of the intelligence field, is the act of obtaining secret
or confidential information (intelligence).
Introduction – Mobile Forensics
Challenges in Mobile Forensics

• Device Diversity: Different models, manufacturers, chipsets.

• Frequent OS Updates: Android/iOS versions affect data storage and extraction.
• Data Encryption: Full-disk encryption complicates access.
• Cloud Integration: Some data may not be stored locally.
• Third-party App Security: WhatsApp, Signal, and Telegram encrypt chats, making analysis harder.

*FDE
• FDE automatically encrypts data and operating systems (OSes) to prevent unauthorized access.
• Full-disk encryption was introduced to Android in 4.4, later using fast encryption from Android 5.0 which only
encrypts used blocks on the data partition to avoid the first boot taking a long time.
• Microsoft includes a full disk encryption feature built into Windows called BitLocker.
• Apple offers a built-in encryption tool for macOS called FileVault.
Evolution of Android
• Android is an open-source, Linux-based mobile operating system primarily developed for touchscreen devices
such as smartphones, tablets, and wearables.
• It allows extensive customization by manufacturers and developers due to its open-source nature.
• Originally developed by Android Inc. in 2003, founded by:
• Andy Rubin
• Rich Miner
• Nick Sears
• Chris White
• The initial goal was to create a smarter mobile OS with improved location awareness and internet capabilities.
• In 2005, Android Inc. was acquired by Google, who continued its development under the Open Handset
Alliance (OHA).
Evolution of Android
• The first commercial Android version was released in 2008.
• It debuted on the HTC Dream smartphone (also marketed as T-Mobile G1), marking Android’s official entry
into the mobile market.
• Android quickly evolved and surpassed earlier platforms like Symbian, BlackBerry OS, and Windows
Mobile.
• Over the years, Android has introduced:
• Advanced UI and UX improvements
• Powerful app development frameworks
• Robust security mechanisms
• Diverse file systems and data storage models
• Due to its global dominance and data-rich environment, Android is a major focus in mobile forensics for
retrieving and analyzing digital evidence.
Evolution of Android
Version Codename Year Key Features
Android 1.0 – 2008 Basic apps, web browser
Android 1.5 Cupcake 2009 On-screen keyboard
Android 2.2 Froyo 2010 Wi-Fi hotspot

Android 4.0 Ice Cream Sandwich 2011 Unified UI for phones & tablets

Android 5.0 Lollipop 2014 Material Design

Android 6.0 Marshmallow 2015 Runtime permissions
Android 7.0 Nougat 2016 Multi-window support

Android 8.0 Oreo 2017 Background app limitations

Android 9.0 Pie 2018 Adaptive battery, gesture navigation

Android 10 – 2019 Dark mode, privacy controls

Android 11–14 – 2020–2023 Scoped storage, enhanced privacy, AI features

Evolution of Android

Reference: https://cubettech.com/resources/blog/android-1-0-to-android-m-the-story-of-mobile-evolution/
Evolution of Android
1. Android 1.0 (2008)
• Codename: None
• Key Features: Basic apps (Gmail, Maps), Web browser
• Importance: First stable Android OS; introduced foundational app and file structure.

2. Android 1.5 – Cupcake (2009)

• Key Features: On-screen keyboard, widget support
• Importance: Enabled text input via software keyboard - relevant for keyboard logging or pattern analysis.

3. Android 2.2 – Froyo (2010)

• Key Features: Wi-Fi hotspot, performance boost via JIT
• Importance: Wireless tethering introduced, expanding potential communication logs.
Evolution of Android
4. Android 4.0 – Ice Cream Sandwich (2011)
• Key Features: Unified UI for tablets and phones, facial unlock
• Importance: Biometric data and broader screen-size app support - affecting data storage formats.

5. Android 5.0 – Lollipop (2014)

• Key Features: Material Design UI, improved notifications
• Importance: Introduced ART (Android Runtime), changed how apps are compiled and executed (relevant
for app behavior analysis).

6. Android 6.0 – Marshmallow (2015)

• Key Features: Runtime permissions, fingerprint API, full disk encryption
• Importance: Major forensic challenge - access to sensitive data restricted without user permission; data
encryption by default.
Evolution of Android
7. Android 7.0 – Nougat (2016)
• Key Features: Multi-window, improved Doze mode, file-based encryption
• Importance: Power-saving changes affected background data logging; encryption at the file level
increased complexity of recovery.

8. Android 8.0 – Oreo (2017)

• Key Features: Background execution limits, notification dots
• Importance: Limited what apps can do when running in the background - reducing available forensic
artifacts.

9. Android 9.0 – Pie (2018)

• Key Features: Adaptive battery, gesture navigation, enhanced privacy
• Importance: New gesture navigation impacts usage patterns; adaptive features change how apps behave,
complicating analysis.

*Doze Mode - a power-saving feature introduced in Android 6.0 (Marshmallow) to conserve battery life by restricting
background activities when the device is idle.
Evolution of Android
10. Android 10 (2019)
• Key Features: System-wide dark mode, refined location controls, scoped storage (optional)
• Importance: Scoped storage began limiting app access to entire file systems - reducing ability to extract
shared data without special permissions.

11. Android 11–14 (2020–2023)

Key Features:
• Android 11: One-time permissions, auto-reset unused app permissions
• Android 12: Privacy dashboard, mic/camera usage indicators
• Android 13–14: Refined Scoped Storage, AI-based personalization
Importance:
• Enhanced privacy controls heavily restrict access to sensitive data.
• Forensic tools must adapt to scoped storage policies, temporary permissions, and reduced background
app access.
Evolution of Android

Reference: https://www.linkedin.com/pulse/android-evolution-jun-jonathan-zhang/
Evolution of Android
Evolution Highlights for Forensics

• Increased Security: Modern versions introduced features like full-disk encryption, scoped storage, and
security sandboxing, complicating forensic access.
• App Behavior Changes: Over time, Android restricted background access and file I/O, affecting data
extraction.
• Cloud Sync: Shift towards cloud storage in apps (e.g., WhatsApp backups on Google Drive) reduced local
artifacts.
• File System Changes: From YAFFS2 to EXT4 to F2FS, file carving and deleted data recovery methods had
to adapt.

*Scoped Storage:
Apps have access only to their app-specific directory on shared storage (eg: SD card or external storage), as well as specific
types of media that the app has created. This approach ensures that apps cannot access files belonging to other apps directly.
Scoped storage became mandatory for apps targeting Android 11 (API level 30) or higher.
Evolution of Android
Importance of Evolution in Mobile Forensics

• Extraction Tools Compatibility: Tools like Cellebrite or ADB need version-specific handling.
• Permissions Model: From static (pre-Marshmallow) to dynamic runtime permissions (post-Marshmallow),
impacting what data apps and tools can access.
• Encryption Defaults: Full disk encryption became mandatory in Android 6.0+, altering recovery strategies.
• Rooting Difficulties: Modern Android restricts rooting more aggressively, reducing forensic access unless
bootloader is unlocked.

• Android’s evolution has directly impacted how forensic professionals extract and analyze data.
• Each version brought improvements in security, performance, and user privacy.
• Investigators must be aware of OS version differences to choose the correct extraction and analysis
techniques.
Android Model
• Android architecture is a multi-layered software stack built on the Linux kernel, designed to support mobile
devices.
• Android is structured in layers, where each layer offers a set of services to the layer above it.
• This architecture ensures modularity, flexibility, and efficient management of system resources.
• Understanding Android's internal architecture is essential for forensic analysts, as it reveals the location of
data, data flow, storage mechanisms, and security implementations.

• The key layers in Android architecture include:

• Linux Kernel
• Libraries
• Android RunTime
• Application Framework
• Applications
Android Model
Android Model
1. Linux Kernel
• Acts as the hardware abstraction layer (HAL).
• Manages core system services like process management, memory management, and device drivers.

2. Libraries
• Provides C/C++ core libraries for graphics, data storage, web rendering, etc.

3. ART (Android Runtime)

• It executes app code and manages memory and performance.

4. Application Framework
• Offers high-level services to applications (e.g., Activity Manager, Content Providers).
• Controls the lifecycle of apps and system-wide interactions.

5. Applications Layer
• Contains all the user-installed and pre-installed Android apps.
• These apps interact with the system through APIs exposed by the application framework.
Android Model

Linux Kernel (Base Layer)

• Role: Acts as the hardware abstraction

layer.
• Components: Includes drivers for
display, camera, audio, keypad, WiFi,
flash memory, power management, and
inter-process communication (Binder).
• Importance in Forensics: Kernel-level
logs, system crashes, or low-level
device control data can be crucial in
physical acquisition and analysis.
Android Model
Libraries

Role: Provides C/C++ core libraries used by

various system components and apps.
Key Libraries:
• Surface Manager, Media Framework:
Graphics and multimedia rendering.
• SQLite: Lightweight database for app
data storage.
• WebKit, OpenGL|ES: Web rendering
and 3D graphics support.
• SSL, Libe: Security and network
handling.
Forensic Relevance: SQLite databases and
WebKit caches often store important app
artifacts (e.g., messages, history).
Android Model
Android Runtime (ART / Dalvik)

Role: Executes Android apps and manages

memory and performance.
Components:
• Core Libraries: Provide Java
functionality to applications.
• Dalvik Virtual Machine (or ART):
Runs the bytecode of Android apps
(.dex files).
Forensic Relevance: Understanding the
runtime helps in interpreting app behavior,
memory dumps, and reverse engineering.
Android Model
Application Framework

• Role: Provides high-level services for

application development and execution.
• Key Managers:
Activity, Window, Package, Notification,
Location Managers, etc.
• Function: These services control the
lifecycle, UI, resources, and background
tasks of apps.
• Forensic Relevance: Helpful when
analyzing how apps behave, access data, and
manage permissions.
Android Model
Applications (Top Layer)

• Role: End-user apps like Phone, Contacts,

Browser, Camera, etc.
• Function: These apps use the APIs exposed
by the framework to function.
• Forensic Relevance: Most user data (SMS,
call logs, chats, photos) resides here, making
this layer a primary focus in logical or
manual extraction techniques.
Android Model
Understanding this architecture is crucial in
mobile forensics as it:
• Guides where to look for data (app layer,
libraries, databases, system logs).
• Helps in choosing the right extraction
technique (manual, logical, physical).
• Assists in understanding app behavior, data
flow, and access patterns for accurate
evidence reconstruction.
Android Model – Forensic Artefacts

Feature Forensic Relevance

• Android apps run in isolated environments (sandboxes), preventing direct access to each other’s
data.
Sandboxing
• Forensic relevance: Limits access to app data; forensic tools must bypass sandboxing or gain
root access to extract cross-app artifacts.

• A standard Android component that enables apps and system tools to access structured data (e.g.,
contacts, SMS, call logs).
Content Providers
• Forensic relevance: Many tools use content providers to extract user data during logical
acquisition.

• Most Android apps store data such as messages, browsing history, login sessions, and user
preferences in SQLite database files.
SQLite Databases
• Forensic relevance: SQLite DBs are rich sources of evidence and often hold deleted or residual
data.
Android Model - Forensic Artefacts

Feature Forensic Relevance

• Android uses internal storage (private app files) and external storage (shared media files,
downloads).
External/Internal
Storage • Forensic relevance: Investigators must understand storage locations to recover user files, app
data, and media. External storage is more accessible, while internal storage often requires root or
physical access.

• Android uses a dynamic permission system where apps must request and be granted access to
sensitive resources (e.g., camera, location, contacts).
Permissions Model
• Forensic relevance: Reviewing app permissions helps investigators understand what data an app
could access and potentially misuse.
Android Model – App Sandboxing
App sandboxing is a core security feature of the Android operating system that isolates each application to
run in its own separate environment.
• Every app runs as a separate user (UID) in the system.
• It has its own private data directory (in /data/data/<package_name>) that other apps cannot access.
• Even if two apps are from the same developer, they cannot share data unless they use explicit
methods (e.g., content providers, shared user ID with same signature).

Forensic Relevance:
• Limits unauthorized data access: Investigators cannot access app data without root access or special
permissions.
• Makes data acquisition harder, especially in non-rooted devices.
• Forensic tools must work around sandbox restrictions (e.g., use ADB, root, custom recovery).

App sandboxing enhances user privacy and app security, but it also poses a challenge for forensic data
extraction.
Android Model - Storage Locations
Type Explanation
• Stored at /data/data/<package> - Contains sensitive app files like databases,
Internal App Data preferences, and caches
• Requires root access to view.
• Located at /sdcard/ or /storage/emulated/0/ - Used for media, downloads,
External Shared Storage and app-exported files
• Easily accessible, even without root.
• Found in /system, /proc, /cache - Includes OS files, boot logs, and runtime
System Config/Logs info
• Mostly read-only or restricted for security.

• Internal data is most valuable but hardest to access.

• External storage often reveals user behavior (photos, downloads).
• System logs help in timeline analysis and detecting tampering or root access.
Android Security
• Android security is a framework of features and mechanisms designed to protect users, apps, and data
from malicious attacks and unauthorized access. In forensics, understanding these security mechanisms
helps analysts determine how data is protected and what techniques are needed to retrieve it.

Security Features
• App Sandboxing
• Permissions Model
• Verified Boot
• SELinux
• Encryption
• Google Play Protect
• Security Updates
• Keystore System
• Biometric Authentication
Android Security

2. Permissions
1. App Sandboxing 3. Verified Boot
Model

Each app runs in an Apps must request Ensures the device

isolated environment permissions to access boots only with
with a unique user ID sensitive data (e.g., authenticated system
(UID). camera, contacts). software.

It cannot access the

Detects tampering or
data of other apps From Android 6.0
rooting by verifying
unless permission is onwards, permissions
the boot chain using
explicitly given (via are granular and user-
cryptographic
content providers or controlled at runtime.
signatures.
shared storage).
Android Security

4. SELinux
6. Google Play
(Security-Enhanced 5. Encryption
Protect
Linux)

Android uses Full Disk Continuously scans

Implements mandatory
Encryption (FDE) or apps for malware
access controls (MAC)
File-Based Encryption during installation and
at the kernel level.
(FBE). in the background.

Defines strict rules

Protects data at rest, Helps identify and
about what system
requiring a PIN, remove harmful apps
processes and apps can
password, or biometric based on behavior
do, reducing attack
input to decrypt. analysis.
surfaces.
Android Security

9. Biometric
7. Security Updates 8. Keystore System
Authentication

A secure storage Enables fingerprint,

Google releases
location for face, or iris recognition
monthly patches to fix
cryptographic keys and for unlocking and
known vulnerabilities.
credentials. secure access.

Device manufacturers Keys stored here Often used in

and carriers push cannot be exported, combination with
updates to users based enhancing protection encryption to secure
on their support for authentication and device and app-level
policies. encryption. access.
Android Security

Feature Definition

Each app runs in its own isolated environment with a unique UID,
App Sandboxing
preventing other apps from accessing its data or code.

Apps must explicitly request permission to access sensitive data

Permissions Model like location, camera, contacts, etc. (especially enforced from
Android 6.0+).

Ensures the device boots only with verified and unmodified

Verified Boot
system images, preventing rootkits or boot-level malware.

SELinux (Security-Enhanced Enforces mandatory access control policies at the kernel level,
Linux) limiting what system processes and apps can do.
Android Security

Feature Explanation

Android uses file-based encryption (FBE) or full-disk encryption

Encryption
(FDE) to protect user data at rest. Requires authentication to decrypt.

Scans apps for malware before and after installation; also helps
Google Play Protect
detect suspicious app behavior during runtime.

Regular patches for vulnerabilities. Devices with long-term support

Security Updates
(like Pixel) receive monthly security updates.

Secure container for cryptographic keys and certificates. Used by

KeyStore System
apps and the system for authentication and encryption.

Fingerprint, face unlock, and iris recognition improve device security

Biometric Authentication
and control access to sensitive areas.
Android Security
Relevance in Mobile Forensics:

• Encryption and sandboxing are major challenges in forensic data extraction.

• Permissions help track what apps had access to specific data types.
• SELinux policies may log denials useful in tracing suspicious activities.
• Play Protect logs can hint at app removals or suspicious behavior alerts.

• These features restrict direct access to data unless bypassed or extracted through authorized methods.
• Investigators may need root access, custom recovery, or bootloader unlocking to bypass protections,
while respecting legal boundaries.
• Understanding Android security also helps in identifying tampering, malware presence, or data wiping
attempts.
Android File Hierarchy & File System
• Android’s file system is based on a Linux-like directory structure.
• Each application and system component stores data in defined locations with specific permissions.
• Understanding this hierarchy is crucial in mobile forensics to locate user data, logs, cache, databases,
and configuration files.

Reference:
https://www.scaler.com/topics/android/android-file-system/
Android File Hierarchy & File System

1. Root Directory (/) 2. /system

• Top-most level in Android’s file • Contains read-only OS files (apps,

system. libraries, binaries).
• Contains all system folders and • Default apps (pre-installed) and system
partitions. services reside here.
• Requires root access to view or • Only modifiable if the device is rooted
modify. or bootloader is unlocked.
• Important subdirectories include • Files like build.prop, default settings,
/system, /data, /cache, /vendor, etc. and init scripts are found here.
• Forensics: Navigating from here • Forensics: Helpful for identifying
provides full visibility into OS firmware version, pre-installed apps,
structure (if rooted). and custom ROMs.
Android File Hierarchy & File System

3. /data (User Data Partition) 4. /cache

• Stores user apps and their data: • Used for storing temporary system
/data/data/<package_name>/. data, downloaded updates, app
• Includes shared preferences, cache.
SQLite databases, cache, files. • Cleared periodically by the system
• Also stores user credentials or during factory reset.
(encrypted), chat history, logs. • May contain OTA update
• Accessible only with root packages and logs.
permissions or physical access • Forensics: Temporary evidence
with custom recovery. (e.g., update info, install logs)
• Forensics: Most valuable for app might be recovered here.
data extraction and user activity
tracking.
Android File Hierarchy & File System

5. /sdcard or /storage/emulated/0 6. /proc and /sys

• Internal shared storage for user- • Virtual filesystems exposing real-

accessible files like media, time kernel and system
documents, downloads. information.
• Apps can store user-created files • /proc holds running processes,
(e.g., WhatsApp images, CPU info, memory usage.
screenshots). • /sys exposes kernel modules,
• Does not require root to access. power, and device status.
• Accessible via ADB or file • Data is not stored here; it's
managers. generated dynamically.
• Forensics: Important for • Forensics: Snapshotting /proc
recovering deleted files, chat during live analysis can help
attachments, media artefacts. malware or rootkit detection.
Android File Hierarchy & File System

7. /mnt and /storage 8. /dev

• /mnt is the traditional mount point • Contains device nodes (block,

for external storage. character) for all hardware
• /storage provides paths to all components.
mounted volumes: internal, • Automatically managed by the
external SD card, USB OTG. kernel.
• Contains symlinks like • Forensics: Rarely holds user data
/storage/emulated/0, but useful when analyzing device
/storage/XXXX-XXXX (SD card drivers or kernel exploits.
UUID).
• Forensics: Important to trace
external device usage and file
transfers.
Android File Hierarchy & File System
Understanding the file hierarchy helps locate critical artefacts like:
• App data (chat logs, preferences, databases)
• Media files (images, videos, documents)
• System logs and temporary files
Access level depends on whether the device is rooted, unlocked, or encrypted.
Android File System & Hierarchy

Watch:
https://www.youtube.com/watch?v=FD_eVX_B1Dg
Android File System
Common File Systems

1. YAFFS2 (Yet Another Flash File System 2)

• Used in: Older Android devices with NAND flash storage

• Type: Flash-specific file system
Features:
• Supports wear-leveling, which helps prolong flash memory life.
• Stores data in chunks with tags, making recovery complex.
• Often found in Android versions below 4.0.
Forensic Notes:
• Needs special tools (like NAND image parsers) to interpret.
• Deleted files may be recoverable if not overwritten.
Android File System
Common File Systems

2. ext4 (Fourth Extended Filesystem)

• Used in: Most modern Android devices (since Android 2.3+)

• Type: Standard Linux file system
Features:
• Journaling capability (helps in data integrity).
• Supports large files and file permissions.
• Well-supported by forensic tools (e.g., Autopsy, Sleuth Kit).
Forensic Notes:
• Widely used in /system, /data, and /cache partitions.
• Artefacts can be extracted using Linux tools or forensic suites.
Android File System
Common File Systems

3. F2FS (Flash-Friendly File System)

• Used in: Newer Android phones (e.g., Samsung, OnePlus)

• Type: Designed specifically for NAND flash memory
Features:
• Better performance on flash storage than ext4.
• Uses log-structured file system approach.
• Supported in recent Android kernels.
Forensic Notes:
• Some forensic tools may have limited support.
• Custom kernel or emulators may be required to mount images.
Android File System
Common File Systems

4. VFAT / FAT32 / exFAT

• Used in: External storage like SD cards and emulated storage

• Type: Legacy DOS/Windows-compatible file systems
Features:
• No native support for Linux permissions or encryption.
• Compatible across platforms (Windows, Linux, Android).
Forensic Notes:
• Easy to mount and analyze.
• Deleted file recovery possible using basic tools (e.g., PhotoRec).
Android File System
Common File Systems

5. SquashFS

• Used in: Read-only system images (e.g., boot/recovery partitions)

• Type: Compressed, read-only file system
Features:
• Saves space on read-only areas.
• Cannot be written to without rebuilding the entire image.
Forensic Notes:
• Tools like unsquashfs can decompress and analyze it.
• Not useful for user data but important for firmware analysis.
Android File System
Common File Systems

6. OverlayFS (in newer Android versions)

• Used for: Dynamic system updates and A/B partitioning

• Type: Virtual file system overlay
Features:
• Merges read-only system with writable partitions.
• Helps implement seamless updates without modifying base system.
Forensic Notes:
• Requires understanding of base and overlay layers.
• Tools may need root access or custom recovery to expose layers.
Android File System

Why OverlayFS is Used in Android:

• Modifies read-only partitions (like /system) without
altering them directly.
• Enables seamless system updates through A/B
partitioning.
• Supports system integrity and rollback features.
• Helps manufacturers avoid re-signing full system images
for minor changes.

Forensics Relevance:
• Investigators need to analyze both lower (read-only) and upper
(OverlayFS) layers to understand system changes.
• Some changes (e.g., malware injections, tampering) may only
appear in the overlay, not in the base image.
• Root access or custom recovery may be needed to inspect
OverlayFS data during acquisition.
Android File System

Android Version OverlayFS Usage Purpose

Android 9 (Pie) Not used officially Used traditional system, vendor partitions

Android 10 (Q) Introduced Used experimentally with dynamic partitions

Used for read-only partitions to allow

Android 11 (R) Adopted broadly
seamless updates and rootless modifications

Required for Virtual A/B updates, dynamic

Android 12 (S) Standard partitions, and GKI (Generic Kernel Image)
support

Integral to seamless updates, modularization,

Android 13–14 Continued use
and system integrity