Home » Research » Part 4: USB Device Research – The Testing Environment & Registry Artifacts for USB Devices at First Insert

Part 4: USB Device Research – The Testing Environment & Registry Artifacts for USB Devices at First Insert

In the previous posts I posited my research goals and introduced the three major USB transport protocols: MSC, PTP and MTP; as well as some basic information about each. Then, I discussed some of the basic concepts surrounding how Windows selects the most appropriate drivers for a newly inserted USB device. In this post as well as upcoming posts, I will be going over the findings of my research, including the testing environment and the procedures used in running the various tests. For this post, I will go over registry entry changes at first insert of a device comparing the different transport protocols for USB.

1.0 Testing Environment

In table 1.1.1, the details surrounding the testing environment are provided. For all tests performed, the virtualization software WMWare Workstation was used. Before running a test, baseline reports were captured, a test was run, and final reports were generated to capture the resulting changes within the operating system. Then, pertinent files were copied and cataloged. After collecting data, the virtual machine was reverted back to a clean snapshot to preserve consistency throughout future tests.

1.1 Additional Considerations

Due to limitations of virtualization software currently available for use, analysis could not be performed on USB 3.0 devices. Although USB 3.0 devices were used in testing, these devices were automatically downgraded to USB 2.0 by the virtualization software.

In addition, MTP and PTP device testing was conducted using a limited number and variety of devices, therefore, test results may not account for the range of capabilities that other devices support.

Table 1.1.1 Testing Environment: USB Transport Protocol Artifact Identification Research

2.0 Test 1: Registry Artifacts at First Insert

The purpose of this test is to identify a discernible pattern for how Windows classifies and installs different kinds of USB devices. This was accomplished by observing what registry entries are changed when a device is first inserted into a system. The hypothesis entering into this test was that Windows installs and selects drivers for devices primarily based on the transport protocol used by a device. The goal was see if the changes observed exhibited a consistent pattern per protocol, yet differed between each other for the three USB transport protocols, MSC, PTP, and MTP. Then, depending on the findings, determine if there may be additional factors to consider for how Windows classifies and installs USB devices.

2.1 Scenario 1: A Comparison of Protocols within Windows XP with SP 3

In table 2.1.1, the data represents the registry hives and their specific keys that displayed changes when a device was first inserted into a virtual machine running Windows XP with service pack 3.

A test was performed for each of the devices mentioned in table 1.1.1, and per protocol, it was apparent that Windows XP does categorize and install devices primarily based on the transport protocol used. Looking at the table and comparing the three protocols, there are significant differences for what registry entries are affected when a device is first inserted for a particular protocol.

You can download the registry files for the following devices tested:

XP_1-toshiba_canvio_1tb_usb30.zip
XP_2-seagate_bkplus_3tb_usb20.zip
XP_3-sandisk_cruzer_8gb_usb20.zip
XP_4-sandisk_cruzer_16gb_usb20.zip
XP_5-ipod_5thgen_30gb.zip
XP_6-htc_magic_android.zip
XP_7-ipad_1.zip
XP_8-ipad_2.zip
XP_9-iphone_4.zip
XP_10-sandisk_sansa_m240.zip
XP_11-samsung_galaxys3_android.zip
XP_12-blackberry_storm_9530.zip

Some items of particular interest that should be noted are as follows:

  1. From the table, we can see that there are only three registry entries common between the three protocols. All others are specific to a protocol.
  2. Due to limited commonality between protocols, forensic software that collects information from the registry and elsewhere to identify attached USB devices may not be incorporating all pertinent registry keys and therefore, may not account for a device in its reporting output. A forensic analyst would then have to manually go through the registry to identify whether or not additional devices were attached to a system and are of importance to an investigation.
  3. For PTP and MTP devices, there are no registry changes that occur in the NTUSER hive when a device is first inserted. This would make it difficult to identify which user was utilizing a particular device. However, it should be noted that although inserting a PTP or MTP device does not leave artifacts within the Windows XP NTUSER hive, other actions that a user performs related to a device of the aforementioned type will create user specific artifacts that can link a device to a specific user. Those items will be discussed later.

Windows7-USBChangesFirstInsert

 

 Table 2.1.1 Windows XP: A Protocol Comparison of USB Registry Changes at First Insert

2.2 Scenario 2: A Comparison of Protocols within Windows 7 Service Pack 1

In table 2.2.1, the data represents the registry hives and their specific keys that displayed changes when a device was first inserted into a virtual machine running Windows 7 with service pack 1.

You can download the registry files for the following devices tested:

Win7_1-wd_mypassport_500gb_usb20.zip
Win7_2-wd_mypassport_1tb_usb30.zip
Win7_3-toshiba_canvio_1tb_usb20.zip
Win7_4-toshiba_canvio_1tb_usb30.zip
Win7_5-seagate_bkplus_3tb_usb20.zip
Win7_6-sandisk_cruzer_8gb_usb20.zip
Win7_7-sandisk_cruzer_16gb_usb20.zip
Win7_8-adata_s102_8gb_usb30.zip
Win7_9-ipod_5thgen_30gb.zip
Win7_10-htc_magic_android.zip
Win7_11-ipad_2.zip
Win7_12-iphone_4.zip
Win7_13-sandisk_sansa_m240.zip
Win7_14-samsung_galaxys3_android.zip
Win7_15-samsung_galaxys4_android.zip
Win7_16-blackberry_storm_9530.zip

Analyzing the table, some items of particular interest that should be noted are as follows:

  1. Windows 7 appears to use two different factors in determining if a device should be installed with WPD support. If a device is installed with WPD support, the registry entries used to install and enumerate a device reflects this classification. The factors that Windows appears to use to determine WPD support are:
    1. The protocol used: PTP and MTP are automatically installed and enumerated as WPD supported. MSC devices are installed as mass storage class devices, some having WPD support, which is determined by the next factor.
    2. The state of the Removable Media Bit for MSC devices: For devices with the removable media bit turned on (Flash drives and other devices using MSC), Windows installs these devices with WPD support. External drives appear as “fixed” drives and have the removable media bit turned off. They are not installed and enumerated with WPD support. In the table 2.2.1, registry entries that incurred changes at first insert with the removable media bit turned on is marked as “RM” under the column “MSC”.
  2. As with Windows XP, Windows 7 does not provide artifacts in the NTUSER hive for PTP and MTP devices when a device is first inserted into a system, unless the device supports Device Stage.
  3. With the advent of Windows 7, a new feature was introduced called Device Stage.[1] Depending on manufacturer implementations, some USB devices are equipped to support Device Stage. Within Windows 7, the installation of those devices offer additional artifacts that can be of forensic importance. For example, within the NTUSER hive, an examiner can identify which user inserted a particular device. The entry that is generated in the NTUSER hive for Device Stage devices contains a value in the name “DDO” that can be linked back to the value name “ContainerID” in the SYSTEM hive registry key ENUM\USB specific to the device. In the table, registry entries for devices identified as supporting Device Stage are labeled DS under the MTP column.
  4. One final item of importance that should be noted is that for devices enumerated with WPD, Windows identifies what functions a device supports. Depending on the supported functions of a device, Windows uses different registry keys to install and enumerate the device. Due to the limited number of MTP and PTP devices tested, accounting for all possibilities was not possible. The functions a device supports can be extrapolated indirectly from what keys are utilized to enumerate the device, or directly by viewing the registry keys, subkeys and values in the SOFTWARE hive under Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\DeviceHandlers\ for the device in question.

Windows7-USBChangesFirstInsert

 2.2.1 Windows 7: A Protocol Comparison of USB Registry Changes at First Insert

You can download the tables shown in the previous sections in excel format here.

Coming Up…

In the next post I will go over the test results for directory traversal on MSC and MTP devices in Windows 7. The post will include shell bagMRU entry structures and a comparison of the differences between the two protocols.

Resources

[1] http://msdn.microsoft.com/en-us/windows/hardware/gg463154.aspx

commentscomments

  1. […] lunch, has written up more of her research into different USB attached devices and protocols. http://nicoleibrahim.com/part-4-usb-device-research-usb-first-insert-results/. It’s very thorough and worth a serious read and […]

  2. phocean says:

    Hi,

    and thanks for sharing this great research.
    Just curious of the tools that you used to build the baseline and then check the changes.
    Or did you use custom scripts ?

    • Nicole Ibrahim says:

      Hello,

      I mainly use RegShot as my tool of choice. It reports what was present before and after in keys that were either created, modified or deleted. It also includes in the reporting output a categorized list of file creations, deletions and modifications but does not identify what the contents of those files are/were. There is also another good tool that outputs similar reports, which is InCtrl5. Both are great tools. I’m more familiar with RegShot’s reports, which is why I use it more than InCtrl5. However, InCtrl5 provides some decoding of the registry key value data within the reporting output, while RegShot does not. Something else to keep in mind is OS compatibility. InCtrl5 supposedly is compatible with Windows 9x and higher, but I have not personally cross-checked its results in Windows Vista and up.

      Since I was running tests on Windows based operating systems, I chose not to use scripts as the tools were already available. However, scripts would be a nice option for Unix based operating systems. The basic “find” command would be a great start.

      - Nicole

Leave a Reply