MSc System and Network Engineering

Computer Crime & Forensics

A Framework for Testing Hardware USBWrite Blockers

Authors:Tom Curran

Frank UijtewaalMarch 30, 2016

Abstract

The aim of this research is to assess the possibility of implementing a testing framework forhardware USB write blockers that is both easier and more affordable for the forensic community.

Using the NIST Hardware Write Blocker Specification, Assertions and Test Plan documentsas a foundation, we outline prominent components in a test framework and discuss how theymight be realistically implemented in an automated fashion.

Using open source tooling, namely USBProxy, we prove that write blocking functionalitycan indeed be tested without paying prohibitively high fees. We conclude that implementingan automated hardware USB write blocking test at low-cost is possible, but requires a lot ofwork. The most significant barriers being the lack of development in open source USB protocolanalysers and absent of software libraries supporting automated usbmon packet inspection.

Contents

1 Introduction 21.1 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Related Work 3

3 Background 53.1 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Connecting a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.2 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.3 Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.4 USB Mass Storage Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Hardware Write Blockers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Building the Framework 84.1 Validation Test Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.1.1 Categorising Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.1.2 Developing Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.1.3 Performing the Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.4 Publishing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.2 Commands to Be Tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2.1 USB Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2.2 SCSI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.3 Techniques for Verifying Commands . . . . . . . . . . . . . . . . . . . . . . . . . 104.3.1 Verification Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3.2 Securing Commands as they Enter and Exit the HWB . . . . . . . . . . . 104.3.3 usbmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3.4 USBProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5 Experiments 125.1 Proof of concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6 Discussion 146.1 Thoughts on the Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . . 146.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7 Conclusion 16

Appendices 17

A NIST HWB Specifications 18A.1 Command Operation Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . 18A.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18A.3 Test Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19A.4 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

B SCSI commands 20

1

1. Introduction

Write blockers are an essential tool when conducting forensic investigations in order to preservethe integrity of digital artifacts and ensuring they can stand as evidence in the courtroom.

A number of hardware write blockers (HWB) exist with prices ranging anywhere from e30to over e1000. Recent open-source alternatives have made it possible for groups with modestbudgets to assemble their own HWBs using hobby computing devices such as the BeagleBoneBlack [10]. The variation in price and hardware implementation of write blockers raises thequestion of their relative performance and whether or not they properly perform what they claim.

Investigators currently lack tooling that provides a standardised platform for testing theefficacy of hardware write blockers. This has lead to the practice of opting for devices consideredto be “industry standards”. Though these devices have undergone some form of validationprocedure, current testing approaches require too much time and resources to be conducted on aregular basis by multiple parties.

How can we take a hardware write blocker produced by an unknown manufacturer and verifyits functionality? The theory behind write blocking is easy to grasp; preventing alterations tothe attached device while allowing all data to be retrieved. In practice however, the situationis more complex, as there are many different commands which can be sent to a storage devicefrom a variety of different components in the host computer. We wish to ensure a HWB preventsalterations under all circumstances.

1.1 Research Question

How does one create a framework that automates the process of validating hardware USB writeblocker?To answer this, we will address the following sub-questions:

• Which USB commands should a write blocker target specifically?

• How should the ideal write blocker handle these target commands?

• Can a test procedure be implemented using open source tooling?

1.2 Structure

The remainder of this paper is structured as follows. In the next chapter we discuss related workon tests for hardware USB write blockers. In Chapter 3, we provide a brief overview of USB andhardware write blockers. In Chapter 4 we build the test framework, highlighting considerations foreach stage and close with techniques that can be used to actually implement the test. Chapter 5contains details of our experiment design and a discussion of the results, discussing the challengesencountered during our research and suggesting avenues for future work. Finally in Chapter 7we summarise our research and conclude our findings.

2

2. Related Work

Considering the importance of forensically sound tools when conducting computer crime investi-gations, literature on the subject of validating hardware write blockers is surprisingly scarce.

Practitioners working in the field will typically use write blockers that are seen as industrystandards and ave already passed through some form of validation procedure [2]. The logicthat someone tested a certain HWB model from a vendor successfully in the past and manypeople have used the same model in their investigations, therefore using the same model willalso be forensically sound is flawed. Updated protocol specifications, sporadic firmware upgradesfor existing HWBs (if at all), and infrequent device tests highlight the importance of forensicinvestigators being able to test their equipment regularly [8] [7].

