Alcor UFD Controller Hacking update 2

In these days between some exercises for a microeconomics exam , i've continued to work on reverse engineering the Alcor 698x UFD microcontroller, and i've got another poor quality Alcor based flash drive from a friend , so now i've an 8 GB one , and a 4 GB one.

I've started , with the help of wireshark , usbmon and a virtual machine running windows with USB forwarding by SPICE , reverse engineering the format of the various vendor specific commands that are sent to the flash drive.

But while working on it i've encountered a serious problem , the Linux kernel scsi implementation removes the 3 MSBs from the 2nd byte of the SCSI commands , which in our case , breaks various commands , for example , 0x51 directed at LUN 0 , would become 0x11.

The interesting commands now are two: 0x82 and 0x81 , they are used to download and upload configurations to the flash drive.

The 0x81 command is used with that specific CDB

0x81 , 0x00 0xff , 0x00 , 0x00 , 0x00 , 0x00, 0x00 ,0x00 ,0x00 ,0x00 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00 

Then it takes 512 bytes of data that contains the actual configuration, below there's an example of that configuration:

Let's look at what i've found so far:

Going from the start of the file to the end

99 07 : This seems to be some sort of signature i have yet to find a flash drive that does not have it

10 : This is the vendor string length ( including zeroes , the length field itself and the type field )

26: This is the product string length ( including zeroes , the length field itself and the type field )

12 01 10 01 00 00 00 08: These bytes are still unknown , 12 could be the SCSI vendor string length , but still not tested

8F 05: This is the little endian representation of the VID ( Vendor ID ) that the usb device will show to the PC

87 63: This is the little endian representation of the PID ( Product ID ) that the usb device will show to the computer

05 01: These are the bcdDevice field of the usb descriptor

01:  Manufacter index ( not confirmed )

02: Product index , ( not confirmed )

00 01: Unknown

10: Again vendor string length

03: Descriptor type ( String)

10 03 48 00 61 00 63 00 6B 00 69 00 6E 00 67 00: Actual Vendor String

26: Product string length ( Again )

03: Descriptor type ( String )

50 00 52 00 4F 00 56 00 41 00 50 00 52 00 4F 00 44 00 4F 00 54 00 54 00 4F 00 50 00 52 00 4F 00 56 00 41 00: The actual product string

47 65 6E 65 72 69 63 20 46 6C 61 73 68 20 44 69 73 6B 20 20 20 20 20 20 38 2E 30 30: SCSI Identification string (Generic Flash Disk      8.00)

02: This byte is a checksum of the all bytes before it , if you set it incorrectly , the flash drive will refuse to use the settings, to calculate it , sum all bytes values ( unsigned ) , and then do &0xFF to use only the first eight bits.

AA 55 : Unknown 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : Padding

3C C3 : Unknown

2A : Serial string length

03: Descriptor type (String )

32 00 30 00 31 00 34 00 30 00 37 00 31 00 39 00 31 00 34 00 31 00 34 00 32 00 37 00 30 00 38 00 35 00 46 00 30 00 37 00 42: The actual serial number string

After that there are @ offset 0xc3 an 0xc7 two 02 which are unknown

And @ 0xd4 there's 88 50 51 49 which is unknown too

Once the settings have been uploaded , the flash drive has to be unplugged and plugged in again

The 0x82 command

This command instead, is used to read current configuration, it can be used in two ways

82 51 01 00 00 00 00 00 00 00

In that way you will get the current usb configuration with the same format as 0x81 command, 512 bytes too

82 51 00 00 00 00 00 00 00 00 

With this one instead you get another configuration(maybe) that still has to be investigated, and i have to figure out how it is uploaded too

I've created a git repository on github.com containing the kernel patch and the current code for the alcorhack tool

https://github.com/tizbac/alcorhack

Again , if someone wants to help, contact me on G+ or comment here