Evidence Acquisition, Handling, and Chain of Custody Questions

Direct answer

I treat a microSD card the same way I treat any evidence device, photograph, write-block, hash, image, but its small size and cheap, often mislabeled flash controllers create pitfalls a standard hard drive rarely does: hidden or misreported capacity, manufacturer-specific formatting, and outright counterfeit chips. The write-blocking step in particular is where microSD punishes assumptions carried over from hard drives.

On-scene actions

Photograph the device and the card slot before removal, noting the card's orientation and any printed capacity or brand markings. If the phone is powered on and the card might hold volatile data, consider live acquisition only with explicit approval, and be aware that on some handsets ejecting the tray prompts a restart. Otherwise remove the card and place it in an anti-static evidence bag with a tamper seal, avoiding repeated power cycling of the host device.

Write-blocking strategy

Use a hardware write blocker with a microSD adapter (for example a Tableau-style bridge, Tableau being a long-established maker of forensic write-blocking hardware and nothing to do with the business-intelligence software of the same name). This is the only option in this list that actually filters the command stream reaching the card.

Two commonly suggested substitutes do not work, and it is worth knowing why before you rely on one in front of a court:

• The lock tab on a full-size SD adapter is not a write blocker. The switch position is not detected by the card's internal circuitry at all: it is a mechanical notch a socket senses and reports to the host, and the host decides whether to honour it. Some devices ignore it outright and others allow an override, so a card behind a slid-down tab can still be written. It is a convenience feature for consumer devices, not an enforcement mechanism.
• A read-only bind mount is not a write blocker either. The Linux mount documentation is explicit that with mount -o bind,ro the read-only property applies at the VFS level while the original filesystem remains writable, and that the operation is not even atomic (it is implemented in userspace as an additional remount call). Anything holding the underlying device or the original mount can still write to the media.

If no hardware blocker is available, the workable software approach is to set the block device itself read-only before anything touches it (blockdev --setro /dev/sdX on Linux, verified with blockdev --getro), never mount the filesystem at all, and image straight from the raw device node. Then hash before and after handling, since the hash is the only proof the card was not altered while you had it. Record the method used and note in the report that a software approach was used and why, because that choice will be asked about.

Imaging

Use dd or ddrescue for a bit-for-bit clone of the whole device node, not a partition, with a GUI tool such as Guymager or FTK Imager if preferred. For a damaged card, ddrescue is the right tool because it retries and records exactly which ranges failed in its mapfile, which then becomes an evidence artifact in its own right. Do not reach for dd conv=noerror,sync as the damaged-media recipe: conv=sync zero-pads every short read to the full block size, including the final block whenever the card's size is not a multiple of the block size, so the image ends up larger than the source and its hash cannot match. Measured on a 10,244-byte source, dd bs=4096 conv=noerror,sync produced a 12,288-byte output with a different SHA-256, while plain dd bs=4096 reproduced the source hash exactly.

What could trip you up that a standard drive would not

• Reported capacity mismatch: some cards, especially counterfeit ones, report a larger capacity than the physical flash actually holds, silently wrapping so that late writes overwrite early data. On evidence you cannot test this by writing, so detect it by reading the full claimed capacity and looking for the tell-tale repetition of earlier content, and by comparing the reported size against the card's CID and CSD register values where the reader exposes them.
• Hidden or unusual partitioning: manufacturer utility or recovery partitions may not be visible through a normal filesystem view and need a partition-table tool (fdisk or parted) run against the raw image to surface. Image first, examine the partition table from the image, never from the card.
• Proprietary or non-standard formatting: some devices write a manufacturer-specific layout that a generic tool may misparse, producing an image that looks complete but analyzes incorrectly. If the parsed structure disagrees with the raw bytes, trust the raw bytes.
• Wear-levelling inside the card's own controller: unlike a spinning disk, the logical block a file lived in and the physical flash cell holding it can diverge, so deleted content may be unreachable from the logical view even though the cells still hold it, which limits how confidently deleted data can be carved and is worth stating as a limitation in the report rather than discovering later.

Throughout, document every step and preserve the original card for re-analysis rather than working from it directly.

Direct answer

The single decision that determines everything else is whether the LUKS (Linux Unified Key Setup, the standard on-disk format for dm-crypt encrypted volumes) volume is already unlocked when you arrive. If it is, the decryption key exists in kernel memory right now and capturing that memory, without closing the unlocked mapping, is your best and possibly only shot at getting plaintext access; if it's locked, you're limited to preserving the ciphertext and the LUKS header for later, and you have to be upfront in the report about what you cannot currently read.

Structured elaboration

Preserve first