The most comprehensive documentation on validating HWBs comes as part of the ComputerForensics Tool Testing (CFTT) project, developed by NIST [5]. In [5] NIST defines a specificationof requirements that HWBs using ATA, SCSI, USB, and Firewire interfaces should meet. Indoing so, they define a scope of assumptions under which a test should be made (e.g. onlytesting operations that are accessible via a storage devices interface functionality), categorisethe available commands, and develop a series of assertions that should be tested as part of adevice validation (See Appendix). Most interestingly, they group commands that do not directlybut could potentially cause modification to the device. This includes commands that may beundefined in the interface specifications (i.e. vendor-specific), change configurable parameters ofthe device, or are necessary pre-requisites for other modifying commands.

Following the release of the HWB specification in, NIST later released their the HardwareWrite Blocker (HWB) Assertions and Test Plan [6], which offers a foundational framework fromwhich to develop validation schemes. In this paper they formulate a number of test cases for eachassertion and the steps required to perform them. Fig 2.1 illustrates the methodology used toassess the tools. When a tool is to be tested, the methodology begins by acquiring the tool, witha review of the tool documentation. If this documentation is unavailable, the tool is analysed inorder to generate such documentation, leading to a list of features along with the requirementsfor these features and a test strategy.

The NIST approach is both rigorous and scientific, and results are verified by both vendorsand the testing organisation. However this strength is also a source of weakness, as the amount oftime and resources needed are likely to reduce the frequency and groups conducting the tests. Assuch, by the time test results may be made publicly available, the information could be outdatedor changes to the tool must be reflected in the testing strategy. The specifications and testassertions are still in draft form and were released in 2004 and 2005, respectively. Since then,there have been few updates to the progress of the project. Test support software is apparentlyin development.

3

Figure 2.1: NIST testing methodology.

4

3. Background

The aim of this chapter is to understand how a USB mass storage device communicates with ahost and how HWBs are typically implemented. First we provide a brief overview of the USBprotocol and USB mass storage devices. Then follows a general discussion on HWB methods.

3.1 USB

USB devices are ubiquitous. In recent years the use of USB mass storage devices using NANDflash storage have replaced magnetic media such as floppy discs, and optical media, such asCD/DVD, as the standard means for backup and file exchange.

A key factor contributing to its success over existing connectors prior to its introduction isits relative ease of use for the end user; offering plug and plug functionality without the need forprior knowledge of the board type, its speeds, or the drivers needed to get it running.

As USB itself is a very large topic, we focus on the level of depth necessary to understand ourresearch at hand. Many detailed explanations are available, such as [1] to [11]. And of course,the USB specifications [4], [3].

3.1.1 Connecting a DeviceA host (e.g. PC) discovers newly connected devices through a process of enumeration. Duringthis process, the host will determine the speeds a device is capable of communicating at, learnwhat capabilities the device possesses and what protocols should be used to communicate withit.

The communication flow between the host and the device takes place using endpoints and ahost learns about the capabilities of a device through its descriptors. Once the host knows whattype of device is connected, it can load the appropriate device driver and the device can be used.

3.1.2 EndpointsEndpoints are unidirectional communication pipes over which fragmented data packets are trans-ferred. In practice, addresses are assigned for endpoints by the host during an initial enumerationprocess, that are used to store and retrieve data. There are four types of endpoints: control, bulktransport, interrupt and isochronous.

All devices must have at least one control endpoint, EP0, that is used to determine the devicescapabilities and handle standard requests from the host e.g. setting or retrieving addresses,descriptors, statuses.

Transfers on control endpoints consist of up to three stages: setup, data (optional), and status.During the setup stage, a setup token and an eight byte request is sent to the device. This requestcontains information about the type of request and recipient, e.g. which device on the hub therequest is for, as well as parameters for the request. After a valid setup request is received, thedevice responds with an acknowledgement packet and, depending on the request may send therequested information to the host, followed by a zero length data packet as an acknowledgementof success.

5

Bulk transport endpoints are used to transfer large quantities of data efficiently, offering nolatency guarantees but the highest throughput on an idle bus. These are used extensively inmass storage devices.

Interrupt and isochronous endpoints are used for communicating with low-speed devices ortime-critical devices, such as keyboards and web cameras, and are not our main concern in thisproject.

