Data Recovery and Forensic Analysis Questions

Covers principles and practices of digital evidence recovery and artifact analysis. Topics include recovering deleted files from unallocated space, interpreting metadata such as timestamps and permissions, understanding file system artifacts, registry entries, browser history, cache, cookies, temporary files, event logs, application logs, memory and network traffic. Emphasizes how different artifacts contribute pieces of evidence, chain of custody considerations, integrity and provenance of artifacts, and appropriate tools and techniques for extracting and reconstructing activity.

EasyTechnical

35 practiced

Describe the role of cryptographic hashing in ensuring forensic evidence integrity. Compare MD5, SHA-1, and SHA-256 in terms of collision resistance and current best practices. Explain how you would implement hashing in an evidence workflow (image-level and file-level hashes), how often to re-hash, and how to handle a discovered hash mismatch.

MediumTechnical

23 practiced

You're provided with three drives that were part of a RAID 5 array, but one drive is missing and another shows partial corruption. Describe a methodical process to attempt logical reconstruction of the array: determining RAID parameters (chunk size, parity rotation), rebuilding missing data where possible, dealing with corrupted stripes, and tools you would use (for example mdadm, UFS Explorer, R-Studio). Discuss reporting limitations and when to stop reconstruction.

Sample Answer

**Overview / plan**I would proceed methodically: preserve evidence, identify RAID parameters, attempt logical reconstruction, handle corrupted stripes conservatively, and document everything for court.

**Step 1 — Preservation**- Create bit-for-bit images of all drives (write-blockers) using ddrescue; work only on images.- Record hardware/firmware IDs, serials, timestamps.

**Step 2 — Identify RAID parameters**- Inspect superblocks (mdadm --examine) for metadata version and layout.- If no superblock, use tools to infer: trial mounts with mdadm --build trying common chunk sizes (64K, 32K, 128K) and parity orders; check offsets with hexdump/strings for filesystem headers (NTFS, ext4) in reconstructed device.- UFS Explorer and R‑Studio can auto-detect chunk size and rotation — use them to corroborate.

**Step 3 — Reconstruct missing drive**- Use mdadm --build or UFS Explorer to assemble array marking the missing disk as missing; mdadm will calculate parity to present reconstructed device.- If a drive has partial corruption, map bad sectors (ddrescue log) and substitute zero/known-good blocks when parity allows.

**Step 4 — Handle corrupted stripes**- Detect stripes with unresolvable parity (more than one failure) — mark affected ranges as unreadable.- Attempt targeted reconstruction: - If only one block in a stripe is bad, use parity XOR of remaining blocks to rebuild. - If multiple blocks unknown, extract what’s recoverable and document gaps.- Use forensic viewers to validate filesystem integrity; export recovered files with hashes.

**Tools**- ddrescue, mdadm, hexdump/xxd, losetup; UFS Explorer, R‑Studio, X-Ways Forensics, e2fsck/testdisk for filesystem checks.

**Reporting & stopping criteria**- Stop reconstruction if further writes risk evidence integrity, reconstruction yields ambiguous data (multiple parity failures), or recovery becomes speculative.- Report: methods, parameters tried, artifact timelines, ranges unrecoverable, hashes of images and recovered files, confidence level for each recovered item, and limitations (possible overwritten data, uncertain parity rotation). Provide chain-of-custody and reproducible commands.

HardTechnical

20 practiced

Explain the decision-making process and technical steps for performing a JTAG or chip-off acquisition on an Android device when logical and typical physical acquisition methods fail. Discuss when each technique is appropriate, the specialized equipment and expertise required, the risks to device and evidence integrity, and how to validate and interpret raw NAND/eMMC dumps.

Sample Answer

**Overview / When to use which technique**- Use JTAG when the device boots but logical extraction is impossible (locked bootloader, disabled debug, intact board pins accessible). - Use chip‑off when JTAG inaccessible or NAND/eMMC corrupted, or you need raw die access (severe physical damage). Both are last‑resort, destructive (chip‑off more so).

**Decision process**1. Triage: document device condition, take photos, preserve power state and battery. Check for test pads, labels, eMMC presence. 2. Legal: obtain written authorization for destructive techniques. 3. Choose path: try deep logical + recovery first; if fail, attempt JTAG; if JTAG unavailable or fails, plan chip‑off.