• Document the live system's state before touching anything: which volumes are mounted (mount, lsblk), the cryptsetup status of any open LUKS mapping, and running processes, with photographs and timestamps for everything you observe.
• Isolate the host from the network to limit further tampering, but do not shut it down or close any open encrypted volume until you've decided what to do with the key material in memory.

Live considerations and capturing the key

• If the volume is mounted, the key lives in kernel memory. Capture full physical RAM immediately with a Linux memory-acquisition tool such as LiME, writing the image to a trusted external host, and preserve the kernel keyring state (cat /proc/keys) alongside it.
• If the LUKS volume sits on top of LVM (Logical Volume Manager, which can span a mapped, encrypted device across the underlying physical layout), do not close the device-mapper mapping to "simplify" the acquisition. Closing it drops the live decrypted access you're trying to capture and can complicate re-establishing the exact same mapping later; work with the mapping open and image the decrypted logical device directly (for example /dev/mapper/cryptroot) while it's still available, rather than tearing down the LVM/LUKS stack first and hoping to reconstruct it afterward.

Forensically-sound imaging

• Image the underlying raw block device with ddrescue or dc3dd, hashing as you go, regardless of whether the volume is open or locked, since the raw ciphertext image is valuable evidence either way.
• If the volume is open, additionally image the decrypted mapped device to capture plaintext filesystem content while access is still available: dd if=/dev/mapper/cryptroot of=/evidence/plain_root.img bs=4M, hashed immediately after.
• If locked, capture the LUKS header with cryptsetup luksDump /dev/sdaX, which reveals metadata (cipher, key-slot count, UUID) without needing the passphrase, and preserve it as its own evidence item in case a key surfaces later.

Analysis, if a key or passphrase is available

• Open the volume read-only for analysis: cryptsetup luksOpen /dev/sdaX crypt_suspect --readonly, then mount read-only and extract logs, shell history, and other artifacts, hashing everything you pull.

Limitations if keys are unavailable

• A ciphertext-only image preserves block-level metadata and the LUKS header, but the file contents stay unreadable. Offline passphrase recovery against weak passphrases is possible in principle using the LUKS header and dedicated password-recovery tooling, but is genuinely infeasible against a strong passphrase, and if the header itself has been overwritten by an attacker, the volume may be permanently unrecoverable without a prior header backup.

Chain of custody and reporting

• Log every command, timestamp, and hash, so the chain of custody, the unbroken written record of who handled the evidence and exactly what they did to it, survives an acquisition where you had to work on a machine while it was still running. State the limitation plainly if plaintext access wasn't possible: "ciphertext imaged; plaintext inaccessible without recovered keys," rather than implying more access than you actually achieved.

Worked example

You arrive at a live Linux server and find /dev/mapper/cryptroot mounted at /, meaning LUKS is currently unlocked and sits on an LVM logical volume. You leave the mapping open, capture full memory with LiME to an external host, then image both the raw underlying physical volume with dc3dd (for the ciphertext and header) and the open /dev/mapper/cryptroot device with dd (for the plaintext filesystem), hashing each output as it completes. Because you never closed the mapping, you got a clean plaintext image even though the passphrase itself was never typed or known to you, something that would have been impossible if you had powered the system down or torn down the LVM stack first.

Trade-offs and pitfalls

Common wrong turn: closing an open LUKS-on-LVM mapping to make the acquisition "cleaner," which throws away the one window you had to capture plaintext access. Common wrong turn: only imaging the decrypted mapped device and skipping the raw ciphertext image, which loses header and metadata evidence that matters if the case ever needs to show exactly what encryption was in use. Pitfall: overstating what a password-recovery attempt can realistically achieve against a strong passphrase in a report, when in practice it's likely infeasible and should be described that way rather than as a routine next step. Senior signal: explicitly stating the limitation in the report when keys aren't available, "ciphertext preserved, plaintext inaccessible," rather than letting the report imply more access than you actually achieved.

Situation & goal
I would build an automated audit pipeline that ingests chain-of-custody (CoC) logs, applies deterministic rule checks + statistical anomaly scoring, and routes triaged alerts to examiners and case owners.

Data model & structures

• Normalize logs into a relational table (item_id, event_type, actor_id, signature_present(bool), timestamp, custody_duration_secs, seal_id, location, raw_json).
• Index on item_id, timestamp, seal_id.
• Maintain time-series aggregates in a columnar store (e.g., ClickHouse) and an in-memory LRU cache (Redis) for recent items.

Detection rules & implementation

