CHFI Mobile and Malware Forensics Practice Question
A forensic analyst is examining an Android device for evidence of a specific app's usage. Which TWO locations are MOST likely to contain app-specific data that can be recovered through a logical acquisition?
⚠ Common exam trap
The CHFI exam often tests the misconception that /system/bin/ or /proc/ contain app-specific data because they sound like common storage locations, but in Android forensics, only /data/data/ and external storage paths like /mnt/sdcard/Android/data/ hold recoverable app artifacts during logical acquisition.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
/data/data/
Option B (/data/data/) is correct because this is the primary internal storage path where Android stores each app's private data, including databases, shared preferences, and cache files, and on a rooted or debuggable device it can be captured during a logical acquisition. Option C (/mnt/sdcard/Android/data/) is correct because it is the app-specific external storage directory (also referenced as /sdcard/Android/data/ or /storage/emulated/0/Android/data/) where apps place user- and app-generated files such as downloads, media, and OBB assets that are recoverable via logical extraction. Option A (/system/bin/) is not app-specific data but the read-only system partition containing OS binaries and shell tools. Option D (/proc/) is a virtual kernel filesystem exposing runtime process and system state, not persistent app evidence. Option E (/init.rc) is the Android init startup script defining boot-time services and actions, not user app data.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
/system/bin/
Why it's wrong here
/system/bin/ is part of the read-only system partition and contains the Android OS's core executables and daemons, such as app_process, toolbox, and service binaries. These files are never modified by user-installed applications and are not a per-app storage area, so they cannot contain user data, databases, or shared preferences. While the directory may be forensic-interesting for firmware versioning or tampering, it holds no app-level evidentiary data relevant to this question.
- ✓
/data/data/
Why this is correct
/data/data/ is the definitive internal storage directory for each installed Android app, where the system creates a package-owned folder containing databases, shared_prefs, files, cache, and code-cache. This location is protected by the app's UID and Linux file permissions, and it is where applications persist user-generated content, login tokens, and SQLite databases that are prime forensic evidence. For both physical and logical acquisitions, this directory is the primary target for recovering app artifacts.
- ✓
/mnt/sdcard/Android/data/
Why this is correct
/mnt/sdcard/Android/data/ is the external app-data directory, typically symlinked or mounted on the shared emulated storage (e.g., /storage/emulated/0/Android/data). Applications write large files, media, or caches here when they need more space than internal storage allows, and this folder is package-namespaced just like /data/data/. However, since Android 6 and especially with scoped storage, access is more restricted, but the directory still contains app-specific evidence such as downloaded files, logs, or media that can supplement what is found on internal storage.
- ✗
/proc/
Why it's wrong here
/proc/ is a procfs virtual filesystem that exposes kernel and process metadata in real time, such as CPU, memory, file descriptors, and per-process statistics. It exists only in RAM and is dynamically regenerated on every boot, so it contains no persistent data written by apps or the user. Forensic imaging should ignore /proc because it is ephemeral and not a storage destination for application evidence; attempting to parse it yields transient system state, not historical app data.
- ✗
/init.rc
Why it's wrong here
/init.rc is a top-level Android init script written in the Android Init Language, executed by the init process at system startup to define services, actions, and mount/device rules. It is a static boot configuration file that is not writable by applications or user interactions, and it does not store runtime data. Its forensic value is limited to understanding boot behavior or customization (e.g., adding a daemon), but it cannot be the location where an app's evidentiary data resides.
Go deeper
Related to this question
About these practice questions
One of 745 original CHFI practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CHFI practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CHFI exam.