**Technical steps — JTAG**- Identify JTAG/test pads from board schematics or teardown guides. - Clean pads, connect via JTAG adapter (e.g., RIFF Box, JTAGulator) to a workstation. - Halt CPU, read eMMC via DMA or read raw NAND using OpenOCD, JTAGBox tools. - Capture register maps, bootloader, partitions; log every action.

**Technical steps — Chip‑off**- Use hot‑air or IR rework station to remove package; note BGA reball risk. - Clean substrate, place in specialized socket or use NAND reader (e.g., PC‑3000 Mobile). - Read raw NAND/eMMC with multiple passes, extract vendor ECC/meta data.

**Equipment & expertise**- Tools: microscope, hot‑air/IR station, rework bench, chip readers (PC‑3000), JTAG adapters, logic analyzer, ESD control. - Skills: electronics soldering, BGA rework, NAND architecture, ECC and bad‑block handling.

**Risks**- Permanent device damage; heat can destroy die; wrong mapping corrupts evidence. Chain of custody and authorization critical.

**Validating & interpreting dumps**- Verify hashes of raw dumps; compare multiple reads to detect bit flips. - Identify and apply vendor ECC and bad‑block tables; reconstruct translation layer (FTL) for raw flash. - Use tools (PC‑3000, Flash Extractor, open-source nand2tetris style utilities) to parse partition tables, recover YAFFS2/EXT4, verify file system consistency and timestamps. - Document methodology, offsets, corrections, and uncertainties for court.

MediumTechnical

32 practiced

You are given an iOS iTunes-style backup (unencrypted) and an Android adb backup for a user account. Describe the steps and tools you would use to extract forensic artifacts such as messages, call logs, app data, photos, and browser history from each backup format. Highlight differences in artifact locations and limitations when dealing with logical backups vs physical acquisitions.

Sample Answer

**Situation & goal**I’m examining an unencrypted iTunes backup and an Android ADB logical backup to extract messages, call logs, app data, photos, and browser history, preserving forensic soundness and chain of custody.

**iOS (iTunes backup) — steps & tools**1. Verify integrity and generate hashes of backup folder.2. Use iOS-specific parsers: iPhone Backup Extractor, libimobiledevice tools, or Oxygen/ElcomSoft for deeper parsing.3. Locate artifacts (relative to Manifest.db and file mappings): - Messages: ChatStorage.sqlite (Library/SMS/ChatStorage.sqlite) → SMS, iMessage, attachments. - Call logs: CallHistory.storedata or CallHistoryDB (Library/CallHistoryDB/CallHistory.storedata). - App data: App domain folders in Applications/, check Library/Preferences (.plist) and Documents/ for app DBs (usually SQLite). - Photos: Media/DCIM/ and Backup/Media or MediaDomain/Media/DCIM; also review MediaMetadata. - Browser history: MobileSafari/Library/Safari/History.db and WebKit caches.4. Parse plists with plutil or plistlib to extract account settings and timestamps.5. Validate extraction, export evidence artifacts, and document file paths and timestamps.

**Android (ADB backup — logical) — steps & tools**1. Verify backup size/hash; convert .ab (Android backup) to tar with Android Backup Extractor or dd + OpenJDK tools.2. Use Autopsy/AccessData/AXIOM or manual extraction (tar) then inspect app folders.3. Artifact locations: - Messages/call logs: If included, found in /data/data/com.android.providers.telephony/databases/mmssms.db and /data/data/com.android.providers.contacts/databases/contacts2.db (call log). Logical backups often omit these unless rooted. - App data: /data/data/<package>/databases/ and shared_prefs/. Look for SQLite DBs. - Photos: /sdcard/DCIM/, /sdcard/Pictures/ or MediaStore entries. - Browser history: Chrome: /data/data/com.android.chrome/app_chrome/Default/History (SQLite).4. Parse SQLite DBs with sqlite3 or forensic tools; extract timestamps (Unix epoch, convert timezone), attachments, and blobs.

