Case Study 1 — SanDisk USB Flash Drive

Incident: Critical Excel workbooks were overwritten when a Windows deployment image was accidentally applied to the USB device (wrong target selected).
Symptoms observed: Device enumerated normally; partition table showed a recent bootable layout; previously visible data absent.

Forensic Objectives

1. Preserve evidence and halt wear levelling writes.

2. Acquire a block-level clone with full error telemetry.

3. Determine overwrite depth/geometry (MBR/GPT, filesystem header, FAT/exFAT/NTFS metadata).

4. Reconstruct prior filesystem structures and recover Excel workbooks—intact where possible, fragment-reassembled where necessary.

Technical Procedure

1) Write-block & imaging

• Attached the SanDisk USB through a hardware write-blocker (USB bridge that enforces SCSI-2/Mode Sense locks).

• Identified controller and flash characteristics (VID/PID, SATA bridge quirks, 512e sector presentation).

• Performed a two-phase acquisition using ddrescue: quick forward pass with 64 KiB blocks (no retries) to map stable regions, then an adaptive retry pass (down to 4 KiB) on bad or unstable sectors. All operations logged with a persistent mapfile.

• Result: clean clone with sparse error regions limited to the first ~4–6 GiB—consistent with a Windows imaging tool writing from LBA 0 upwards.

2) Layout & overwrite analysis

• The current device signature: protective MBR with GPT, single NTFS partition, and a BOOTMGR/BCD tree—strongly indicative of a Windows PE or deployment image.

• Searched the clone for legacy filesystem artefacts using raw signature sweeps: exFAT BS (EB 76 90), FAT32 BS (EB 58 90/EB 3C 90), exFAT upcase table, and directory entries.

• Located a backup exFAT boot sector and allocation bitmap beyond the overwritten prefix. Overwrite depth assessment showed initial 1–2 GiB fully replaced, mid-range partially intact, tail end preserved.

3) Filesystem reconstruction (exFAT)

• Recovered the exFAT Allocation Bitmap and Upcase Table and rebuilt a synthetic Volume Boot Record.

• Using the recovered exFAT directory entries and allocation chains, re-mapped cluster runs for candidate Excel files.

• Where directory metadata was missing, switched to carving + validation:

  • Signature-based detection for Office Open XML (PK\x03\x04), enforcing ZIP central directory sanity (EOCD, CEN offsets), then validated the xl/workbook.xml and shared strings.

  • Repaired partially overwritten ZIPs by rebuilding central directory structures and re-inflating individual XML parts; replaced missing [Content_Types].xml from a template when needed, preserving relationships (.rels) and sheet bindings.

4) Fragment reassembly

• For fragmented XLSX, used cluster entropy, cross-file similarity and deflate stream continuity to align fragments; verified with XML schema checks and Excel’s internal CRCs (ZIP file header CRC-32 and per-entry CRCs).

• Where cell data was present but workbook control parts damaged, reconstructed minimal viable workbooks and remapped orphaned worksheets to new workbook manifests.

Outcome

• Full, verifiable recovery of all high-priority Excel workbooks identified by the client (hash-verified where historical checksums were available). Some low-value temp files remained unrecoverable due to complete overwrite within the first 1–2 GiB. A formal inventory with SHA-256 digests was delivered.

Case Study 2 — SanDisk Ultra 128 GB SDXC (UHS-I)

Incident: Card became extremely slow; opening images/videos took minutes. High-value content (wedding photos and 1080p/4K H.264/HEVC video). Boots and a local shop could not assist.
Symptoms observed: Timeouts under standard USB readers; sporadic read backs; exFAT volume intermittently mountable; SMART-like telemetry not available (typical for SD).

Forensic Hypothesis

• Controller-level read-retry escalation (ECC at/near correction limit), worn NAND with failing pages and expanding bad block list. Possible FTL metadata drift. The “very slow” symptom typically indicates the controller is re-reading pages many times to achieve ECC decode.

Technical Procedure

1) Controlled acquisition (logical first)

• Avoided consumer readers; used a forensic UHS-capable reader with adjustable clock and voltage.

• Throttled to conservative modes (fallback from SDR104 to SDR25), increased inter-read delays, disabled OS caching to reduce re-reads.

• Two-stage ddrescue imaging with extensive telemetry: first a no-retry map to identify stable regions, then targeted multi-retry on unstable zones (up to 5–8 passes with cooling periods).

• Result: ~92–95% of LBAs cloned; remaining regions exhibited persistent uncorrectable errors, suggesting controller-visible page failures.

2) Monolith pathway (chip-level) — invoked due to persistent unreadables

• SanDisk SDXC is a monolith; we evaluated non-destructive microscopic pad access first (test pads for D0/D1/CMD/CLK/VCC/VSS). Signal integrity proved insufficient for full extraction.

• Proceeded with monolith milling to expose bond wires and pads (under microscope, micro-abrasive). Wired to a specialised flash reader.

• Acquired raw NAND dumps per die/plane with full spare/OOB areas.

