Android File System
Android File System Deep Dive: A Forensic Perspective
During my recent forensics certification and first year working on mobile forensics, I've discovered that understanding Android's file system structure is essential for successful investigations. While the basics seem straightforward, there's a lot of nuance that isn't covered in standard documentation. Here's what I've learned so far.
File System Structure: The Real Deal
The Android file system isn't just a single entity - it's a collection of partitions, each serving specific purposes. Here's what I typically encounter:
/data Partition
This is where most of our evidence lives. I found crucial evidence in these locations:
/data/data/[package_name]/ - Each app gets its own sandbox here
/data/media/ - The internal storage that shows up as main storage to users
/data/system/ - System settings and configurations
Quick tip: When you're looking at messaging apps, check both /data/data/[app]/databases/ AND /data/data/[app]/shared_prefs/. I recently found message attachments referenced in shared preferences that weren't in the main database.
/system Partition
While this is mounted read-only during normal operation, examining it can reveal:
Modified system apps
Custom ROMs
Potential malware disguised as system files
/cache Partition
Don't skip this! Last week, I recovered deleted browser data from /cache that wasn't available anywhere else. Cache often contains:
Failed OTA updates
Temporary app files
Emergency logs
File Systems in Use:
Modern Android devices typically use either ext4 or f2fs. During training, I learned that Samsung often uses f2fs for better flash memory performance. This matters because:
ext4 journal can contain recently deleted file information
f2fs requires different carving tools than ext4
Recovery of deleted files varies significantly between the two
! I made the mistake of using ext4 tools on an f2fs partition - complete waste of time. Always verify the file system type first!
Encryption:
Every device I've examined in the past six months has had either:
Full Disk Encryption (FDE) - Everything encrypted with one key
File-Based Encryption (FBE) - Different files can have different keys
Tip: With FBE, look for DirectBoot storage. Some apps store data there that's accessible before the user unlocks the device.
Practical File Recovery
Here's what actually works when recovering deleted files:
For ext4: Examine journal first, then try file carving
For f2fs: Focus on block-level analysis
Check /data/media/.trash/ - some OEM skins use this for recently deleted files
Common issues I've run into:
TRIM makes recovering deleted files harder on newer devices
Some apps use secure deletion - overwriting files before deletion
Encrypted devices need to be unlocked before file recovery
File Timestamps:
Something they don't teach in training: Android's timestamp handling varies by manufacturer. I've seen:
Some devices store timestamps in UTC
Others use local time
A few mix both
! Document the time settings before starting analysis. Trust me, explaining timestamp inconsistencies in court isn't fun.
Tips:
1. Always check /data/misc/wifi/ for network details
2. /data/system/packages.xml reveals installed app history
3. /data/system/sync/ shows what accounts were syncing
4. Look for backup files with .bak extension
Moving Forward
I'm still learning new aspects of Android forensics every day. Currently studying up on:
Dynamic partitions in Android 10+
New storage permission models
Cloud storage integration
The field keeps changing, but solid understanding of file system basics has helped me adapt. Would love to hear thoughts from other analysts about their experiences with newer Android versions.
Note: This reflects my experience level as a newer analyst - always verify current best practices for your specific case requirements.
Author:
Hasan Hashim
Cyber Security and Digital Forensics