3.1.3 DescriptorsDescriptors are structures used to describe devices and their capabilities, providing the host withinformation about the device such as its vendor ID, product ID, and device class. Essentially,they describe how to communicate to a device. For example, they’ll describe properties such aspower requirements, the number of interfaces, maximum packet size.

3.1.4 USB Mass Storage DevicesUSB flash drives store data to NAND flash chips and are presented as SCSI hard drives whenconnected to a computer, supporting a reduced SCSI instruction set appropriate for memory-baseddevices.

Unlike most USB devices which use control endpoints for all but data transfer, Mass storagedevices (MS) use control endpoints during the initial enumeration process and then use bulkendpoints for everything else i.e. command and data flow.

Communication over bulk endpoints consists of three phases:

• Command Block Wrapper (CBW)

• Data Transport (optional)

• Command Status Wrapper (CSW).

Commands are sent in a Command Block (CB) that is wrapped within a CBW. A CBW willbegin with the signature ”USBC”, a tag value to associate a CBW and its corresponding CSW,as well other information such as the length and direction of the transfer, and the actual CB.

Commands involving reading or writing data operate in the data transport phase, where datais broken up into packets and transferred.

A command terminates with a CSW, starting with the signature "USBS", the tag valueshared with its corresponding CBW, and a status byte that can be: pass (00), fail (01), or phaseerror (02).

3.2 Hardware Write Blockers

Write blockers come in two forms: software and hardware. Both aim to serve the same purpose,that is, to intercept and block any commands that could potentially alter the connected USBdrive. Software write blockers (necessarily) reside on the host system and can block operationsfor multiple interfaces, logically.

HWBs differ in that they use a two-segment bus to connect a host with a device. Eachsegment communicates with the connected host and device respectively and logic built-into theHWB intercepts commands as they pass through and selects a desired course of action.

Examples of actions HWBs can take [9]:

• The blocker forwards the command to the device.

6

• The blocker substitutes a different command, which is sent to the device.

• The blocker simulates the command without actually forwarding the command to the device(e.g. re-using information from previous requests such as size of the device).

• If a command is blocked, the blocker may return success or failure for the blocked operation.

In the most case a HWB will have a set of hard-coded commands that are allowed to passthrough, and block everything else. To avoid errors on the host, often a success status is returnedby the HWB even though the command was not processed. This is the case with the Wiebe TechUSB WriteBlocker that will seem, from the perspective of the OS, to permit data to written,however it will not appear when the device is removed and later reconnected.

7

4. Building the Framework

In this chapter we develop the framework for testing Hardware USB Writeblockers, taking intoconsideration our primary goal of making tests more accessible and (hopefully) routine part ofan investigators duties. We make a distinction between the methods and the techniques usedfor validation. The method refers to the test procedure and ensuring that it is both efficientand effective. The techniques refer to how certain steps within the method could implementedpractically and cost-effectively. We conclude this chapter with a generic outline of a validationsetup, which we later test as a proof of concept in Chapter X.

4.1 Validation Test Methodology

To develop a suitable framework for validating HWBs, we subdivide the problem into severalcomponents:

1. Categorising commands

2. Developing test cases

3. Performing the test

4. Publishing and validating results with peers

4.1.1 Categorising CommandsTesting the functionality of something requires first identifying possible scenario and determiningan expected course of action. In the context of HWB, we have a set of commands that mayor may not alter the data on the device. Regardless of which command is sent, it is a statedrequirement of the HWB [5], that data is not altered (See Appendix).

As mentioned earlier, NIST divide the command sets for the ATA and SCSI protocols in threecategories; read, modifying, and information. Though the command set for a protocol will changebetween releases (e.g. new commands introduced), it is often the case that many commandspersist across versions. Creating a database that enumerates the possible command space foreach of the ATA and SCSI protocols, categorises each command, and notes for which protocolsthey each apply is a crucial step in developing a test. An example of such a database is presentedin Appendix B.

4.1.2 Developing Test CasesTo validate a HWBs performance, one must identify test cases that determine its actions forcommands that could potentially alter data on a storage device. NIST present nine test cases(See Appendix) that comprehensively covers the required functionality expected from a device.Beyond the clear need to verify that modifying commands are blocked, it also tests to ensurethat information and read commands, such as querying the disk size, are handled correctly.

