Android Artifact Analysis: Extracting Evidence from System and App Data

12/07/2025

1. Acquisition Methods

#

The acquisition process consists of creating forensic images and collecting all necessary data from the seized device.
We frequently encounter eight types of acquisition: Manual, Logical, Physical, File-System, Triage, JTAG, Chip-Off, Micro Read.

Micro Read is an acquisition method that involves physically reading the memory chip cells using an electron microscope. Very expensive and rarely practiced, it is reserved for highly sensitive cases, typically when all other techniques have failed.

Triage Acquisition, on the other hand, is commonly used to quickly extract targeted data either in the field (Live Triage) or in the lab (Post-Mortem Triage) to prioritize which devices to examine.

Due to their specific nature, these two methods will not be further detailed in this article.

Manual Acquisition is the simplest and least technical method. It involves exploring the device directly via its interface without using any specialized tool.
It is sometimes used in minor administrative investigations or during border controls when access to forensic tools is limited.
This method does not allow recovery of deleted or hidden data.

Logical Acquisition consists of extracting, in a forensically sound manner, the user-accessible files and folders from the device’s logical partitions.
This method uses the operating system’s interfaces via a wired or wireless connection. It allows recovery of data visible to the user, such as call logs, messages, contacts, calendars, multimedia files, etc. However, it does not provide access to system-protected files, free space, or permanently deleted data.
Logical acquisition is widely supported by mobile forensic tools and can be performed on most unlocked devices. It is fast, reliable, and may occasionally recover files marked for deletion that are still present on the system.

Physical Acquisition consists of making a full bit-by-bit copy of an Android device’s internal storage. Unlike logical acquisition, it allows extraction not only of visible files but also of deleted, hidden, system-protected data and unallocated space. It may also include portions of RAM (Random Access Memory), although this is often limited depending on the device model, the method used, and the device’s state at the time of acquisition.
This method is particularly useful when anti-forensic techniques are suspected or when recovering deleted or hidden files is critical.
By obtaining a raw memory image, the analyst can search for residual artifacts, analyze partially deleted fragments, and detect inconsistencies indicating digital tampering or sabotage.

File-System Acquisition is an intermediate method between logical and physical acquisition. It allows extraction not only of user data but also the file system structure, system configurations, application settings, and certain system files. This method can, for example, recover deleted data from partially existing SQLite databases. The Android phone generally needs to be unlocked, and USB debugging enabled for this to work.

JTAG Acquisition allows direct access to internal memory via JTAG ports on the motherboard. It requires disassembly of the phone and physical connection to test pins. It can be used even if the device is locked or USB debugging is disabled. The data extracted is in raw format, often encrypted.

Finally, Chip-Off Acquisition involves physically removing the memory chip from the phone to extract a bit-by-bit image. Used on heavily damaged devices. Requires advanced technical skills and specialized equipment.

1.1 Common Acquisition Tools

#

Here is a non-exhaustive list of tools that can be used during acquisition phases:

Non-exhaustive list

1.2 Technical Constraints

#

Acquisition capabilities are heavily influenced by the Android version and enabled encryption mechanisms. Starting with Android 7, full storage encryption (FBE/FDE) is enabled by default, restricting access to data if the device is locked. Recent versions (Android 10+) also enforce restrictions on access to system partitions and logs, even for forensic tools. These protections enhance security but complicate extractions, sometimes making physical or file-system acquisition impossible without root access or an exploitable vulnerability.

Additionally, Android distinguishes two critical states in a forensic context:

• BFU mode (Before First Unlock): as long as the user has not unlocked the device after a reboot, most data remains inaccessible, including metadata and system logs. The file tree may be visible, but content is encrypted and unusable.
• AFU mode (After First Unlock): once the device has been unlocked at least once since boot, certain encrypted data becomes available in memory via active decryption keys. This allows a richer extraction, although still limited by software and hardware protections.

Thus, the state of the device at the time of seizure (on/off, locked/unlocked) has a major impact on the acquisition potential and the intervention strategy.

1.3 Legal Focus: Unlocking a Mobile Device

#

What happens if a device is locked? Can the suspect be forced to unlock it?

In French law, forced unlocking of a mobile device is regulated by several articles in the Penal Code:

• R226-3 and R226-12 govern the use of extraction tools exploiting vulnerabilities (e.g., MSAB, Cellebrite). Their use requires specific judicial authorization.
• R226-7 mandates that only certified individuals may use such tools.
• 434-15-2 requires a suspect to provide their decryption secret (password, key). Refusal constitutes a criminal offense punishable by several years of imprisonment and fines up to €270,000.

2. Forensic Analysis - Locating and Exploiting Common Artifacts

#

