The Law Enforcement and Forensic Examiner’s Introduction to Linux: A Comprehensive Practitioner’s Guide to Linux as a Digital Forensics Platform

Digital fornesics (most notably acquisitions) and basic system administration will sometimes require root permissions. But simply logging in as root and conducting your analysis, particularly from an GUI session, is not advisable. We need to add a normal user account. From there you can use su to log in as root temporarily (covered in the next section).

Slackware comes with a convenient script, adduser, to handle the details of setting up our additional account. Some of the items set by this script include:

For the most part, the defaults are acceptable (even the default groups - be careful not to skip this part). You invoke the script with the command adduser (run as root, obviously) and the program will prompt you for the required information. When it asks for additional groups, be sure to use the up arrow on your keyboard to display available groups. Accepting the default groups is fine for our purposes.

Once complete, you can log out completely using the exit command and log back in as a normal user.

So, we’ve established that we need to run our system as a normal user. If Linux gives you an error message indicating a permissions problem, then in all likelihood you need to be root to execute the command or edit the file, etc. You don’t have to log out and then log back in as root to do this. Just use the su - command to give yourself root permissions (assuming you know root’s password). Enter the password when prompted. You now have root privileges (the system prompt will reflect this). When you are finished using your privileges, return to your original login by typing exit. We can use the whoami command to print our current user. Here is a sample su session:

Note that the - after su allows Linux to apply root’s environment (including root’s path) to your su login. So you don’t have to enter the full path of a command. Actually, su is a "switch user" command, and can allow you to become any user (if you know the password), not just root. Notice that after we type exit as root, our prompt indicates that we are back to our normal user.

It’s always useful to know exactly what hardware is on your system. There will be times when you might need to change or select different kernel drivers or modules to make a piece of hardware run correctly. Because there are so many different hardware configurations out there, specifically configuring drivers for your system will remain outside the scope of this guide. Kernel detection and configuration of devices (network interfaces, graphics controllers, sound, etc.) is automatic in most cases. If you have any issues, make note of your hardware (see below) and do some searching. Google is your friend, and there is a list of helpful starting places for assistance at the end of this guide.

There are a number of ways to determine what specific hardware you are running on your system. You can use lspci to get more detailed information on specific devices attached to your system. lspci (list PCI devices), is for those devices specifically attached to the PCI bus. If you have hardware issues and you search for something like "network card not detected in linux", and you follow a link to a support forum, you will almost always find the request to "post the output of lspci". It’s one of the first diagnostic steps for determining many hardware issues in Linux. This command’s output can get increasingly detailed (or "verbose") by adding the options -v, -vv, or -vvv. Note that you can run lspci from the installation disk prior to running the setup program. Note we are logged in as root to run lspci.

Sample summary output for lspci:

Reading through this output you can see the network interface in this system is an Intel Corporation Wireless 7260 chipset. This is useful information if you are having issues with getting the interface to work and you want to search for support. You are far more likely to get useful help if you search for "Linux Intel wireless 7260 not working" rather than "Linux network card not working".

This brings us to the subject of kernel modules.

As mentioned previously, the kernel provides the most basic interface between hardware and the system software and resource management. This includes drivers and other components that are actually small separate pieces of code that can either be compiled as modules (loaded or unloaded dynamically) or compiled directly in the kernel image.

There may come a time when you find that the kernel is loading a less than ideal module for a specific piece of hardware, perhaps causing it to either fail to work, or in some cases work at less than optimal performance. Wireless network cards can be a common example.

Looking back out our previous lspci output, for example, recall that our output showed an Intel Corporation Wireless 7260 chipset (last line of output above).

If I wanted to see exactly which kernel module is being used to drive this device, I can use the -k option to lspci (output abbreviated):

This time the output provides some additional information, including which modules are loaded when the device is detected. This can be an important piece of information if I’m trying to troubleshoot a misbehaving device. Online help might suggest using a different driver altogether. If that is the case, then you may need to "blacklist" the currently loaded module in order to prevent it from loading and hindering the correct driver (that you may need to specify). Blacklisting a kernel driver is normally done in /etc/modprobe.d/ by creating a <modulename>.conf file with a blacklist entry, depending on your distribution. Files placed in /etc/modprobe.d/ will be given precedence over identically named files in /lib/modprobe.d/. According to /etc/modprobe.d/README:

As indicated in the README file’s output above, in Slackware you can read the man page for modprobe.d for more information. Since the steps for this vary wildly depending on the driver, it’s dependencies, and the existence of competing modules, we won’t cover this in any more depth. Specific help for individual driver issues can be found online.

Note that if you are using a laptop or desktop with a USB wireless adapter, it likely won’t show up in lspci. For that you’ll have to use lsusb (list USB - there’s a pattern here, see?). In the following output, lsusb reveals info about a wireless network adapter. Use the -v option for more verbose output (bold for emphasis):

Or use the script usb-devices, which organizes the information from
/sys/bus/usb/devices/usb into a (mortal) human readable format. Note that it also returns the kernel module in use, much like lspci -k does for PCI bus devices (bold for emphasis). We use the pipe ( |) to the less command to page the output for reading (more on this later):

Note that the commands covered here are largely portable across distributions, but the locations of files and methods for managing modules may differ. The process of identifying modules and hardware should mostly be the same. Manual pages (read using the man command) and distribution documentation should always be relied on for primary problem solving.

Keep in mind that these same commands can be run against a subject computer by using Linux based forensic boot media. If you have the time, it’s a great way to inventory a subject computer either prior to seizure or if you cannot seize the computer (only image it for whatever reason), but still wish to have a full hardware inventory.^[1]

In modern distributions, Linux device management has been handed over to eudev (or udev under Systemd)^[2]. In the past, the device nodes (files representing the devices, located in the /dev directory) were static, that is they existed at all times, whether in use or not.

So why do we cover device hot-plugging in a forensic guide? A basic knowledge of device access is critical to understanding how devices (external disks, subject hard drives, etc.) are detected and presented to the examiner.

Udev creates device nodes "on the fly". The nodes are created as the kernel detects the device and the /dev directory is populated in real time. In addition to being more efficient, udev also runs in user space. One of the benefits of udev is that it provides for "persistent naming". In other words, you can write a set of rules that will allow udev to recognize a device based on individual characteristics (serial number, manufacturer, model, etc.). The rule can be written to create a user-defined link in the /dev directory, so that for example, my thumb drive can always be accessed through an arbitrary device node name of my choice, like /dev/my-thumb, if I so choose. This means that I don’t have to search through USB device nodes to find the correct device name if I have more than one external storage device connected. Writing such rules is outside the scope of this document. We will used udisks to accomplish persistent naming with properly labeled volumes.

On Slackware, [e]udev runs as a daemon from the startup script /etc/rc.d/rc.udev. We will discuss these startup scripts in more detail later in this document. We will not do any specific configuration for udev on our forensic computers at this time. We discuss it here simply because it plays a major part in device handling and as such is of interest to forensic examiners that want to know what their system is doing. udev does NOT involve itself in auto mounting or otherwise interacting with applications. It simply provides a hardware to kernel interface. Disks and other storage media are handled by udisks or udisks2. We will cover this in more detail later.

The mount command uses the following syntax:

mount -t <filesystem> -o <options> <device> <mountpoint>

One of the options we pass to the mount command, using -t, is the file system type ^[3]. But what if you don’t know what file system is on a device you’ve been handed? First, we need to to know the partition layout of the device. Is there one partition? Two? Once we’ve selected the partition we want to work with, we need to know what file system might be on there. We can accomplish this using a series of commands we covered earlier. We use the lsblk command to view our devices that have been detected, and show the partitions that we might try to mount. Then we use the file command with the -s option to determine the file system type we will be mounting. For example, if I insert a thumb drive into my system and I want to manually mount it, I can use the following commands to gather the information I need:

The pertinent output is highlighted in red. lsblk shows us that the drive was detected as /dev/sdb with a single partition at /dev/sdb1. The file command reads the signature of the partition and determines it is an EXT4 file system. We will discuss the file command extensively later in this guide. For now, just understand that it determines the type of file by its signature (regardless of extension or name), in this case a file system signature.

We can then use that information to mount the drive (this command assumes the directory /mnt/analysis exists – if not then create it with mkdir):

Now change directory to the location of the newly mounted file system:

You should now be able to navigate the thumb drive as usual. Essentially, what we have done here is take the logical contents of the file system on /dev/sdb1 and made it available to the user through /mnt/analysis. You can now browse the contents of the disk.

When you are finished, leave the /mnt/analysis directory (if you do the cd command by itself, you will return to your home directory), and unmount the file system with:

Some points to keep in mind:

Another example: Reading an optical disk

If you want to see a list of file systems currently mounted, just use the findmnt --real command. It will list the mount point and file system type of each device on system, along with the mount options used. In the below output, TARGET is the mountpoint, and SOURCE is the volume that is mounted:

The ability to mount and unmount file systems is an important skill in Linux. We use it to view the contents of a physical volume, and we use it to mount external storage for collecting evidence files, etc. There are many options that can be used with mount (some we will cover later), and a number of ways the mounting can be done easily and automatically. Refer to the info or man pages for the mount command for additional information.

In most modern distributions, optical disks will be auto-detected, and an icon placed on the desktop for it. Of course this will depend on your particular setup, but this is generally the case whether you are using XFCE, KDE, or some other combination of GUI and window manager. We’ll cover more on GUI disk handling in an upcoming section.

The /etc/fstab file is used to mount default file systems when the computer starts. It provides a list of volumes, their respecitve mount points and file system types along with the options used to mount the file system. This file can be added to or adjusted as internal storage is added to the computer to allow for either automatic mounting at boot, or simplified mounting on the fly.

An example /etc/fstab may look like this:

The columns are:

<device> <mount point> <file system type> <default options>

Notice a line for /dev/sdb1 has been added, showing the file system type as ext4, and a mount point at /mnt/data. With this in the /etc/fstab, that file system will be mounted automatically at boot. In most cases this would be done for extra storage added internally or permanently attached.

Mounting can also take place via automated or partially automated processes through your desktop environment. Linux has a huge list of available choices in desktop systems and management (XFCE, KDE, Gnome, Mate, etc.). They all have the capability to handle and mount removable devices for the user. This is normally done through the dynamic addition of context capable desktop icons that may appear when removable media is plugged in. Volumes can then be mounted via a right-click menu.

There are a number of useful changes for the general Linux user that make this sort of desktop capable mounting sensible. First, for general daily use as a desktop workstation, who wants to have to log in as root to mount external devices? What if you are working on a system that you don’t have elevated privileges on? In addition to the personal logistics, there’s also the fact that more modern systems will place removable device mount points in a user’s personal space rather than a system wide mount point. This offers better security and accessibility for the user.

The following example will show what can happen on an XFCE desktop when a USB drive is inserted. This is just an illustration. Be sure to check your own system for default configurations that might differ from this. You certainly don’t want to accidentally mount evidence just because you were unaware the system is doing it for you automagically.

In this case the USB disk has a partition with a volume label Corsair_32G (the volume label can be set by any number of tools when the file system is formatted).

With the USB drive inserted, an icon appears on the desktop (at the bottom of the figure).

Back in the earlier section on disks and device nodes, we talked about device detection and naming. In addition to the /dev/sdx naming, there are other names assigned to the disk by UUID, label, and kernel path. When I see the Corsair_32G label appear on the desk top, a terminal can quickly be opened to see exactly what partition on which disk that label belongs to by accessing the /dev/disk/ sub-folders, specifically /dev/disk/by-label:

