Table of Contents for

Practical Forensic Imaging

8
SPECIAL IMAGE ACCESS TOPICS

This chapter demonstrates techniques for getting information about disk image files and making them accessible as block devices and as mounted directories. You’ll learn to set up loop devices and create logical devices with device mapper tools. You’ll also explore methods to map or convert software-encrypted disk images, making them accessible by forensic tools. These methods are useful in situations in which the contents of an image cannot be accessed directly and a layer of active translation or decryption is needed. Examples of such images include encrypted filesystems, virtual machine (VM) images, and other image file formats that forensic tools do not directly support.

Each section also includes examples of safely mounting (read-only) image files as regular filesystems on the forensic acquisition host. Then you can easily browse and access the filesystem using common programs, such as file managers, office suites, file viewers, media players, and so on.

Forensically Acquired Image Files

The basis for many of the methods and examples you’ll see in this section is the Linux loop device (not to be confused with a loopback device, which is a network interface). A loop device is a pseudo device that can be associated with a regular file, making the file accessible as a block device in /dev.

Linux systems typically create eight loop devices by default, which might not be enough for a forensic acquisition host, but you can increase that number, either manually or automatically, on boot up. To create 32 loop devices during boot up, add max_loop=32 to the GRUB_CMDLINE_LINUX_DEFAULT= line in the /etc/default/grub file; after reboot, 32 unused loop devices should be available. The sfsimage script uses loop devices to mount SquashFS forensic evidence containers.

This chapter will cover different VM images from common VM systems from QEMU, VirtualBox, VMWare, and Microsoft Virtual PC. I also describe access to OS-encrypted filesystems, including Microsoft’s BitLocker, Apple’s FileVault, Linux LUKS, and VeraCrypt (a fork of TrueCrypt). But let’s begin the with the simplest form of image: a raw disk image acquired using a dd-style acquisition tool.

Raw Image Files with Loop Devices

The simplest demonstration of a loop device can be shown using a raw image file (possibly acquired from a simple dd command). The losetup command attaches and detaches loop devices from a Linux system. This example creates a block device for an image.raw file:

# losetup --read-only --find --show image.raw
/dev/loop0

Here, the flags specify that the loop should be read-only (--read-only) and the next available loop device should be used (--find) and displayed on completion (--show). The filename specified (image.raw) will then become available as an attached block device.

Running the losetup command without parameters displays the status of all configured loop devices. Here we can see the one just created:

# losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
/dev/loop0         0      0         0  1 /exam/image.raw

The /dev/loop0 device now points to /exam/image.raw, and you can access it with any tools that operate on block devices. For example, here the Sleuth Kit mmls command is able to see the partition table on the image.raw file using the loop device:

# mmls /dev/loop0
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000002047   0000002048   Unallocated
02:  00:00   0000002048   0058597375   0058595328   Linux (0x83)
03:  00:01   0058597376   0078129151   0019531776   Linux Swap / Solaris x86 (0x82)
04:  00:02   0078129152   0078231551   0000102400   NTFS (0x07)
05:  00:03   0078231552   0234441647   0156210096   Mac OS X HFS (0xaf)

When you no longer need a loop device, simply detach it as follows:

# losetup --detach /dev/loop0

Loop devices are flexible and configurable. In the previous mmls example, a filesystem starts at sector 2048. It’s possible to specify an offset each time you run a forensic tool, but it’s easier to have a separate device for each partition (similar to /dev/sda1 for example). You can create a separate loop device with the losetup command just for that partition by specifying the correct offset flag (--offset) and size flag (--sizelimit). However, a more commonly accepted way is to use the device mapper.

You could do this manually using dmsetup and mapping tables as described in “RAID and Multidisk Systems” on page 178. However, the kpartx tool automates the creation of partition devices for a particular image file. A forensically acquired image with four partitions is used in the following example to demonstrate the kpartx tool making mapper devices for each partition:

# kpartx -r -a -v image.raw
add map loop0p1 (252:0): 0 58595328 linear /dev/loop0 2048
add map loop0p2 (252:1): 0 19531776 linear /dev/loop0 58597376
add map loop0p3 (252:2): 0 102400 linear /dev/loop0 78129152
add map loop0p4 (252:3): 0 156210096 linear /dev/loop0 78231552

Here, the kpartx tool reads the partition table on a disk or image file, creates a loop device for the whole image, and then creates mapper devices for each partition. The -r flag ensures the drive loop and partition mappings are read-only, and the -a flag instructs kpartx to map everything it finds. Use the verbose flag -v to document the command output and to indicate what was just mapped.

In this example, a loop device is created (/dev/loop0) for the whole image file and is accessible as a raw block device. In addition, partition devices are now available in the /dev/mapper directory, and you can access them using forensic tools that operate on partitions, without specifying any offsets. Here are a few example Sleuth Kit commands for some of the partitions:

# fsstat /dev/mapper/loop0p1
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext4
Volume Name:
Volume ID: d4605b95ec13fcb43646de38f7f49680
...
# fls /dev/mapper/loop0p3
r/r 4-128-1:    $AttrDef
r/r 8-128-2:    $BadClus
r/r 8-128-1:    $BadClus:$Bad
r/r 6-128-1:    $Bitmap
r/r 7-128-1:    $Boot
d/d 11-144-2:   $Extend
r/r 2-128-1:    $LogFile
r/r 0-128-1:    $MFT
...
# fsstat /dev/mapper/loop0p4
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: HFS+
File System Version: HFS+
...

A filesystem mapped to a device from an image file can be safely mounted as read-only. This will allow you access it with a standard file manager, applications, and other file-analysis tools. You can mount and unmount loop partitions, as shown in this example:

# mkdir p3
# mount --read-only /dev/mapper/loop0p3 p3
# mc ./p3
...
# umount p3
# rmdir p3

Here, a directory, p3, representing the partition was created in the same directory as the raw image. Then p3 was used as the mount point (the chosen mount point can be anywhere on the examiner host filesystem). Midnight Commander (mc) is a text-based file manager (a Norton Commander clone) and is used in this example to review the files on the mounted partition. When the mount point is no longer needed, the umount command (this command is spelled correctly with only one n) unmounts the filesystem, and rmdir removes the mount point directory. This is the traditional Unix way to mount and unmount a filesystem on a host system.

When you no longer need the drive loop and partition mappings, you can remove them all by using the kpartx delete (-d) flag and the name of the image file, like this:

# kpartx -d image.raw
loop deleted : /dev/loop0

Note that this “delete” has no effect on the disk image’s contents. The loop and mappings are deleted, not the drive image, and the drive image is not modified.

If a raw image has a corrupt or overwritten partition table, you can scan the image for filesystems and use dmsetup to manually map filesystems as devices (using dmsetup tables).

When you create, mount, unmount, or detach a loop device, root privileges are required. They’re also required for operating on the /dev/loopX device with forensic tools. The examples shown in this section were run as the root user to reduce the complexity of the command lines, making them easier to understand. Prefixing the commands with sudo can be used to run privileged commands as a non-root user.

Forensic Format Image Files

The ewflib software package includes a tool called ewfmount to “mount” the contents of a forensic image, making it accessible as a regular raw image file.

The following example shows a group of *.e01 files. A mount point, raw in this example, is created with mkdir and will contain the raw image file:

# ls
image.E01  image.E02  image.E03  image.E04  image.E05
# mkdir raw

The ewfmount tool creates a FUSE filesystem containing a virtual raw image from one or more EWF files. You can run ewfmount command with the first of the EnCase EWF files and the mount point to access a raw image file like this:

# ewfmount image.E01 raw
ewfmount 20160424

# ls -l raw
total 0
-r--r--r-- 1 root root 16001269760 May 17 21:20 ewf1

You can then operate on this virtual raw image file using tools that don’t support EWF formats directly. In the following example, a hex editor (without EWF support) is used in sector mode to analyze the raw image:

# hexedit -s raw/ewf1
...

The kpartx tool is again useful to identify partitions and create corresponding loop devices, enabling the use of tools that can operate on block devices and allowing the mounting of the filesystems for regular browsing. The kpartx output of the *.e01 files mounted with ewfmount is shown here:

# kpartx -r -a -v raw/ewf1
add map loop0p1 (252:0): 0 29848707 linear /dev/loop0 63
add map loop0p2 (252:1): 0 2 linear /dev/loop0 29848770
add map loop0p5 : 0 1397592 linear /dev/loop0 29848833

Let’s continue using this example to create a mount point for a partition and mount and access a filesystem:

# mkdir p1
# mount --read-only /dev/mapper/loop0p1 p1
# ls p1
cdrom  home/       lib32/       media/  proc/  selinux/  tmp/  vmlinuz
bin/     dev/   initrd.img  lib64        mnt/    root/  srv/      usr/
boot/    etc/   lib/        lost+found/  opt/    sbin/  sys/      var/
...

In this example, a mount point corresponding to the partition is created in the local directory, the partition device is mounted on it, and the file-system is accessed with ls. If possible, avoid the use of /mnt or other shared mount directories when mounting evidence files and containers. It is easier to perform forensic work when the mount points for an image are in the same working directory as other related case files.

As before, when the work is completed, you need to clean up the mounts and virtual files. Again, this is done in the reverse order:

# umount p1
# kpartx -d raw/ewf1
loop deleted : /dev/loop0
# fusermount -u raw
# rmdir p1 raw

The fusermount command is shown in this example, but the standard Linux umount command would also work. Make sure your current working directory is not inside the mount point and that no programs have open files inside the mount points. Both conditions will cause these cleanup steps to fail.

When using SquashFS forensic evidence containers, you can access the raw image by mounting the *.sfs file with sfsimage -m, creating the partition devices, and then mounting the desired partition. You can then execute regular commands on the subject image’s filesystem. A complete example is shown here:

# sfsimage -m image.sfs
image.sfs.d mount created
# kpartx -r -a -v image.sfs.d/image.raw
add map loop1p1 (252:0): 0 29848707 linear /dev/loop1 63
add map loop1p2 (252:1): 0 2 linear /dev/loop1 29848770
add map loop1p5 : 0 1397592 linear /dev/loop1 29848833
# mkdir p1
# mount /dev/mapper/loop1p1 p1
mount: /dev/mapper/loop1p1 is write-protected, mounting read-only
# ls -l
...

Once you are finished accessing the raw image and its filesystems, clean up with SquashFS forensic evidence containers is also done in reverse. The sfsimage -u command unmounts a SquashFS filesytem as shown in this example:

# umount p1
# kpartx -d image.sfs.d/image.raw
loop deleted : /dev/loop1
# sfsimage -u image.sfs.d/
image.sfs.d unmounted

This section has demonstrated several methods for accessing the contents of forensic formats, both as block devices and as regular filesystems. The ewfmount tool also works with FTK SMART files. Afflib has a similar tool called affuse for mounting *.aff files. Both ewfmount and affuse can operate on single or split files of their respective formats.

Note that many forensic tools (Sleuth Kit, for example) are able to operate directly on forensic formats without the need for a raw block device or raw file.

Prepare Boot Images with xmount

Forensic investigators often want to examine a subject drive image with nonforensic tools, such file managers, office suites, applications, or other file viewer tools. This can be done by making the drive contents safely available over a read-only mount for the local examiner machine to access.

In some cases, it is useful to boot a subject drive in a VM to observe and interact directly with the live subject environment. This allows you to view the subject’s desktop and use the installed programs of the subject PC. To do this, you can use a number of tools described in this section.

The xmount (pronounced “crossmount”) tool creates a virtual disk image that you can boot using VM software, such as VirtualBox or kvmqemu. The xmount tool allows you to simulate a read-write drive, making the VM think the disk is writable, but it continues to protect the image in a read-only state. Multiple VM output formats are available, including raw, DMG, VDI, VHD, VMDK, and VMDKS.

The input formats include forensically acquired image files, such as *.raw, EnCase *.ewf, and AFFlib *.aff files.

Here is an example of a raw image (image.raw) set up with xmount as a VirtualBox *.vdi file:

$ mkdir virtual
$ xmount --cache xmount.cache --in raw image.raw --out vdi virtual
$ ls virtual/
image.info  image.vdi
$ cat virtual/image.info
------> The following values are supplied by the used input library(ies) <------

--> image.raw <--
RAW image assembled of 1 piece(s)
30016659456 bytes in total (27.955 GiB)

------> The following values are supplied by the used morphing library <------

None
$ virtualbox

In this example, the directory virtual is created to hold the virtual image file (it will be FUSE mounted). From an existing image.raw file, the xmount command creates a write-cached VirtualBox VDI image in the ./virtual directory. This is just a virtual representation of the image file; it is not copied or converted (thus not wasting disk space on the examiner machine). The --in and --out flags specify the image format used. The input formats must be raw, AFF, or EWF. Multiple output formats are possible.

Booting an OS image in a VM can be challenging when the installed OS is expecting a different hardware configuration than provided by the VM. Typically, this is less of an issue with Linux installations but can be problematic with Windows and OS X. To solve this problem, two tools, opengates and openjobs, were created to prepare Windows and OS X images for safely booting subject disks in a virtual environment. I won’t cover how to use opengates and openjobs, but you can find more information about them at https://www.pinguin.lu/openjobs/ and https://www.pinguin.lu/opengates/.

When you no longer need the VM image, you can clean up by unmounting the virtual image and removing the mount point directory:

$ fusermount -u virtual
$ ls virtual/
$ rmdir virtual

A xmount.cache file containing data written during the use of the VM might exist. You can save the file if you need to continue the previous VM session, or you can remove it.

VM Images

With the increasing performance of home computers, hardware virtualization in most modern CPUs, and the availability of inexpensive or free virtualization software, there is an increased need to analyze the contents of VM images. In some cases, you might find many VM images on subject PCs. This section focuses on accessing common VM image file types such as QCOW2, VDI, VMDK, and VHD.

QEMU QCOW2

The QCOW2 format is a common VM image type found on Linux and used by the QEMU emulator. In this section, I’ll make a QCOW2 image available as a block device and safely mount it for browsing.

The libqcow-utils package (written by Joachim Metz, author of ewflib) contains the qcowinfo and qcowmount tools. You can use both tools in the same way as you used the ewfinfo and ewfmount tools in previous examples. But the following example shows an alternative method using the qemu-img command, the nbd kernel module, and the qemu-nbd tool. This method offers performance advantages because it operates in the kernel and saves you a few steps because you don’t need to use kpartx.

Given a *.qcow2 file, the qemu-img command can provide a summary of the file:

# qemu-img info image.qcow2
image: image.qcow2
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 141M
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

To access a QCOW image in a raw image representation with nbd, you need to load the nbd kernel module:

# modprobe nbd
# dmesg | grep nbd
[16771.003241] nbd: registered device at major 43

Unlike with the losetup command, the device is not automatically chosen. A /dev/nbd* device needs to be specified as follows:

# qemu-nbd --read-only --connect /dev/nbd0 image.qcow2
# dmesg | grep nbd0
[16997.777839]  nbd0: p1

Here, the QCOW2 image file was connected to the kernel module in read-only mode, and the partition device was automatically detected. You can use this raw device with forensic tools, as shown in this example:

# mmls /dev/nbd0
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000002047   0000002048   Unallocated
02:  00:00   0000002048   0010485759   0010483712   Linux (0x83)

The partition devices (the raw device name with p1 in this example) are also ready for you to use directly with forensic tools. To illustrate, here’s the fls command operating directly on a filesystem on the partition device:

# fls /dev/nbd0p1
d/d 11: lost+found
r/r 12: hosts
d/d 327681:     $OrphanFiles
...

Mounting the devices locally for browsing is trivial. A local mount point directory is created, and the filesystem is mounted normally, as follows:

# mkdir p1
# mount /dev/nbd0p1 p1
mount: /dev/nbd0p1 is write-protected, mounting read-only
# ls p1
hosts  lost+found/

The cleanup here is similar to the examples using loop devices, but with fewer steps. All processes should close files, and you should leave the mounted directory so it can be unmounted. A qemu-nbd disconnect command specifying the device name will unregister the device from the kernel, like so:

# umount p1
# qemu-nbd --read-only --disconnect /dev/nbd0
/dev/nbd0 disconnected
# rmdir p1

An optional step is to remove the kernel module using rmmod nbd. But there is no harm in leaving it in if you’ll be doing more QCOW mounts. You can also autoload the nbd module at boot by adding it to the /etc/modules file.

VirtualBox VDI

VirtualBox is an open source project maintained by Oracle (formerly Sun Microsystems). Although it supports multiple VM image formats, VirtualBox VDI images are used in the examples that follow. The same qemu-nbd command is used as before but with an OpenSolaris image.

The VirtualBox software package includes a number of utilities; the VBoxManage tool is shown here, providing information about the VDI image:

# VBoxManage showhdinfo OpenSolaris.vdi
UUID:           0e2e2466-afd7-49ba-8fe8-35d73d187704
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /exam/OpenSolaris.vdi
Storage format: VDI
Format variant: dynamic default
Capacity:       16384 MBytes
Size on disk:   2803 MBytes
Encryption:     disabled

You can mount VirtualBox images using qemu-nbd and the nbd kernel module (as you saw in the previous section using QCOW2). The Open-Solaris example shown here is slightly different from the partitioning scheme Windows and Linux use. Multiple disk slices¹ are also shown:

# qemu-nbd -c /dev/nbd0 OpenSolaris.vdi
# dmesg
...
[19646.708351]  nbd0: p1
                p1: <solaris: [s0] p5 [s1] p6 [s2] p7 [s8] p8 >

In this example, a single Solaris partition (p1) contains multiple slices (p5, p6, p7, and p8).

You can use the same methods as in the previous QEMU example to access the raw and partition devices, then mount the partitions as read-only to a local mount point. Here again, you don’t need to use kpartx to find the partitions, because the kernel does it automatically. Once you are finished accessing the partitions (or slices, here), perform the cleanup steps to unmount filesystems and disconnect the nbd device.

VMWare VMDK

The Virtual Machine DisK (VMDK) format is used by VMWare’s VM software products. The following example uses the libvmdk-utils software package on an Apple Lion VMDK image split into multiple parts:

# ls
lion-000001-s001.vmdk  lion-000003-s007.vmdk  lion-s009.vmdk
lion-000001-s002.vmdk  lion-000003-s008.vmdk  lion-s010.vmdk
lion-000001-s003.vmdk  lion-000003-s009.vmdk  lion-s011.vmdk
lion-000001-s004.vmdk  lion-000003-s010.vmdk  lion-s012.vmdk
lion-000001-s005.vmdk  lion-000003-s011.vmdk  lion-s013.vmdk
lion-000001-s006.vmdk  lion-000003-s012.vmdk  lion-s014.vmdk
lion-000001-s007.vmdk  lion-000003-s013.vmdk  lion-s015.vmdk
lion-000001-s008.vmdk  lion-000003-s014.vmdk  lion-s016.vmdk
...

