Home / Alt manpages / cryptsetup-tcryptdump(8)

  • cryptsetup-tcryptdump(8)
  • Admin command
  • linux

Inspect a TCRYPT Header Safely with cryptsetup tcryptDump

You will inspect the header of a TrueCrypt or VeraCrypt-compatible volume without opening a mapping or changing the device. The examples target cryptsetup 2.7.0 from the installed cryptsetup-bin package, version 2:2.7.0-1ubuntu4.2. Allow about ten minutes for a read-only inspection, plus time to identify the correct device.

You need a shell, the device or image file, and a passphrase if the header requires one. A device path such as /dev/sdb must be readable by your account. Use sudo only when ordinary read access fails. Do not run these examples against a device you intend to modify until you have checked the path carefully.

1. Confirm the installed command

Check the version and action-specific help first. Both commands are ordinary, read-only checks:

$ cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
$ cryptsetup tcryptDump --help

The command shape is cryptsetup tcryptDump [options] device. Keep the capital D in the action name when copying the documented form into scripts and notes.

Checkpoint

Confirm the binary you are about to use:

$ command -v cryptsetup
/usr/sbin/cryptsetup

2. Inspect the normal header

Replace /path/to/tcrypt-device with an exact block-device path or a file containing the volume. This reads metadata and asks for the passphrase interactively when needed:

$ cryptsetup tcryptDump /path/to/tcrypt-device

Successful output begins with TCRYPT header information and includes fields such as the cipher chain, cipher mode, payload offset and key size. Exact values depend on the volume. A successful dump does not open the volume or create a device-mapper mapping.

Do not copy a guessed path from a listing into a destructive workflow. Check the candidate first:

$ ls -l /path/to/tcrypt-device
$ file /path/to/tcrypt-device

If the device is only readable by root, rerun the same inspection with elevated privileges:

$ sudo cryptsetup tcryptDump /dev/sdb

Elevated privileges change who can read the volume; they do not repair a wrong path, missing header or incorrect passphrase.

3. Select a non-default TCRYPT header

TrueCrypt-compatible volumes can have more than one relevant header location. The normal command searches according to cryptsetup's TCRYPT handling. Use an explicit selector only when you know the volume layout:

  • --tcrypt-hidden selects the hidden-volume header.
  • --tcrypt-system selects a system TCRYPT drive with a bootloader.
  • --tcrypt-backup selects the backup, or secondary, header.

For example, inspect a backup header with:

$ cryptsetup tcryptDump --tcrypt-backup /path/to/tcrypt-device

Use one selector at a time unless you have a specific reason to combine options and have checked the resulting behaviour. A header selector is not a conversion or repair operation. If the selected header is not present or cannot be unlocked, cryptsetup returns an error and leaves the device unchanged.

Checkpoint

Save the output as a text record only if your handling policy permits it. Header metadata can reveal layout details even when it does not contain a passphrase.

4. Handle VeraCrypt volumes deliberately

In cryptsetup 2.7.0, VeraCrypt-compatible mode is enabled by default for TCRYPT operations. The explicit --veracrypt option is accepted but ignored. To restrict detection to TrueCrypt-compatible modes, use:

$ cryptsetup tcryptDump --disable-veracrypt /path/to/tcrypt-device

For a VeraCrypt volume using a custom Personal Iteration Multiplier, supply the known value with --veracrypt-pim:

$ cryptsetup tcryptDump --veracrypt-pim 123 /path/to/veracrypt-volume

Replace 123 with the actual PIM. Do not guess it repeatedly on a slow or busy system. If the PIM is not known, ask for it interactively with:

$ cryptsetup tcryptDump --veracrypt-query-pim /path/to/veracrypt-volume

These options affect how the header is searched and derived. They do not make a VeraCrypt volume compatible with another tool or change its on-disk format.

5. Supply a passphrase without putting it in shell history

The normal interactive prompt is usually the safest choice for a one-off check. If a process needs a key file, use --key-file and protect the file with the normal filesystem permissions:

$ cryptsetup tcryptDump --key-file /secure/path/tcrypt-passphrase /path/to/tcrypt-device

A key file is combined with the passphrase processing described by cryptsetup, so treat it as secret material. The option can be repeated when the volume needs more than one key-file input. Avoid placing a passphrase directly in the command line: it can appear in shell history or process inspection.

To read from standard input, use a literal hyphen:

$ printf '%s' 'REPLACE_WITH_PASSPHRASE' | cryptsetup tcryptDump --key-file - /path/to/tcrypt-device

This example is safe to understand but not safe to paste with a real passphrase into a shared shell transcript. Standard-input reading does not stop at newline characters, so control exactly what your calling process supplies. Do not add --verify-passphrase to a key-file or standard-input workflow: the manpage says verification applies to interactive input and is ignored for file or stdin input.

6. Use timeouts and diagnostics without leaking secrets

The default interactive timeout is zero, which means wait forever. Set a finite timeout when a check runs from a boot or monitoring path that must not stall:

$ cryptsetup tcryptDump --timeout 30 /path/to/tcrypt-device

The timeout applies to terminal passphrase input and has no effect with --key-file. It does not impose a limit on every part of header detection or key derivation.

When a dump fails, first repeat the command with the path and selected header reviewed. Then add debug output if you need a report for diagnosis:

$ cryptsetup tcryptDump --debug /path/to/tcrypt-device

Debug lines are prefixed with #. Review the output before sending it anywhere. Do not include passphrases, key files or volume-key output in an issue, ticket or chat transcript.

7. Never expose the volume key casually

--dump-volume-key prints the volume key instead of ordinary header information. Anyone who obtains that key can decrypt the data without the passphrase. The installed manpage warns that compromising it means the whole device must be erased to prevent further access.

Security boundary

Do not run this option as a diagnostic shortcut, redirect it to a normal log, or paste its output into a terminal recording. If a controlled recovery procedure genuinely requires it, obtain approval, store the output only in an encrypted and access-controlled location, and destroy the temporary copy according to that procedure. This guide intentionally gives no copy-and-paste volume-key command.

If you ran the option accidentally, assume the displayed key is compromised. Stop distributing the output, preserve evidence for the person responsible for the volume, and follow your key-compromise response plan. There is no undo command for a key that has already been displayed.

Common failures

"Device or file not found" or permission denied: check the path with ls -l, confirm that the device is present, and use sudo only for the read permission problem. Do not create or format anything to make the command accept the path.

No valid TCRYPT header: check whether the input is the right container, whether it is a system or hidden volume, and whether --tcrypt-backup is appropriate. For VeraCrypt, confirm the PIM and remember that VeraCrypt mode is already enabled by default.

Passphrase rejected: stop retrying if the volume may use a key file, hidden header or different PIM. Check the input method and selected header without changing the device. A failed dump does not justify using --batch-mode; that option suppresses confirmation questions and also disables passphrase verification unless verification was explicitly requested.

Done means

  • You confirmed the installed cryptsetup version and exact device path.
  • You dumped the intended TCRYPT header without opening or modifying a mapping.
  • You selected hidden, system, backup or VeraCrypt parameters only when the volume requires them.
  • You kept passphrases and especially volume keys out of logs and shared transcripts.
  • You can explain any failure from the path, header selection, passphrase method or PIM instead of guessing.