Using ls -l we see that the file /dev/disk/by-label/Corsair_32G is a symlink, or shortcut to /dev/sdb1.

If we right click on the icon and select Mount Volume from the menu, the volume is mounted on /run/media/$USER]/$LABEL. In this case the user is barry and the label is Corsair_32G.

Once mounted, we can see the results from the terminal using the findmnt --real command:

Make sure you know how to control the mounting of disks and volumes within your desktop environment. XFCE shipped with Slackware does no auto-mounting of any volumes by default. The icons appear on the desktop, but you are free to mount them as you see fit. There are configuration options available to change this behavior, so be careful. Make sure you test what happens when you "hot plug" USB media or other removable storage. For example, some distributions might elect to auto-mount devices on the GUI desktop immediately upon insertion. This is undesirable for digital forensics.

XFCE is a lighter weight (meaning lighter on resources) desktop. And while XFCE is capable of automatically handling hot plugged devices, it also allows for easy control. Consider the following snapshot of an XFCE settings dialog for removable media. By default, on Slackware, devices are NOT auto mounted in the XFCE environment. Not all distributions might be configured this way, however. Be sure to check and test for yourself. As a forensic examiner, you do NOT want your system automatically mounting devices simply because you plugged them into the system. We will cover this in a bit more detail later.

You might notice that we need to be logged in as root to use the mount command to manually mount a volume to /mnt (or any other directory we create). The same applies when we try to mount a volume manually that is not defined in /etc/fstab. On the other hand, when we insert media and use the desktop icon to mount the device, we can be logged in as a normal user and simply right click on the device icon to have it mount to /run/media/XXX. So how is that happening?

Userspace mounting on most Linux systems is handled by the udisks package. There are two versions of this: udisks and udisks2 (the newer version). For the sake of simplification, we’ll say that if your system is using udisks (version 1), it will normally mount to /media. If your system is using udisks2, it will normally mount to /run/media/$USER. As we’ve seen, this userspace mounting can be done via the desktop using the mouse.

What happens if you are at a terminal without a GUI, or if you are using a desktop/window manager that does not allow for dynamic volume icons? You can still use the userspace capabilities of udisks on the command line. The following command session shows the use of the udisks2 command line utility udisksctl by a normal user to mount a volume. Note that udisksctl mounts to /run/media/$USER.

The above session shows the output of lsblk to identify the volume we want to mount. The udisksctl command with the mount and -b /dev/sdb1 options is then run and the resulting successful mount is displayed. (-b specifies the ’block’ device to mount). We then use lsblk again, this time showing the volume /dev/sdb1 and it’s mount point in /run/media. Notice that we are only providing a volume to mount, we do not provide a mount point. udisks will use the volume label (in this case it’s SANDISK) to create a dynamic mount point under /run/media/$USER. If there is no volume name, then it uses the volume UUID.

We unmount the volume using udisksctl as well (and then re-check with lsblk just for good measure):

In this section we’ve covered enough about dealing with disks to get you started on accessing storage media and volumes. Next, we’ll delve into actually being able to manipulate and view some data with an introduction to basic commands.

Command options can be combined, so that if we use ls -lhaR we’ll get a detailed listing of files, with sizes in ’human readable’ format, including hidden (or ’dot’ files), recursively.

A simple ls -lah will give us the following:

We will discuss the columns in the ls output in more detail later on, though some like - file size and file name - are obvious.

If you want to find information about a command and its various options, you use the man(ual) page. For example, the find command can be daunting. But I can gather lots of helpful information with man find:

There are other useful commands for displaying text that you might want to explore as you learn more. Examples are utilities like bat, an improved cat; and view, a read-only instance of the vim text editor.

grep : Searches for patterns.

grep <pattern> <filename>

The grep command will look for occurrences of <pattern> within the file <filename>. grep is an extremely powerful tool. It has many uses given the number of options it supports. Check the man page for more details. We will use grep in our forensic exercises later on.

find : Searches for files based on any number of criteria. These can include dates, sizes, name patterns, object type, etc.

find <start dir> <criteria>

A simple search for a file named fstab could look something like this:

This means "find, starting at the /etc directory" by name, fstab. find will allow you to search by file type (regular files vs. directories, etc.), or even various file times. We’ll use this tool extensively later on. Check man find and see if you can find the difference between the -name, and -iname options.

pwd : Prints the present working directory to the screen. The following example shows that we are currently in the directory /home/barry:

file : Categorizes files based on what they contain using signature comparison. The categorization occurs regardless of name or extension. The file header is compared to a magic file to determine the file type. Here’s an example using a standard JPEG image:

ps : List current processes. This is a little like the task manager in Windows. It gives the process ID number (PID) and the terminal on which the process is running. ps ax will show all processes (a), including processes without an associated terminal (x). Note the lack of a dash in front of the options. Read the man page for more details. The below output shows the parent of all processes init and 3 virtual terminals running the bash shell (some output removed).

strings : Prints out the readable characters from a file. This command will print out strings that are at least four characters long (by default) from a file. Useful for looking at data files without the originating program, and searching executables for useful strings, etc. More on this forensically useful command later.

chmod : Changes the permissions on a file ("change mode"). We’ll cover this command and its use later on.

chown : Changes the owner (and group) of a file much the same way chomd changes permissions.

clear : Clears the terminal.

exit : Exits the terminal and closes it.

shutdown : This command will be used to cleanly exit the system and power down (or restart) the computer. You can run several different options here (and be sure to check the man page for additional details).

shutddown -r now - will reboot the system now.

shutddown -h now - will shut down the system now.

If we need to do some calculations on the command line, we can use bc and either open an interactive session, or pipe the expression to be evaluated via the echo command through bc. You’ll need these techniques to calculate byte offsets in later exercises. You don’t want to have to open a calculator app, do you?

For an interactive session, simply type bc at the prompt and you will be dropped into the session. Type the expression and hit <enter>. For clarity, our input is in bold.

Type quit to finish, and you’ll exit the session. Pay close attention to the last expression we entered, 5/3. Note that the response is 1, a whole number, rather than the fraction we would assume. This is because bc is a fixed precision calculator, and the default scale is 0 (zero decimal places). You can set the scale with the scale=x function, where x is the precision you’d like. If you want your answer rounded to two decimal places, you can use scale=2.

Here we see our expected result.

If you’d prefer not to use an interactive session, you can pipe your expression to bc using echo:

The above example shows both the default output and scale setting via echo. The last command shows a common calculation for byte offset when given a sector number (or sector offset) in forensic work. We will use this frequently in later chapters.

Finally, we can use bc to convert hexadecimal values to decimal values by using the option ibase=16, either interactively or via echo. Note that alpha characters in the hex expression MUST be upper case for bc to work. Here are a couple of examples (again our interactive input is in bold):

If you are dealing with simple integers (or hex conversion), and floating point or decimal responses are not required, you can use more simple bash (shell) arithmetic expansion. This is probably the quickest and easiest way to do calculations for simple addition, subtraction and multiplication where integer volume offsets are needed and you are not likely to encounter fractional evaluations. Note that you need to use the echo command to evaluate the expression, or the evaluation itself will be interpreted by the shell as a command. Hexadecimal values should be preceded by 0x (zero x) Here’s an example set of evaluations:

One of the more useful concepts with this shell expansion method of arithmetic is that it can be used directly in a command. We will use this later on during our dive into forensics. For additional information, see man bash.

In simple terms, an interactive login shell is generally one in which you authenticate your user, and then interact with the shell. An example of this is when you log into the system at runlevel 3, or when you open an ssh session on a remote computer. There are actually quite a few files that can be used to customize a Linux user’s shell experience. Here are some that will get you started.

Read man bash for more detailed info.

The bash startup sequence is actually more complicated than this, but this should give you a starting point. The man page for bash is an interesting (and long) read, and will describe some of the customization options. In addition, reading the man page will give a good introduction to the programming power provided by bash scripting. When you read the man page, you will want to concentrate on the INVOCATION section for how the shell is used and basic programming syntax.

On some systems you may notice that opening a terminal window for the first time shows a very generic command prompt. On Slackware, for example, opening a terminal from the XFCE desktop for the first time will give a prompt that looks like this:

This is because terminals opened from an X desktop are generally non login shells. As a result, the options in /etc/profile are not applied. There are two general ways to remedy this (many distributions do this for you):

You only need to do one of the above to get a consistent shell experience. Adding the appropriate bash configuration files is generally the preferred method, since you will likely want to create these files for additional customization later anyway.

For the first method, it’s simply a matter of entering the terminal program’s preferences (Edit --> Preferences --> General in the XFCE terminal), and checking the appropriate box for Run command as login shell:

Without any other changes, this will result in a login shell that reads /etc/profile and (if it exists) .bash_profile. Close and re-open the terminal window. Now your prompt looks like this:

The second method is preferable because it will result in consistent configuration regardless of the invocation of login or non-login shells. In this case, we will simply create both the .bash_profile and .bashrc files and ensure that each is sourced regardless of the shell type.

Create the two files with the following contents:

Contents of .bashrc:

This makes sure that /etc/profile is always read for non-login shells (and that file should always exist, so there’s no test needed). Now your non-login shell will appear the same as a login shell.

Contents of .bash_profile:

This tests to see if .bashrc exists, and if it does, then read the contents (referred to as "sourcing".)

With these two files in place, you can add any additional customizations to your .bashrc, and be assured that they will apply to all login and non-login shells.

ethX

If you are using either a desktop or laptop computer with a physical network cable plugged into a port on you computer, you will most likely be using an Ethernet adaptor. If you are using a virtual machine, then you are also most likely going to see an Ethernet adapter for your main network connection in the VM, even if your host machine uses wireless networking. These are normally named eth0 for the first physical connection, eth1 for the second, etc.

wlanX

Wireless adapters can include built in wireless network interfaces or external USB ’dongles’. If you are using a wireless network, then most likely you will be using an interface called wlan0. Again, if you are using a VM, you will most likely not see a wireless adapter in the VM even if your host computer uses wireless - virtual machines normally bridge (or use network address translation) from the host computer’s network to a virtual Ethernet adapter on the guest operating system.

lo

The loopback interface (lo) is a special interface that points to the host machine itself, with an IP address of 127.0.0.1. Commonly referred to as "home" or "localhost", the loopback device is most often used for network troubleshooting and to connect to services locally (the CUPS printing system, for example).

Some distributions using the newer systemd daemon might have different naming conventions. If your network interfaces have names like enp1s0 (for Ethernet) or wlp2s0 (for wireless), then you have a Linux distribution that uses the newer "persistent" naming conventions for network devices. This has been introduced for a number of reasons, including maintaining persistent interface names between reboots. More information on this system of naming can be found in Network device naming schemes (SystemD).

If you are using Slackware the installation routine would have run the netconfig program for you. It would have looked something like this:

Here is where we select how our computer will connect to available networks.

Selecting a static IP will result in your computer having the same ’fixed’ IP address on a network. You’ll need to know a network compatible IP address to fill in, a default gateway (for traffic to pass outside the local network), a netmask (to identify the subnet you are on), and a nameserver (to interact with DNS services).

The two other choices we’ll cover here are far more likely to be used, and easier to configure. You can always re-run netconfig as root after installation to change your connection method.

DHCP (Dynamic Host Control Protocol) utilizes a server to assign network settings automatically. If you are running an Ethernet (hardwired) network with a DHCP server or router (most commercial ISP routers come so equipped) you will find DHCP the easiest path to take if you are not worried about changing connections.