8

In developing the test cases a measure of success must be defined. In the case where we areevaluating the validity of a HWB, we are most concerned with ensuring that results are accurate,rather than the relative performance across devices. As such, success can be defined as a deviceconforming to its requirements and assertions, in spite of situations that should invalidate it.

4.1.3 Performing the TestIn order to reach as wide an audience as possible, the ease of use and overall costs should beas low as possible. Releasing the tool as a software automates the process of testing for users,saving them time, and maintaining structural consistency between tests which can be useful forcommunity repositories of previous test results. It also allows for updates to be made to thetesting software that extends it’s functionality and test cases as the protocols continue to evolve.In an ideal scenario, the testing software will be used by many investigators. To ensure that testscan be repeated by different users, it is important to create a hash of the test software itself aspart of the test procedure.

4.1.4 Publishing the ResultsPublishing the results from tests should be automatic, detailed and ideally shared to a publicdatabase. Doing so would allow users to not only compare their results for a certain device withother users, but also test setups. Through browsing the database, users could identify HWBs thatare both low-cost, but consistently deliver the required functionality. In doing so, investigatorscan make better informed decisions about the equipment they bring into their department and,perhaps, increase the availability of such devices.

To mitigate issues such as fraudulent test results, for whatever reason, users of the testsoftware can vouch to sign their test results cryptographically. Doing so places the investigator’sreputation on the line, to an extent, and increases the credibility of a report.

4.2 Commands to Be Tested

4.2.1 USB CommandsEven though USB mass storage devices usually communicate over SCSI, the lower USB layer isstill at play. If a HWB was just to block SCSI commands and subsequent communications thatit knows of, a simple USB bulk write transfer could ruin the storage device’s integrity. Therefore,simple USB write commands should be checked as well.

4.2.2 SCSI commandsThe SCSI-3 Block Command (SBC) set is quite large. This is partly due to the existence ofmany forms of write and read commands. In reality only a subset of of the SBC commands areimplemented by USB Mass Storage devices. Which commands are implemented depends both onwhat is considered “required” and what commands are usually available on the host. For example,the Write(10) command is the primary write command variant in use. Other variations, likeWrite(12) for example, are a lot less common in USB devices. In the end, the differences betweenthe variations are only minor as can be seen in [13, pp. 190, 194].

The same can be observed with HWBs: even though connected USB drives may implementmore then the primary commands, write blockers may not. This is not necessarily a problem. Ifthe HWB doesn’t support a specific command it may still simply reject the command. As long

9

as unsupported commands are rejected the command doesn’t reach the protected USB device(such a rejected command usually results in an “ILLEGAL REQUEST/INVALID COMMANDOPERATION CODE” [13, p. 46]).

Some commands in the SBC explicitly write and therefore modify the contents of storagedevices. Others explicitly read. Another set is meant for retrieving device information and yetanother group is not easily classified into one of the above. NIST has made such a classificationin their “HWB Assertions and Test Plan” [6]. This list can also be found in the appendix of thisdocument in table B.1.

4.3 Techniques for Verifying Commands

4.3.1 Verification ApproachesTo test whether a hardware write blocker performs correctly, one has roughly two options:

1. Take a hash of the mass storage device; Execute command; Take a hash again and comparethe hashes.

2. Execute a command and observe what happens on the bus between the HWB and the massstorage device.

The first approach is simpler to implement, but offers less control over what happens. Forexample, if a hash has changed after a command, does it mean that the write blocker just let itthrough? Or did it wrongfully substitute it with another modifying command? This can onlyreasonably be observed by looking at what happens between the write blocker and the USBdevice.

4.3.2 Securing Commands as they Enter and Exit the HWBIn order to see how a HWB handles the commands it receives, one has to know what commandsenter and exit from it. In a test setup the input commands are specifically created and thereforeknown. There’s no particular need to see the commands going over the USB into the HWB otherthan just as an extra verification. What is important is the USB between the HWB and device.

Professional USB protocol analysers are available that have been specifically built to interceptand scrutinise USB traffic. These would be ideal tools to observe a HWB’s behaviour. Thedownside of these tools is that they’re expensive and therefore not a feasible solution for buildinga HWB testing framework that is to be easily accessible to the community.