**Differences & limitations**- Logical backups capture filesystem-level files but rarely include deleted data, unallocated space, or low-level artifacts; physical acquisitions allow carving/deleted recovery.- iTunes backup maps sandboxed files and often includes more app data for non-rooted iOS; Android ADB logical backup may exclude /data for unrooted devices (missing SMS/call/app private data).- Timestamps: iOS uses Cocoa epoch (2001-01-01) in some stores — convert appropriately; Android uses Unix epoch (1970-01-01).- Encrypted backups or apps with encryption/authentication may render content inaccessible.- Always document tool versions, commands, hashes, and maintain chain of custody.

**Example commands**- Convert Android .ab to tar: use "android-backup-extractor" or:

bash

java -jar abe.jar unpack backup.ab backup.tar
tar -xvf backup.tar

- Query SQLite:

bash

sqlite3 ChatStorage.sqlite "SELECT datetime(date/1000000000 + strftime('%s','2001-01-01'),'unixepoch') FROM message;"

**Conclusion / best practices**Prioritize preservation, use validated tools, record all transforms, and note limitations of logical backups in reports (no deleted/unallocated data, potential missing private app data on Android).

MediumTechnical

24 practiced

Explain how BitLocker (Windows) and FileVault (macOS) full-disk encryption operate at a high level: key storage, TPM involvement, user passphrases, and recovery keys. For each describe practical acquisition strategies when a system is powered on (live) versus powered off, and discuss relevant legal or organizational steps to obtain recovery keys (for example Active Directory recovery or cloud backups).

Sample Answer

**High-level operation (BitLocker / FileVault)**

- BitLocker (Windows): volume master key (VMK) encrypts disk; VMK wrapped by one or more key protectors — TPM-only, TPM+PIN, password, or external recovery key. TPM stores measurements and releases VMK when platform state matches and (optionally) user PIN supplied.- FileVault 2 (macOS): disk encryption key (DEK) encrypts volume; DEK protected by users’ login passwords tied to their local keychains and by a recovery key. On T2/Apple Silicon Macs the Secure Enclave / SEP handles key escrow and hardware root of trust.

**Live (powered on) acquisition strategies**

- Memory acquisition first: capture RAM immediately (e.g., FTK Imager, Belkasoft, DumpIt). If user logged in and disk unlocked, keys/DEK or wrapped secrets often in memory and can be extracted.- For BitLocker TPM+PIN, capturing RAM after PIN entry may reveal VMK; also collect TPM event logs, system state, running processes, and hibernation file.- For FileVault, if user unlocked the session, key material may be in kernel memory or the process space of securityd; acquire full physical memory and keychain files.

**Powered-off acquisition strategies**

- If powered off and disk locked, you generally need the user passphrase or recovery key. Cold-boot/ DMA attacks are rarely practical and risky; T2/Secure Enclave and modern TPMs resist these.- For BitLocker: try recovering a 48-digit recovery key from enterprise stores (AD, Azure AD, Intune) or from printed/USB recovery media.- For FileVault: retrieve institutional recovery key or iCloud escrowed key if the user enabled it.

**Organizational / legal steps to obtain recovery keys**

- Query Active Directory: BitLocker recovery passwords can be stored in AD object attributes (msFVE-RecoveryPassword). Requires domain admin access or legal process (warrant/subpoena).- Azure AD / Intune: request key material from organization’s Intune/Azure AD portal — legal authorization required.- Apple iCloud / MDM: FileVault recovery keys may be escrowed to iCloud or an MDM (Jamf, Workspace ONE). Engage legal/in-house counsel to obtain cloud provider/MDM records or use enterprise MDM admin to retrieve.- Documentation and chain-of-custody: obtain written authorization, preserve logs, record timestamps and procedures; include forensic images and hashed evidence for court admissibility.

**Practical tips for examiners**

- Prioritize volatile evidence: seize live RAM, attached TPM state, and system logs.- Avoid powering on a seized machine without authorization — if necessary, follow lab-approved live response checklist and document everything.- When keys aren’t available, document attempts and escalate to legal/IT to access escrow/AD/cloud backups.

Unlock Full Question Bank

Get access to hundreds of Data Recovery and Forensic Analysis interview questions and detailed answers.

Join thousands of developers preparing for their dream job.