Let’s have a look at where these configuration choices (static, DHCP, or Network Manager) are stored, and how they differ. If you select either a static IP address or DHCP configuration, your settings will be saved to the file /etc/rc.d/rc.inet1.conf. Note that this particular configuration file is well commented. Read the top of the file for more details on how these settings are interpreted. The following examples show the (truncated) contents of that file if you are setting up an Ethernet interface.

For a static IP address, where you fill in the values for IP address, gateway, and broadcast address yourself in the netconfig utility, the settings for eth0 under /etc/rc.d/rc.inet1.conf would look like this (abbreviated output):

For a dynamic IP address (using DHCP), the same entry would look like the following. All the entries are blank except USE_DHCP, which is set to yes. The other values are blank because the DHCP server takes care of the assigned values. There is no need to enter them in the configuration:

The last choice in the list of network configuration options is to use NetworkManager. NetworkManager is a program that will find and connect you to known networks. It works for both wired (Ethernet) connections and for wireless networks. While using DHCP for an Ethernet connection is trivial and easy to setup, wireless networks can be somewhat more complex. Tools like wpa_supplicant allow you to locate and configure nearby wireless networks. Using NetworkManager, however, is much easier and allows for quick switching of networks when moving from place to place and connecting to different hotspots.

But wait…​We are talking about forensic workstations here. Why would we be concerned about "connecting to different hotspots"? The short answer is that the nature of computer forensics and incident response has changed in the past few years. It’s not uncommon now to take mobile workstations (powerful laptops, for example) to search scenes or to incident response locations. There may be a need to connect to a network to download tools or conduct wireless reconnaissance in support of an investigation.

Once selected, NetworkManager will do the work of connecting and managing your interfaces for you. When using it in a GUI, you will usually find an icon in the system tray or menu bar that allows you to access available networks. This is what the network configurate file will look like when NetworkManager is selected. Note all the fields are blank. The NetworkManager daemon takes care of the configuration "on the fly".

Here are a couple of examples of what you might see - one on a computer running an XFCE desktop with an Ethernet connection, and the second on a different desktop GUI connected to a WiFi network:

When selected to configure your network, NetworkManager is started via an rc script as discussed in the chapter section on system startup scripts. Since the NetworkManager rc script has executable permissions set (octal 755), it is started when the system is booted.

One of the most basic pieces of information available to you is your own IP address. There are several ways to find out what IP address is assigned to your computer. Both the ifconfig and the ip command will give you that information. But what’s the difference? First, let’s have a look at how to use each to find your IP address, then we’ll discuss why we have two commands that appear to do the same thing.

ifconfig has been around for a very long time. It can be used to view network interface configurations, and can also be used to actually configure connections - bring an interface up, or take it down; and assign IP addresses, default gateways, and broadcast addresses. In it’s simplest form, we call the command to view our network configuration, using it with the -a option to show all interfaces:

Notice that ifconfig can be run as a normal user (for viewing interface information). You just need to provide the full path to the command, since the executable resides in the /sbin directory (for "system" binaries), but /sbin is not normally in a user’s PATH.

The line in the output above containing the network information is highlighted in red, including the interface IP address ("inet"). Also, highlighted in blue, is the interface’s MAC address ^[5]. In this particular output we have a single Ethernet interface (eth0) with an IP address (10.0.2.15). And the loopback interface (lo) with the expected IP address of 127.0.0.1.

We can obtain very similar information with the ip command. Using ip with the addr option (or even just a), we can get the details on our running network interfaces:

Again notice the line with the IP address highlighted in red and the MAC address highlighted in blue. Similar output, different tool. So what’s the difference?

Put simply, the ip command is a newer and more versatile tool. It belongs to the iproute2
package and largely supersedes the ifconfig command (from the net-tools package). The ip command extends the functionality of ifconfig, uses different system calls, and actually simplifies network management. So which should you use? ifconfig or ip?

Normally I default to using the most "UNIX" like command we can find. ifconfig has been a standard command on so many UNIX platforms over the years. I always suggest learning standard tools over other network utilities because you can usually find them on any UNIX system you might come across. Much like vi, you learn it because you will always find it available. This is not really the case with network programs anymore. Even Solaris is moving away from ifconfig to newer network utility implementations. So my suggestion is you learn both ifconfig and ip and understand how to use each…​you will likely find one or both on any give *nix system.

Having said all that, one other "nice to know" utility is nmcli. If you are using NetworkManager to manage your network connections and configurations, nmcli provides a nice view of your configuration on its own. Here’s an example of nmcli output for a workstation connected to a wireless network called Hivehom:

So this gives us a pretty good idea of how we can find out where we sit on a network using three different tools: ifconfig, ip, and nmcli. We’ll move on now to painting a picture of what we present to the network.

We’ll start our security configuration with the most basic steps…​disabling services (and/or daemons) that start when the computer boots. It’s fairly common knowledge that running programs and network services that you are not using and do not need serves only to introduce potential vulnerabilities. There are all sorts of services running on any given workstation, regardless of distribution or operating system. Some of these services are required, some are optional, and some are downright undesirable for a forensic environment. As previously discussed, this is where you will find quite a difference among the various distributions. Consult your distribution’s documentation for more info, and don’t neglect this part of your Linux education!

Previously, we discussed the system initialization process. Part of that process is the execution of rc scripts that handle system services. Recall that the file /etc/inittab invokes the appropriate run level scripts in the /etc/rc.d/ directory. In turn, these scripts test various service scripts, also in the /etc/rc.d/ directory, for executable permissions. If the script is executable, it is invoked and the service is started. This can be chained, where rc.M checks to see if an rc script is executable, and if so the execution of that script checks for more scripts that are executable. For example, the test inside the rc.M (multiuser init script) that will run the network daemons initialization script (rc.inet2) looks like this (abbreviated):

The code shown above is an if / then statement where the brackets signify the test and the -x checks for executable permissions. So it would read:

if the file /etc/rc.d/rc.inet2 is executable, then execute the script `/etc/rc.d/rc.inet2`

Once rc.inet2 is running, it checks the executable permissions on the network service scripts (among other things). This allows us to control the execution of scripts simply by changing the permissions. If an rc script is executable, it will run. If it is not executable then it is passed over. As an example, let’s have a look at the OpenSSH (secure shell) portion of rc.inet2:

Again, this portion of rc.inet2 checks to see if rc.sshd is executable. If it is, then it runs the command /etc/rc.d/rc.sshd start. The rc service scripts can have either start, stop or restart passed as arguments in most cases. So, in summary for this particular example:

Earlier on we discussed file permissions. Now let us look at a practical example of changing permissions for the purpose of stopping select services from starting at boot time. A look at the permissions of /etc/rc.d/rc.sshd shows that it is executable, and so will start when rc.inet2 runs:

To change the executable permissions to prevent the SSH service to start at boot time, I execute the following:

The directory listing shows that I have changed the executable status of the script, and therefore prevented the service from starting when the system boots. Depending on your color terminal settings, you may also see the color of the file name change in a listing.

You can use this technique to go through your /etc/rc.d directory to turn off those services that you do not need. Since I’m not running an old laptop, and don’t need PCMCIA services nor do I have wireless network support on my workstation (particularly in most cases for a VM), I’ll make sure these do not have executable permissions:

If you want to know what each script does, or if you are unsure of the purpose of a service started by a particular rc script, just open the script with your paging program (less, for instance) and read the comments (lines starting with a #). Turning off a service you need is just as bad as leaving an unneeded service running. Learn what service each script starts, and why, and enable or disable accordingly.

For example, here’s the comments at the beginning of /etc/rc.d/rc.yp:

As mentioned earlier, Leave the sshd service running (via permissions on the /etc/rc.d/rc.sshd script). Even if you do not think you will use SSH, as you become more proficient with Linux, you will find that SSH, the “secure shell”, becomes an important part of your toolbox.

It is common practice for many forensic practitioners to utilize some sort of host based firewall program to monitor their workstation’s network connections and provide some form of baseline protection from unsolicited access. You may want to do the same thing on your Linux workstation, or you may, in some cases, be required to run a host based firewall by agency or corporate policy. In any event, the most commonly used Linux equivalent for this sort of thing in the past has been the iptables network packet filter.

There are newer (relatively) network packet filters. Over the past few years nftables, managed using nft, has become more popular and is included in the mainstream Linux kernel. It is included by default in Slackware and most other distributions and more information can be found on the Internet. Here we will illustrate how to use the newer nftables while providing some comparisons between the older iptables and newer nftables implementations.

Of all the subjects covered in this document, this is one of the more complex, with little direct relationship to actual forensic practice. It is, however, too important not to cover if we are going to discuss Linux as a forensic platform and the subject of workstation security. A host based firewall may not be a requirement for a good forensic workstation, especially given that many agencies and companies are already working in a well protected (or air gapped) network environment. However, in my humble opinion, knowing the basics and minimal implementation of o host firewall is still a very good idea. It’s all too common to see novice Linux users rely completely on the notion that Linux is "just more secure" than other operating systems. And I know from personal experience that there are digital forensic practitioners out there that have workstations connected directly to the Internet and don’t take these precautions.

Unlike most of the other subjects covered in this configuration section, nftables requires a bit more explanation to effectively set it up from scratch than I’m willing to put in a simple practitioner’s guide. As a result, rather than giving a detailed description and step by step instructions, we are going to briefly discuss how to view the nftables configuration and provide a baseline script to get the reader started. Our “baseline” script is adapted from the same general layout as the iptables example used in earlier editions of this guide.

Earlier applications used for host based protections included security tools like TCP Wrappers. This program acted like a network bouncer, checking lists of allowed and denied hosts to determine what connections could be made to specific network services. TCP Wrappers would block access at the application level, whereas packet filters like nftables and the older iptables block network traffic at the specified physical network interface. This is an important distinction. Packet filters essentially sit between the network and the applications and accepts or rejects network packets at the kernel level.

Where iptables deals with a fixed set of built-in chains that always exist to control network packets (INPUT, OUTPUT, FORWARD), the newer nftables takes a different approach. Tables and chains in nftables don’t exist until you define them, and each chain is explicitly attached to a network-stack “hook” (such as input, output or forward) along with a priority. This means a completely fresh nftables configuration has no rules and no chains at all, rather than a set of empty, default-ACCEPT chains. Each chain also lives inside a table, and tables are typed by network family (ip, ip6, or inet for both at once), which lets us write a single rule set that covers both IPv4 and IPv6 traffic instead of maintaining separate iptables and ip6tables configurations.

Let’s have a look at our default nftables configuration (in this case “default” means “empty configuration”). To do this we can use nft with the list ruleset command to display every table, chain and rule currently loaded:

This nftables command produces no output at all. With no tables or chains defined, nftables has nothing to show us and, more importantly, nothing to filter. None of our network traffic is being touched.

Let’s start our configuration of nftables with a simple example. It is often desirable to hide our systems from all network traffic, including ping traffic. With our empty nftables configuration, from an external host (in this case a host named hyperion), we can ping our forensic workstation, (192.168.86.83) and the ICMP packets come though:

Have a look at the following script, created with vi (I’m told this is a good exercise in vi editing), which we’ll
save as /etc/rc.d/rc.firewall. It’s important that you get the name right as this is another script that is called from
/etc/rc.d/rc.inet2, as we discussed earlier. Once the script is created and saved, let’s have a look at it.

The file, shown above, starts with variable definitions, followed by a number of lines that set various kernel parameters for better security – these are unchanged from the iptables version in previous interations of this guide, since they’re a kernel level setting and have nothing to do with which packet filter we’re using. We then define a single inet table named filter, containing our input, output and forward chains. Each chain’s policy drop; sets the default policy for that chain to the far more secure DROP, rather than simply ACCEPT. Also note that we have a rule accepting new TCP connections (ct state new) on destination port 22 (tcp dport 22) in the input chain. This will allow SSH traffic in.

With the file saved to /etc/rc.d/rc.firewall we start it by making the file executable. The firewall script, if it exists and has executable permissions, will be called from /etc/rc.d/rc.inet2. Check the permissions on the file, change them to executable (using chmod) and check again. We can load the rules by simply calling the script explicitly:

The last command in the session illustrated above shows that we have executed the firewall script.

Now when we look at our nftables configuration, we see the rules in place:

Here we see each chain’s policy is now set to drop, and we have several rules in each chain.

Since our default policy is to drop all incoming traffic, and there is no explicit rule to allow incoming ICMP traffic, we can no longer ping our forensic workstation from an external host. Here we are trying to ping the forensic workstation (at IP 192.168.86.83) from a host called hyperion.

We can, however, connect with SSH since we have a rule that accepts new TCP connections on destination port 22 (Assuming the SSH server is running on the default port).

If you need to allow other traffic, there are many tutorials and examples on the Internet to work from. This is a very simple and generic host based network packet filter. And as with the other subjects in this guide, it is meant to provide a primer for additional learning.

Slackware provides a set of utilities for manipulating packages in pkgtools. These are pkgtool (menu driven), installpkg, removepkg and upgradepkg. These are discussed in detail here: https://www.slackbook.org/html/package-management-package-utilities.html.

We are going to focus on Slackware’s automated tool for package management: slackpkg. It’s extremely easy to configure and use. The man page provides very clear instructions on using slackpkg along with a good description of some of it’s capabilities.

We start by picking a single “mirror” (Slackware repository) listed in the slackpkg configuration file. Log in as root and open /etc/slackpkg/mirrors with vi (or your editor of choice). Un-comment a single line and you’re ready to go (delete the # sign from the front of an address). The line you un-comment needs to be for the specific architecture (32 bit vs 64 bit, etc.) and version of Slackware you are running. ^[8], and should be near your geographic region (US, UK, Poland, etc.).

Take note that there are two versions of Slackware64 available in the mirrors file. There are Slackware64-15.0, and Slackware64-current. Slackware64-15.0 is the stable version of Slackware with only minimal updates for security and bug fixes. Slackware64-current is the development version and is more of a "rolling release" that is continuously updated until it reaches a milestone where it becomes the next "stable" release. Make sure you pick a correct mirror for the version of Slackware you are running. As of this writing, our version of Slackware for the purpose of this guide and selecting an update mirror is Slackware64-current. ^[9]

The below example shows an edited /etc/slackpkg/mirrors file where a single mirror has been un-commented (bold for emphasis - note the # has been removed). The mirror we are selecting is for Slackware64-current. Select a mirror appropriate for your location. Or, as in the example below, you can select the mirrors.slackware.com address for your mirror and have it find a nearby mirror.

One precaution you may want to take with slackpkg is to add several packages to the blacklist. The blacklist specifies those programs and packages that we do not want upgraded on a regular basis. We do this to avoid having to complicate periodic security updates with changes to our bootloader and other components that add excessive complexity to our upgrade process (and potential changes to our forensic environmemnt). In particular, we want to avoid (for now) having to go through all the steps required to upgrade our kernel packages on a regular basis.

The blacklist file is located at /etc/slackpkg/blacklist and there are several lines regarding kernel upgrades that are included but commented out. Un-comment those lines by removing the leading # symbol, and add the additional lines as shown so the file looks like this (in part):

When a critical update to one of the kernel packages is required, the lines in the blacklist can always be temporarily commented out and the packages updated as usual. If you leave the lines commented out, you will get periodic kernel updates. Just remember that an updated kernel will require you to update your boot loader as well. You will be prompted for this when it occurs.

We’ve selected our mirror and adjusted our blacklisted packages, now it is simply a matter of updating our package manifest…​we do this with the simple command slackpkg update, which will download the updated file list (including patches). Once that is complete, you run slackpkg install-new and you will be presented with a selection of packages recently added to the operating system. These can be new libraries or programs that have been added to the repository since your initial installation. This is followed by slackpkg upgrade-all and, again, you will be presented with a selection of packages to upgrade (minus the blacklisted packages).

The man page for slackpkg provides easy to follow instructions. In a nutshell, for our purposes here, usage is simply:

I would strongly suggest you take a minute to read the change log for the version of Slackware (or whatever distribution) you are using. Understanding what you are updating and why is an important part of understanding your forensic platform. It may seem tedious at first, but it should be part of your common system maintenance tasks. You can read the file ChangeLog.txt at the mirror you selected for updating your system, or simply go to: https://mirror.SlackBuilds.org/slackware/slackware64-current/ChangeLog.txt when updates are available. Once you update your package manifest, you can also view the complete change log with slackpkg show-changelog.

Using the slackpkg method above is the easiest way to keep your OS up to date with the latest stable security fixes and patches. Periodically, you can run slackpkg update and slackpkg upgrade-all to keep your system up to date. The first two steps only need to be done once on your system.

Once again, if you are not using Slackware, be sure to check your distribution’s documentation to determine how best to keep your workstation properly patched. But please continue to bear in mind that “latest and greatest” does not translate to “properly patched”. An important distinction.

Compiling from source is the most basic method for installing software on Linux. It is generally distribution agnostic and will work for any given package on most distributions, assuming dependencies are met. Correctly used, compiling from source has the benefit of being tailored more to your environment, with better optimization. The biggest drawback is that compiling from source, without careful manipulation of configuration files, can “litter” your system with executables and libraries placed in less than optimal locations. It can also result in difficult to manage upgrade paths for installed software, or even just trying to remember what you have previously installed.

The source files (containing source code) normally come in a package commonly referred to as a “tarball”, or a tar.gz file (a gzip compressed tar archive). The archive is extracted, the source is compiled, and then an install script is executed to place the resulting program files and documentation in the appropriate directories. The following shows a very abbreviated view of a quick source compilation. The normal course of commands used is (usually):

tar xzvf packagename.tar.gz
cd packagename
./configure
make
make install

First we extract the package and change into the resulting directory. The ./configure command ^[10] sets environment variables and enables or disables program features based on available libraries and arguments. The make command compiles the program, using the parameters provided by the results of the previous ./configure command. Finally, the make install command moves the compiled executables, libraries and documentation to their respective directories on the computer. Note that make install is generally not distribution aware, so the resulting placement of program files might not fit the conventions for a given Linux distro, unless the proper variables are passed during configuration (outside of the scope of this guide).

The way the software we are compliling is actually built with make is controlled by the `Makefile`. The Makefile contains commands, macros, and definitions that make the compliation "automatic".

Here’s a quick illustration:

Once we have a package downloaded, we extract the tarball. After the package has been extracted, we change into the resulting directory and then run a “configure script” to allow the program to ascertain our system configuration and prepare compiler options for our environment. We do this with ./configure

Assuming no errors (from missing dependancies or wrong compiler versions, etc.), we type make and watch the compiler go to work. Finally, we run the command that properly installs both the tools to the proper path, and any required libraries to the proper directories. This is generally accomplished with make install

Our program is now installed and ready to use. Knowing how to use source packages for software installation is important part of understanding how Linux works.

The above description of manually installing software is a bit oversimplified. There are source code packages (python programs for example) that don’t work the same way. Most source packages will include a README or INSTALL.txt file when extracted. Read them. Our goal here is to illustrate the difference between manual software installation and distribution package management. The latter is preferable, and we cover that now.

As we’ve already mentioned, just about every Linux distribution has some sort of “package manager” for installing and updating packages. For updating and adding official Slackware software (included in the distribution), we’ve introduced using slackpkg. slackpgk is actually a front end to the pkgtool group of utilities which handle the work of adding and removing software packages from your system. For an excellent overview of pkgtool and its various commands, have a look at http://www.slackware.com/config/packages.php.

Slackware packages are really just compressed archives that, when installed, place the package files in the proper place. To install a single Slackware package, when we are not using the slackpkg front end, we use the pkgtool command installpkg.

Our example here will be a pretend Slackware package called software. Slackware packages are generally named with the extension tgz or txz (since they are really just compressed archives). Once you’ve downloaded or prepared your package (our example is called software.tgz), you install it with the following command:

Packages can be similarly removed or upgraded with removepkg or upgradepkg, respectively.

You can find pre-made packages for all sorts of software for many distributions all over the Internet. The problem with many of them is that they do not come from trusted sources and you often have no idea what configuration options were used to build them.

As a general rule of thumb, I always like to build my own packages for software that is not part of the Slackware full installation. This allows me to build the software with the options I need (or without ones I don’t), optimized for my particular system, and it further allows me to control how the software is eventually installed. Luckily Slackware provides a relatively easy way to create packages from source code. SlackBuilds.

In short, a SlackBuild is a script that (normally) takes source code and compiles and packages it into a Slackware .tgz (or .tzx) file that we can install using installpkg.

The SlackBuild script handles the configure options and optimizations that the script author decides on (but are visible and editable by you), and then installs the software and related files into a package that follows Slackware software conventions for executable and libraries, where applicable, and assuming the build author follows the template. The scripts are easily editable if you want to change some of the options or the target version, and provide for an easy, human readable way to control the build process. SlackBuilds for a large selection of software are available at
http://www.SlackBuilds.org.

The SlackBuild itself comes as a .tar.gz file that you extract with the tar command. The resulting directory contains the build script itself: software.SlackBuild, with software being the name of the program we are creating a package for. There are normally four files included in the SlackBuild package:

In most cases, to build a Slackware compatible package, you simply drop the source code for the software into the same directory the <software>.SlackBuild is in (no need to extract the source tarball) and execute the SlackBuild script. The package is created and (normally) placed in the /tmp directory ready for installation via installpkg.

Of course, there are automated tools to handle building Slackware packages for you. You can check out sbopkg, sbotools, slpkg and a few others.

We will talk specifically about one of the package management tools you can use with Slackware to automate some of the more mundane steps we take when installing software. For that we will use use sbotools. This will assist us in building and installing the remainder of the software we’ll use in this guide. sbotools comes in two versions right now:

We will be using sbotools (version 4.4.2).

Since we are using Slackware-current as of this writing, there is a prebuilt Slackware package for sbotools hosted at LinuxLEO.com. Since we know the location of the package we want, well use the wget tool to download it directly. In the next set of commands we’ll accomplish the following:

We are logged in as root to accomplish this.

sbotools is now installed for managing software not included with the default Slackware install.

So, now we’ve installed sbotools, and we are going to use it in lieu of all the downloading, MD5 checks, extracting and building. It is extremely important that we remain mindful of the README files and ensure that we don’t allow the automation to make us complacent. Read the documentation for each package you are installing and be familiar with what it is doing to your system along with what options you may want to enable or disable. If there are optional dependancies specified in the README (which sbotools will show you by default), then you will be prompted to add them.

sbotools is actually a collection of utilities. We need to initialize our local SlackBuild repository. By default, sbotools (via sbocheck) will pull or update (if it already exists) the entire SlackBuilds tree (from SlackBuilds.org) and place it locally in /usr/sbo/repo. If you look closely at the output of sbocheck you will see that the correct version of Slackware is detected, and the correct download mirror is set.

Once this is done, you can search, install and upgrade packages and their initial dependencies all from single commands using the following:

We’ll be using sbotools to install software throughout the remainder of this document (if you are using Slackware). But lets start with a quick example of a simple installation for some anti-virus/malware detection software that we’ll cover later.

I have a clean Slackware install with a single external software package, sbotools, installed. Now I want to install more software.

To illustrate a more automated install - but one that still requires user intervention - we’ll install ClamAV (clamav), a virus/malware scanner. First we will use sbofind to search for clamav. We then narrow our search and take a quick look at the README file. Then we simply run sboinstall to download, check, build and install the package for us. The shortcut to all this is to simply type sboinstall clamav and we’re done. But I prefer a more cautious approach.

First, let’s search for available packages that match clamav:

The clamav package we are looking for is the second on the list.

Now I’m going to run sbofind again, but this time limit the output to an exact match for the clamav package I want to actually find an exact match for the string I search (-e) with no tags (-t) and view the README file for the package (-r).

And what we have here is a perfect example of why we read the README files prior to installing software. In order to make it run correctly, we need to make sure we have a group and user called clamav. The commands we need to accomplish this are provided right in the README. So we run those and then we are ready to install the software. You can even allow sbotools to run the commands for you, but I would suggest you run them yourself and decline the prompt in the sboinstall command. clamav also has a secondary README.Slackware file with additional instructions for running the program as a mail scanner. You can elect to read that as well, if you like, though we won’t be setting that up in this example.

Now sbotools will download, check, unpack, configure, build and finally install the package and its dependencies for us. When you run sboinstall clamav, you will see that it immediately indicates that the dependencies rust-opt and libmspack will be installed first. You can review these required dependencies by viewing the clamav.info file with sbofind -t -e -i clamav and checking the REQUIRES line. Optional dependencies will be listed in the README for the target package. Keep in mind that at times you will have dependencies that themselves have dependencies. These will also be handled automatically by sboinstall.

We’ll continue to use this method to install software through the rest of this guide. We will cover ClamAV usage later.

Remember we can periodically use sbocheck to see if we hve any external software that needs updating (recall that slackpkg update is used for official Slackware packages).

One final note on package management. A complete list of packages (on Slackware) installed on your system is maintained in /var/lib/pkgtools/packages. You can browse that directory to see what you have installed, as well as view the files themselves to see what was installed with the package. One nice thing about using SlackBuilds is that an SBo tag is added to the package name. We can grep for this tag in /var/lib/pkgtools/packages and see exactly which external packages we have installed via SlackBuilds. This is one of the great advantages of using a package manager vs. simply compiling and installing software from source directly…​the ability to track what versions of which packages are installed.

We have just installed two packages using build scripts from SlackBuilds.org. One via manual download (sbotools), and one via sbotools (clamav, plus its two dependancies). We can use grep to see this within the /var/lib/pkgtools/packages directory (assuming this is a clean Slackware system and you’ve installed no other .tgz or .txz Slackware packages):

When it comes time to upgrade (or check for updates to) software we’ve installed via SlackBuilds and sbotools, you can use sbocheck. Running this command will fetch a fresh SlackBuilds tree from SlackBuilds.org and compare your installed packages to those currently available.

In this case, we run sbocheck and there are no updates. If an update were listed in the output, we would simply run sboupgrade <packagename> and the package would be downloaded, compiled, and properly upgraded. This provides us an easy way to install and upgrade external packages, in a Slackware friendly format, with minimal fuss.

The earlier caution still stands. Make sure you understand what you are installing and always always read the README file.

It has become common practice in digital forensics to split the output of our imaging. This is done for a number of reasons, either for archiving or for use in another program. We will first discuss using split on its own, then in conjunction with dd for “on the fly” splitting.

For example, we have our 80GB image and we now want to split it into 4GB parts so they can be written to other media. Or, if you wish to store the files on a file system with file size limits and need a particular size, you might want to split the image into smaller sections.

For this we use the split command.

The split command normally works on lines of input (i.e. from a text file). But if we use the` -b` option, we force split to treat the file as binary input and lines are ignored. We can specify the size of the files we want along with the prefix we want for the output files. split can also use the -d option to give us numerical numbering (*.01, *.02, *.03, etc.) for the output files as opposed to alphabetical (*.aa, *.ab, *.ac, etc.). The -a option specifies the suffix length. The command looks like:

split -d -aN -bXG <file to be split> <prefix of output files>

where N is the length of the extension (or suffix) we will use and X is the size of the resulting files with a unit modifier (K, M, G, etc.). With our image of /dev/sdd, we can split it into 4GB files using the following command (The last file will be sized for the remainder of the volume if it’s not an exact multiple of your chosen size.):

This would result in a group of files (4GB in size) each named with the prefix case1.split1. as specified in the command, followed by 000, 001, 002, and so on. The -a option with 3 specifies that we want the extension to be at least 3 digits long. Without -a 3, our files would be named *.01, *.02, *.03, etc. Using 3 digits maintains consistency with other tools^[11]. Note the trailing dot in our output file name. We do this so the suffix is added as a file extension rather than as a suffix string appended to the end of the name string.

The process can be reversed. If we want to reassemble the image from the split parts, we can use the cat command and redirect the output to a new file. Remember cat simply streams the specified files to standard output. If you redirect this output, the files are assembled into one.

In the above command we’ve re-assembled the split parts into a new 80GB image file. The original split files are not removed, so the above command will essentially double your space requirements if you are writing to the same mounted device/directory.

The same cat command can be used to check the hash of the resulting image sections by streaming all the parts of the image through a pipe to our hash command:

Once again, we see that the hash remains unchanged. The – at the end of the output denotes that we took our input from stdin, not from a file or device. In the command above, sha1sum receives its input directly from the cat command through the pipe.

Another way of accomplishing multi-segment images would be to split the image as we create it (directly from a dd command). This is essentially the “on the fly” splitting we mentioned earlier. We do this by piping the output of the dd command straight to split, omitting the of= portion of the dd command. Assuming our subject drive is /dev/sdd, we would use the command:

Here, instead of giving the name of the file to be split in the split command, we give a simple "-" (after the 4G, where we had the input name in our previous example). The single dash is a descriptor that means “standard input”. In other words, the command is taking its input from the data pipe provided by the standard output of dd instead of from a file. Any options you want to pass to dd (block size, count, etc.) go before the pipe. The output above shows the familiar number of sectors is correct for the disk we are imaging (156250000).

Once we have the image, the same technique using cat will allow us to reassemble it for hashing or analysis as we did with the split images above.

For practice, you can use a small USB thumb drive if you have one available and try this method on that device, splitting it into a reasonable number of parts. You can use any sample drive, being sure to replace our device node in the following command with /dev/sdx (where x is your thumb drive or other media). Obtain a hash first, so that you can compare the split files and the original and make sure that the splitting changes nothing.

This next example uses a 2GB USB drive that is arbitrarily split into 512M section. Follow along with the commands, and experiment with options while watching changes in the resulting output. It’s the best way to learn. We’ll start by identifying the thumb disk with lsscsi as soon as it’s plugged in (output is abbreviated for readability):

Looking at the output of the above commands, we first see that the thumb drive that was plugged in is identified as a Generic USB Flash Drive’. We then hash the device, image and split on the fly with dd, and check the hash. We find the same hash for the disk, for the split images “cat-ed” together, and for the newly reassembled image.

We’ll have some more fun with this command later on. It is more than just an imaging tool.

The first alternative imaging tool we will cover is dc3dd. This imaging tool is based on original (patched) code from dd. It is very similar to the popular dcfldd but provides a slightly different feature set. The choice of whether to cover either dcfldd or dc3dd is largely arbitrary. dc3dd is maintained by the DoD (Department of Defense) Cyber Crime Center (other wise known as Dc3)^[13] Regardless of which (dc3dd or dcfldd) you prefer, familiarity with one of these tools will translate very nicely to the other with some reading and experimentation, as they are very similar. While there are some significant differences, many of the features we discuss in this section are common to both dc3dd and dcfldd.

The source package and more information for dc3dd can be found at https://sourceforge.net/projects/dc3dd/.

dc3dd is installed by default on recent versions of Slackware. If you are using a different distribution, check your package manager’s repository.

The man page for dc3dd is concise and easy to read. All the information you need to use the advanced features of this imaging tool are neatly laid out for you.

Let’s have a look at the basic usage of dc3dd. As you read through the usage section of the man page, you’ll notice a number of additions to regular dd for the forensic examiner. Let’s concentrate on these notables additions:

If we redo our imaging of /dev/sdd (our original 80GB disk) using dc3dd with simple if= and of= parameters, as we used with dd, the session would look something like this. We are still in our ~/case1/images directory.

Our input file is still the disk sdd (if=/dev/sdd), our output file is now case1.disk1.dc3dd.raw (of=case.disk1.dc3dd.raw). One of the first things you notice right away is that dc3dd returns more usable information while the program is running. It gives you a very nice progress indicator. We also see immediately that the correct number of sectors for /dev/sdd were captured (156250000), and that there were no "bad" sectors detected. The start and stop time stamps are also added by default. If you specify a log file, this information is all captured very nicely. We will look at the hashing options and logging in more detail in just a moment.

This verbose output and the availability of simple logging is one of the things that makes dc3dd a better candidate for general forensic imaging when compared to dd.

As mentioned, dc3dd can incorporate the hashing, splitting and logging of an acquisition into a single command. All of this can be done with regular dd and external tools (with pipes, redirection or scripting) but many practitioners prefer an integrated approach. Additionally, the standard options available to the regular dd command still are readily available in dc3dd (bs, skip, etc.).

More than just incorporating the other steps into a single command, dc3dd extends the functionality. For example, using a regular split command with dd as we did in a previous exercise, we can either allow the default alphabetic naming convention of split, or pass the -d option to provide us with decimal extensions on our files. In contrast, dc3dd allows us to not only define the size of each split as an option to the imaging command (using ofsz) without need for a piped command, but it also allows more granular control over the format of the extensions each split will have as part of its filename. So, to our 80GB disk into 4GB sections, I would simply use:

ofs=BASENAME.FMT ofsz=4G

The ofs parameter is essentially "output file split". The extension following the output files names is directly formatted in the command itself. According to the dc3dd man page:

So if I issue the base command as something like this:

I can adjust the values for FMT and my split file extensions would change accordingly:

In addition, when using regular GNU dd, our hashing functions are performed external to the imaging, by either the md5sum, sha1sum, or some other algorithm, depending on the analyst preference. dc3dd allows the user to run BOTH hashes concurrently on an acquisition and log the hashes. Before we run our split images with dc3dd, lets look at the hashing options a little closer.

We select our hash algorithm with the option hash=, specifying any of md5, sha1, sha256, sha512, or a comma separated list of algorithms. In this way you can select multiple hash methods for a single image file. These will be written to a log file we indicate, a special hash log, or to standard output if no log is specified.

dc3dd also provides hof and hofs parameters. The hof option acts much like of, but hashes the output, compares it to the input and records it. You must select a hash algorithm. Likewise, hofs acts much like ofs, splitting the output into chunk sizes specified by ofsz. The hofs option differs in that it also hashes each of the input/output streams and compares and logs them for each chunk.

You can pass the log=filename parameter to log all output in a single place, or you can log hashes separately using the hlog=filename option.

Let us redo our dd example with the 2G thumb drive. This time we will use dc3dd. We will discuss the options and output below. We are running these commands in root’s home directory (or any directory of your choosing - so we don’t get the resulting image files confused with our case1 data).

The options used above are:

The resulting output (shown by our ls command below) gives us 4 split image files, with numerical extensions starting with 000. We also have a log file of our hashes and any error messages, which we can view with less or cat:

As previously discussed, the log file contains our hashes and our error messages. For the hashes, the input hash from the imaged device are displayed first (for each hash algorithm we requested). Then the output hashes are displayed for each of the output files. If the input hash matches the output hash for a given range (or the whole device), the output hash is preceded with [ok] so you do not have to manually compare the output.

The log file ends with a time stamp for your documentation.

Another useful feature of dc3dd when compared to regular dd is the ability (without the use of external pipes or piping programs) to collect multiple images at the same time. If logistics allows, and there is a need to collect multiple copies on location to distribute to multiple parties, we can create additional output files:

The demonstration above illustrates collecting two images simultaneously. You can see we selected to hash the output files (hof) using the md5 algorithm (hash=md5). The output shows the single input stream was hashed, but there are two output streams, and each was hashed and verified separately. This can be a very useful feature of dc3dd.

Remember that dc3dd outputs raw images. They can be hashed exactly the same as dd output: Directly hashed with your hashing algorithm of choice (sha1sum, md5sum, etc.), or in the case of split files, using the cat command to stream the output of multiple files to the hash program.

Now we’ll continue our look at alternative imaging tools with a utility that is used to collect and manipulate Expert Witness (E01 or EWF) files, one of the more ubiquitous formats used in computer forensics today.

There may be times when you are asked to perform examinations collected by someone else, or perhaps your organization has elected to standardize on a given format for forensic images. In any case, chances are you will eventually come across Expert Witness Format files (EWF, commonly referred to as “EnCase” format). There are many tools that can read, convert or work with these images. In this section we will learn to acquire and manipulate evidence in the EWF format.

We will explore a set of tools here belonging to the libewf project. These tools provide the ability to create, view, convert and work with expert witness evidence containers.

One of the benefits of covering libewf before other advanced forensic utilities is because it needs to be installed first in order to supply the required libraries for other packages to support EWF image formats. The libewf tools and detailed project information can be found at https://github.com/libyal/libewf/

We will start by installing libewf using sbotools. Check your distribution documentation, or the install instructions at the website shown above if you are using a distribution other than Slackware. The installation is simple. libewf has no additional requirements (you can view the info file with sbofind -tei libewf). When you start the installation process be sure to take the time to read the README file that displays.

Take care to download and install the correct version. We are using version 20140816, which is under the libewf-legacy tree. It was actually released in 2023 and is considered "stable". Newer versions of libewf are considered "experimental". For now 20140816 is the safer choice.

Once the download, compile, build, and installation of the resulting package is complete, the actual tools are placed in /usr/bin. We will have a closer look at the following:

We’ll start with the ewfacquire command used to create EWF files that can be used in other programs. The easiest way to describe how ewfacquire works is to watch it run. To get a list of options (there are many), just run ewfacquire -h. To obtain an image, simply issue the command with the name of the file or physical device you wish to image. Unless you memorize or script the options, this is the easiest way to run the program. You are prompted for required information, to be stored with the data in the EWF format (the below output is interactive):

In the above command session, user input is shown in bold. In places where there is no input provided by the user, the defaults (shown in brackets) are used. Notice that ewfacquire gives you several options for image formats that can be specified. The file(s) specified by the user is given an E** extension and placed in the path directed by the user. Finally, an MD5 hash is provided at the end of the output for verification. Note that the MD5 hash provided by ewfacquire is the same as calculated with md5sum in the above session. As with dc3dd, you also get a time stamp for documentation.

You can also issue a single command and specify those options we used above on the command line. For example, to get similar results, we can issue the following command:

You can look at the individual options provided in the command above by viewing man ewfacquire. Essentially this command allows us to run ewfacquire without having to answer any prompts. The important option to note here is -u (unattended mode) that forces ewfacquire to use the defaults for options not specified. Make sure you know what you are doing before running the command unattended.

Once acquired, the resulting files from ewfacquire are compatible with any software that will read EWF format images. We’ll be using some forensic utilities later to do just that.

Let’s look now at ewfinfo and ewfverify. These two tools, also included with `libewf,`provide information on any properly formatted EWF files you may come across.

ewfinfo simply reads the image metadata that was entered during the imaging process. It will work with image files acquired using other EWF software as well, as long as it is in a proper EWF format. For the files we just collected using ewfacquire the output would look like this (Note the operating system used and the software version used):

If you run ewfinfo on files collected using tools other than ewfacquire (EnCase under Windows, for example), the output might look like this. Note the Operating system used and Software version used fields. These give some hint as to how the files were created (EnCase version 7 on Windows 7).

Also note that the MD5 value shown is the value of the data, NOT the image files themselves. Hashing the EWF image files does not allow you to verify against the hash of the original media – the E0* files contain meta data and so do not represent an exact copy of the source media alone. If you want to verify the hash of the data after it’s been moved, you need to use a tool like ewfverify.

Hashing the data in EWF files requires a tool that recognizes the metadata associated with an EWF file and can parse and hash the original data in the container. For this we use ewfverify.

This command simply rehashed the data and compared it to the hash already stored within the file’s metadata. Every time you move data between volumes, it’s always good practice to check that the data is still intact. ewfverify allows you to accomplish this integrity check quickly and efficiently with EWF files.

Now for one last command in the libewf suite of tools. Let’s talk about those situations where you’ve been provided a set of image files (or file) that were obtained using a popular Windows forensic tool. There will be times where you would like read the meta-data included with the images, verify the contents of the images, or export or convert the images to a bit stream (or raw) format. Once again, the libewf tools come in handy for this. They operate at the Linux command line, don’t require any other special software, license, or dongle and are very fast. We will use a copy of an NTFS practical exercise image we will see more of later in our upcoming advanced exercises. The EWF files we’ll be working on can be downloaded using wget, as we have done previously. Once downloaded, check the hash and compare:

As we’ve seen previously with our software downloads, this file has a tar.gz extension. That means it is a compressed TAR archive. To review, the tar part of the extension indicates that the file was created using the tar command (see man tar for more info). The gz extension indicates that the file was compressed (commonly with gzip). When you first download a tar archive, particularly from un-trusted sources, you should always have a look at the contents of the archive before decompressing, extracting and haphazardly writing the contents to your drive. View the contents of the archive with the following command:

The above tar command will list (t) and decompress (z) the file (f)
NTFS_Pract_2017_E01.tar.gz. This allows you to see where the file will be extracted, and as the output shows, there are five files that will be extracted to a new directory,
NTFS_Pract_2017/, in the current directory. We will use the tar command extensively throughout this document for downloaded files.

Now we actually untar the images with the tar x option and change into the resulting directory. We use the v option for verbose output to see the files being written:

The first thing we can do is run the ewfinfo command on the first file of the image set. This will return the meta-data that includes acquisition and media information, as we’ve seen previously. We learn the version of the software that the images were created with, along with the collection platform, date of acquisition, name of the examiner that created the image with the description and notes. Have a look at the output of ewfinfo on our file set (you only need provide the first file in the set as an argument to the command):

Notice that the last line in the output provides us with an MD5 hash of the data in the file set. Again, don’t confuse this with the hash of the file itself. A file in EWF format stores the original data from the media that was imaged along with a series of CRC checks and meta-data. The hash of the E01 file(s) itself will NOT match the hash of the original media imaged. The hash of the original media and therefore the data collected are recorded in the metadata of the EWF file for later verification.

You can see from our output below that the NTFS_Pract_2017.E0* file set verifies without error. The hash obtained during the verification matches that stored within the file:

Now we’ll look at ewfexport. This tool allows you to take an EWF file set and convert it to a bit stream image file, essentially removing the meta-data and leaving us with the data in raw format, as with dd. It is interesting to note that ewfexport can actually write to standard output, making it suitable for piping to other commands. Here, we issue the command with several options that result in the EWF file being exported to a raw image.

We use the -t option (“target”) to write to a file. The -f option with raw indicates that the file format we are writing to is raw, as with dd output. We use -u to accept the remaining defaults and prevent an interactive session. This results in a single raw file that has the same hash as the original media (see the output of the md5sum command). We also see an XML formatted .info file that contains the hash value.

At this point, we’ve covered dd, dc3dd, ewfacquire and common methods for checking the integrity of and exporting the collected images.

All of the tools we’ve covered so far are great for ideal situations, where our media behaves as we expect. In addition, they all have options or built in mechanisms that would allow our acquisition to read past (or more accurately “around”) any non-fatal disk errors while syncing the output so that the resulting image might still be usable. While many practitioners suggest these options as a default for running dd related commands, I tend to urge against it. Some of the reasons for this will become more apparent in the following section. :hash: # :ast: * :usc: _ :crt: ^ :lb: [ :rb: ]

Now that we have a basic understanding of media acquisition and the collection of evidence images, what do we do if we run into an error? Suppose you are creating a disk image with dd and the command exits halfway through the process with a read error?

We can instruct dd to attempt to read past the errors using the conv=noerror option. In basic terms, this is telling the dd command to ignore the errors that it finds, and attempt to read past them. When we specify the noerror option it is a good idea to include the sync option along with it. This will “pad” the dd output wherever errors are found and ensure that the output will be “synchronized” with the original disk. This may allow file system access and file recovery where errors are not fatal. Assuming that our subject drive is /dev/sdc, the command will look something like:

Forensic examiners should use caution when using the conv=noerror,sync option, however. While dd is capable of reading past errors in many cases, it is not designed to actually recover any data from those areas. There are a number of tools out there that are designed specifically for this purpose. If you need to use conv=noerror,sync, then you are using the wrong tool. That is not to say it will not work as advertised (with some caveats), only that there are better options, or at least important considerations.

In addition, the error handling of solid state media can differ greatly from traditional spinning drives. While what we are using here applies to flash media in many cases, your results may vary.

Which brings us to ddrescue.

Testing has shown that standard dd based tools are simply inadequate for acquiring disks that have actual errors. This is NOT to say that dd, dc3dd or dcfldd are useless…​far from it. They are just not optimal for error recovery. You may be forced to use dd or
dc3dd because of limits to external tool access or considerations of time. We teach dd in this guide because there are instances where it may be the only tool available to you. In those cases, understanding the use of command line options to optimize the recovery of the disk regardless of errors is important for evidence preservation. However, if there are options, then perhaps a different tool would make sense.

This section is not meant to provide an education on disk errors, media failure, or types of failure. Nor is it meant to imply that any tool is better or worse than any other. We will simply describe the basic functionality and leave it to the reader to pursue the details and test for functionality that suits your investigative needs.

First, let’s start with some of the issues that arise with the use of common dd based tools. For the most part, these tools take a “linear” approach to imaging, meaning that they start at the beginning of the input file and read block by block until the end of the file is reached. When an error is encountered, the tool will either fail with an “input/output” error, or if a parameter such as conv=noerror is passed, will ignore the errors and attempt to read through (or skip) them, continuing to read block by block until it comes across readable data again. Here is a simple dd command on a disk with errors. The disk is 41943040 sectors:

The dd command above was only able to read 12840 sectors (which is 6574080 bytes, as the dd output shows). The same command, this time using conv=noerror,sync will ignore the error, pad the error sectors with null bytes, and continue on:

What you end up with at the end of this command is an image of the entire disk, but with the error sectors filled in (sync’d) with zeros. This done to ensure that the data that is properly copied remains on the appropriate block boundries and data stays in sync with file system tables.

Obviously, simple failure (“giving up” when errors are encountered) is not good. Any data in readable areas beyond the errors will be missed. The problem with ignoring errors and attempting to read through them (using options like conv=noerror) is that we are further stressing a disk that is already possibly on the verge of complete failure. The fact of the matter is that you may get few chances at reading a disk that has recorded “bad sectors”. If there is an actual physical defect, the simple act of reading the bad areas may make matters worse, leading to disk failure before other viable areas of the disk are collected. All of this applies, of course, to disks with “physical” storage. Solid state storage is another matter entirely.

So, when we pass conv=noerror to an imaging command, we are actually asking our imaging tools to “grind through” the bad areas. Why not initially skip over the bad sections altogether, since in many cases recovery may be unlikely? Instead we should concentrate on recovering data from areas of the disk that are good. Once the “good” data is acquired, we can go back and attempt to collect data from the error areas, preferably with a recovery algorithm designed with purpose.

In a nutshell, that is the philosophy behind ddrescue. Used properly, ddrescue will read the “healthy” portions of a disk first, and then fall back to recovery mode – trying to read data from bad sectors. It does this through the use of some very robust logging, referred to as a ’map file’. This allows ddrescue to resume any imaging job at any point, given a map file to work from. This is an important (perhaps the most important) point about using ddrescue - that is, with a map file you never need to re-read already successfully recovered sectors. When ddrescue references the map file on successive runs, it fills in the gaps, it does not “redo” work already finished.

ddrescue is installed by default in Slackware Linux (for full installations), but check with your distribution of choice to determine availability.

The documentation for ddrescue is excellent. The detailed manual is in an info page. The command info ddrescue will give you a great start to understanding how this program works, including examples and the ideas behind the algorithm used. I’ll run through the process here, but I strongly advise that you read the info page for ddrescue before attempting to use it on a case.

The first consideration when using any recovery software, is that the disk must be accessible by the Linux kernel. If the drive does not show up in the /dev structure, then there’s no way to get tools like ddrescue to work.

Next, we have to have a plan to recover as much data as we can from a bad drive. The prevailing philosophy of ddrescue is that we should attempt to get all the good data first. This differs from normal dd based tools, which simply attempt to get all the data at one time in a linear fashion. ddrescue uses the concept of “splitting the errors”. In other words, when an area of bad sectors is encountered, the errors are split until the “good” areas are properly imaged and the unreadable areas marked as bad. Finally, ddrescue attempts to retry the bad areas by re-reading them until we either get data or fail after a certain number of specified attempts.

There are a number of ingenious options to ddrescue that allow the user to try and obtain the most important part of the disk first, then move on until as much of the disk is obtained as possible. Areas that are imaged successfully need not be read more than once. As mentioned previously, this is made possible by a robust map file. The map file is written periodically during the imaging process, so that even in the event of any interruption, the session can be restarted, keeping duplicate imaging efforts, and therefore disk access, to a minimum.

Given that we are addressing forensic acquisition here, we will concentrate all our efforts on obtaining the entire disk, even if it means multiple runs. The following examples will be used to illustrate how the most important options to ddrescue work for the forensic examiner. We will concentrate on detailing the map file used by ddrescue so that the user can see what is going on with the tool, and how it operates.

Let’s look at a simple example of using ddrescue on a small drive without errors, to start. The simplest way to run ddrescue is by providing the input file, output file and a name for our map file. Note that there is no if= or of=. In order to get a good look at how the map file works, we’ll interrupt our imaging process halfway through, check the map file to illustrate how an interruption is handled, and then resume the imaging.

Here we used /dev/sdb as our input file, wrote the image to ddres_image.raw, and wrote the map file to ddres_map.txt. Note the output shows the progress of the imaging by default, giving us a running count of the amount of data copied or "rescued", along with a count of the number of errors encountered (in this case zero), and the imaging speed. The process was interrupted right at about 50% completion, with the <ctrl-c> key combo.

Now lets have a look at our map file:

The map file shows us the current status of the acquisition ^[14]. Lines starting with a # are comments. There are two sections of note. The first non comment line shows the current status of the imaging while the second section (two lines, in this case) shows the status of various blocks of data. The values are in hexadecimal, and are used by ddrescue to keep track of those areas of the target device that have marked errors, those areas that have already been successfully read and written, and those that remain to be read. The status symbols we will discuss here (taken from the info page) are as follows:

In this case we are concerned only with the ? and the +. Essentially, when the copying process is interrupted, the log is used to tell ddrescue where the copying left off, and what has already been copied (or otherwise marked). The first section (status) alone may be sufficient in this case, since ddrescue need only pickup where it left off, but in the case of a disk with errors, the block section is required so ddrescue can keep track of what areas still need to be retried as good data is sought among the bad.

Translated, our log would tell us the following (narrowed down to the position and status):

The status shows that the current imaging process is copying data at byte offset 1091371008 (0x410D0000). In our first pass, this indicates the “non-tried” blocks.

The size of our partial image file matches the size of the block of data marked “finished” with the + symbol in our log file (size bold for emphasis):

We can continue and complete the copy operation now by simply invoking the same command. By specifying the same input and output files, and by providing the map file, we tell ddrescue to continue where it left off:

The above session shows the output of the completed ddrescue command followed by the contents of the map file. The ddrescue command shows the initial status line indicating where we left off, and then current status through image completion. The echo command converts our hexadecimal value to decimal, just so we can illustrate that the total rescued is equal in size to the size of the image.

The real power of the map file lies in the fact that we can start and stop the imaging process as needed and potentially attack the recovery from different directions (using the -R option to read the disk in reverse) until you’ve scraped together as much of the original data as you can. For example, if you had two identical disks, with mirrored data, and both had bad or failing sectors, you could probably reconstruct a complete image by imaging both with ddrescue and using the same map file (and output file). Once recovered and recorded as such in the map file, sectors are not accessed again. This limits the stress to the disk.

Using a disk with known errors we’ll invoke ddrescue with some additional options. In this case, I may have started imaging a subject disk using a common tool like dd or dc3dd, and found that the copy failed with errors. Knowing this, I’ll switch to using ddrescue. The options in the below command are -i0 to indicate starting at offset 0. Offset 0 is the default, but I’m being explicit here. There are situations where you might want to start at a different offset and then go back…​the map file allows for this easily. The -d option means that we are going to directly access the disk, bypassing the kernel cache. Next, the -N option is provided to prevent ddrescue from “trimming” the bad areas that are found. This option allows ddrescue to start the recovery process by collecting good data first, disturbing the error areas as little as possible.

The output above shows a couple of things (highlights for emphasis). We have the completed initial run with the -N option, and the output shows that we have 65536 bytes “non-trimmed”, indicating an area of errors. The map file shows the position of un-copied area of the disk (offset 0x00640000) and a size of 0x00010000 (65536 bytes). The status of this area is indicated with an asterisk. Note that the 65536 bytes is exactly 128 sectors, and this is the default “cluster” size used by ddrescue. This does not mean that there are 128 sectors that cannot be read. It simply means that the entire cluster could not be read, and the -N option prevented “trimming”, or paring the sectors down to smaller readable chunks. The cluster size can be controlled with the \-\-cluster-size=X option, where X is the number of sectors in a cluster. We now have a partial image.

Now we can continue the imaging with the same input and output file, and the same map file, but this time we remove the -N option, allowing error areas to be trimmed, and we add the -r option to specify the number of retries when a bad sector is encountered, which is three in this case.

The output shows that our “non-trimmed” areas are now 0, and the error size is 3072 bytes. Looking at the map file, we see that there is a section of the disk that is marked with the “-”, indicating bad hardware blocks, which in this case are unrecoverable. The size in the map file (0x00000C00) matches the bad-sector in the output (3072). This means we have 6 bad sectors (512 bytes each).

While we were not able to obtain the entire disk in this example, hopefully you recognize the benefits of the approach we take using ddrescue to get the good data first while recovering as much as we can before accessing and potentially causing additional damage to bad areas of the disk. :imagesdir: image :hash: # :ast: * :usc: _

The next step is to open a "listening" port on the collection computer. We will do this on our evidence collection system with nc (our netcat utility), making sure we have a mounted file system to store the image on. In this case we are using an external USB drive mounted on /mnt/evidence (on the collection workstation) to store our image:

This command opens a netcat (nc) listening session (-l) on TCP port 2525 (-p 2525) and pipes any traffic that comes across that port to the dd command (with only the of= flag), which writes the file /mnt/evidence/net_dd.raw.

Now on the subject computer (note the command prompt with the hostname bootdisk), we issue the dd command. Instead of giving the command an output file parameter using of=, we pipe the dd command output to netcat (nc) and send it to our listening port (2525) on the collection computer at IP address 192.166.0.1.

This command pipes the output of dd straight to nc, directing the image over the network to TCP port 2525 on the host 192.168.0.1 (our collection box’s IP address). If you want to use dd options like conv=noerror,sync or bs=x, then you do that on the subject dd side of the pipe.

Once the imaging is complete^[16], we will see that the commands at both ends appear to “hang”. After we receive our completion output from dd on the subject computer (records in / records out), we can kill the nc listening on our collection box with a simple <ctrl-c>.

When you see this on the subject computer, you would use <ctrl-c> to end the listening process on the collection workstation.

This should return our prompts on both sides of the connections. You should then check the resulting image on the collection workstation to see if they match.

Our hashes match and our network acquisition was successful.

As we discussed previously, there are a number of tools we can use for imaging that provide a more forensic oriented approach. dc3dd is as good a choice for over the wire imaging as it is on local disks. You also have some flexibility with dc3dd in that even if your boot media does not come with it installed, you are still able to use all its features on the evidence collection computer.

dc3dd does all its magic on the output side of the acquisition process (unless you are acquiring from file sets or some other non-standard source). This means we can use plain dd on our subject computer (using the boot media) to acquire the disk and stream the contents across our netcat pipe, and still allow dc3dd on our collection workstation to handle hashing, splitting and logging. Most of dc3dd’s options and parameters work on the output stream. So, while our listening process on the collection system will use dc3dd commands, the subject system can use the same dd commands we used before.

On the collection system, let’s set up a listening process that uses dc3dd to split the incoming data stream into 2GB chunks and logs the output to nc.dc3dd.raw. As soon as we initiate our command, dc3dd will start and sit waiting for input from the listening port (2525):

The dc3dd output will start immediately, but stay at 0 bytes until it receives input through the pipe. As soon as you start the imaging process on the subject machine, you’ll see the dc3dd command on the listening machine start to process the incoming data. Again notice we are using plain dd on the subject box to simply stream bytes over the pipe. dc3dd takes over on the collection machine to implement our dc3dd options and logging.

When the transfer is complete, you will see the completion messages from dd (number of input and output records).

We can look at the resulting files and the dc3dd log on our collection machine.

We can see that the dc3dd log ended with an “aborted” message because we had to manually stop the listening process (with ctrl-c) since in this case dc3dd is not handling the input itself, but just accepting the stream through netcat – you need to manually tell it when the stream is complete. Again, when completed, you should check the resulting hashes against our original hash of /dev/sda on the subject machine.

Last, but not least, we will cover a tool that will allow us to take a stream of input (with the same netcat pipe) and create an EWF file from it. ewfacquirestream acts much like ewfacquire (and is part of the same libewf package we installed previously), but allows for data to be gathered via standard input. The most obvious use for this is taking data passed by our netcat pipe.

In previous examples, once the data reached the destination collection computer, the listening netcat process piped the output to the dd or dc3dd command output string, and the file was written exactly as it came across, as a bitstream image.

But by using ewfacquirestream, we can create EWF files instead of a bitstream image. We simply pipe the output stream from netcat to ewfacquirestream. If we do not wish to have the program use default values, then we issue the command with options that define how we want the image made (sectors, hash algorithms, error handling, etc.) and what information we want stored. The command on the subject machine remains the same. The command on the collection system would look something like this (utilizing many of the command defaults):

This command takes the output from netcat (nc) and pipes it to ewfacquirestream.

No extension is given, and ewfacquirestream automatically appends an E0* extension to the resulting file. To get a complete list of options, look at the man pages, or run the command with the -h option.

Back on the subject system we use our standard “send the data across the wire from a subject computer” command…

Once the acquisition completes (you’ll need to stop the ewfacquirestream process on the collection system when the dd command completes on the subject system - again you will know when you see the dd input/output message on the subject side), you can look at the resulting files, and compare the hashes. Since we used sha1sum previously, we’ll re-run with md5sum so we can compare the hash against the ewfverify output (which uses MD5):

…​compare the md5sum output from /dev/sda on the subject computer and the end of the ewfverify output and we see our verification is successful.

Another useful technique while imaging is compression. Considering our concern for forensic application here, we will be sure to manage our compression technique so that we can verify our hashes without having to decompress and write our images out before checking them.

For this exercise, we’ll use the GNU gzip utility. gzip is a command line utility that allows us some fairly granular control over the compression process. There are other compression utilities (lzip, xz, etc.), but we’ll concentrate on gzip for the same reasons we learned dd and vi…​almost always available, and fine starting place to learn the foundations of command line concepts. Most source packages for software are minimally available in a gz compressed format, but you should explore other compression options on your own.

First, for the sake of familiarity, let’s look at the simple use of gzip on a single file and explore some of the options at our disposal. I have created a directory called testcomp and I’ve copied the image file NTFS_Pract_2017.raw (from our ewfexport exercise in the section on libewf) into that directory to practice on. Copying the image file into an empty directory gives me an uncluttered place to experiment. You can use any file you want to practice this particular section on. First, let’s double check the hash of the image:

Now, in its most simple form, we can call gzip and simply provide the name of the file we want compressed. This will replace the original file with a compressed file that has a .gz suffix appended.

So now we see that we have replaced our original 500M file with a 61M file that has a .gz extension. To decompress the resulting .gz file:

We’ve decompressed the file and replaced the .gz file with the original image. A check of the hash shows that all is in order.

Suppose we would like to compress a file but leave the original intact. We can use the gzip command with the -c option. This writes to standard output instead of a replacement file. When using this option we need to redirect the output to a filename of our choosing so that the compressed file is not simply streamed to our terminal. Here is a sample session using this technique:

In the above output, we see that the first directory listing shows the single image file. We then compress using gzip -c which writes to standard output. We redirect that output to a new file (name of our choice). The second listing shows that the original file remains, and the compressed file is created. We then use gzip -cd to decompress the file, redirecting the output to a new file and this time preserving the compressed file.

These are very basic options for the use of gzip. The reason we learn the -c option is to allow us to decompress a file and pipe the output to a hash algorithm. In a more practical sense, this allows us to create a compressed image and check the hash of that image without writing the file twice.

If we go back to a single image file in our directory, we can see this in action. Remove all the files we just created (using the rm command) and leave the single original dd image. Now we will create a single compressed file from that original image and then check the hash of the compressed file to ensure it’s validity:

First we see that we have the correct hash. Then we compress the image with a simple gzip command that replaces the original file. Now, all we want to do next is check the hash of our compressed image without having to write out a new image. We do this by using gzip -c (to standard out) -d (decompress), passing the name of our compressed file but piping the output to our hash algorithm (in this case sha1sum). The result shows the correct hash of the output stream, where the output stream is signified by the -.

Okay, so now that we have a basic grasp of using gzip to compress, decompress, and verify hashes, let’s put it to work “on the fly” using dd to create a compressed image. We will then check the compressed image’s hash value against an original hash.

Find a small thumb drive or other removable media to image. I’ll be using a small 16GB USB stick. Clear out the testcomp directory - or create a new directory - so that we have a clean place to write our image to (or where ever you have the space to write).

Obtaining a compressed dd image on the fly is simply a matter of streaming our dd output through a pipe to the gzip command and redirecting that output to a file. Our resulting image’s hash can then be checked using the same method we used above. Consider the following session. The physical device we have as an example in this case is /dev/sdc (if you are using a device to follow along, remember to use lsscsi or lsblk to find the correct device file).

In the above dd command there is no “output file” specified, just as when we piped the output to netcat in our “over the wire” section. The output is simply piped straight to gzip for redirection into a new file. We then follow up with our integrity check by decompressing the file to standard output and hashing the stream. The hashes match, so we can see that we used dd to acquire a compressed image (6.8G compressed image vs. the 16G device), and verified our acquisition without the need to decompress (and write to disk) first.

Now let’s go one step further in our on the fly compression demonstration. How about putting a few of these steps altogether? Recall our imaging over the network through
netcat. If you look at the different sizes of our compressed vs. un-compressed images, you’ll see there’s quite a difference in size (which will, of course, depend on the compress-ability of the data on the volume being imaged). Do you think it might be faster to compress data before sending over the network? Let’s find out.

Going back to our simple network setup, let’s do the same imaging, but this time we’ll pipe to gzip -c on one side of the network and gzip -cd on the other, effectively sending compressed data across the wire. The resulting image is NOT compressed. We decompress it before it reaches the imaging tool. You can elect to leave that out if you like and simply write a compressed image.

We’ll start by hashing the subject hard drive again from our boot disk. Assuming the network settings are all correct, and then opening our netcat listener and dc3dd process on the collection box:

Open the listening process, redirecting the output to a file. I’m using dc3dd with hof= to collect input and output hash to compare with the SHA1 hash above.

When you hit enter, you can see dc3dd is waiting for input from the pipe.

And now start the imaging on the subject computer:

When the imaging is complete, we can check the resulting dc3dd log, netCompress.log, to verify the integrity of the resulting image:

A couple of things to notice here. First, our hashes match. We successfully read a device, compressed the data, piped it over a network, decompressed the data and wrote an image file. The reason we do this is to save some time. You can test this yourself, imaging over a network and timing the entire process with and without compression.

Keep in mind that the usefulness of this is dependent on where your particular bottlenecks are. On a local network, via crossover cable, and writing to a USB drive, compressing across the network may have little impact. But if you are imaging over an enterprise network, or remotely, you may see quite a performance gain from compression. Your results may vary, but be aware of the technique.

The first step in all this is to determine what volumes and file systems are available for logical mounting within our image. “Structure”, in this case, refers to the partitioning scheme and identification of volumes and file systems within the image.

Given that our images have been of physical disks, they should all likely have some sort of partition table in them. We can detect this partition table using fdisk or gdisk. We will cover more “forensically” oriented software for this later (mmls from the Sleuth Kit), but for now, fdisk and gdisk should be available on any modern Linux system.

We will cover fdisk first, as it was previously discussed, earlier using the -l option. We can get the partition information on /dev/sda, for example, with:

So the output of fdisk shows that the partition label is of type GPT. What if we run the gdisk command on the same disk? Here’s the output:

The important takeaway here is that the output of the two is functionally the same. When recording the output of these commands for a forensic examination, however, I would urge you to utilize the tool specifically designed for the system you are currently dealing with. Use fdisk for DOS partition schemes, and gdisk for GPT partition schemes when recording your output. Our output above shows that /dev/sda has four partitions. Partitions 1 and 3 are of type “Linux”, and partition two is identified as a Linux swap partition (roughly virtual memory or “swap file” for the Linux OS). The last partition is "Microsoft basic data", normally the code for a volume containing an NTFS file system.

It is especially important to note that the file system code and name do not necessarily identify the actual file system on that volume. In our example above, the file systems could be ext2, ext3, ext4, reiserfs, etc.

Recording the output for an examination is a simple matter of redirecting the output of either command (fdisk or gdisk) to a file. Using gdisk as an example (assuming a GPT layout):

A couple of things to note here: The name of the output file (sda.gdisk.txt) is completely arbitrary. There are no rules for extensions. Name the file anything you want. I would suggest you stick to a convention and make it descriptive. Also note that since we identified an explicit path for the file name, sda.gdisk.txt will be created in /mnt/evidence. Had we not given the path, the file would be created in the current directory (/root, as indicated by the tilde character in the command propmt [shorthand for the currently logged in user’s home directory]).

Once you have determined the partition layout of the disk, it’s time to see if we can identify the file system and mount the volumes to review the contents.

Before we jump straight to mounting a volume for analysis or review, you might want to identify the file system contained in that volume. There are a number of ways to do this. The mount command is actually very good at identifying file systems when mounting, so giving a -t <fstype> option is not always needed (and is often not used). But it is still good practice to check and record the file system prior to mounting, assuming you will be doing a manual review of the logical volume contents.

For a simple file system example, download the following file, and check the hash:

We can use the file command to give us an idea of what is contained in the image. Remember that the output of file is dependent on the magic files for your given Linux distribution. Running the file command on the current system gives this:

There’s a lot of information provided in the file output. We get the IDs, number of sectors (this is read from meta data, not from the image size itself), serial number, and other identifiers. We’ll cover images with separate partitions in a moment. This is a simple image of a file system that is not part of multi-partition media. You may see images like this where USB thumb drives or other removable media have been imaged and contain a single un-partitioned volume.

A quick word on using the file command directly on devices. The file command will provide a response on exactly the object you reference. If I run file on /dev/sda, for example, I get notified that it is a block special file. If you want to know more about the device rather than the device file, then use the -s option to file to specify that we want to know about the volume being referenced by the /dev block device. Try this on your own system:

Running file -s ond /dev/sda gives us an indication that we have a boot partiiton with LILO installed (see bold in the output), along with a summary of the partition table. Following with the same command on the first partition (/dev/sda1), we see the output shows us we have an ext4 formatted volume.

Back to our file output on the fat_fs.raw image. So we know what file system we are dealing, now we need to mount the image as a device so we can see the contents. For that we can use a loop device.

We can mount the file system(s) within the image using the loop interface. In basic terms, the loop device can associate a regular file with a device node. Thisallows you to “mount” a file system within an image file (instead of a disk) to a mount point and browse the contents. In this way, the loop device acts as a proxy disk to serve up the file system as if it were on actual media.

For a simple file system image (where there are not multiple partitions in the image), we can use the same mount command and the same options as any other file system on a device, but this time we include the option loop to indicate that we want to use the loop device to mount the file system within the image file. Change to the directory where we placed fat_fs.raw, and type the following (skip the mkdir command if you already created this directory in our earlier section on mounting external file systems):

Recall that the -o specifices that we are passing options. In this case, the options are ro for "read-only" and loop to indicate that we want to associate the image with a loop device for mounting.

Now you can change to the /mnt/analysis directory and browse the image as if it were a mounted disk. Use the mount command by itself to double check the mounted options (we pipe it through grep here to isolate our mount point):

We introduced the findmnt --real command in our earlier section on mounting external file systems. Use it here to see the image is mounted on /mnt/analysis.