infrastructure-bitlocker-forensics

Native parser for the BitLocker FVE metadata block: enumerates the VMK key-protector inventory (clear key / TPM / TPM+PIN / recovery password / password / startup key) as cited Observations, no verdicts. Reads the newer XTS-AES metadata versions that the packaged libbde/dislocker builds reject.

What it is for

Native parser for the BitLocker FVE metadata block: enumerates the volume's key-protector inventory (the VMK entries) as cited Observations, never a verdict.

Why this exists rather than a wrapper crate: the packaged libbde (20190102) and dislocker (0.7.3) both abort on the XTS-AES metadata versions Windows 10/11 writes (unsupported FVE metadata entry version / the VIRTUALIZATION datum), so the established "thin wrapper around the reference tool" pattern has no working reference tool for these images. This reads the documented on-disk structure directly.

Layout is the libyal libbde documentation of the FVE metadata:

• the -FVE-FS- volume header carries three metadata-block offsets at byte 0xb0;
• each metadata block opens with the -FVE-FS- signature, an FVE metadata header at

0x40 (metadata size, header size, volume GUID, encryption method), then a run of entries ("datums");

• a datum is size:u16, entry_type:u16, value_type:u16, version:u16 then its value;
• a VMK datum is entry_type == 0x0002, value_type == 0x0008; its value is

guid16, modification_time:i64, unknown:u16, protection_type:u16.

No secret is ever needed to read this: protector types live in the metadata in the clear. Whether a given protector can then unlock the FVEK (a clear-key protector can; a TPM/recovery/password protector needs its secret) is a fact the caller reads off the inventory — this crate states what protectors exist, it does not attempt any unlock.

Capabilities

crate root

Native parser for the BitLocker FVE metadata block: enumerates the volume's

BdeError

Native parser for the BitLocker FVE metadata block: enumerates the volume's

BitlockerMetadata

Native parser for the BitLocker FVE metadata block: enumerates the volume's

ProtectionType

Native parser for the BitLocker FVE metadata block: enumerates the volume's

VmkProtector

Native parser for the BitLocker FVE metadata block: enumerates the volume's

How to use it

No examples/ target and no doctest in this crate's rustdoc. The tests listed under Verification are the closest executable usage.

Module structure

No public modules: the crate root is its whole surface.

Public surface

`crate root`

No pub use re-exports: every item above is declared in this crate.

Boundary

Depends on no other workspace tier.

Shares tier infrastructure with 82 other crates: infrastructure-acquire, infrastructure-adapters-google-calendar, infrastructure-adapters-google-gmail, infrastructure-adapters-google-places, infrastructure-adapters-google-trends, infrastructure-adapters-shodan, infrastructure-adapters-yelp, infrastructure-agent, … (82 total).

_What this crate deliberately does NOT own is a judgment. No committed registry records one for it, so none is stated here._

Where it sits

Dependencies

Runtime, in this workspace.

Runtime, from outside the workspace.

Development. None.

Build. None.

Depended on by. 1 workspace crate.

Signal flow — what reaches this crate, and what it reaches.

flowchart LR
  n_tools_ir_triage["tools-ir-triage"] -->|uses| SELF
  SELF["infrastructure-bitlocker-forensics"]
  SELF -->|runtime| n_infrastructure_host_forensics["infrastructure-host-forensics"]
  classDef self fill:#1f883d,stroke:#1f883d,color:#fff;
  class SELF self;

Feature flags

No Cargo features are defined: every capability is unconditional, so no consumer can receive a half-wired crate.

Targets

Error model

Operational characteristics

No unsafe block, unsafe fn, unsafe impl or unsafe trait was found by the parser anywhere in this crate's source.

Configuration

No environment variable is read with a literal name anywhere in this crate. A variable whose key is computed at run time cannot be listed here, and is not claimed to be absent.

Related capabilities

1 workspace crate depends on this one: tools-ir-triage.

Verification

Evidence by module. How often each public module is named by something executable.

What the tests establish, by name:

• a_corrupt_entry_size_ends_the_walk_without_panicking — src/lib.rs
• all_known_protector_codes_map_and_a_typical_os_drive_needs_a_secret — src/lib.rs
• clear_key_means_recoverable_without_secret — src/lib.rs
• description_and_guid_and_modtime_are_cited — src/lib.rs
• metadata_offsets_reads_the_table_and_rejects_non_bitlocker — src/lib.rs
• non_bitlocker_block_is_rejected — src/lib.rs
• protection_codes_round_trip_through_from_code — src/lib.rs
• recovery_password_protector_is_read_at_the_right_offset — src/lib.rs
• truncated_metadata_size_is_an_error_not_a_panic — src/lib.rs

Documentation coverage

pie showData
    title Public items with rustdoc
    "Documented" : 11
    "No rustdoc detected" : 0

Metrics

pie showData
    title Public API by kind
    "enum" : 2
    "function" : 3
    "method" : 4
    "struct" : 2

pie showData
    title Rust source composition
    "Code" : 386
    "Blank or comment" : 136

Generation

Rendered by tools-corpus corpus readme from repository evidence alone, renderer schema 2, lexicon current. No model, network service or database was consulted. Regenerate with tools-corpus corpus readme --write; verify with --check.