CHFI Mobile and Malware Forensics Practice Question
A forensic analyst is examining an Android device using ADB extraction. Which TWO statements about ADB extraction are true?
⚠ Common exam trap
The CHFI exam often tests the misconception that ADB extraction provides full file system or physical access, but the trap is that ADB is a logical extraction method with significant privilege restrictions, and candidates confuse 'ADB backup' or 'ADB pull' with physical imaging capabilities.
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
✓
ADB extraction requires USB debugging to be enabled on the device
Option A is correct because ADB (Android Debug Bridge) communication over USB is only possible when the device has USB debugging enabled in Developer Options; without it, the adb daemon on the host cannot establish a session with the device. Option E is correct because, once USB debugging is on, the device presents an RSA key fingerprint prompt and the host must be authorized (the device stores the host's public key in adb_keys); an unauthorized host is rejected, so the analyst must accept the prompt or pre-provision the key. Option B is wrong because non-rooted ADB access is confined to the shell user's permissions and cannot read protected app data or system partitions. Option C is wrong because ADB extraction is a logical acquisition (e.g., adb pull, adb backup) and cannot produce a bit-for-bit physical image of the flash storage. Option D is wrong because deleted files in unallocated space are only recoverable from a physical image or raw flash dump, not through ADB's logical file-level access.
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 extraction requires USB debugging to be enabled on the device
Why this is correct
ADB cannot communicate with an Android device unless USB debugging is enabled in Developer Options, which starts and configures the adbd daemon to accept commands over the USB transport; without it, the device appears offline to the host. For a forensic analyst, toggling this setting modifies system settings, so its status and any resulting evidence-integrity impact must be documented before beginning logical acquisition.
- ✗
ADB extraction allows full file system access without root
Why it's wrong here
By default, ADB accesses the device through the adbd daemon running as the unprivileged shell user (uid 2000), so it cannot read app-private data under /data/data or system directories protected by SELinux and Android's app sandbox. Full file system access normally requires root privileges, an unlocked bootloader with a custom recovery, or a physical acquisition method, not standard ADB commands.
- ✗
ADB extraction can acquire a physical image of the device
Why it's wrong here
ADB extraction copies files at the logical file-system level and never produces a bit-for-bit replica of userdata; the adbd daemon and Linux kernel do not expose raw block devices to the ADB interface. A physical image—including partition layout, slack space, and all deleted blocks—requires chip-off, JTAG, or forensic boot images, and is categorized as physical acquisition rather than ADB logical extraction.
- ✗
ADB extraction can recover deleted files from unallocated space
Why it's wrong here
Standard ADB logical extraction only enumerates active, accessible files through a readdir/read-based process, so it does not and cannot read the unallocated blocks where deleted file contents reside. Since adbd does not provide raw storage access, forensic carving for deleted data from free space cannot be performed through ADB and would require a physical image to recover remnants.
- ✓
ADB extraction requires the device to be authorized to the computer
Why this is correct
Before any ADB session proceeds, the device must have accepted the host's public key: when a new computer connects, Android displays a prompt with the computer's RSA key fingerprint and a request to allow USB debugging, and until the user confirms, adbd refuses a session with 'device unauthorized' status. The authorized host keys are stored under /data/misc/adb/adb_keys, so an analyst encountering an unauthorized dialog must obtain lawful user approval to bind the computer's key, since the process cannot be bypassed on a locked or encrypted device.
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
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.