Hardware or software write blockers - which is more reliable?

Are hardware record blockers more reliable than software?

Foreword

Conducting forensic investigations in investigating information security incidents, conducting forensic examinations, and many other activities related to computer forensics require the maximum possible preservation of the integrity of the studied data. For this purpose, write blockers are used — programs or devices that do not allow writing anything onto the drive under study. The need to use such tools comes from both the requirements of procedural law (for example, the Code of Criminal Procedure of the Russian Federation) and various methodological and other recommendations, as well as from standards (for example, STO BR IBBS-1.3-2016). Some aspects of the functioning of record blockers will be discussed in this article.


One of the early recording hardware blockers (2002)

Introduction

Many computer forensic experts and lawyers share the opinion that hardware recording blockers are more reliable than software recording blockers; this judgment can still be found, directly or indirectly, in various publications ^{1 2 3} . In this article I will try to reveal the internal structure of the hardware and software write blockers, showing the various problems that exist in these products.

Principles of operation

Recording hardware blockers

All hardware record blockers can be divided into two groups depending on how they handle the commands received from the host:
')

• working on the basis of the white list;
• working on the blacklist.

The hardware write lock works on the whitelist basis when it blocks any command to the drive, if it is not included in the list of known safe commands (not making changes to the data stored on the drive). In this mode of operation, the write blocker will block all unknown commands, including those specific to the manufacturer (for example, for carrying out low-level diagnostics of the drive) and new (not yet implemented in the built-in program of the write blocker). Such a write lock can block new standardized secure commands by interpreting them as unknown.

The hardware write lock works on a blacklist basis when it blocks commands included in the list of known unsafe commands (making changes to the data stored on the drive or performing other dangerous actions), and allows any other commands to pass to the drive. In this mode of operation, the write lock will allow unknown (manufacturer-specific or new standardized) unsafe commands to the drive.

In addition, all hardware record blockers can be divided into two other groups, depending on the details of their implementation:

• working as a command translator;
• working as modules providing access to a block device.

The hardware write lock works as a command translator when it simply translates allowed commands received from the source interface by repeating them to the destination interface. For example, a simple SATA-to-USB write lock can receive SCSI commands from a USB interface (using the “SCSI transparent command set” command set for the “mass storage” class), and then for each allowed SCSI command make a SATA-request the controller via AHCI, redirecting any responses back to the host via the SCSI protocol.

A hardware write lock works as a module that provides access to a block device, when it contains a full-fledged general-purpose operating system, the connected drive is defined as a block device in this operating system, and read access to this block device is shared with the host through a special driver. Such a write lock with a USB connection to the host will identify the connected drive as a block device, and then use the USB gadget to emulate the USB drive using the specified block device as the data source for the emulated drive. In this configuration, the hardware write lock does not directly translate the commands received from the host to the address of the drive, it translates the commands received from the host into internal requests used to read data from the source block device. Thus, multiple read commands received from the host can be combined into one read request, resulting in a single read command being sent to the connected drive. In addition, the write blocker firmware can perform read-ahead in the cache, which leads to the fact that one read command received from the host may not immediately send the corresponding read command to the connected drive, since the requested data is already have been read and added to the cache by the firmware.

In addition, recording hardware blockers can provide special functions for some typical and non-typical applications:

• work in the "read-write";
• permission to write commands, saving modified data on another drive;
• the representation of the drive to the host with a write protection mark (this adds another level of protection, since it is expected that the operating system will not write to the drive with a write protection mark);
• hiding write errors;
• Providing access to data areas hidden by HPA or DCO;
• Allowing some unsafe commands used to open access to hidden data areas (remove DCO or permanently remove HPA);
• transparent reading of data from bad (damaged) sectors of a drive; transparent work with defective drives.

Software write blockers

The implementation details of the software write blockers depend on the operating system used. On real-world operating systems such as DOS, software write blockers intercept a BIOS 0x13 interrupt, used to read and write disk data, filter write requests and call the original interrupt handler for read requests. Modern operating systems like Windows and GNU / Linux use direct access drivers to interact with drives, the BIOS 0x13 interrupt is used by the bootloader to read the kernel and other data (such as direct access drivers) only at an early stage of loading. Thus, there are many ways to implement the write lock functionality, for example:

• a driver that operates in read-only mode for a specific class of drives (PATA, SATA, SCSI, USB, etc.);
• a program (driver) that filters write requests on their way to the driver of a certain class of lower-level drives;
• a driver providing a block device in read-only mode for a selected drive or partition, with a parallel device in the operating system of a block device in read-write mode for the same drive or partition (it is assumed that the use of different programs will be applied to block device in read-only mode).

Depending on the implementation, software record blockers can analyze or block the following types of requests:

• read, write, reset the cache and other requests in a unified format specific to the operating system (which is not based on the low-level interaction protocol with the drive);
• requests in a format based on the protocol used to interact with the drive (for example, SCSI), or which directly implements this protocol.

In addition, a software write blocker can represent the drive to the operating system with a read-only mark.

In modern operating systems, the following write lock implementations were encountered:

Windows:

• Installing a filter driver for packets with I / O requests that are used to send SCSI commands to a low-level port driver driver (the operating system uses the SCSI protocol to communicate with the port driver drivers, the request packets are translated, if necessary, to the protocol used specific equipment).

Linux:

• installing a “loop” device in “read only” mode for a block drive device (or partition), in this situation the “loop” device driver filters write requests to the main block device (the kernel uses its own structure to describe requests to the drive for reading, writing, flushing the cache, etc.), it is supposed to use the device - the “loop” for data access;
• kernel patching to filter write requests sent to the block device in read-only mode.

When working with queries formed on the basis of the native protocol (such as SCSI in Windows), the software write blocker can work with black and white lists, as was shown earlier.

In general, software record blockers should intercept requests either at one point (for example, before sending a request to one of many storage drivers), or in all places at once (for example, in all storage drivers).

It should be noted that the software write blocker cannot block all possible ways of transmitting an unsafe command to the drive. For example, the kernel may provide an interface for sending “raw” requests to the drive (such as the SG_IO interface on Linux), or the driver driver architecture may allow any driver to send a request to bypass the filter driver (as in Windows), or the low-level driver can send unsafe commands, or any program can simply disable the write lock. And although you can take some measures against these shortcomings, the idea is simple - there is always a way around the software write blocker.

Software quasi blockers

It is possible to create an operating system that does not send unsafe commands to connected drives during and after booting, except when the user explicitly runs a program that sends unsafe requests. In this case, there is no component that blocks the recording, but there are no commands to be blocked (and such operating systems are often referred to as containing the recording blocking mechanism, therefore the term “quasi” is used in this section)

Unfortunately, some products are described as containing a software blocker, but in reality there is no such blocker, and depending on various circumstances, such a product can send unsafe commands to a connected drive.

Comparison of hardware recording blockers with software

The following important differences between hardware and software write blockers can be noted:

• Hardware write blockers make the gap between the host and the drive, as a result, unsafe commands from the host are subject to blocking regardless of their origin. Software write blockers can be circumvented by malware, as shown earlier.
  
  
• Software write blockers for direct access drivers are inactive during the early boot phase: there is no write lock when the bootloader uses a BIOS 0x13 interrupt or EFI services to load the kernel and other components of a modern operating system. At the same time, the hardware write blockers do not process any commands until the completion of their initialization.

It is believed that software write blockers cannot be reliable because they depend on a fragile software environment: for example, updating the operating system, or updating the driver, or an error (in hardware or software) can interfere with the write-lock mechanism; hardware recording blockers, on the other hand, are considered reliable because they contain stable, well-tested hardware and firmware ⁴ .

Forensic Validation

Software quasi blockers

SUMURI PALADIN 4.01

PALADIN is a distribution-free distribution (based on Linux), designed to load the computer under study for the purpose of previewing or collecting data. In addition, this distribution can be used on a forensic workstation as a ready-made operating system.