3) NAND-level reconstruction

• Determined NAND parameters via analysis of dump: page and block sizes, plane count, interleave, BCH/LDPC ECC scheme, XOR/scrambler patterns, and data/metadata interleave.

• Corrected ECC and removed XOR/scramble; rebuilt the Flash Translation Layer (FTL) logically:

  • Reconstructed logical-to-physical mapping using translation pages and journalled block tables found in spare areas.

  • Resolved pair order and die interleave; handled factory bad block tables and grown bads.

• Emitted a coherent logical image of the card’s exFAT volume from the corrected physical data.

4) Filesystem & media repair

• Mounted the exFAT image read-only; validated the Allocation Bitmap and directory tree.

• For JPEGs: extracted by allocation chains; verified with JFIF/SOI-EOI markers and entropy checks; repaired truncated EXIF where needed.

• For MP4/MOV: several files had damaged or missing moov atoms (index). Used stream-copy re-indexing to rebuild container metadata from mdat (media data) by parsing H.264/HEVC NAL units (SPS/PPS/VPS) and audio tracks (AAC) to reconstruct timescales, durations, and sample tables.

• Delivered images and videos with original timestamps (from EXIF and QuickTime mvhd/tkhd where present) and folder hierarchy; supplied a playability report (100% playable for client-flagged sets; a handful of long-form clips required index rebuild but were complete).

Outcome

• Near-complete recovery of wedding photos and videos. The final gap corresponded to sectors mapped to NAND pages with total data loss (both primary and mirror pages failed)—no consumer tool can recover those without valid ECC parity. Client received a formal report and SHA-256 digests for all deliverables.

Case Study 3 — MacBook Pro Not Booting / External Media Not Recognised

Incident: MacBook Pro would not recognise external HDD/SSD; suspected firmware/bridge issue. Apple Store could not restore operability, replaced the internal SSD, and referred the client to us for data recovery.
Environment: APFS on Intel T2 or Apple Silicon (both pathways covered below). FileVault status unknown at intake.

Key Constraints (Apple Platform Security)

• T2 and Apple Silicon encrypt internal storage at rest by default. Raw chip-off recovery is not viable: keys are held in the SEP (Secure Enclave) and bound to the SoC. Data access must flow through Apple’s secure path with valid authentication (password/recovery key).

• External boot/target access may be policy-restricted (Secure Boot settings).

Technical Procedure

1) Non-destructive access path

• If Intel T2: attempted Target Disk Mode over USB-C/Thunderbolt 3 to a lab Mac, or Share Disk from macOS Recovery (⌘-R) to expose the internal APFS container.

• If Apple Silicon: used 1TR (Power+Hold → Options) and Share Disk, or a DFU-attached second Mac with Apple Configurator to Revive (restore bridgeOS/firmware without erasing user data).

• In both cases, we never wrote to the client disk; all operations were on a hardware write-blocked target once imaged.

2) Authentication & container access

• With client authorisation, used the user password/FileVault recovery key to unlock the APFS container (diskutil apfs unlockVolume).

• Listed snapshots (diskutil apfs listSnapshots) and captured the pre-failure snapshot if available—this often avoids post-crash journal damage.

3) Forensic imaging

• Performed a block-level image of the unlocked APFS volume group with asr or ddrescue via Thunderbolt, capturing I/O error telemetry.

• If the machine refused to present storage externally (common when USB/TB controllers are unstable), we used DFU Revive (not Restore) to reinstall bridge firmware while preserving the user volume, then repeated Share Disk / Target Disk Mode.

• For Macs with removable blade SSDs (2013–2015), we used an Apple-compatible NVMe carrier to image the module directly; for soldered SSDs (2016+), access remained over the Apple data path only.

4) APFS repair & data extraction (on the clone, never the original)

• Validated APFS container/superblocks and volume structures with fsck_apfs (read-only checks first).

• If the live volume log was inconsistent, mounted a snapshot as the working set; otherwise performed a cautious journal replay on the image.

• Extracted user data, preserving POSIX metadata and extended attributes. For Photos libraries and Mail stores, ran integrity passes to rebuild databases; for VMs or large sparse bundles, verified band maps and used checksummed copy to new storage.

5) External media non-recognition root cause (documented but not required for recovery)

• Documented that the original “won’t recognise external drives” was due to a bridge/firmware policy: Secure Boot disallowing external boot and certain USB mass-storage enumeration failures caused by a TB/USB controller state. After a Revive and policy adjustment (Startup Security Utility / 1TR settings), external devices enumerated normally—this is recorded in the report but we do not modify client configuration unless asked.

Outcome

• Full logical recovery of user home data (Desktop/Documents/Photos/Logic/Final Cut libraries, etc.) with APFS snapshot timestamping retained. Where FileVault was enabled, the client-provided credentials allowed lawful decryption. Delivered a verified dataset with SHA-256 manifest. Apple’s soldered-SSD + SEP architecture was respected end-to-end; no risky chip-level attempts were required (and would not succeed given hardware binding).