Skip to content

core: volume-analysis — BitLocker/To-Go encryption + FAT/exFAT/NTFS serial#14

Merged
h4x0r merged 3 commits into
mainfrom
volume-analysis
Jul 12, 2026
Merged

core: volume-analysis — BitLocker/To-Go encryption + FAT/exFAT/NTFS serial#14
h4x0r merged 3 commits into
mainfrom
volume-analysis

Conversation

@h4x0r

@h4x0r h4x0r commented Jul 12, 2026

Copy link
Copy Markdown
Contributor

The scheme-agnostic volume-analysis foundation for usb-forensic's layering (ADR 0003/0004). Volume encryption and volume serial are properties of a volume, not the bus or partition table, so the forensic knowledge belongs here in the knowledge base.

  • volume_encryption::detect_encryption() → BitLocker (-FVE-FS-) / BitLocker To Go (identifier-GUID scan). A To Go discovery volume looks like plain FAT to a filesystem detector; the GUID is the only tell.
  • volume_serial::volume_serial() → FAT BS_VolID (0x43/0x27), exFAT (0x64), NTFS 8-byte serial (0x48); VolumeSerial::{Short,Long}.

Panic-free, MSRV 1.75, offsets/signatures cited to libbde + the Microsoft FAT/exFAT/NTFS specs. Validated on the real NIST CFReDS rm2 stick (encryption None, serial B4D8-5399 — ground-truth match). 35 core tests pass.

Once published, the mbr/gpt/apm partition crates call these to populate {fs, serial, encryption} on every partition uniformly, disk-forensic surfaces it, and usb-forensic's device_image thins to a consumer.

🤖 Generated with Claude Code

h4x0r and others added 3 commits July 12, 2026 23:33
The volume-analysis foundation for the scheme-agnostic layering (usb-forensic
ADR 0003/0004): the BitLocker/FVE forensic knowledge belongs in the knowledge
base, next to the filesystem-signature catalog, because a volume's encryption is
a property of the volume — identical over USB, FireWire, Thunderbolt, or SATA,
and independent of the MBR/GPT/APM partition table.

`detect_encryption(volume) -> Option<VolumeEncryption>`: `-FVE-FS-` at offset 3 →
BitLocker (fixed drive); else the BitLocker identifier GUID scanned in the volume
header → BitLocker To Go (a FAT/exFAT discovery volume that a filesystem detector
cannot see). Panic-free, MSRV 1.75, spec-cited to libbde. Non-false-positive
control validated against the real NIST CFReDS rm2 FAT stick (returns None).

Next: volume_serial() (FAT BS_VolID / NTFS-serial offsets), then the partition
crates populate {fs, serial, encryption} per partition uniformly.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The second half of the volume-analysis foundation (usb-forensic ADR 0003): the
volume serial is a forensic join key (a FAT BS_VolID matches the EMDMgmt/Shell-Link
serial for the same volume) and is a volume property, not a partition-scheme one.

`volume_serial(volume) -> Option<VolumeSerial>`, keyed off the FS signature: NTFS
8-byte serial at 0x48, exFAT at 0x64, FAT32 BS_VolID at 0x43, FAT12/16 at 0x27.
`VolumeSerial::{Short(u32), Long(u64)}` renders XXXX-XXXX / XXXXXXXX-XXXXXXXX.
Panic-free, MSRV 1.75, offsets cited to the Microsoft FAT/exFAT/NTFS specs.
Validated on the real CFReDS rm2 FAT32 stick: reads B4D8-5399 (ground-truth match).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…e_serial

Adding two public modules changed the surface; regenerate the committed baseline
(cargo public-api 0.52.0) so the public-api tripwire passes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@h4x0r h4x0r merged commit 75ab409 into main Jul 12, 2026
11 checks passed
@h4x0r h4x0r deleted the volume-analysis branch July 12, 2026 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant