Shadow and Shield / Evidence Acquisition

Evidence acquisition.

Shield-399 acquires connected media through native imaging, logical extraction, evidence scanning, source-drive protection, forensic image handling, and supported smart-card inspection.

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.

Key Imaging Differentiators

Key imaging differentiators.

  • Create a Synthetic E01 from an unlocked BitLocker or LUKS volume where supported.
  • Keep large acquisitions moving with destination spillover and hot-swappable destination media.
  • Multiple tool options - select your preferred acquisition and verification engine.
  • New purpose-built native imaging engine with dedicated E01, Ex01, and AFF4 writers.

01 / Source Protection

Source-drive protection.

  • Source evidence is accepted exclusively through commissioned, write-protected USB ports.
  • All udisks2 activation paths and desktop automount functions are disabled.
  • Source/INPUT and unrecognized USB media are protected automatically; no per-drive operator action is required.
  • Before permitting evidence access, Shield-399 verifies the entire block-device family is read-only and checks for unauthorized mounts or write-capable handles.
  • Protection failures, uncertain topology, and unrecognized connections fail closed.
  • Destructive commands are restricted to verified Destination media.
  • Shield-399 provides operating-system enforcement. External hardware write blockers can be added where organizational policy requires them.

02 / Forensic Imaging

Forensic imaging.

  • E01, Ex01, AFF4, and raw DD/RAW acquisition workflows where supported by the selected format and deployment.
  • Ex01 output uses the native EWF2 writer and installed ewfverify for post-acquisition verification; compatibility can vary by third-party reader and version.
  • 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.
  • When verification is enabled, Shield-399 automatically queues a dependent job that re-reads the completed image, compares recorded and computed hashes, and stores per-algorithm results with the acquisition record.
  • Destination spillover allows supported native acquisitions to continue across multiple destination drives as media fills.
  • When a single destination fills during an active acquisition, Shield-399 pauses the job so the operator can hot-swap the destination drive and resume.
  • Shield-399 records the placement of image segments or raw parts in an output manifest so distributed acquisitions can be reconstructed for verification and downstream use.

03 / Synthetic E01

Synthetic E01 output.

  • Synthetic E01 output can be created from an unlocked BitLocker or LUKS volume where supported.
  • Synthetic output preserves accessible decrypted filesystem content rather than the source’s original encrypted block representation.
  • Acquisition provenance, resulting hashes, and supported region metadata are recorded with the output.

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.
  • Selections can also be driven by completed hash-comparison and keyword-search results, with date, size, and zero-byte filters available where configured.
  • 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.
  • Saved configuration profiles support repeatable logical acquisition workflows for teams and field users.
  • Completed destination extractions include a SHA-256-sealed extraction ledger. When destination verification is enabled, Shield-399 re-reads the output and writes a verification report with a checksum sidecar.

05 / Evidence Scanning

Evidence scanning.

  • A fast scan starts automatically in the background when a source drive is connected, inventorying discovered files and directories.
  • Scan outputs can include deleted-file indicators, partition information, and filesystem information where applicable.
  • Detailed scanning can build on the fast-scan inventory with deleted-file status, file attributes, extension metadata, and suspicious-file heuristics where applicable.
  • File-browser views can present scan results by partition, category, or file type.
  • Local AI filename translation populates an English translation alongside the original filename to accelerate review of supported non-English file listings.
  • Supported filename-translation models include OPUS and TranslateGemma where configured.

06 / Image Handling

Forensic image handling.

  • Evidence scanning can identify pre-existing E01/Ex01, DD/RAW/IMG, and AFF4 images by filename extension.
  • Image Information can read embedded case fields, acquisition and device details, segment counts, compression details, and stored image hashes where those fields are present.
  • 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 PC/SC-compatible smart-card readers can provide the card ATR, identity fields, PIN-object metadata, publicly accessible data objects, and certificate metadata where exposed.
  • 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.

08 / Records

Case association and acquisition history.

  • Physical imaging, logical extraction, evidence scanning, smart-card scanning, and image verification create durable records in the local platform database.
  • Depending on the operation, records can include operator identity, case context, source and destination details, selected configuration, timestamps, hash values, verification results, source-protection events, and errors.
  • Records are available through the network dashboard and reporting views where supported.

Capability availability depends on the selected format and engine, connected hardware, verification settings, and configured case context.