Inspect a BitLocker Device with cryptsetup bitlkDump

cryptsetup bitlkDump lets you read a BitLocker header on Linux without opening the volume or changing a byte. The normal command prints BITLK header information and leaves the on-disk data alone. Allow about ten minutes, plus time to identify the correct device.

You need the cryptsetup-bin package and a readable block device or image.

1. Confirm the installed command and version

This guide follows cryptsetup 2.7.0, installed here from cryptsetup-bin version 2:2.7.0-1ubuntu4.2. Options and diagnostic wording can differ in another release, so check the binary on the machine that will do the inspection:

$ command -v cryptsetup
/usr/sbin/cryptsetup
$ cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
$ dpkg-query -W -f='${Package} ${Version}\n' cryptsetup-bin
cryptsetup-bin 2:2.7.0-1ubuntu4.2

The feature flags and package revision are host-specific. What matters is that the command exists and reports the release you intend to use.

2. Check the option shape without touching a device

Ask for the short help text first. This is an ordinary read-only command and normally needs no elevated privileges:

$ cryptsetup bitlkDump --help

The installed program uses this action form:

cryptsetup bitlkDump [options] <device>

For a non-destructive argument check, cryptsetup also accepts --test-args. It validates the command line and deliberately does not run the action:

$ cryptsetup --test-args bitlkDump /dev/example
No action taken. Invoked with --test-args option.

3. Identify the correct device

Use your normal inventory process to map the BitLocker volume to a stable path. If you have lsblk, this read-only listing is a good starting point:

$ lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,LABEL,UUID

Do not rely on a changing name such as /dev/sdb1 if the device can be reattached in a different order. Confirm the size, partition role, label or UUID against your records. For a disk image, use its explicit image path instead of guessing a loop-device name.

Reading a block device can fail for an ordinary account even though the device is present. Start without sudo. If the error is an access denial, ask an administrator for the required read access, or rerun the same command with the minimum privilege needed:

$ sudo cryptsetup bitlkDump /dev/REPLACE_WITH_CONFIRMED_DEVICE

4. Dump the BITLK header

Run the action against the confirmed device:

$ cryptsetup bitlkDump /dev/REPLACE_WITH_CONFIRMED_DEVICE

BITLK is cryptsetup's name for a BitLocker-compatible device, and the command prints its header information. The fields and values belong to the device, so do not copy an example header into a report as if it were universal.

A successful run returns to the shell without an error. Capture the output if you need to compare the header with recovery records, but handle it as potentially sensitive storage metadata.

$ status=$?
$ printf 'bitlkDump exit status: %s\n' "$status"
bitlkDump exit status: 0

Status 0 means the command completed successfully. It does not prove that the device can be unlocked, that its data is intact, or that you have a usable BitLocker recovery credential.

5. Keep passphrases and keys out of the terminal history

The basic header dump does not need a passphrase on the command line. If cryptsetup asks for one in a workflow that needs authenticated access, enter it at the prompt rather than appending it as an argument. Arguments can be exposed through shell history or process inspection.

For a key stored in a file, the documented option is --key-file (short form -d). Note two behaviours:

• The name - means standard input. Reading does not stop at newline characters.
• Limit the read when needed. Use --keyfile-size to exclude trailing data, and check the file's ownership and permissions first.

$ cryptsetup bitlkDump --key-file /path/to/REPLACE_WITH_PROTECTED_KEYFILE \
    --keyfile-size REPLACE_WITH_BYTE_COUNT \
    /dev/REPLACE_WITH_CONFIRMED_DEVICE

Do not put a real secret in the placeholder or in a shared transcript. The default maximum key-file size on this installation is 8192 kB, and cryptsetup --help reports the compiled-in limit for the current build.

6. Treat volume-key options as an emergency boundary

If a controlled recovery procedure genuinely requires the key, prefer --volume-key-file so it goes to a protected file rather than standard output:

$ cryptsetup bitlkDump --dump-volume-key \
    --volume-key-file /path/to/REPLACE_WITH_RESTRICTED_OUTPUT \
    --key-file /path/to/REPLACE_WITH_PROTECTED_KEYFILE \
    /dev/REPLACE_WITH_CONFIRMED_DEVICE

This creates or replaces the named output file. Stop and check your recovery policy before running it. If the file is no longer required, remove it under that policy and verify that no backup, shell transcript or diagnostic log kept a copy.

7. Diagnose a failed inspection

A message that the device cannot be opened can mean a wrong path, insufficient read permission, an unsupported format or damaged metadata. Check the path without changing anything:

$ ls -l /dev/REPLACE_WITH_CONFIRMED_DEVICE
$ test -r /dev/REPLACE_WITH_CONFIRMED_DEVICE && echo readable
$ cryptsetup bitlkDump --debug /dev/REPLACE_WITH_CONFIRMED_DEVICE

Debug output can contain device details, so store it only where access is appropriate. The manpage recommends adding --debug when reporting a failure, but review the output before sending it outside the system.

--timeout controls how long cryptsetup waits for an interactive passphrase prompt. Its default is zero, meaning wait forever, and it has no effect when --key-file is used. A bounded prompt can stop a maintenance shell hanging:

$ cryptsetup bitlkDump --timeout 30 /dev/REPLACE_WITH_CONFIRMED_DEVICE

Use this only when a prompt is expected. It does not make an inaccessible or invalid device work.