You can retrieve information about the assembled image and each of the “Extents” using vmdkinfo:

# vmdkinfo lion.vmdk
vmdkinfo 20160119

VMware Virtual Disk (VMDK) information:
        Disk type:                      2GB extent sparse
        Media size:                     42949672960 bytes
        Content identifier:             0xadba0513
        Parent content identifier:      0xffffffff
        Number of extents:              21

Extent: 1
        Filename:                       lion-s001.vmdk
        Type:                           Sparse
        Start offset:                   0
        Size:                           2146435072 bytes
...

Creating a mount point and mounting the image makes it accessible as a raw image file:

# mkdir lion
# vmdkmount lion.vmdk lion
vmdkmount 20160119
# ls -ls lion
total 0
0 -r--r--r-- 1 root root 42949672960 May 17 22:24 vmdk1
# mmls lion/vmdk1
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Safety Table
01:  -----   0000000000   0000000039   0000000040   Unallocated
02:  Meta    0000000001   0000000001   0000000001   GPT Header
03:  Meta    0000000002   0000000033   0000000032   Partition Table
04:  00      0000000040   0000409639   0000409600   EFI System Partition
05:  01      0000409640   0082616503   0082206864   Untitled
06:  02      0082616504   0083886039   0001269536   Recovery HD
07:  -----   0083886040   0083886079   0000000040   Unallocated

Using kpartx, as shown earlier in the chapter, will create the associated disk and partition block devices. You can then use forensic analysis tools on them directly or mount them on the local machine to browse the filesystem.

Microsoft VHD

A number of methods help you make the Microsoft VHD virtual image format accessible. For example, you can use the qemu-nbd method or use the libvhdi-utils with vhdiinfo and vhdimount.

A third method is available using the blktap-utils with the Xen blktap xapi interface. Similar to the nbd method, the blktap requires you to insert a kernel module and manually allocate a device. A tapdisk process is spawned, attached to the driver, and instructed to open a disk image. The manual pages for blktap-utils aren’t very useful, but you can find a description on the Xen website at http://wiki.xen.org/wiki/Mounting_a_.vhd_disk_image_using_blktap/tapdisk and at http://lists.xen.org/archives/html/xen-api/2012-05/msg00149.html.

To complete this section, I’ll repeat the process for setting up devices using the libvhdi tools. For simplicity, the previous examples used the privileged root user. But the following examples demonstrate a nonprivileged user authorized to use sudo.

To run the FUSE mount and unmount commands as a nonprivileged user, you need to set user_allow_other in /etc/fuse.conf.

You can find information about the image using vhdiinfo, and no special privileges are required:

$ vhdiinfo windows.vhd
vhdiinfo 20160111
Virtual Hard Disk (VHD) image information:
        Format:                 1.0
        Disk type:              Dynamic
        Media size:             136365211648 bytes
        Identifier:             c9f106a3-cf3f-6b42-a13f-60e349faccb5

You can FUSE mount the image without root privileges, but you need to explicitly instruct the vhdimount command to allow the root user access by adding the -X allow_root flag. This flag is also needed to allow root to perform further actions through sudo (like creating block devices with kpartx):

$ mkdir raw
$ vhdimount -X allow_root windows.vhd raw
vhdimount 20160111

$ ls -l raw/
total 0
-r--r--r-- 1 holmes holmes 136365211648 Jan 20 08:14 vhdi1

The raw image is now available in the ./raw directory, and you can access it with standard tools. To create loop and mapper devices, run kpartx with the sudo command. Once the devices are created, you can access them with tools via the sudo command. The sudo command is required for all block device access. Examples with kpartx and fls are shown here:

$ sudo kpartx -r -a -v ./raw/vhdi1
add map loop0p1 (252:0): 0 266334018 linear /dev/loop0 63
$ sudo fls /dev/mapper/loop0p1
r/r 4-128-4:    $AttrDef
r/r 8-128-2:    $BadClus
r/r 8-128-1:    $BadClus:$Bad
r/r 6-128-1:    $Bitmap
r/r 7-128-1:    $Boot
d/d 11-144-4:   $Extend
r/r 2-128-1:    $LogFile
r/r 0-128-1:    $MFT

Mounting the filesystem also requires sudo, and explicitly specifying -o ro mounts it as read-only. An example of creating a mount point, mounting the filesystem from the previous example, and accessing it with ls is shown here:

$ mkdir p1
$ sudo mount -o ro /dev/mapper/loop0p1 p1
$ ls p1
AUTOEXEC.BAT                 IO.SYS          $RECYCLE.BIN/
...

The cleanup of this session requires sudo for unmounting the raw image and removing the loop and mapper devices. You can remove the FUSE mount of the *.vhd file without root privileges. These steps are shown here:

$ sudo umount p1
$ sudo kpartx -d raw/vhdi1
loop deleted : /dev/loop0
$ fusermount -u raw

You configure the sudo command by editing the /etc/sudoers file. Many of the examples in this book use the root user for simplicity’s sake to reduce the number of commands on an already complex command line. It’s good practice to work as a nonprivileged user with security mechanisms such as sudo.

OS-Encrypted Filesystems

Now let’s look at accessing popular encrypted filesystems. The focus is not on key recovery (although I do provide a couple of suggestions) but on accessing the filesystems with a known key. It’s assumed the keys or passwords are available from memory dumps, escrow/backup in enterprise organizations, individuals legally compelled to provide them, victims offering to help, commercial recovery services/software, or other sources.

You can determine the type of filesystem encryption with various partition-analysis tools that can identify headers, magic numbers, and other artifacts unique to a particular encrypted filesystem type. You’ll find an overview of identifying filesystem encryption in a forensic context at http://encase-forensic-blog.guidancesoftware.com/2014/04/version-7-tech-tip-spotting-full-disk.html.

In this section, you’ll find the information about a particular encrypted image needed to create an unencrypted block device or file that you can access using forensic tools or safely mount for local browsing.