Consider figure 4.1. It depicts the four major components of the chain. The first componentis capable of sending a range of, predominantly, SCSI commands. As already explained, thecommands as seen on the USB could already be captured here for extra validation purposes. Thenext block, the Write Blocker, is expected to correctly handle all those commands that couldpossibly change the state of the mass storage device. The traffic between the Write Blocker andthe USB Mass Storage Device is sniffed on the USB bus. The implementation of this model isdiscussed in chapter 5, Experiments.

4.3.3 usbmonusbmon is a facility in the kernel that is used to collect USB I/O on the USB bus, similar to howtools such as texttttcpdump use packet sockets to capture network traces. usbmon records therequests that are made by peripheral-specific drivers to Host Controller Drivers.

10

Figure 4.1: High level overview of test setup.

usbmon’s primary output is in binary format. It can be read and interpreted by tools likeWireshark [18]. With mass storage devices, SCSI runs on top of USB and is therefore alsocaptured by usbmon. Wireshark understands most SCSI commands as well and is capable ofdissecting them, making this an effective tool chain for experimentation [17].

4.3.4 USBProxyThe “USBProxy” project [14] is an open-source implementation of a USB protocol analyserdesigned for use with a BeagleBone Black single-board computer (SBC). It has been designed forthe Beaglebone Black specifically because it has both USB client and host ports, which is not astandard amongst popular SBCs such as the Raspberry Pi.

As USB follows a client-host architecture, the Beaglebone must act as both a host and aclient in order to intercept the USB traffic between any two devices. Using the GadgetFS Linuxframework, virtual USB devices are created that can simulate endpoints to (from) which datacan be written (read).

Proxy interfaces listen on both ends of the USB connection, presenting an interface thatmimics the opposite end. A relaying thread runs in a continuous loop, polling both proxyinterfaces for data packets. If packets are found, they can be optionally passed through a seriesof filters, dropped, modified or logged to a PCAP file, before it is passed on to the destinationproxy.

USBProxy is an ideal solution to our problem as the necessary tooling is both cheap andreadily available. Some limitations arise in the stability of the software as it serves a smallcommunity and lacks a dedicated development team. Nevertheless, the tool is functional, and afundamental component in our HWB testing strategy.

11

5. Experiments

Chapter 4, Building the Framework discussed what aspects of a hardware write blocker need tobe tested and how one can do so. This chapter describes a proof of concept testing framework.

5.1 Proof of concept

The test setup is simple. A regular computer is used to send a SCSI Write(10) command towhat it understands is a directly connected USB device. This command is intercepted by thehardware write blocker. If it decides to forward the command, it sends it off on its host port.The command is then again intercepted by the the Beagle Bone Black, which runs USBProxy[14]. See figure 5.1 for the schematic overview.

Figure 5.1: Schematic overview of test setup.

During the test tcpdump is running on both the computer and the Beagle Bone Black, usingusbmon to listen in on the USB traffic. Capturing on both locations makes it easier to correlatethe Beaglebone’s capture with what is happening on the computer side of the system.

To test the complete chain, a Write(10) command is used as it is understood by all components.When executed, it should be picked up by tcpdump capturing the USB packets at the computer.As it should be blocked by the write blocker, it shouldn’t show up in the capture taken at theBeagle Bone. The write script, with the device’s address hardcoded for brevity, is shown in figure5.2.

We capture the packets at the HWB’s input side by running Wireshark on the host computer.As expected, the Write(10) command is visible in the computer’s capture. The relevant linesare shown in figure 5.3. The command consists of three phases of the BOT protocol: commandtransport, data transport and status transport. The last two packets, which represent the statustransport phase, show everything went fine.

Figure 5.3: SCSI Write(10) command observed when sent from a computer.

12

#!/usr/bin/python3

from pyscsi.pyscsi.scsi_device import SCSIDevicefrom pyscsi.pyscsi.scsi import SCSI

device = ’/dev/sdc’

sd = SCSIDevice(device)s = SCSI(sd, 512)r = s.write10(7653376, 1, (512*’x’).encode())

Figure 5.2: Simple python script for executing a SCSI Write(10) command.

To gather the USB traffic on the HWB’s output side, a remote tcpdump was run over ssh,piping the output back to an analysis machine for live dissection in Wireshark. Of course, toenable sniffing USB traffic the usbmon module was loaded on the BeagleBone. The complete sshcommand that was used is shown in figure 5.4.