• Missing signature fields: SQL query where signature_present = false → score 0.9 if event_type == transfer.
• Non-monotonic timestamps: windowed query per item_id ordering timestamps; flag where next_timestamp < prev_timestamp → score 0.95. Use partitioned window functions.
• Unusually long custody durations: compute baseline per actor/type (median, IQR). Flag durations > median + 3 * IQR or > absolute threshold (e.g., 7 days) → score proportional to deviation.
• Mismatched seal IDs: detect when seal_id changes between sealed transfer start/close without seal-release record → score 0.9. Use joins to expected-seal table.
• Duplicate item IDs: detect same item_id assigned to multiple physical_evidence_ids concurrently → score 0.99.

Thresholds & baselines

• Use rolling 90-day baselines per chain/location; apply robust stats (median, IQR). Allow configurable sensitivity per case priority.

Query techniques

• Use window functions, existence joins, group-by histograms, approximate distinct counts (HyperLogLog) for scale. Batch jobs for full re-scan; stream checks via Kafka + Flink for real-time.

Alerting & prioritization

• Compute composite risk score (weighted rules, weights tuned by false-positive history). Priority tiers: Critical (>0.9) -> immediate pager to senior examiner + case owner; High (0.7–0.9) -> email + ticket; Medium/Low -> queued dashboard. Include contextual payload (last 10 events, actor history, evidence image links).

Process & governance

• Provide human-in-the-loop workflows: adjudicate, annotate, feed labels to refine thresholds. Log audit trail for chain integrity and legal defensibility.

Direct answer

With no key and no passphrase, my options fall into four categories: get the key from somewhere it might still exist outside the disk itself (memory, hibernation data, an escrow system), get legal or vendor assistance to compel or obtain it, attack the passphrase itself with a targeted, proportionate effort, or accept that the data is inaccessible for now and preserve the encrypted evidence unaltered for later. I will not attempt invasive or destructive techniques without explicit legal authority and a documented decision that the evidentiary value justifies the risk, and anything I do recover gets validated by actually decrypting a copy before I rely on it for anything.

Structured elaboration

• Volatile memory, if it still exists. If the machine was seized powered-on, a RAM capture may contain the decryption key material for whatever was mounted at seizure. This is time-critical and only available if you got to the machine before it was powered off; once RAM has lost power there is nothing left to capture.
• Artifacts the OS left behind. Hibernation files and pagefiles can retain remnants of key material or plaintext that was in memory when the system slept or paged. This is a real avenue but a probabilistic one: whether anything useful survives depends on what the OS overwrote afterward, and on some platforms these regions are themselves encrypted, which forecloses the avenue entirely.
• Legitimate key-escrow and legal process. Many organizations escrow recovery keys (BitLocker keys in Active Directory or Microsoft Entra ID, FileVault keys via MDM, Mobile Device Management, the enterprise system many organizations use to manage and escrow keys for company devices), and some vendors will respond to valid legal process. This is the least technically risky option and should usually be tried in parallel with anything else, not as a last resort.
• Attacking the passphrase, done properly. This is the workhorse option and it is not the same thing as "brute force everything". Full-disk encryption headers (BitLocker, LUKS, VeraCrypt, FileVault) are attacked offline, against a copy, by extracting the key-derivation material from the header and running a targeted candidate list. What makes it work is the wordlist, not the hardware: passwords recovered from the subject's other seized devices, browser and OS credential stores, password managers, sticky notes photographed at the scene, and rules built from those (a reused password with a digit appended is the single most common outcome). What makes it fail is treating it as an exhaustive search. Modern key derivation is deliberately slow and memory-hard precisely so that an unguided search costs more than the case is worth, so the honest framing to a supervisor is a time-boxed, hypothesis-driven attempt with a stated budget and a stated stopping point, not an open-ended job left running for months.
• Physical and hardware attacks are the last resort, and only with authority. Techniques like cold-boot (chilling the DRAM chips that make up RAM, to slow how fast their contents decay after power loss) or direct memory access over a debug or expansion interface exist and are documented in the literature, but they are invasive, may not work on modern hardware with memory encryption and DMA protections, and carry real risk of altering or destroying the very evidence you're trying to recover. I would not attempt these without written authorization, and I would document why the ordinary avenues above were exhausted or infeasible first.
• How far I'm willing to go. My line is: legal authority in hand, technique validated in a lab on non-evidentiary hardware first if it's destructive or novel, and a documented cost-benefit call (with supervisor or legal sign-off) before touching the original media with anything irreversible. If a technique requires opening the case or desoldering a chip, that decision does not get made unilaterally in the field. Compelling a passphrase from the subject is a legal question with sharply different answers by jurisdiction, so it goes to counsel rather than becoming an examiner's improvisation.

Worked example

Say a laptop with full-disk encryption is seized powered-on and running. Priority order:

1. Capture RAM immediately with a trusted, validated tool, hash it, and set it aside. This preserves the best chance of a key regardless of what happens next, and it decays fastest.
2. In parallel, submit a legal request for any organizational key escrow (the subject's employer, cloud identity provider), since that carries no technical risk at all and often resolves the whole problem in a day.
3. Image the disk, then work only from copies. Examine hibernation and pagefile artifacts from the copy for residual key material.
4. Build a candidate passphrase list from everything else already in evidence (other devices, credential stores, seized notes, the subject's known password habits) and run a time-boxed attack against the header extracted from the copy.

If a candidate key turns up from any of these paths, I do not trust it just because it looks like a key.

Trade-offs and pitfalls

Powering the system off "to be safe" before capturing RAM destroys the one lead that decays the fastest. If the machine is live, memory capture is usually the first move, not the last.

Never apply a recovered key directly to the original evidence. Mount and decrypt a verified bit-for-bit copy instead, and confirm success by checking that known filesystem structures and a sample of expected file hashes appear where you'd expect. Only then is the key validated. A key that unlocks the header but yields a filesystem that does not parse is not a success, it is a coincidence you have not yet explained.

Document every attempt, successful or not: which techniques were tried, in what order, on what copy, with what authorization, what the search budget was, and what the outcome was. A negative result that is documented is a defensible answer to "did you try". A negative result that is not documented looks like an omission. In court the defensibility of your process matters as much as whether you actually got in.

Direct answer

My process runs in a fixed order because each step protects the one after it: prepare and stay safe, isolate and document before touching anything, decide whether volatile data must be captured live, image behind a write blocker, hash to prove nothing changed, then label and sign the evidence into the lab. Reordering any of these risks either contaminating the evidence or losing something that cannot be recreated.

Before I arrive: equipment and safety

I bring a kit that covers the whole chain: a hardware write blocker (the unit the evidence drive plugs into instead of straight into my laptop, which passes read commands through to the drive and answers every write command with a refusal, so even an operating system that habitually mounts and journals a disk the moment it sees one cannot change a single sector), a validated imaging laptop, anti-static bags, tamper-evident evidence tape and labels, nitrile gloves, and a chain-of-custody form, meaning the signed running record of who held the item at every moment from seizure to lab, which is what leaves no unexplained gap in which the evidence could have been altered. Safety comes first: I confirm I have legal authority to seize the device, and on an active scene, such as an insider-threat case, I coordinate with security or law enforcement before touching anything rather than acting alone.

On scene: isolate and document, before touching the device

I photograph the device, its screen, cables, and surroundings in place, and note the power state (on or off, locked or unlocked). I record its make, model, and serial number, and for a corporate laptop, its asset tag, because that ties the seizure to an internal inventory record the company can corroborate. This happens before anything is moved or connected, because a photograph of the original state is the only evidence of that state if anything looks different later.

Decision point: does anything need to be captured live?

If the device is powered on and might hold volatile evidence (an unlocked session, an active connection, in-memory credentials), I stop here and decide whether to perform a live memory capture before proceeding to imaging. This is a deliberate branch, not an afterthought: once the device is powered off or imaged without capturing memory first, that volatile data is gone permanently.

Imaging

For storage devices, I connect through a hardware write blocker and image with a validated tool such as FTK Imager, Guymager, or dd/ddrescue. For small removable media like a USB drive, the same write-blocking discipline applies even though the media is easy to handle; I wear gloves and use an anti-static bag when it comes off the device, both to avoid contaminating physical trace evidence and to protect flash media from static discharge. For a corporate laptop, I package it with its charger if seized, note whether it was issued to a specific employee, and record who else has administrative or remote-wipe access to it, since that is a real risk to the evidence between seizure and lab arrival.

Hashing and verification

I compute a cryptographic hash (for example SHA-256) on the source before imaging, then the same hash on the resulting image; the two must match. This step is what turns a copy into a copy that can be proven identical to the original.

Labeling, chain of custody, and lab handoff

I label the media with case ID, exhibit number, collector name, and timestamp, and complete the chain-of-custody form for every transfer, including the transfer into lab storage. Before signing in, I do a final check that hashes match, the image mounts read-only, and the partition structure looks as expected.

What I would not do

I would not power on a device to take a quick look, image without a write blocker because it is "obviously off," or skip photographing because the scene seems straightforward. In an insider-threat case especially, skipping documentation is the mistake that turns a strong case into a disputed one, because the first question from the other side is what was touched before documentation started.

Why the order matters

Each step protects evidence the next step could otherwise destroy: documentation before touching anything preserves the original state as a reference; the live-capture decision comes before imaging because imaging or powering off destroys volatile data; write-blocked imaging comes before hashing because a stable copy is needed to hash; and hashing comes before lab sign-in because the lab needs proof the image matches the source the instant custody changes hands. Reordering any of these breaks the chain that makes the final image trustworthy in court.