Microsoft BitLocker

Microsoft’s current default filesystem encryption is BitLocker. It encrypts at the block level, protecting entire volumes. A variant of BitLocker designed for removable media is called BitLocker-To-Go, which uses encrypted container files on a regular unencrypted filesystem. Two open source tools, dislocker and libbde, are shown in the examples in this section.

Written by Romain Coltel, you’ll find the dislocker package at https://github.com/Aorimn/dislocker/. It provides various tools for handling BitLocker volumes, including viewing metadata, creating decrypted image files, and FUSE mounting volumes.

The dislocker-find tool scans all attached partition devices and specified files to identify the existence of any BitLocker volumes. Scanning for BitLocker devices might not be necessary if the subject device was already identified during the process of attaching it to the acquisition host.

The dislocker-metadata command provides an overview of a BitLocker drive. The next example is an image taken from a USB thumb drive. The entire drive is encrypted, and it doesn’t have a partition table. The image file can be queried as follows:

# dislocker-metadata -V bitlocker-image.raw
...
Wed Jan 20 13:46:06 2016 [INFO] BitLocker metadata found and parsed.
Wed Jan 20 13:46:06 2016 [INFO] =====[ Volume header informations ]=====
Wed Jan 20 13:46:06 2016 [INFO]   Signature: 'MSWIN4.1'
Wed Jan 20 13:46:06 2016 [INFO]   Sector size: 0x0200 (512) bytes
...
Wed Jan 20 13:46:06 2016 [INFO]   Number of sectors (64 bits): 0x0000000200000000
    (8589934592) bytes
Wed Jan 20 13:46:06 2016 [INFO]   MFT start cluster: 0x0000000000060001 (393217)
    bytes
...
Wed Jan 20 13:46:06 2016 [INFO] =====================[ BitLocker information
    structure ]=====================
Wed Jan 20 13:46:06 2016 [INFO]   Signature: '-FVE-FS-'
Wed Jan 20 13:46:06 2016 [INFO]   Total Size: 0x02f0 (752) bytes (including
    signature and data)
Wed Jan 20 13:46:06 2016 [INFO]   Version: 2
Wed Jan 20 13:46:06 2016 [INFO]   Current state: ENCRYPTED (4)
Wed Jan 20 13:46:06 2016 [INFO]   Next state: ENCRYPTED (4)
Wed Jan 20 13:46:06 2016 [INFO]   Encrypted volume size: 7918845952 bytes
    (0x1d8000000), ~7552 MB
...

The output of this command provides a lot of detailed cryptographic information not shown here. You can save the output of dislocker-metadata to a text file for documentation purposes. This command can also operate directly on attached devices.

As in previous password and encryption examples, it’s assumed that you have the key. Some commercial tools are available to attempt password brute force to recover the key. In addition, you can use a volatility plug-in to extract the FVEK from a memory image (https://github.com/elceef/bitlocker/), and you could use this tool in conjunction with the inception memorydumping tool. The use of these tools is not covered here.

You can create a virtual file or block device to operate on a decrypted view of the disk image “in place.” The process to do so is similar to the examples in “VM Images” on page 237. The dislocker software package provides a tool to create a FUSE filesystem with virtual representation of the decrypted volume:

# mkdir clear
# dislocker-fuse -u -V bitlocker-image.raw clear
Enter the user password:
# ls -l clear/
total 0
-rw-rw-rw- 1 root root 7918845952 Jan  1  1970 dislocker-file
...

The file that appears in the clear directory is a decrypted representation of the encrypted filesystem, and you can operate on it using regular forensic tools. An example using Sleuth Kit’s fsstat is shown here:

# fsstat clear/dislocker-file
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT32

OEM Name: MSDOS5.0
Volume ID: 0x5a08a5ba
Volume Label (Boot Sector): NO NAME
Volume Label (Root Directory): MY SECRETS
File System Type Label: FAT32
Next Free Sector (FS Info): 34304
Free Sector Count (FS Info): 15418664
...

You can safely mount the decrypted filesystem image for normal browsing. The mount command has a loop option, which allows a partition image file to be directly mounted, as shown here:

# mkdir files
# mount -o loop,ro clear/dislocker-file files
# ls files
Penguins.jpg  private/  System Volume Information/
...

The cleanup in this example is a simple matter of unmounting the files’ mount point, removing the FUSE mount, and deleting the mount directories:

# umount files
# rmdir files
# fusermount -u clear
# rmdir clear

Note that the preceding examples were done with root privileges to reduce complexity and make them easier to understand. You can perform the same commands as a nonprivileged user, as shown here:

$ dislocker-metadata -V bitlocker-image.raw
$ mkdir clear files
$ dislocker-fuse -u -V bitlocker-image.raw -- -o allow_root clear
$ sudo mount -o loop,ro,uid=holmes clear/dislocker-file files
...
$ sudo umount files
$ fusermount -u clear
$ rmdir clear files

Here dislocker-fuse passes -o allow_root to the FUSE driver, allowing sudo to be used for mounting and unmounting. The uid=holmes ensures that Mr. Holmes can access the mounted files without root privileges. It’s assumed that Mr. Holmes is a member of the FUSE Unix group, and the /etc/fuse.conf file contains the line user_allow_other.

Using dislocker, you can provide three possible credentials to unlock a BitLocker container. A -u flag (used in the previous example) specifies that the user’s password be requested. A -p flag provides a recovery password (48 digits long). And an -f flag specifies a key file (BEK file).

Using a recovery password (-p) instead of a user password (-u) requires manually keying in the 48-digit recovery password, as follows:

# dislocker-fuse -p -V bitlocker-image.raw clear
Enter the recovery password: XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX
Valid password format, continuing.

The non-root version of this command passes flags to FUSE, which allows for mounting with sudo:

$ dislocker-fuse -p -V bitlocker-image.raw -- -o allow_root clear

You can also decrypt the BitLocker image and save it separately as a regular filesystem image (only the specified volume is saved, not the partition table or other partitions). This will take some time depending on the size of the BitLocker image, as the entire image is decrypted and written to a new image file on the disk. You’ll need to do some capacity planning, because the two images, encrypted and decrypted, will take up space on the acquisition host. You can create a decrypted version of the volume as follows:

# dislocker-file -u -V bitlocker-image.raw bitlocker-image.clear
Enter the user password:
# ls -hs
total 15G
7.4G bitlocker-image.clear  7.4G bitlocker-image.raw

The resulting decrypted image file is the same size as the original because each BitLocker block was decrypted and the cleartext block written to the new image. This command does not need root privileges.

Now you can mount the decrypted BitLocker image file and access it as a partition using a mount command with a loop option:

# mkdir files
# mount -o loop,ro bitlocker-image.clear files
# ls files/
Penguins.jpg  private/  System Volume Information/

The only command that is different for non-root use is mount:

$ sudo mount -o loop,ro,uid=holmes bitlocker-image.clear files

Because BitLocker is the default filesystem encryption on the dominant OS platform, it’s worth providing a second example using a different software package. The libbde package (written by Joachim Metz, the author of ewflib) also provides libraries and tools to access BitLocker images.

The example shown next is slightly more complex than the previous one, because it involves a notebook disk with a regular partition table (in contrast to a USB thumb drive without a partition table). After calculating the offsets from the mmls output, the bdeinfo tool is demonstrated to provide a compact overview of the BitLocker container.

Both dislocker and libbde can be given a byte offset for the start of the BitLocker-encrypted volume. But this is unnecessary when working with image files of volumes/partitions or devices without partitions. In this example, an acquired image has a partition table, and the BitLocker-encrypted volume offset (in bytes) must be calculated.

The next example demonstrates how to determine the byte offset. The Sleuth Kit mmls command displays the partition table and the sector offsets for each partition. The sector offset must be converted into a byte offset, which can be used with the decryption tools:

# mmls image0.raw
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000002047   0000002048   Unallocated
02:  00:00   0000002048   0004098047   0004096000   NTFS (0x07)
03:  00:01   0004098048   0625140399   0621042352   NTFS (0x07)
04:  -----   0625140400   0625142447   0000002048   Unallocated
# echo $((4098048*512))
2098200576

You can convert the sector offset shown by mmls to a byte offset by multiplying by the sector size. On the command line it is convenient to use Bash math expansion. In this example, the sector offset is 4098048 and the sector size is 512. Multiplying these gives a byte offset of 2098200576. You can use this value for the bdeinfo command as follows:

# bdeinfo -o 2098200576 image0.raw
bdeinfo 20160119

BitLocker Drive Encryption information:
        Encryption method:              AES-CBC 128-bit with Diffuser
        Volume identifier:              5f61cbf2-75b5-32e5-caef-537fce3cf412
        Creation time:                  Jan 10, 2014 17:43:50.838892200 UTC
        Description:                    Notebook System 15.01.2014
        Number of key protectors:       2

Key protector 0:
        Identifier:                     3cd1fd6c-2ecb-2dc7-c150-839ce9e710b6
        Type:                           TPM

Key protector 1:
        Identifier:                     837ef544-e1ca-65c1-a910-83acd492bc1a
        Type:                           Recovery password
...

The bdemount command operates similarly to the dislocker command and creates a virtual file that represents the decrypted image (the full key has been shortened here):

# mkdir raw
# bdemount -o 2098200576 -r 630641-...-154814 image.raw raw

The file will appear in the ./raw directory, where you can analyze it directly or mount it to a loop device for regular browsing. The mount commands are the same as the previous BitLocker example, so they’re not repeated here.

Apple FileVault

Apple’s filesystem encryption built into OS X is FileVault. It is also a block-level encryption system, and several open source tools are available to decrypt it. Two tools I’ll describe here are libfvde and VFDecrypt. (The libfvde software package was written by Omar Choudary and Joachim Metz, and you’ll find it at https://github.com/libyal/libfvde/.)

Before you use the libfvde tools, you need to calculate the correct byte offset of the FileVault-encrypted volume. The mmls command provides the sector offset of the volume, which needs to be converted to bytes:

# mmls image.raw
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Safety Table
01:  -----   0000000000   0000000039   0000000040   Unallocated
02:  Meta    0000000001   0000000001   0000000001   GPT Header
03:  Meta    0000000002   0000000033   0000000032   Partition Table
04:  00      0000000040   0000409639   0000409600   EFI System Partition
05:  01      0000409640   0235708599   0235298960   HDD
06:  02      0235708600   0236978135   0001269536   Recovery HD
07:  -----   0236978136   0236978175   0000000040   Unallocated
# echo $((409640*512))
209735680

Multiplying the sector offset by the sector size using simple Bash math expansion provides a byte offset of 209735680, which you can use for the fvdeinfo and fvdemount tools.

The fvdeinfo tool provides an overview of the FileVault-encrypted volume:

# fvdeinfo -o 209735680 image.raw
fvdeinfo 20160108

Core Storage information:

Physical volume:
        Size: 120473067520             bytes
        Encryption method:             AES XTS

Logical volume:
        Size:                          120137519104 bytes

To decrypt the FileVault volume, you need to recover the EncryptedRoot.plist.wipekey file and provide either a user password or recovery key. You can find and extract the wipekey file using Sleuth Kit tools, as shown here:

# fls -r -o 235708600 image.raw | grep EncryptedRoot.plist.wipekey
+++++ r/r 1036: EncryptedRoot.plist.wipekey
# icat -o 235708600 image.raw 1036 > EncryptedRoot.plist.wipekey

The recursive fls output of the Recovery HD partition uses the sector offset found with mmls. The output is grepped for the EncryptedRoot.plist.wipekey file. After it’s found, the icat tool is used to extract it (using the inode, which is 1036 in this example). Notice how a sector offset was used with fls and icat, and not a byte offset.

The 24-character recovery key is used with the -r flag and the now-recovered EncryptedRoot.plist.wipekey file. You can then use this key to create a FUSE mount of a decrypted representation of the volume, as shown here (the recovery key has been shortened):

# mkdir clear
# fvdemount -o 209735680 -r FKZV-...-H4PD -e EncryptedRoot.plist.wipekey image.raw
    clear
fvdemount 20160108

# ls -l clear
total 0
-r--r--r-- 1 root root 120137519104 Jan 20 22:23 fvde1
...

You can provide a user password (-p) instead of a recovery key (-r), and also using the EncryptedRoot.plist.wipekey file, you can access the resulting volume image with regular forensic tools. An example using Sleuthkit’s fsstat on the decrypted volume is shown here:

# fsstat clear/fvde1
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: HFS+
File System Version: HFS+

Volume Name: HDD
...

You can also mount this decrypted volume as a regular filesystem for browsing, as follows:

# mkdir files
# mount -o loop,ro clear/fvde1 files
# ls -l files
total 8212
drwxrwxr-x 1 root   80      50 Mar  2  2015 Applications/
drwxr-xr-x 1 root root      39 Jun  2  2015 bin/
drwxrwxr-t 1 root   80       2 Aug 25  2013 cores/
dr-xr-xr-x 1 root root       2 Aug 25  2013 dev/
...

When the analysis work is complete, you’ll need to do some cleanup:

# umount files
# rmdir files
# fusermount -u clear
# rmdir clear

Note that the preceding examples were done with root privileges to reduce complexity and make them easier to understand. Most of the commands can be done as non-root with a few exceptions. Examples in which a command is different when run by a nonprivileged user are shown here:

$ fvdemount -o 209735680 -r FKZV-...-H4PD -e EncryptedRoot.plist.wipekey image.raw
    -X allow_root clear
$ sudo mount -o loop,ro clear/fvde1 files
$ sudo ls files/Users/somebody/private/directory
$ sudo umount files

The -X allow_root string in the fvdemount command allows root to access the FUSE mounted directory. The sudo command is needed to mount and unmount the hfsplus filesystem. When you’re browsing the filesystem, you might also need the sudo command if filesystem permissions restrict access to files or directories.

Several other notable open source tools exist for operating on File-Vault images. The VFDecrypt tool also provides decryption of FileVault images. Originally written by Ralf-Philipp Weinmann, David Hulton, and Jacob Appelbaum, it is now maintained by Drake Allegrini. You’ll find it at https://github.com/andyvand/VFDecrypt/. It can decrypt an image into an unencrypted volume image.

FileVault Cracking software was created by some of the same authors as VFDecrypt; you’ll find it at http://openciphers.sourceforge.net/oc/vfcrack.php.

Linux LUKS

A number of file encryption systems are available in the open source world. Some, like eCryptfs or encfs, are directory based. Others, like GPG and various crypt tools, operate on individual files.

In this section, I mainly focus on the LUKS encryption system, but I’ll also touch on plain dm-crypt and loop-AES. Using the cryptsetup tool, you can set up all three. (You can also use the cryptsetup tool to manage True-Crypt volumes, which I’ll describe in the following section.)

The examples that follow operate on a forensically acquired image with a LUKS-encrypted filesystem. We’ll create a block device representing the decrypted content of an encrypted filesystem and show methods to safely mount the filesystem structure for browsing with regular tools. The three goals are to get information about the encryption, create a device that can be accessed with forensic tools, and safely mount the filesystem for regular browsing.

The first step requires the byte offset of the LUKS-encrypted partition. The sector offset is shown by Sleuth Kit’s mmls of the image file. The byte offset is the sector offset multiplied by the sector size, which is calculated to be 1048576 using simple Bash math expansion:

# mmls luks.raw
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000002047   0000002048   Unallocated
02:  00:00   0000002048   0058626287   0058624240   Linux (0x83)
# echo $((2048*512))
1048576

You can use the byte offset to create a loop device of the encrypted partition by employing losetup as follows:

# losetup --read-only --find --show -o 1048576 luks.raw
/dev/loop0

The LUKS-encrypted partition is now accessible as a block device, which the cryptsetup tool can use. You can find information about the encrypted partition using cryptsetup’s luksDump command:

# cryptsetup luksDump /dev/loop0
LUKS header information for /dev/loop0

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      8b 88 36 1e d1 a4 c9 04 0d 3f fd ba 0f be d8 4c 9b 96 fb 86
MK salt:        14 0f 0d fa 7b c3 a2 41 19 d4 6a e4 8a 16 fe 72
                88 78 a2 18 7b 0f 74 8e 26 6d 94 23 3d 11 2e aa
MK iterations:  172000
UUID:           10dae7db-f992-4ce4-89cb-61d126223f05

Key Slot 0: ENABLED
        Iterations:             680850
        Salt:                   8a 39 90 e1 f9 b6 59 e1 a6 73 30 ea 73 d6 98 5a
                                e1 d3 b6 94 a0 73 36 f7 00 68 a2 19 3f 09 62 b8
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

The key slots can be of interest from a forensics perspective. A LUKS volume can have up to eight keys, meaning there are potentially eight different passwords where you can attempt recovery.

With the password to the LUKS-encrypted filesystem, you can use cryptsetup’s open command on the loop0 device to create a mapper device. This device provides a decrypted representation of the encrypted image. The mapper device is named clear in this example:

# cryptsetup -v --readonly open /dev/loop0 clear
Enter passphrase for /hyb/luks/luks.raw:
Key slot 0 unlocked.
Command successful.

The encrypted loop device is opened with the --readonly flag. The verbose (-v) flag is also given to provide more information about the success of the decryption key. After a successful key has been entered, a new (decrypted) partition device will appear in the /dev/mapper directory and can be operated on using standard forensic tools. For example, you can run the Sleuth Kit fsstat tool:

# fsstat /dev/mapper/clear
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext4
Volume Name: My Secrets
Volume ID: ba673056efcc5785f046654c00943860
...

You can also mount this partition device on the local machine for regular browsing:

# mkdir clear
# mount --read-only /dev/mapper/clear clear
# ls clear
lost+found/  the plan.txt

Once the examination work is complete, the cleanup process can take place. Each step is done in reverse:

# umount clear
# rmdir clear
# cryptsetup close clear
# losetup --detach /dev/loop0

Note that this is a simplified example of a single partition on a single non-bootable data disk. A LUKS-encrypted disk with an bootable OS may have an additional Logical Volume Manager (LVM) layer. Such disks may have additional devices that appear in the /dev/mapper directory (root, swap, and so on). You can access or mount each of these devices individually. During the cleanup process, you need to remove the partition devices with dmsetup before closing the LVM device with cryptsetup.

For simplicity, the steps shown in this section were performed as a root user. To run the examples as a non-root user, losetup, cryptsetup, mount, and umount need sudo to execute, as do any tools that access the /dev/mapper partition device. Depending on the filesystem mounted, additional user options may be useful (uid=holmes for example).

Images encrypted with plain dm-crypt and loop-AES can also be decrypted using the cryptstetup tool. These follow a similar process as the preceding LUKS example. The cryptsetup open command needs to have either plain or loopaes specified using the --type flag. For example:

# cryptsetup -v --readonly open --type plain /dev/loop0 clear
Enter passphrase:
Command successful.

Using --type loopaes will also require a key file. Specifying --type luks is also possible, but unnecessary, because it’s the default.

You’ll find more information about cryptsetup and LUKS at https://gitlab.com/cryptsetup/cryptsetup/wikis/home/. And you’ll find a compatible Windows implementation at https://github.com/t-d-k/librecrypt/.

TrueCrypt and VeraCrypt

After development of TrueCrypt was stopped, several forks emerged. The dominating fork at the moment is VeraCrypt. It offers backward compatibility as well as new extensions.

The two examples of VeraCrypt I’ll provide are a normal encrypted container and a hidden container. I used the standard command line version of VeraCrypt in conjunction with familiar tools to make the containers available for further analysis.

The first example shows a simple encrypted TrueCrypt or VeraCrypt container file. The --file-system=none flag is important because it prevents VeraCrypt from mounting any filesystems:

$ veracrypt --mount-options=readonly --filesystem=none secrets.tc
Enter password for /exam/secrets.tc:
Enter PIM for /exam/secrets.tc:
Enter keyfile [none]:

Using the -l flag, you can list all the decrypted containers on the host system by slot number. The slot number is an important identifier to use in subsequent commands. In this example, the slot number is 1 and the familiar /dev/mapper/* directory is used:

$ veracrypt -l
1: /exam/secrets.tc /dev/mapper/veracrypt1 -

After providing the correct credentials, you can request more information about the container by specifying the slot number, as shown here:

$ veracrypt --volume-properties --slot=1
Slot: 1
Volume: /exam/secrets.tc
Virtual Device: /dev/mapper/veracrypt1
Mount Directory:
Size: 2.0 GB
Type: Normal
Read-Only: Yes
Hidden Volume Protected: No
Encryption Algorithm: AES
Primary Key Size: 256 bits
Secondary Key Size (XTS Mode): 256 bits
Block Size: 128 bits
Mode of Operation: XTS
PKCS-5 PRF: HMAC-SHA-512
Volume Format Version: 2
Embedded Backup Header: Yes

Two devices have been created. The device /dev/loop0 is encrypted as a raw image (the same as the file on the filesystem). The device shown in the volume properties, /dev/mapper/veracrypt1, is the decrypted volume, which you can operate on directly using forensic tools. Here is an example of Sleuth Kit examining the filesystem:

$ sudo fls /dev/mapper/veracrypt1
r/r * 4:        photo.jpg
r/r 6:  spy-photo.jpg
v/v 66969091:   $MBR
v/v 66969092:   $FAT1
v/v 66969093:   $FAT2
d/d 66969094:   $OrphanFiles

You can also mount the mapper device on the local machine and browse the filesystem with regular tools, like this:

$ mkdir clear
$ sudo mount -o ro,uid=holmes /dev/mapper/veracrypt1 clear
$ ls -l clear
total 360
-rwxr-x--- 1 holmes root 366592 Jan 21 23:41 spy-photo.jpg

Obviously, deleted files will not be visible in the user-mounted area; they will only be visible when you use forensic tools via the /dev/mapper/veracrypt1 device.

Again, the cleanup process is the reverse of the setup process:

$ sudo umount clear
$ rmdir clear
$ veracrypt -d --slot=1

The second VeraCrypt example I’ll provide shows how to access a hidden volume. One feature of TrueCrypt and VeraCrypt is that it’s possible to have two passwords that reveal two separate volumes. The use of both passwords is compared in the two command outputs below.

Here, hidden.raw is a VeraCrypt drive containing a hidden volume. Providing the first password produces a functioning standard TrueCrypt container with files, claiming the full 1GB capacity of the drive and showing Type: Normal:

$ ls -l
total 3098104
-rw-r----- 1 holmes holmes 1024966656 Jan 22 00:07 hidden.raw
...
$ veracrypt --mount-options=readonly --filesystem=none hidden.raw
Enter password for /exam/hidden.raw: [XXXXXXXXXXX]
...
$ veracrypt --volume-properties --slot=1
Slot: 1
Volume: /exam/hidden.raw
Virtual Device: /dev/mapper/veracrypt1
Mount Directory:
Size: 977 MB
Type: Normal
Read-Only: Yes
...
$ sudo fls /dev/mapper/veracrypt1
...
r/r 20: fake secrets.pdf
...

If the volume is dismounted and then mounted again using the hidden volume’s password, you’ll see a completely different set of files. The time needed to mount the volume is also different. With the container in the preceding example, 3.5 seconds was needed to unlock it, whereas unlocking the hidden container in the same file needed 29 seconds. This is because the standard volume decryption is attempted first (with all supported algorithms), and upon failing, the decryption of a hidden volume is finally tried. In the volume properties, the real size is now shown together with Type: Hidden, as shown here:

$ veracrypt -d --slot=1
$ veracrypt --mount-options=readonly --filesystem=none hidden.raw
Enter password for /exam/hidden.raw: [YYYYYYYYYYY]
...
$ veracrypt --volume-properties --slot=1
Slot: 1
Volume: /exam/hidden.raw
Virtual Device: /dev/mapper/veracrypt1
Mount Directory:
Size: 499 MB
Type: Hidden
Read-Only: Yes
...
$ sudo fls /dev/mapper/veracrypt1
...
r/r 19: the real hidden secrets.pdf
...

The mapped device of a hidden volume produces a filesystem that you can directly analyze with forensic tools.

TrueCrypt and VeraCrypt volumes can also be managed by newer versions of cryptsetup (version 1.6.7 and later), providing you with similar mounting possibilities.

There are commercial and open source cracking tools for TrueCrypt/VeraCrypt containers, but their use is beyond the scope of this book.

Closing Thoughts

In this chapter, you learned to make acquired image files available as block devices, create partition devices, and safely make them available for use with regular filesystem tools. You also learned to use loop devices and became more familiar with /dev/mapper devices. I showed tips for booting up suspect images and demonstrated methods for accessing VM images from various VM formats. Finally, you learned how to make a variety of encrypted filesystems available for access in decrypted form.