Game Input MultipleXer

Posted: **Sat Mar 03, 2012 7:03 pm**

Congrats on releasing firmware for the 360! The firmware device descriptor reflects the bcdDevice 1.10 Controller.

The main difference between 1.10 and 1.14 are the unrecognized class-specific descriptors for each interface. With the firmware release and the latest GIMX (with debug turned on), the tail end of the spoof with a bcdDevice 1.14 Controller contains:

Code: Select all

0xc1  0x83  0x10  0x5c  0x03  0x01  0x16  0x00 
--> GET
bRequestType: 0xc1 bRequest: 0x83 wValue: 0x5c10 wIndex: 0x0103 wLength: 0x0016
read from controller: 22 data: {0x49,0x4c,0x00,0x00,0x10,0x3b,0x35,0x9a,0x14,0xd2,0xc5,0x03,0xee,0xbd,0x68,0xc7,0x7e,0x60,0x11,0x36,0x96,0xc7,}

 0xc0  0x01  0x00  0x00  0x00  0x00  0x04  0x00 
--> GET
bRequestType: 0xc0 bRequest: 0x01 wValue: 0x0000 wIndex: 0x0000 wLength: 0x0004
read from controller: 4 data: {0x81,0x83,0x0a,0xd5,}

 0x40  0xa9  0x0c  0xa3  0x23  0x44  0x00  0x00 
--> SET
bRequestType: 0x40 bRequest: 0xa9 wValue: 0xa30c wIndex: 0x4423 wLength: 0x0000
[b]libusb_control_transfer failed with error: -9[/b]

 0xc1  0x01  0x00  0x01  0x00  0x00  0x14  0x00 
--> GET
bRequestType: 0xc1 bRequest: 0x01 wValue: 0x0100 wIndex: 0x0000 wLength: 0x0014
libusb_control_transfer failed with error: -9

For reference, 1.14 Device+Configuration Descriptor: http://pastebin.com/aF8tDkji

===EDIT===

Changing the firmware to 1.14 resulted in "Spoof successful!" from gimx-serial

Specifically:

Code: Select all

	.ReleaseNumber          = 0x0110,

	.UnkownDescriptor1 =
		{
		  0x11, 0x21, 0x10, 0x01, 0x01, 0x25, 0x81, 0x14, 0x03, 0x03, 0x03, 0x04, 0x13, 0x02, 0x08, 0x03, 0x03
		},
		
  .UnkownDescriptor2 =
    {
      0x1b, 0x21, 0x00, 0x01, 0x01, 0x01, 0x83, 0x40, 0x01, 0x04, 0x20, 0x16, 0x85, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x16, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
    },

  .UnkownDescriptor3 =
    {
      0x09, 0x21, 0x00, 0x01, 0x01, 0x22, 0x86, 0x07, 0x00
    },

  .UnkownDescriptor4 =
    {
      0x06, 0x41, 0x00, 0x01, 0x01, 0x03
    },

Code: Select all

	.ReleaseNumber          = 0x0114,

  	.UnkownDescriptor1 =
  		{
  		  0x11, 0x21, 0x00, 0x01, 0x01, 0x25, 0x81, 0x14, 0x00, 0x00, 0x00, 0x00, 0x13, 0x01, 0x08, 0x00, 0x00
  		},

      .UnkownDescriptor2 =
        {
          0x1b, 0x21, 0x00, 0x01, 0x01, 0x01, 0x82, 0x40, 0x01, 0x02, 0x20, 0x16, 0x83, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x16, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
        },

      .UnkownDescriptor3 =
        {
          0x09, 0x21, 0x00, 0x01, 0x01, 0x22, 0x84, 0x07, 0x00
        },
          
      .UnkownDescriptor4 =
        {
          0x06, 0x41, 0x00, 0x01, 0x01, 0x03
        },

Posted: **Mon Mar 05, 2012 8:25 am**

Thanks for the info. Maybe usbspoof should transfer standard requests too...

Don't you sometimes have to make several attempts before it works?

Posted: **Thu Mar 08, 2012 2:41 am**

Several attempts before what works? Transferring standard request or spoofing?

With regard to transferring standard request, yes, I have seen issues with enumeration where instead of the expected request I get the original device descriptor request and the process repeats until the pc/xbox stops attempting. I was doing this at 115200 baud, not 500000 baud, and with my own firmware which had extra "protocol" overhead that you don't have. If this is what you meant, I could try it out at 500000 baud with your firmware and see if I have the same issues.

With regard to spoofing with your firmware and GIMX, I have not had any issues.

Just brainstorming on the spot, I wonder if transferring the entire controller's descriptor (device/configuration/string/misc) over serial before enabling the usb on the mcu might work instead of transferring standard request or hardcoding the firmware.

Posted: **Thu Mar 08, 2012 8:37 am**

saund098 wrote:my own firmware which had extra "protocol" overhead that you don't have

What's the purpose of these extra transfers?

saund098 wrote: Just brainstorming on the spot, I wonder if transferring the entire controller's descriptor (device/configuration/string/misc) over serial before enabling the usb on the mcu might work instead of transferring standard request or hardcoding the firmware.

Saving all descriptors into the SRAM before enabling the usb will be problematic with chips like the at90usb82/162 that only have 512bytes of SRAM.

Posted: **Fri Jul 06, 2012 7:40 pm**

Can someone explain? some one said that he got Spoof sucseful with this but i sont understand..

Posted: **Sat Jul 07, 2012 8:17 am**

In a terminal, type:

Code: Select all

lsusb

In the result, you should see something like:

Code: Select all

Bus 002 Device 007: ID 045e:028e Microsoft Corp. Xbox360 Controller

Type (replace 2 and 7 with your own values):

Code: Select all

sudo lsusb -v -s 2:7

It will display the bcdDevice. If your bcdDevice is 1.14, you may be more succesful using the firmware modifications explained in this post.

Posted: **Sat Jul 07, 2012 2:55 pm**

ok ill tried that, tanks, but the last time it didnt work but i was very tired...

Posted: **Sun Jun 16, 2013 10:39 pm**

saund098 wrote:Changing the firmware to 1.14 resulted in "Spoof successful!" from gimx-serial

Hi saund098!,

Would you mind posting that modded firmware for Teensy board (atmega32u4.hex)???

Thank you.

Best regards.

Game Input MultipleXer

Xbox 360 Controller with bcdDevice 1.14

Xbox 360 Controller with bcdDevice 1.14

Re: Xbox 360 Controller with bcdDevice 1.14

Re: Xbox 360 Controller with bcdDevice 1.14

Re: Xbox 360 Controller with bcdDevice 1.14

Re: Xbox 360 Controller with bcdDevice 1.14

Re: Xbox 360 Controller with bcdDevice 1.14

Re: Xbox 360 Controller with bcdDevice 1.14

Re: Xbox 360 Controller with bcdDevice 1.14