According to the documentation available in PALADIN 4.01 , PALADIN has been modified to protect against the recording of all connected drives after the start of the boot ( “PALADIN has been changed to boot” ). However, this version does not contain any component that blocks the recording; The following facts were also recorded on the connected drives during the distribution boot (this and the following sections do not contain an exhaustive list of problems (flaws) detected, only some specific problems are indicated; for the same reason, similar problems in other forensic products based on Debian, Ubuntu and other distributions are not listed):

• if a connected drive contains a dirty (not properly unmounted) Ext3 / 4 file system, then this file system is restored using its log;
• if the attached drive contains a dirty NTFS file system, then the log ($ LogFile) of this file system is cleared.

These problems are related to the early stage of loading non-installation distributions based on Ubuntu or Debian, when programs in the initial RAM file system are started to find the bootable drive by mounting the file systems on each drive (including the objects of study) and search for certain signatures in these file systems (such as a file containing a specific UUID). These actions are necessary to complete the transition from the BIOS 0x13 interrupt or EFI services used by the bootloader to the direct access drivers used by the kernel to read from the boot drive.

Although such problems are present in this and other versions of PALADIN, this distribution has been validated by NIST without any comments on these issues ⁵ .

Software write blockers

SUMURI PALADIN 6.01

PALADIN 6.01 includes a kernel component (Linux) for blocking a record, which was tacitly included without any mention in the documentation or in the change log. This component was secretly excluded from later versions of this distribution (for example, PALADIN 6.07).

During validation, the following error was detected in the write lock implementation: at an early stage of loading, when programs are started from the startup file system, the write lock component blocks requests for writing and release (discard) addressed to all block devices with the highest number 8 (and only) . In such an implementation, only PATA / SATA / SCSI / USB drives are write-protected at the specified download stage, at the same time, for example, the media in card readers (MMC) are not write-protected, and therefore subject to the problem points mentioned earlier.

Recording hardware blockers

Forensic duplicator Tableau TD3

The forensic duplicator of the Tableau TD3 (software version: 2.0.0) can be used as a network write blocker that allows access to the connected test drive via iSCSI protocol. The iSCSI driver blocks write requests addressed to the drive under study, and there is no write blocking component in the kernel (Linux) or in the hardware. It was found that connecting the drive with the Ext4 file system, in the log of which an I / O error was detected, causes the duplicator to send several write commands (modifying the file system) through the “write-locked” port, because the operating system used by the duplicator (Linux-based ) automatically mounts file systems on a drive connected via a “write-locked” port.

Forensic Bridge Tableau T356789iu

The forensic bridge Tableau T356789iu (software version: 1.3.0) blocks attempts by the host to read the sectors adjacent to the bad ones. It was discovered that one bad sector on a connected drive leads to the fact that 128 bad sectors cannot be read by the host, ostensibly due to a read error. It has been established that the forensic bridge uses the kernel proactive reading and cache caching (Linux) functionality when reading data from a connected drive (the kernel can read and send the contents of the sectors to the cache before it is requested by the program, read requests are processed through the cache), and the kernel It has a poor “shredding” of errors (it does not re-read individual sectors within a large cached block after reading errors of this block).

Forensic Bridge Tableau T35es

According to information from Guidance Software ⁶ , the forensic bridges of Tableau T35es with the old software version allowed the transmission of SCSI commands WRITE (16) received from the host via a USB connection to the connected drive. This problem is an example of the lack of work on the blacklist.

Forensic Bridge Tableau T8-R2

According to information from Guidance Software ⁷ , the forensic bridges of the Tableau T8-R2 with the old software version were sent to the connected drive write commands, being connected to the host via a USB connection, under unspecified circumstances. No details were provided, except that the recorded data is random.

findings

One can quite definitely say that the hardware write blockers are not more reliable than software ones, in each of them there may be critical problems (especially in situations where the hardware record lock contains a complete general-purpose operating system). But this answer cannot be considered satisfactory for the forensic community, since it does not give us a way to solve the problem.

In my opinion, you need to consider and implement the following:

• the community needs improved methodologies and validation methods for specialized software;
• these methods should cover all typical applications of specialized software;
• these methods should not rely solely on black box testing;
• developers of specialized software should not hide the problems confirmed by them, as well as covertly correct errors.

Why do we need improved methodologies and validation methods for specialized software?

The answer is simple: current methodologies and methods do not meet current community requirements.

Methodologies and methods for testing software write blockers published by NIST ^{8 9} do not affect the write-blocking mechanisms in Linux-based operating systems, nor do they affect other problems existing in Windows and Linux-based distribution kits that do not require installation (such as automatic execution of code from examinations at boot time from a USB drive by selecting the drive to be examined as a boot drive or using the file system on the drive being examined as containing an update, use automatically to the downloadable software environment).

The testing methodology and related documents for hardware record blockers published by NIST ^{10 11} do not focus on the situation in which the hardware record blocker independently writes to the connected drive without the appropriate command from the host. Problems with the "crushing" of errors are also not affected by these documents. In general, the hardware test blocker test methods mentioned earlier imply that the hardware write blocker is a command translator.

Why do we need methods covering all typical applications?

Because typical applications of specialized software are broader than a typical attempt at validation.

For example, NIST did not fix problems with data modification in PALADIN 4.0, because the tests performed did not include “dirty” file systems. However, “dirty” file systems are a common situation during forensic investigations (for example, after turning off a computer by interrupting the power supply).

In two recent reports published by NIST ^{12 13} , it is written that some installation-free distributions were tested in conjunction with hardware recording blockers, but typical cases of using such distributions include copying data without a hardware recording blocker (for example, when a drive cannot be removed from a computer or it cannot be connected to a hardware write lock). Obviously, the results in these reports cannot be extrapolated to copy data without a hardware record blocker.

Why do we need methods that do not rely solely on black box testing?

Because the number of typical cases of use exceeds the real possibilities.

File systems contain various flags that can be set or cleared in superblocks or other similar structures, a journaling file system can be used without a log, etc. File systems can be written on hard disk drives, flash drives and other types information carriers, and operating systems may behave differently depending on that. It is not possible to take into account all possible states of the file system (and, therefore, all possible execution paths that may lead to sending write requests).

Given this fact, it is more realistic to identify weak points using the white box approach, and then develop test kits for the black box.

Why do we want developers to disclose the problems they have confirmed and the bug fixes they have implemented?

Of course, changing the data on the objects of research does not automatically lead to the recognition of such evidence as inadmissible. For example, copying information from mobile devices and working systems implies making changes to the data on the original drive in order to gain access to the same data. But such methods of copying cannot serve as an excuse for changes made by means from which it is not expected (although even such changes do not yet make the evidence unacceptable in all cases).

Depending on the requirements of the legislation, the person conducting the study may be interested in obtaining information about what changes to the data on the object of research, if any, are made by the chosen means, what are the causes and conditions of such behavior and how does all this affect evidence in every situation. Without information from developers (such as detailed change logs for each problem with forensic accuracy) such requirements cannot be fully satisfied.

Links

1. Nikkel B. Practical forensic imaging. 2016
2. Morton T. Introduction to Digital Forensics. 2011
3. Al Falayleh M. and Al-Karaki J. On the Selection of Blockers for Disk Acquisition: A Comparative Practical Study. 2013
4. Menz M. and Bress S. The Fallacy of Software Protection in Computer Forensics. 2004.
5. NIST. Test Results for Digital Data Acquisition Tool: Paladin 4.0. 2014
6. Guidance Software. Tableau Firmware Update: TFU v6.80. 2010
7. Guidance Software. Tableau Firmware Update: TFU v6.84. 2011
8. NIST. Software Write Block Tool Specification & Test Plan. 2003
9. NIST. ACES Test Suite User's Guide. 2008
10. NIST. Hardware Write Blocker (HWB) Assertions and Test Plan. 2005.
11. NIST. Hardware Write Blocker Device (HWB) Specification. 2004.
12. NIST. Test Results for Disk Imaging Tool: Paladin v6.09. 2016
13. NIST. Test Results for Disk Imaging Tool: Paladin v6.08. 2016