CHFI Mobile and Malware Forensics Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  adb backup -f backup.ab -apk -shared -all

  Why this is correct

  The `adb backup -f backup.ab -apk -shared -all` command invokes Android's Backup Manager over ADB to create a non-root full logical backup, writing an Android Backup (AB) archive that contains installed APKs (-apk), shared/sdcard data (-shared), and all application data (-all). In forensic triage, this is the correct method to capture user-visible app data without altering the device's system partition, although it cannot retrieve protected app-private files from apps that disable backup or obtain deleted data. The resulting backup.ab can later be parsed with tools like Android Backup Extractor (abe) to reconstruct app content for analysis.

• ✗

  adb shell dd if=/dev/block/mmcblk0 of=/data/backup.img

  Why it's wrong here

  The command `adb shell dd if=/dev/block/mmcblk0 of=/data/backup.img` is a physical acquisition technique that copies the raw eMMC block device bit-for-bit, but it is unavailable on production Android devices without root access because the shell user lacks read permission to the block node and SELinux blocks it. Even if executed with root, writing the image to `/data/backup.img` on the same device contaminates the evidence: the write itself modifies the filesystem, can overwrite free-space/deleted data, and leaves a copy on the suspect medium rather than a forensically sound external storage. It is not a standard ADB backup command and is only appropriate for a targeted chip-off or rooted physical dump with output redirected to an examiner-controlled workstation via `adb shell` and `dd` piped to a local file.

• ✗

  adb pull /data/data/

  Why it's wrong here

  The command `adb pull /data/data/` attempts to recursively copy the application-private data directory from the device to the workstation, but on a non-rooted forensic device, the adbd daemon runs as the `shell` user, which cannot traverse `/data/data` due to Unix permissions and SELinux restrictions; this results in permission denied errors or incomplete pulls of world-readable subdirectories only. If the device were rooted, the pull would still lack the structured Android Backup container, would not include APKs or shared storage, and the live file copy would not provide a coherent snapshot, as app files can change while being read, risking hash mismatches and missing SQLite WAL/SHM sidecars. Thus, `adb pull` is a file-explorer-level retrieval tool, not an ADB backup operation.

• ✗

  adb restore backup.ab

  Why it's wrong here

  The command `adb restore backup.ab` is the inverse of acquisition: it pushes data from a backup archive onto the device, overwriting existing applications and their data. Running this on a suspect device during an investigation destroys current evidence by replacing it with archived content, and it also alters the device's backup-token state, forcing data-breach indicators. Because the question asks for a command that creates a backup, `restore` is fundamentally wrong; it consumes a `.ab` file rather than producing one.

Go deeper

Related to this question