ssh root@<ip-address-of-BBB> tcpdump -U -s0 -w - -i <usbmon#> | wireshark -k -i -

Figure 5.4: Command used for remote USB traffic acquisition using ssh.

In the BeagleBone’s capture, of which the relevant packets are depicted in Figure 5.5, thereis no sign of the write command. This shows that even though the write blocker reported noproblems and let the host think nothing is out of the ordinary, it actually just sinkholed thecommand and never forwarded it to the USB device.

Figure 5.5: SCSI Write(10) not being observed at the Beagle Bone Black.

13

6. Discussion

Chapter 5, Experiments showed it’s possible to create a low-cost and extendible USB HWBtesting tool. Sending SCSI commands can be done with only a few lines of Python code andthe traffic between the write blocker and a USB mass storage device can be intercepted usingUSBProxy on cheap hardware such as the Beagle Bone Black. As we only need a tap into theUSB, the USBProxy takes the place of a considerably more expensive professional USB protocolanalyser.

6.1 Thoughts on the Proof of Concept

Though it is possible to test devices using cheap hardware, there is a number of steps to be madebefore one could actually use the proposed framework on any relevant scale. For starters, it takesa human observer to verify that the HWB’s sniffed output is valid. This adds the factor of humanerror and adds extra labour. It could technically be done by a program, but unfortunately sucha program doesn’t exist nor were any usable libraries found to create one. Scapy, for example,doesn’t support the USB protocol [12]. So, although it is possible to build an application thatcan both send SCSI commands and interpret the results from a tap, it would take a considerableamount of time just to get the plumbing done.

Sending SCSI commands is easy to do with python-scsi. The library is written in a verymodular fashion and is easy to understand, making it no problem to add extra SCSI commandsif necessary.

6.2 Future Work

As mentioned in the 6 section, a great deal of further work must be done before a testingframework such as the one outlined in this paper can be implemented on any relevant scale. Themost significant factor being the quality of the USB protocol analyser and automation of packetinspection. In our experiment, the output was manually viewed using Wireshark. Ideally aneasy-to-use test tool would be available for quick implementation of new commands. Althoughno such library has been found, one may have success by looking at the source code of tools suchas Wireshark or vusb-analyzer [16].

As has been pointed out in the previous section, there’s a lot to be done automation-wise.The biggest issue is the automatic interpretation of usbmon’s output. The USBProxy project stillneeds a lot of work. The tool’s creator, Dominic Spill, admits that the software is in alpha [14].During testing it often crashed. This doesn’t raise hope that even in running condition the toolperforms properly. In our proof of concept this is not of great concern, but if the test frameworkwas to be put to use in a serious environment, it would really be improved by contributing to theUSBProxy project to make the software more stable.

Attempts on making open source USB protocol analysers are few and far between, possibly dueto the “limited” scope of use cases for the typical user. Yet, they are very useful and versatile toolswhich can be used for tasks such as reverse engineering USB-based protocols [15], or modifyingnetwork traffic [14]. The USBProxy project is functional, but buggy. As a concept, it has been

14

proven that such an analyser can be implemented using cheap hardware. Further refinementssimply require further work and attention from the community.

Another area that warrants future research is the automation of packet inspection. Anessential component to the automated test tool is to be able to inspect the intercepted packetsand make decisions based on its contents. Any significant time-savings to the testing process willbe made from automation of the entire process, especially the tedious task of inspecting packets.

15

7. Conclusion

The principle aim for this research was to determine whether it is possible to develop a testingframework for hardware USB write blockers in such a way that it is both easy and affordablefor the wider broader community. By doing so, it is hoped that the standards of tooling used byforensic investigators can be improved, and their use more widespread.

Existing test methodologies, such as NIST’s, are rigorous, but require large amounts oftime to be conducted and expensive tooling. The combination of these factors results in thesituation where very few HWBs are explicitly tested, with investigators instead gravitatingtowards “industry standards” that are frequently used and have, at some point in their history,been tested successfully by someone.

Using the NIST Hardware Write Blocker Specification and Test Assertion documents as abase, we go on to outline prominent components in the test framework, and how those mightrealistically be implemented in an automated fashion.

