SetReport event caught my eye. The hexadecimal
sequence 0x42 0x0C 0x00 0x00 I came across in the
trace is identical to a portion of the Linux code that
enables the DualShock 3, which is also known as SIXAXIS.
Thus far, all of the communications between the
DualShock 3 and the PC have used the control endpoint
(endpoint 0). That tells us that all of the USB traffic up to
this point has been in the form of setup and commands.
Report data moves on the pair of interrupt endpoints.
Digging deeper into the trace, I discovered another
enable function payload hexadecimal match of 0x03 0xF4.
The Setup transaction you see in Screenshot 7 is telling us
that four bytes of data is to be sent to the DualShock 3
interface. These four bytes to be sent consist of the SIXAXIS
enable string (0x42 0x0C 0x00 0x00). None of this will fall
together and make any sense until we can map those hex
characters to a corresponding USB stack function call.
Using the Setup transaction field names, I found a stack
function that just might work. Here are its parameters:
Parameters:
BYTE deviceAddress - Device address
BYTE bmRequestType - The request type as
defined by the USB specification.
BYTE bRequest - The request as defined by the
USB specification.
WORD wValue - The value for the request as
defined by the USB specification.
WORD wIndex - The index for the request as
defined by the USB specification.
WORD wLength - The data length for the request
as defined by the USB specification.
BYTE *data - Pointer to the data for the
request.
BYTE dataDirection - USB_DEVICE_REQUEST_SET
or USB_DEVICE_REQUEST_GET
BYTE clientDriverID - Client driver to
send the event to.
The stack function that belongs to the
aforementioned parameters is defined as follows:
BYTE USBHostIssueDeviceRequest(
BYTE deviceAddress, BYTE bmRequestType,
BYTE bRequest,WORD wValue, WORD wIndex,
WORD wLength, BYTE *data, BYTE
dataDirection,
BYTE clientDriverID )
The function name and arguments appear to
be in line with the call we will have to issue to send
those four bytes of SIXAXIS enable data.
THE SNAKE IS HISSING
The 48-byte hex dump that follows is actually
the contents of a buffer that is sent as a report to
the DualShock 3. I found this in a Python listing:
0x00, 0x00, 0x00, 0x00, 0x00,
// rumble control
0x00, 0x00, 0x00, 0x00, 0x00,
// LED Control
0xFF, 0x27, 0x10, 0x00, 0x32,
// LED4
0xFF, 0x27, 0x10, 0x00, 0x32,
// LED3
0xFF, 0x27, 0x10, 0x00, 0x32,
// LED2
0xFF, 0x27, 0x10, 0x00, 0x32,
// LED1
0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00
The Explorer 200 captured the packet payload
in this configuration:
56 June 2013
■ SCREENSHOT 4. USB descriptors aren't very difficult once
you understand how they support each other. The Configuration
descriptor informs us about the interfaces and configurations.
The Interface descriptor lays out the endpoints. The endpoints
are described in their respective descriptors.
0x00, 0x96, 0x00, 0x96, 0x00,
// rumble control
0x00, 0x00, 0x00, 0x00, 0x02,
// LED Control
