Case Study 1 — MacBook (Fusion configuration)

Symptom: SSD not shown in Startup Disk; system unbootable. Device reported as “Fusion” (Apple logical volume spanning an internal SSD + HDD). Suspected NAND degradation on the SSD tier.

Technical Assessment

Apple Fusion can be implemented as:

• CoreStorage Fusion (older macOS): logical volume group (LVG) spanning SSD (tier0) + HDD (tier1).

• APFS Fusion (newer macOS): a single APFS container spanning both devices, with the SSD hosting key metadata (container superblocks / spacemaps / object maps) and the HDD hosting bulk data.

Loss of the SSD (NAND wear, controller error, or service area corruption) often renders the entire Fusion group non-mountable even if the HDD is physically healthy.

Laboratory Procedure

1. Non-destructive access & unlock path

   • Captured device identifiers and security context (Intel vs T2 vs Apple Silicon).

   • If T2/Apple Silicon: used Share Disk / Target Disk Mode or DFU Revive via Apple Configurator to restore bridge firmware without erasing user data.

   • If FileVault was enabled, used client credentials or recovery key to unlock at the container level. All subsequent steps on hardware write-blocked interfaces.

2. Per-device triage and imaging

   • SSD: SMART/telemetry and vendor diagnostics indicated read amplification and high uncorrectable error counts → consistent with NAND wear/FTL translation issues.

   • Executed headless block imaging with adaptive timeouts and queue-depth = 1 to stabilise readbacks; prioritised likely APFS/CoreStorage metadata regions (container superblocks, object maps, checkpoint areas).

   • HDD: imaged at line rate; mapped any remapped LBAs to a defect list for completeness.

3. Fusion reassembly (CoreStorage or APFS)

   • CoreStorage: reconstructed the LVG by recreating the logical mapping from the SSD/HDD physical extents; imported the LVs read-only; repaired HFS+/APFS atop where applicable.

   • APFS Fusion: used the SSD-sourced object map + spacemaps to re-establish the container; where SSD metadata had gaps, rolled back using older checkpoint blocks and validated via nx_superblock consistency and object tree traversal.

   • Any missing SSD regions were safely substituted from secondary metadata copies (APFS maintains multiple superblocks/checkpoints). No writes to the source.

4. Volume repair & data extraction

   • Mounted user volumes read-only; fsck_apfs run against the image, not the original.

   • Replayed transaction logs where safe; otherwise mounted prior snapshots (Time Machine local/APFS snapshots) when available, to avoid post-crash journal damage.

   • Extracted user data; verified with SHA-256 manifest.

Outcome: Full logical recovery of user home data (Documents/Photos libraries/creative apps). APFS Fusion container reconstituted from mixed SSD/HDD evidence with fallback to older checkpoints where necessary.

Case Study 2 — Synology DiskStation DS1522+

Symptom: Repeated I/O device errors on read/write; NAS shares intermittently accessible then unavailable. Model typically runs DSM 7 with Btrfs on top of mdadm RAID/SHR.

Technical Assessment

DS1522+ commonly presents storage as:

• mdadm RAID (RAID5/6 or SHR-1/SHR-2) → LVM PV/VG → Btrfs filesystem.
  I/O errors typically indicate one or more member disks with escalating pending/reallocated sectors; continued operation risks md reshape/bitmap drift, LVM metadata damage, and Btrfs chunk map inconsistencies.

Laboratory Procedure

1. Drive isolation & forensic cloning

   • Removed all disks; strict slot order recorded; DOM not used for data path.

   • Each disk imaged with SAS HBA in pass-through mode; unstable members received adaptive imaging (head-select, time-boxed retries, read-cool cycles).

   • Produced per-member defect maps; all subsequent work on images only.

2. md/SHR layer reconstruction

   • Parsed md superblocks to determine array UUID, member role/order, chunk size, parity rotation and any reshape position if a grow/expand had been in progress.

   • Assembled the array virtually from the images; corrected any 4Kn/512e mis-matches and HPA/DCO anomalies by normalising logical sector sizes in the virtual stack.

3. LVM & Btrfs recovery

   • Reinstated LVM PV/VG from on-disk metadata; where thin-pool metadata existed, restored from spare area if primary was inconsistent.

   • For Btrfs, interrogated superblocks across multiple copies; rebuilt chunk maps; validated CSUM/extent trees.

   • Mounted read-only; for damaged subvolumes/snapshots, used btrfs check --readonly and targeted subvolume export rather than risky in-place fixes.

4. Data validation & export

   • Verified file integrity via Btrfs checksums and independent hashing.

   • Exported the complete share hierarchy; flagged any files sourced from regions that required parity reconstruction or partial sector synthesis.

Outcome: Logical recovery of all client-designated data. Root cause: two members with progressing media errors causing md to flap and Btrfs to report I/O failures. Recommendations provided: replace both disks, scrub schedule, enable SMART alerts, and avoid expansion during degraded states.

Case Study 3 — SanDisk Ultra SDXC 512 GB

Symptom: Overwritten data on an exFAT card; user suspects partial recoverability.

Technical Assessment

On SD cards, controller wear-levelling means logical overwrites often map to new physical pages; old pages persist until garbage-collected, so prior content can sometimes be recovered if not yet erased. Conversely, camera/OS overwrites that fill the card leave fewer intact remnants. Recovery hinges on FTL reconstruction and then carving intact objects.

Laboratory Procedure

1. Triage & acquisition

   • Multiple readers/clock modes (SDR25/50/104) tried. If the controller enumerated unreliably or at ECC limits, proceeded to chip-off.

   • For monolith construction, exposed pads and acquired raw dumps including spare/OOB.

2. NAND-level processing

   • Determined page/block geometry, interleave, XOR/scrambler, and ECC (BCH/LDPC).

   • Corrected ECC; removed XOR/scramble; reconstructed the Flash Translation Layer from translation/journal pages in OOB to produce a coherent logical image reflecting the historic state of the card.

3. File-system & artefact recovery

   • Parsed exFAT structures (VBR, Allocation Bitmap, Upcase table). Because entries had been overwritten, enumerated both current and stale directory entries.

   • Performed deep carving for JPEG/RAW/HEIF/MP4 based on signatures and container structure:

     • JPEG/RAW: checked SOI/EOI, rebuilt EXIF where headers were damaged; validated Huffman tables.

     • MP4/MOV: rebuilt moov atoms from mdat by parsing NAL units (SPS/PPS/VPS) to restore index/timeline; recovered playable files even when directory entries were gone.

   • Harvested secondary artefacts: camera thumbnail caches, preview JPEGs embedded in RAWs, and residual clusters not yet garbage-collected.

4. Quantifying overwrite impact

   • Mapped recovered clusters against the exFAT allocation bitmap versions to determine which files were physically overwritten (irrecoverable) versus logically deleted but still physically present (recoverable).

   • Provided a recovery inventory with confidence levels per file and SHA-256 hashes.

Outcome: Partial but substantial photo/video recovery. Files whose physical pages had been re-used by new data were unrecoverable; many earlier shoots and thumbnails were fully intact. Client received the validated set and an overwrite impact report.