Following from the theoretical framework, we make use of currently available open sourcetooling, namely USBProxy, to prove that the write blocking functionality can indeed be testedwithout a prohibitively high costs.

With a feasible framework outlined and a successful test experiment, we conclude that im-plementing an automated hardware USB write blocking test software on low-cost hardware ispossible, though requires much attention from the wider community. The most significant barriersto its realisation includes the reliability of the only (to the best of the authors’ knowledge) opensource USB protocol analyser and the lack of libraries supporting automated usbmon packetinspection.

16

Appendices

17

A. NIST HWB Specifications

A.1 Command Operation Categories

• Modifying: Any operation that:

1. directly causes a modification

2. could potentially cause a modification

3. is a necessary pre-requisite for a modification

4. is undefined in the interface specifications

5. changes how the storage device is presented to the host

6. changes any of the storage device’s configurable parameters

• Read: Any operation that requests data which is stored at specific locations on a storagedevice’s medium and returns that data to the host. A read operation requests one or moreblocks of data from the storage device’s medium. Each block of data is specified by alocation on the medium and a length.

• Information: Any operation that requests data which is not stored on a storage device’smedium and returns that data to the host.

• Other Non-Modifying: Any operation not existing in any of the other operation cate-gories that requests the storage device to perform a non-destructive action.

A.2 Requirements

General HWB functions could be described as: a HWB should not allow modifying commandoperations to be transmitted to a storage device and should allow retrieval of all accessible dataon the storage device.

• HWB-RM-01 - A HWB shall not, after receiving an operation of any category from thehost nor at any time during its operation, transmit any modifying category operation to aprotected storage device.

• HWB-RM-02 - A HWB, after receiving a read category operation from the host, shallreturn the data requested by the read operation.

• HWB-RM-03 - A HWB, after receiving an information category operation from the host,shall return a response to the host that shall not modify any access-significant information.

• HWB-RM-04 - Any error condition reported by the storage device to the HWB shall bereported to the host.

18

A.3 Test Assertions

An assertion is a condition that must be tested to confirm conformance to a requirement.

• HWB-AM-01 - The HWB shall not transmit any modifying category operation to theprotected storage device.

• HWB-AM-02 - If the host sends a read category operation to the HWB and no error isreturned from the protected storage device to the HWB, then the data addressed by theoriginal read operation is returned to the host.

• HWB-AM-03 - If the host sends an information category operation to the HWB andif there is no error on the protected storage device, then any return access-significantinformation is returned to the host without modification.

• HWB-AM-04 - If the host sends an operation to the HWB and if the operation results inan unresolved error on the protected storage device, then the HWB shall return an errorstatus code to the host.

• HWB-AM-05 - The action that a HWB device takes for any commands not assigned tothe modifying, read, or information categories is defined by the vendor.

A.4 Test Cases

• HWB-01 - Identify commands blocked by the HWB.

• HWB-02 - Identify modifying commands blocked by the HWB.

• HWB-03 - Identify commands blocked by the HWB while attempting to modify a protecteddrive with forensic tools.

• HWB-04 - Attempt to modify a protected drive with forensic tools.

• HWB-05 - Identify read commands allowed by the HWB.

• HWB-06 - Identify read and information commands used by forensic tools and allowed bythe HWB.

• HWB-07 - Read a protected drive with forensic tools.

• HWB-08 - Identify access significant information unmodified by the HWB.

• HWB-09 - Determine if an error on the protected drive is returned to the host.

19

B. SCSI commands

Command Name Category Op Code

READ BUFFER R 3ChREAD DEFECT DATA (10) R 37hREAD DEFECT DATA (12) R B7hREAD LONG R 3EhREAD(10) R 28hREAD(12) R A8hREAD(6) R 08hXDREAD R 52hCOPY M 18hCOPY AND VERIFY M 3AhFORMAT UNIT M 04hREASSIGN BLOCKS M 07hREBUILD M 81hREGENERATE M 82hWRITE AND VERIFY M 2EhWRITE BUFFER M 3BhWRITE LONG M 3FhWRITE SAME M 41hWRITE(10) M 2AhWRITE(12) M AAhWRITE(6) M 0AhXDWRITE M 50hXDWRITE EXTENDED M 80hXPWRITE M 51hREAD CAPACITY I 25hCHANGE DEFINITION 40hCOMPARE 39hINQUIRY 12hLOCK-UNLOCK CACHE 36hLOG SELECT 4ChLOG SENSE 4DhMODE SELECT(10) 55hMODE SELECT(6) 15hMODE SENSE(10) 5AhMODE SENSE(6) 1AhMOVE MEDIUM A7hObsolete 32hObsolete 0BhObsolete 30hObsolete 01h

