A few weeks ago, I purchased a 2GB USB 2.0 flash drive from Best Buy (Geek Squad®) for use in a demo to Computer Science students at Saint Louis University. As usual, I did not examine the packaging closely and realized only after opening the device that it was U3 enabled (which annoyed me at the time). I have spent several hours unraveling the details of these devices and share my findings below. This information is not complete and I encourage anyone reading this with more information, corrections and such to leave comments to further the analysis.

U3 Smart Drive overview and shortcomings

U3 smart drives are intended to allow an individual to carry their data with them and run programs on any Windows computer without leaving personal data behind (full details at U3’s site). However, the drives do not fully live up to their promise to “keep your data safe and secure” as remnants are left on host computers. There have been several write-ups of this shortcoming; try Battling Anti-Forensics: Beating the U3 Stick and The NOISY U3 Thumb Drive File Access behavior in Windows at SANS’ Forensic Weblog.

Initial (failed) brute-force removal

When I discovered the flash drive was U3 enabled, I wanted to remove the U3 software for a purer demonstration. So, I popped the drive into my Linux forensic workstation and did a simple wipe of the drive with:

dcfldd if=/dev/zero of=/dev/sdc

ran fdisk /dev/sdc and added a new NTFS partition and finally created the file system with mkfs.ntfs. Then I put the drive back into my Windows XP computer and to my annoyance, the U3 software auto-ran again and was as happy as could be.

Phase II (the path less traveled)

Since I had never dug deep into how USB mass storage devices identify themselves, I found myself a bit confused. I mean, I was on Linux, I had direct access to the block device and I wiped it with all 0s! How could this not work. There was a easy work around floating around the discussion boards: uninstall the U3 software using their uninstall software. But, I did not want the easy way since I wanted to better understand how it worked.

After some research on USB mass storage devices, I came to understand that the U3 drives are composite devices that present two distinct drives. Now this is self evident when you plug the flash drive into a Windows computer since both a new disk drive and a CD-ROM drive appear but I was not sure how it managed to do this.

USB device details

When a USB device is connected to a computer, the operating system enumerates the device and retrieves information critical for its setup and configuration. When I plugged the drive into Linux, it clearly found two distinct drives:

Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: Best Buy Model: Geek Squad Rev: 7.01
Type: Direct-Access ANSI SCSI revision: 02

Host: scsi3 Channel: 00 Id: 00 Lun: 01
Vendor: Best Buy Model: Geek Squad Rev: 7.01
Type: CD-ROM ANSI SCSI revision: 02

By taking a closer look at various log and configuration files, I could see a few additional details:

sd 3:0:0:0: Attached scsi removable disk sdc
sd 3:0:0:0: Attached scsi generic sg3 type 0
Vendor: Best Buy Model: Geek Squad Rev: 7.01
Type: Direct-Access ANSI SCSI revision: 00
SCSI device sdc: 3907711 512-byte hdwr sectors (2001 MB)

sr 3:0:0:1: Attached scsi CD-ROM sr1
sr 3:0:0:1: Attached scsi generic sg4 type 5
Vendor: Best Buy Model: Geek Squad Rev: 7.01
Type: CD-ROM ANSI SCSI revision: 00
sr1: scsi3-mmc drive: 48x/48x tray

Like any good forensic geek, I grabbed an image of the flash drive (/dev/sdc) with the following:

wintermute:/home/ahoog# dcfldd if=/dev/sdc of=/home/ahoog/slucs/sdc-img.dd conv=noerror,sync hashwindow=0 hashlog=/home/ahoog/slucs/sdc-img.md5 bs=512 hash=md

53907584 blocks (1908Mb) written.
3907711+0 records in
3907711+0 records out

It’s important to note that you must use a block size of 512 otherwise you will not get a clean bit-by-bit copy since the total sectors on this disk are 3,907,711 (from dmesg results above) and dcfldd has a default block size of 32kb (leaving you with padded zeros on the resulting image).

Next I wanted to grab an image of the CD-ROM (/dev/sr1) but had to specify the count otherwise dcfldd overran the drive size (I’m not sure why this happened):

wintermute:/home/ahoog# dcfldd if=/dev/sr1 of=/home/ahoog/slucs/sr1-img2.dd conv=noerror,sync hashwindow=0 hashlog=/home/ahoog/slucs/sr1-img.md5 bs=512 hash=md5 count=32736

32512 blocks (15Mb) written.
32736+0 records in
32736+0 records out

If you run file on the resulting image, you get:

wintermute:/home/ahoog# file /home/ahoog/slucs/sr1-img2.dd/home/ahoog/slucs/sr1-img2.dd: ISO 9660 CD-ROM filesystem data ‘U3 System’

and by looking at it in a hex editor, you see the first non-zero byte starting at 0×8000 (32,768 bytes or 63 512 byte sectors) and a reference to the program they used to create the iso9660 file system (Magic ISO v5.2).