On Android, the actual location of artifacts (SQLite contact databases, call logs, SMS/MMS, etc.) is never fixed: it depends on the region- or carrier-specific firmware, known as the CSC (Country/Carrier-Specific Code), which reflects the regional customization of the firmware. Each CSC includes its own system apps and settings; it may introduce or relocate providers (e.g., com.sec.android.provider.logsprovider for Samsung) and automatically enable File-Based Encryption, which moves certain databases into the device-protected directory (/data/user_de/0/...). Additionally, local legal requirements (GDPR, call recording bans, lack of Google services in China, etc.) force manufacturers to alter or disable certain features, generating different paths or empty databases.
For the forensic analyst, the first step is to identify the active CSC (via getprop ro.boot.hwc or dial #1234# on Samsung), then systematically map /data/data/*/databases/ and /data/user_de/*/databases/ to locate the correct files before extraction or parsing.

1234 Samsung code: AP (main firmware), CP (modem — radio communication), CSC (active Country/Carrier-Specific Code)

Contacts and Call Log Artifacts

#

Contacts and call logs have no single location:

• Depending on model, settings, and installed apps, they may be stored in the Google account, phone internal memory, or SIM card.
• Before any manual acquisition, always verify the source indicated by the device to avoid missing data stored elsewhere.
• On Android, contacts and call logs are often grouped in the same SQLite database, but this varies by manufacturer and region.

On the Android file system, SQLite database locations for contacts and call history mainly vary with OS version and manufacturer overlay:

• “Classic” = historical convention from early generations (≤ 2015): more flexible paths and sometimes contact-log merging.
• “AOSP (recent)” = modern convention from Google’s reference code (≥ Android 7): explicit package names, more stable schemas.

SMS/MMS Artifacts

#

On Android, SMS/MMS messages are generally stored in mmssms.db, a SQLite database managed by the “telephony” provider. The exact location and schema may vary depending on brand, region, or encryption.

• Standard Location
  /data/data/com.android.providers.telephony/databases/mmssms.db
  SQLite 3 database containing SMS, MMS, drafts, metadata (number, timestamp, status, attachments).

• Manufacturer / Overlay Variants
  Folder or filename may be modified (e.g., /databases/msgstore.db in some Chinese OEMs).
  Overlays may separate MMS and SMS into different databases or encrypt them when the system is locked.

OEM = Original Equipment Manufacturer

Network and Location Artifacts

#

Cellular network data on Android can be found in /data/data/com.google.android.location/files/:

• cache.cell → last 50 cell towers visited (antenna ID, timestamp)
• cache.wifi → last 200 Wi-Fi access points (MAC + latitude/longitude)

These are in proprietary binary format; use tools like android-locdump or forensic suite parsers (Cellebrite, Magnet, Oxygen) to decode them.

It is also possible to extract Google Maps history from /data/data/com.google.android.apps.maps/databases/:

• da_destination_history.db → departure/destination coordinates for navigation
• search_history.db → searches and suggestions for locations

Note: These files require full file system access (root or agent); once extracted, they reveal a rich history (cell towers, Wi-Fi, routes, queries) valuable for reconstructing user movements.

System Artifacts

#

On Android, the /data/system/ directory (root access required) contains key system artifacts:

By combining these files, the analyst can: list all installed apps, reconstruct usage chronology, identify cloud accounts, and attempt to crack the screen lock (offline attack on password.key / gesture.key). All these traces are in the same place; a full file system dump is sufficient to extract and correlate them.

Multimedia File Artifacts

#

On Android, multimedia files are split between shared storage (visible without root) and private app storage; locating them properly is essential. Photos/videos taken with the camera are stored in /storage/emulated/0/DCIM/ (and possibly the SD card), with EXIF metadata (date, model, sometimes GPS). Apps manage their own media: since Android 11, they usually store them under /Android/media/<package>/… (e.g., WhatsApp/Media/, where each image, video, or voice note remains unencrypted), while more secure apps like Signal encapsulate content as BLOBs in internal SQLite databases (/data/data/<package>/databases/), accessible only with root.
Also consider system thumbnails and caches: often surviving the deletion of originals, they confirm a file’s past presence.

BLOB (Binary Large Object) = SQL field type for binary data. No parsing by SQL engine; it simply stores and returns binary streams.

Cross-referencing these sources enables reconstruction of activity timelines (installations, launches, shares, movements) and identification of deleted content via persistent thumbnails or BLOBs. Hence, Android’s probative value depends on exhaustive collection and precise correlation between system artifacts and application data.

Android forensic analysis requires not only technical expertise but also a deep understanding of how system and application artifacts are structured, stored, and encrypted. By accurately identifying, extracting, and correlating these artifacts, investigators can reconstruct meaningful timelines and uncover critical evidence — even when data has been deleted or obscured.