Shadow and Shield / Evidence Acquisition

Evidence acquisition.

Shadow and Shield acquires connected media through native imaging, logical extraction, evidence scanning, source-drive protection, forensic image handling, and selected peripheral capture.

Under construction · work in progress

This page will continue to change as the hardware, software, and release materials are finalized.

At a Glance

Imaging, extraction, scanning, and acquisition records.

This page covers source-drive protection, supported image formats, native acquisition hashing, multi-destination imaging, synthetic E01 output, logical extraction, background scanning, smart cards, and acquisition history.

01 / Source Protection

Source-drive protection.

  • Source drives are classified separately from destination media so tool eligibility can follow the assigned role.
  • Source-classified drives are placed under operating-system block-device read-only enforcement, and the orchestrator verifies that state before presenting the drive for acquisition.
  • Write-protection verification and source-protection records can support later operational review.
  • External hardware write blockers may still be appropriate for organizations with strict evidence-handling policy requirements.

02 / Forensic Imaging

Forensic imaging.

  • E01, Ex01, AFF4, and raw DD/RAW acquisition workflows where supported by the selected format and deployment.
  • Native acquisition hashing with quick MD5-only mode and full MD5, SHA-1, SHA-256, and BLAKE3 hashing during the acquisition pass.
  • Configurable compression, segment size, destination writing mode, and post-acquisition verification where supported.
  • Automatic dependent verification jobs for E01, Ex01, and AFF4 acquisitions when verification is enabled.
  • Supported imaging workflows can use multi-destination spillover or distribution, while single-destination acquisitions can pause when media is full, accept replacement destination media, and resume where supported.

03 / Synthetic E01

Synthetic E01 output.

  • Synthetic E01 output represents platform-generated evidence data derived or transformed from a source.
  • For unlocked encrypted sources, synthetic output can preserve decrypted, analysis-ready content where supported.
  • Embedded synthetic-identification metadata, companion provenance records, transformed-region detail, and resulting hashes can be retained where space and workflow support it.
  • Synthetic E01 should not be described as a direct bit-for-bit copy of the original source.

04 / Logical Extraction

Logical extraction.

  • Extraction scopes can include full-drive, selected-partition, category-filtered, file-type-filtered, hash-result, deleted-file, trash/recycle-bin, and combined deleted-and-trash workflows where supported.
  • Loose-file output can preserve source folder structure or organize extracted files by category depending on configuration.
  • L01 logical evidence container output can be used where selected and supported.
  • Parallel loose-file extraction uses hardware-aware worker selection.
  • Saved configuration profiles support repeatable logical acquisition workflows for teams and field users.

05 / Evidence Scanning

Evidence scanning.

  • Automatic background quick scanning can inventory files and directories when new source drives are connected.
  • Scan outputs can include deleted-file indicators, partition information, filesystem information, metadata-derived indicators, and suspicious-file heuristics where applicable.
  • File-browser views can present scan results by partition, category, or file type.
  • AI-based filename translation can preserve original filenames alongside translated values when translation models are enabled.
  • Supported translation models include OPUS and NLLB where configured.

06 / Image Handling

Forensic image handling.

  • Image detection can identify supported forensic-image sources.
  • Image information can be surfaced for review where the format exposes it.
  • Image verification can be queued or performed where supported by the selected format and workflow.
  • Image handling records can stay attached to case and execution context.

07 / Smart Cards

Smart card reading.

  • Supported smart-card and USB CCID reader workflows can capture ATR, card identity metadata, PIN status, public data objects, and certificate metadata.
  • Scan results can be recorded with case association, scan history, partial-result capture, and raw OpenSC output where available.
  • Reader, card type, middleware, and deployed host configuration determine what can be captured.
  • This should be framed as a compatibility signal, not a broad credentialing or identity claim.

08 / Records

Case association and acquisition history.

  • Supported acquisitions, scans, verifications, smart-card reads, and logical extraction jobs can retain case context where selected.
  • Acquisition history can include source identity, output format, destination details, hash mode, verification behavior, tool execution context, and operator attribution where recorded.
  • Records should support review of what was acquired, how it was acquired, and which case or session it belongs to.
  • Describe this as acquisition history and case association, not a universal record of every possible evidence-handling event.

Claim boundary: acquisition copy should stay tied to supported formats, enabled verification behavior, connected hardware, case association, and release-validated synthetic or logical-output behavior.