But how does it know a disk drive from a CD-ROM?

I was still confused so I dug deeper into the USB standards.  By running:

wintermute:/home/ahoog# lsusb -v

and examining the output, I could see that the specific devices within the USB drive were defined at the interface level (not unusual for composite USB devices).

Bus 005 Device 005: ID 0781:554f SanDisk Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0781 SanDisk Corp.
  idProduct          0x554f
  bcdDevice            2.00
  iManufacturer           1 Best Buy
  iProduct                2 Geek Squad
  iSerial                 3 153563119AC07CAD
  bNumConfigurations      1

But at the interface level, I only saw 1 interface but 2 endpoints:

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

The endpoints, however, did not further specify the device type.  Reviewing the USB specification, I found that the following three interface settings unraveled the mystery:

bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)

The bInterfaceSubClass 6 tells the host to identify the device type by issuing a SCSI INQUIRY command, which will return a peripheral device type.  So, I looked at the full details of the device using:

wintermute:/home/ahoog# udevinfo -a -p $(udevinfo -q path -n /dev/sdc)

and I saw that CD-ROM portion of the USB device had a type of 5 while the disk portion had a type of 0.  Microsoft’s MSDN has a page that summarizes the identifiers for SCSI devices.  The output for udevinfo for the corresponding devices was:

DRIVE
-------------
 looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb5/5-8/5-8:1.0/host3/target3:0:0/3:0:0:0':
    KERNELS=="3:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{ioerr_cnt}=="0x0"
    ATTRS{iodone_cnt}=="0x120"
    ATTRS{iorequest_cnt}=="0x120"
    ATTRS{iocounterbits}=="32"
    ATTRS{timeout}=="30"
    ATTRS{state}=="running"
    ATTRS{rev}=="7.01"
    ATTRS{model}=="Geek Squad      "
    ATTRS{vendor}=="Best Buy"
    ATTRS{scsi_level}=="3"
    ATTRS{type}=="0"
    ATTRS{queue_type}=="none"
    ATTRS{queue_depth}=="1"
    ATTRS{device_blocked}=="0"
    ATTRS{max_sectors}=="240"

CDROM
-------------
  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb5/5-8/5-8:1.0/host3/target3:0:0/3:0:0:1':
    KERNELS=="3:0:0:1"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sr"
    ATTRS{ioerr_cnt}=="0x6"
    ATTRS{iodone_cnt}=="0x2f3"
    ATTRS{iorequest_cnt}=="0x2f3"
    ATTRS{iocounterbits}=="32"
    ATTRS{timeout}=="0"
    ATTRS{state}=="running"
    ATTRS{rev}=="7.01"
    ATTRS{model}=="Geek Squad      "
    ATTRS{vendor}=="Best Buy"
    ATTRS{scsi_level}=="3"
    ATTRS{type}=="5"
    ATTRS{queue_type}=="none"
    ATTRS{queue_depth}=="1"
    ATTRS{device_blocked}=="0"
    ATTRS{max_sectors}=="240"

Mystery solved

So, by designing the device as a composite USB device with 2 drives and specifying that the operating system must use the “SCSI transparent command set” to determine the device type, the U3 architects figured out a rather elegant have a single flash drive contain both a writable user partition and a read-only system/install partition.  This is similar to how the Apple iPhone implements their partitions except their read-only system partition is 300MB.

Further hacks

I still have some questions.  Ideally, I would like to figure out how to mount the read-only (~6MB) partition using standard Linux commands.  Since, at a block level, the CD-ROM is just a writable disk drive, I think instructing the OS to leave the “sd” driver instead of the “sr” driver would allow regular read-writes on those sectors.  To be certain, this is how the drive is created and updated.  There is a utility availabel called Universal Customizer that allow you to upload you our iso9660 file to the CD-ROM.  I have not tried to reverse engineer the utility however the u3dapi10.dll is bundled with the program and I suspect this library (from the U3 developer kit) allows access to directly write to the “CD-ROM” sectors.

Implications for computer forensics

There are several implications for the computer forensics world:

1. The CD-ROM section of a U3 device should probably be imaged and examined
2. A skillful technician would create a custom CD-ROM utility that required a certain password/keystroke upon inserting the drive otherwise it could erase the data contents or otherwise hide data.  Note, this would only work on computers running Windows with autorun enabled.  Such things have already been done to spread viruses or silently log data on a computer.
3. Develop a live response USB drive that would automate the collection of forensic data using trusted binaries and stored directly on the data portion of the drive.  There is a paper entitled “A Proof-of-Concept Project for Utilizing U3 Technology in Incident Response” with details of this.

There is certainly more to be done here but this post is long enough already.  I hope you find this information helpful and that you will share your thoughts, corrections or additional information in the comments section.

Logs and other analysis media

Below are links to log files and other files used in this analysis.

• USBSnoop log file from SANDisk U3 LPInstaller.exe re-install
• SanDisk U3 .iso file for Best Buy drive