Case Study 1 — QNAP TS-233: Accidental Re-initialisation (Storage Pool/Volume/LUN)

Incident summary

A 2-bay QNAP TS-233 was inadvertently re-initialised in QTS (e.g., Create/Format executed on the wrong pool; deleted/recreated Storage Pool/Volume or iSCSI LUN). This class of action typically overwrites mdadm superblocks and LVM2 headers, and may zero the first MBs/GBs of the prior volume or LUN container. The TS-233 commonly runs QTS ext4 with mdadm + LVM (thin or thick provisioning).

Forensic approach & containment

• Drives removed, bay order recorded, each disk sealed in anti-static bags.

• Originals connected behind hardware write-blockers; we performed full-disk, defect-aware imaging (PC-3000/Atola/DDI) with per-head/zone strategies, reverse passes, adaptive timeouts, and error maps.

• All subsequent work was conducted on clone images. Chain-of-custody, SHA-256 of images and key artefacts preserved.

Layered reconstruction

1. mdadm discovery

• Parsed residual md superblocks (1.0/1.2) across typical offsets on both clones. Where the re-init wrote new metadata, we carved stale superblocks by scanning for superblock signatures and sanity-checking event counters/UUIDs.

• Identified the previous data array (RAID1 on 2-bay; occasionally single-disk JBOD). Reconstructed a virtual md device from the clone set with the last coherent epoch.

2. LVM2 reassembly

• Searched for LVM2 headers ("LVM2 x[5A%r0N*]") and metadata areas. In re-initialisation incidents the primary PV/VG metadata at the start of the device is often overwritten, but backup metadata remains in alternate metadata areas near the end of the PV.

• Using vgcfgrestore-equivalent logic (performed inside our lab tooling, not on originals), we reconstructed:

  • VG (often vg1)

  • LVs: thick LVs and/or thin-pool (vg1-tpool) + thin LVs (data volumes, iSCSI block LUNs).

  • Validated PE/LE maps, extent alignment, and thin-pool metadata/data LV pairing.

3. iSCSI LUN handling

• If the client had file-based LUNs, we enumerated .img containers typically located within hidden directories on the ext4 volume (e.g., /.@iscsi.img/…). Where the header region was zeroed, we stitched sparse extents by analysing ext4 extent trees and unallocated regions.

• If block LUNs, we identified the LV that backed the LUN and exported a clean block image for FS repair.

4. Filesystem repair (ext4 / Btrfs)

• For ext4:

  • Located and used backup superblocks (e.g., 32768× block multiples) when the primary superblock/boot sector was overwritten.

  • Replayed the journal on the cloned image; rebuilt group descriptors/bitmaps; reconciled orphaned inodes; validated directory trees.

• (If the unit was provisioned with Btrfs, we would: enumerate trees/chunks, recover the last consistent root, and salvage via btrfs restore—performed virtually on the image.)

5. Verification & export

• File trees reviewed; critical artefacts opened (databases, media, office docs).

• Delivered an export of the reconstructed volume/LUN and a forensic summary including SHA-256 manifests, recovered layout (md/LVM/FS), and a delta map of sectors newly written by QTS during re-init.

Outcome: Prior pool/volume/LUN reconstructed virtually; user data recovered with minimal corruption limited to regions physically overwritten by the re-initialisation.

Case Study 2 — SanDisk Cruzer USB Flash Drive: Connector Shear (Physical Break)

Incident summary

A SanDisk Cruzer USB flash drive suffered a type-A connector fracture when a laptop was dropped. The device contained business-critical university documents. Post-incident, the drive would not enumerate.

Electrical/physical triage

• Binocular inspection revealed a sheared connector with lifted pads. We probed VBUS/ID/D+/D-/GND pads, ESD diodes, and the 3.3 V LDO/regulator. Oxidation and pad delamination were present.

• Because mechanical stress often propagates to the UFD controller BGA and/or its NAND package, we prepared two recovery paths:

Path A — Non-destructive board repair (preferred if feasible)

• Connector re-termination: micro-replaced the type-A shell; where pads were torn, we ran 30–44 AWG micro-jumpers from D+/D-/VBUS/GND to upstream vias/test points.

• Verified ESD/TVS network not shorted; replaced if clamped.

• If the controller enumerated, we immediately performed read-only imaging using a stable, BOT (non-UASP) path with strict timeout budgeting to avoid resets.

Path B — Flash-level extraction (when board repair was not viable)

Many Cruzer variants are monolithic (controller + NAND in a single epoxy “monolith”) or use TSOP48/BGA132/152 discrete NAND.