20

Obsolete 31hPERSISTENT RESERVE IN 5EhPERSISTENT RESERVE OUT 5FhPRE-FETCH 34hPREVENT-ALLOW MEDIUM REMOVAL 1EhREAD ELEMENT STATUS B4hRECEIVE DIAGNOSTIC RESULTS 1ChRELEASE (10) 57hRELEASE (6) 17hREPORT LUNS A0hREQUEST SENSE 03hRESERVE (10) 56hRESERVE (6) 16hSEEK(10) 2BhSEND DIAGNOSTIC 1DhSET LIMITS(10) 33hSET LIMITS(12) B3hSTART STOP UNIT 1BhSYNCHRONIZE CACHE 35hTEST UNIT READY 00hVERIFY 2Fh

Table B.1: TAble of SCSI-3 Block Commands with categorization: “W” (write),“R” (Read), “I” (Information) and no letter for miscellaneous. Source: [6, p. 26].

21

Bibliography

[1] Jan Axelson. USB Complete: The Developer’s Guide. 5th ed. Complete Guides series.Lakeview Research, 2015. isbn: 978-1931448284.

[2] Forensic Focus Blog. Validating Write Blockers. Jan. 23, 2008. url: http://forensicfocus.blogspot.nl/2008/01/validating-write-blockers.html.

[3] Hewlett-Packard Company et al. Universal Serial Bus 3.1 Specification. July 26, 2013.

[4] Compaq et al. Universal Serial Bus Specification. Revision 2.0. Version 2.0. Apr. 27, 2000.

[5] Hardware Write Blocker Device (HWB) Specification. May 19, 2004. url: http://www.cftt.nist.gov/HWB-v2-post-19-may-04.pdf.

[6] Hardware Write Blocker (HWB) Assertions and Test Plan. May 21, 2005. url: http://www.cftt.nist.gov/HWB-ATP-19.pdf.

[7] U.S. Department of Justice. Test Results for Hardware Write Block Device: T4 ForensicSCSI Bridge (USB Interface). Sept. 1, 2009. url: https://www.dhs.gov/sites/default/files/publications/HWB_T4_Forensic_SCSI_Bridge_USB_Interface_2009.pdf.

[8] U.S. Department of Justice. Test Results for Hardware Write Block Device: Tableau T8Forensic USB Bridge (USB Interface). Aug. 1, 2008. url: https://www.ncjrs.gov/pdffiles1/nij/223432.pdf.

[9] James Lyle. Disk Drive I/O Commands and Write Blocking. Jan. 1, 2012.

[10] Phil Polstra. UDeck. 2015. url: https://github.com/ppolstra/UDeck.

[11] Rajaram Regupathy. Bootstrap Yourself with Linux-USB Stack. 1st ed. 2012.

[12] Scapy. Quick demo : an interactive session. url: http://www.secdev.org/projects/scapy/demo.html (visited on 03/29/2016).

[13] Seagate. SCSI Commands Reference Manual. Version Rev. A. Feb. 14, 2006. url: http://www.seagate.com/staticfiles/support/disc/manuals/scsi/100293068a.pdf.

[14] Dominic Spill. USBProxy. url: https://github.com/dominicgs/USBProxy (visited on03/29/2016).

[15] Anthony Vallee-Dubois. Reverse engineering the Xbox One Controller. Aug. 6, 2015. url:http://www.definedbehavior.com/reverse-engineering-the-xbox-one-controller/(visited on 03/30/2016).

[16] VMware. the Virtual USB Analyzer. url: http://vusb-analyzer.sourceforge.net/(visited on 03/17/2016).

[17] wireshark wiki. Small Computer System Interface (SCSI). url: https://wiki.wireshark.org/Small_Computer_System_Interface (visited on 03/30/2016).

[18] wireshark wiki. USB capture setup. url: https://wiki.wireshark.org/CaptureSetup/USB (visited on 03/30/2016).

22