• Monolith:

  • Identified the pinout via microscopy (test pads) and reference footprints; soldered a monolith access harness to CE/RE/WE/ALE/CLE/RB#/DQS/D0–D7/VCC/GND lines.

  • Read raw NAND with PC-3000 Flash at multiple timings/voltages; captured per-die/per-plane dumps.

• Discrete NAND (TSOP/BGA):

  • Hot-air/lower-temp IR extraction of the NAND package.

  • Read each die with vendor-specific ONFI/toggle parameters; multiple passes for weak cells.

Flash translation & reconstruction

• Determined page/block geometry, bad-block table (BBT), interleave, multi-plane, die addressing.

• Applied vendor-specific XOR/scrambler and ECC decoding; de-interleaved mixed planes; corrected bit-rot with majority voting where possible.

• Recovered the FTL (logical-to-physical) translator using marker analysis and service structures; rebuilt a virtual block device (LBA) for extraction.

Filesystem & data recovery

• Typical FS on Cuzer is FAT32/exFAT/NTFS. We repaired boot sectors/FAT/exFAT bitmaps, rebuilt directory entries, and carved for office/document formats where metadata was damaged.

• Delivered a verified dataset with SHA-256 manifests; corruptions (if any) were isolated to pages with uncorrectable ECC after maximal reads.

Outcome: Full logical image created from either repaired USB path or reconstructed NAND. User data restored; evidential artefacts preserved.

Case Study 3 — SanDisk Extreme Portable SSD: Not Recognised on macOS

Incident summary

A SanDisk Extreme Portable SSD (USB-C) stopped enumerating on a MacBook. Vendor support advised professional recovery. These devices are typically NVMe SSDs behind a USB-to-PCIe bridge (e.g., ASM2362/JMS583/RTL9210) or, in some capacities/revisions, a SanDisk UFD/SSD controller in a custom BGA module. Bridge firmware faults and controller lockups are common failure modes.

Diagnostic decomposition

1. Enclosure/bridge inspection

   • Disassembled the drive; identified the bridge IC and checked for hardware encryption at the bridge level (some bridges support transparent AES; many consumer variants ship without encryption).

   • Tested enumeration on multiple hosts with UASP disabled (BOT mode), alternate cables, and a bench PSU to exclude cable/rail instability.

2. Direct-media access

   • If the unit contained a removable M.2 2230/2242 NVMe module, we extracted it and attached via a PCIe carrier to our NVMe imager (admin-command capable).

   • If it was a soldered BGA NVMe/UFD module, we attempted controller ROM/SAFE mode entry to obtain basic identify data and, if possible, namespace imaging despite firmware faults.

3. Bridge encryption/keystore considerations

   • Where bridge-level encryption was present (detected via high-entropy patterning and metadata tests), we transplanted the original bridge to a stable donor PCB or extracted the keystore/NVRAM so the image could be decrypted on-the-fly during cloning.

   • If no encryption, we bypassed the bridge entirely and imaged the NVMe device natively.

Imaging & controller-aware handling

• Executed admin-queue resets, limited queue depth, and used staged, low-QD imaging to avoid controller watchdog resets.

• For weak NAND/retention issues: performed majority-vote reads, channel/plane isolation and temperature-stabilised passes.

• Where the controller was unrecoverable, we performed chip-off (BGA NAND removal), per-die dumping, applied ECC/XOR/interleave parameters, and reconstructed the FTL (L2P) to build a virtual NVMe namespace image.

Filesystem & macOS specifics

• The volume presented as APFS (common on macOS externals) or exFAT.

• APFS path: rebuilt object map and spacemaps, enumerated snapshots, repaired container/superblock structures, then exported mountable volumes. If FileVault encryption had been enabled on the external, we used the customer’s recovery key/passphrase to decrypt on the clone.

• exFAT path: repaired boot region and allocation bitmap; reconciled directory entries; carved large media if directory metadata was damaged.

• Verified recovered files by sample-open testing (Office, media, Photos libraries) and produced SHA-256 manifests.

Outcome: Device-level access restored via bridge bypass/ROM mode or chip-level reconstruction; APFS/exFAT volumes rebuilt and delivered. Any irrecoverable areas were confined to genuinely unreadable NAND pages after exhaustive re-reads.

Notes on Professional Practice

• Clone-first, read-only methodology: originals never modified; all repairs are performed on images or donors.

• Controller-aware techniques: HDD SA/translator work; SSD/NVMe FTL (L2P) extraction; bridge keystore handling; XOR/scrambler/ECC correction.

• Filesystem reconstruction: APFS/HFS+, NTFS/ReFS, ext/XFS/Btrfs/ZFS; journal/intent replay, B-tree/catalog repairs; content-aware carving for media and office formats.

• Verification: SHA-256 digests, structured reports, and optional evidential documentation for legal/disciplinary processes.