Thanks DeepThoughts.
Make sure to read the very first post.
The one cable I recommend everyone get or make is a button select USB cable. It can be used to play on a PC, update the firmware, play on a PS3, and even play on an Xbox 360 if there is a piggybacked 360 controller inside.
Are these usable on the wii to play brawl?
Yup.
I’m not sure I understand the different modes. Is the “right analog” the c-stick? Does this mean then that all movement would be based on the d-pad as opposed to the gamecube analog stick?
Sorry, that should be the left ‘white’ analog, not right analog; otherwise, the descriptions sound clear to me. Let me know the part that’s confusing and I’ll try to explain.
This isn’t far off what I’d be envisioning, but ideally I’d like to run more input into the Universal PCB. Like everyone else, I’d like to be able to plug other gamepads into the UPCB, e.g. SNES, NES, PS, Saturn, etc. Seems like your firmware is fairly well setup for this, but at the moment the only input is via the buttons, and not any universal input. Perhaps we can put another 15-pin connector on the other side for input, i.e:
15-pin input (with certain pins held high for various system / stick)
|
/
Universal PCB
|
/
15-pin output (current system)
(one plus of such a system is that to add support for a new system, you just need to buy an extension cable, cut it in two and wire accordingly to the DB15s)
Not sure if we have enough pins available, though unless you remove the current stick inputs…
Like you, I don’t see much point in getting input from a PC, but it makes sense for supporting USB devices without using a more complicated device, e.g. Rock Band instruments, USB Racing Wheels, etc.
Anyhow, regarding Xbox 360, I’m planning on doing a man-in-the-middle attack.
I’m going to look into connecting a Wired Xbox 360 pad into a devboard (with USB host and USB gadget) that’s running linux, and writing a small gadgetfs driver and a libusb driver, to hopefully pass through the information from the XBox 360 pad to the devboard.
Best case, I can simulate reattaching the Xbox 360 pad multiple times, to help figure out the security protocol. Worst case, I can modify the HID data being sent, i.e. XFPS.
If anyone has any further information about the XBox 360 controller HID report / protocol besides what is on the Free60 wiki, please PM me.
NB, I work as a Firmware engineer, so I’d be happy to help on the firmware / PCB layout for any future revisions. Also have a few 18LF4550’s (both through-hole and SMD) sitting around for this purpose.
Is the Wiimote/Extension Controllers page on wiibrew.org not enough information for this? I haven’t really looked into the protocol, as I don’t have a Wii, just a Gamecube…
Ahh, my mistake. I just read the Wiimote page. That information is only useful when using the key 0x00000000.
UPCB already has that, exactly in fact. A d-sub 15 specifically for inputs; VCC, GND, four directions, start, select, and six main play buttons. Controlling those with other hardware would be dead simple; line is left high (or floating; there are pull ups on the board) for not pressed, low for pressed.
The plan for using it as a converter is based on the FrameUpdate() function in program.c. Most, eventually all, supported consoles will call that, directly after the controller status has been queried (PSX, Gamecube) or after a timer has expired marking the end of a 1/60th of a second time frame. The FrameUpdate will queried the converted controller to get the status of the controls, and update a couple of global variables. the S_Jab, S_Short, etc. functions will be updated to say ‘if we’re in converter mode, return the value of the ‘jab’ variable’. A function will be placed in main() before the output cable is checked to determine if we’re using a converter input.
The idea for the converter input is very similar to the system select pins of the output cables, but I haven’t completely decided how to do it; one thought is to simply stick with the the high or low checking of pins like the output cables, especially checking opposite directions; if ‘up’ and ‘down’ are both low, we’re definitely using a converter since the physical stick can’t do that, and then check the next couple of pins to determine the type of controller connected. Another idea is by connecting a pair or more of pins; check the specific pins to make sure they’re both high, set one as a low output pin, and see if the match goes low. Set a variable so the FrameUpdate() function knows which controller it’s talking to, and that’s it. Since we can assume all of the pins are held high via pull-up, making the input connectors will be half of the work of the output connectors.
That hard part will be that just about everything will have to be bit-banged, since the SPI and I2C pins are already going to the output cable.
I’m not sure if I understand that part, but I think we have plenty of pins to work with. As for racing wheels, I’d have to doublecheck the datasheet so remember which of the analog pins are where, but if at all possible, I’d rather avoid direct analog input.
As someone who’s been there, let me offer a little bit of advice. Using libusb is great; I abused the hell out of it for getting Xbox and PS3 going, but what we really need is a USB protocol analyzer.
The other part I abused to get what I have so far is a good PIC debugger. You can’t do a super slow step by step with USB, but you can easily setup to record the packets and various states when it starts up, have it hit a breakpoint and then read the recorded packets to translate later. That’s how I saw the different commands being sent by the PS2 emotion engine in a PS3, and how it differed from normal PS3 setups.
But damn a good USB protocol analyzer would be SOOOO much easier.
I don’t know if its from what I’ve read, or what I’ve pieced together, or maybe even what I dreamed, but I seriously don’t think thats the proper way to go about it. What I expect, and I dont have anything to back it up, so maybe Im full of shit, but hey: I expect just about all of the communication between a wired controller and the 360 to be just peachy normal stuff; HID, with a few extra endpoints setup for headset communication, with one exception. There will be a challenge query from the 360, and a response from the pad, once, in the very beginning of the communication. (XFPS says you can removed the wired piggyback pad once its running, but have to reconnect it whenever you plugin the XFPS)
The key, and this is the part that I can’t find ANY information on, is that little eight pin SMD ‘XBOX’ chip on every single controller. I bet if you hook up a good oscilliscope or logic analyzer (one better than mine), you’ll see a simple method of communication between the XBOX chip and the real microcontroller such as SPI or I2C, where the challenge from the 360 is sent, a response read from the XBOX chip, which is then sent back over the USB as the respone.
Why do I say this? Partly because Im a cynical bastard, and partly because the grey market korean and chinese market hasn’t been pumping out their own third party controllers or adapters. Because a man in the middle attack won’t work for the same reason a man in the middle attack doesn’t work in NT challenge/response. Both of the actual transmissions are one way hashes, or RSA signed tokens of some sort. We could probably record a few of the challenges, and see or hope that the recorded responses we parrot back pass the test, but that means we’d have to record thousands or millions or billions of bytes of data to have a database of even a small percentage of possible challenges.
We need to find where the challenge comes in (when endpoint its sent to and anything else we need to identify it as the challenge), what changes the microcontroller makes to the token before sending it to the XBOX chip (oh that’d suck; if the wired mCu’s had to sign the token before handing it off), and how the token is sent to the XBOX chip, how the response is read from the XBOX chip, any changes that need to be made before shipping it out some endpoint to the 360.
THAT is how we’d have to do it; not breaking it directly, but just understanding enough so we could use the XBOX chip soldered to UPCB boards. I don’t even think it’d be that hard to use them; I bet those XBOX chips are nothing more than super cheap Attiny’s or 12F whatever microcontrollers; all it has to do is read in a value, perform their super secret math, and spit it out.
Sure, if you could truly break it, great, but considering how locked down tighter than a frog’s ass the 360 itself is, and the fact much better funded companies ain’t done it yet, I think the way I described is a bit more likely.
Think maybe you could give a hand with this simple problem that’s been a pain in my tail?
http://forum.microchip.com/tm.aspx?m=348519&mpage=1&key=&#
I wouldn’t do direct analog input either. Use a steering wheel from a Playstation or similar, otherwise have a protocol to connect to the PC. The PC can run an app to pass through the analog values through a FTDI chip (using some special protocol). This would be needed if you were using a USB based Steering Wheel, e.g. Driving Force Pro, etc.
Did you actually have a gadget device connected to the PS3 or the Xbox? i.e. a usb client? Or did you just use libusb on the PC to simulate what you saw the PS3 / Xbox doing?
Definitely, but these aren’t cheap. Essentially a USB protocol analyzer is just a device with a host port and a gadget port and some logging capabilities. I expect that you can write a suitable gadgetfs driver to do something similar. All the endpoints (except EP0) are interrupt, so it should be straightforward.
Something like the beagleboard would be good for this.
I want to essentially emulate the XFPS first, and try to log a lot of the authentication challenge/response packet(s). At least this will let me plug other devices into the Xbox 360 without resorting to soldering onto a controller. At the very least I should be able to get the devboard gadget to come up as a separate VID/PID and emulate the Wired Guitar for example. I think the XFPS does this.
This is probably true, but it’s not going to be simple for the average end user to desolder the chip and put it another board.
AFAIK, I don’t think anyone has actually logged the challenge/response mechanisms on the Xbox 360 controller. By removing and reinstalling a gadget driver it will simulate plugging/removing the USB plug and the authentication process. At the very least this will help identify the challenge process, protocol and/or hash.
I’m pretty sure that the 8-pin chip that you’re talking about is based off an Infineon TPM design. I think these chips are in the memory units and wifi adapters too. The Memory_Unit page on the free60 wiki has a bit more info.
Even it ends up being a couple hundred megs for an authentication table, this could just be read off an SD card or something similar. I remember a few years ago no-one knew how the MB86234 FPU / DSP worked in the Sega Model 2.
I’ve taken a quick look at this thread. Only thing that I suggest for now is trying to bit-bang it. Otherwise double check the PIC datasheets. There is generally another configuration bit for SPI polarity. Anyway, will look at it again tomorrow, as it’s too late here.
I haven’t really used the PIC18F4550 for much…
Both. I had the UPCB connected to a ICD2 PIC debugger, so the full chain was PC->debugger->UPCB->PS3/Xbox. I added a little to the USB code to make a 256 byte array, and store each of the setup packets it received in order since they’re only 8 bytes each. After a short period of time, I’d hit Halt, and write down the setup commands. Take it upstairs to my real PC, and use the info on the Usb Made Simple page:
http://www.usbmadesimple.co.uk/ums_4.htm
To decode what each one was doing. I’d have the controller I was trying to clone (Xbox or VSHG) connected to the PC, and write a really small libusb program to send the same query to the device. Here’s the one I used to find the response to the Vendor Specified request sent to my Xbox controller:
http://privatepaste.com/c4gfLbibDy
It was a pain, but it worked; that’s how I saw the different order of commands sent to devices in PS2 BC mode versus regular PS3, and how I got the response to the Xbox request.
WOOT! http://www.free60.org/wiki/Memory_Unit
They already identified it as SPI, small Phillips mCu, with all of the communication done after 3ms from plugin! Time to solder a couple of wires and do some snooping. Damn, as if I didn’t have enough on the TODO list. 
It’ll be a bit before I can get to it, so I’d love to hear whatever you learn when you do.
Hey Toodles, you guys are way over my head already with the friggin little security/authentication chip, so I doubt my 2 cents will be worth 1/10th of that, but this is what I do know…
Any 360 peripheral has this SIC in it (what I call it, for Security IC) Controllers Wired and Wireless, Wireless headset, the Camera, WiFi adapter and any 3rd party controller that works on the 360 all have that thing.
On the newer CL version Wired controller when it’s plugged into an XP machine, if that SIC is missing ya get quadrants 1 and 4 lit up on the controller and the analog lines go haywire, but all of the buttons still seem to work just fine.
On the bottom of the chip in the one I have here it’s marked…
GEPK2BD
ZA745
067IB1
I’m kinda limited to what I can do with a soldering iron, hot air setup and my imagination, but I can tell ya if that SIC is missing and the Wired CL controller is plugged into a 360 ya get quadrant 1 and 4 lit up, same as the PC, but no response at all from the controller, it will not even turn the 360 on via the Guide button.
If the SIC is in place and the controller THEN plugged into the 360 and THEN the SIC removed you can turn the 360 on with the controller as it seems to authenticate right there (since the 360 always has a 5v standby on the USB ports the controller is in a sort of ‘sleep mode’ even when the 360 is off) but it will NOT authenticate or whatever it does to lock on to a controller number after the 360 is powered on, all 4 quadrants will just flash and the controller is unresponsive.
If the chip is in place, controller plugged up and 360 turned on and left until the controller ‘locks on’ to the #1 spot or whichever is available, and THEN ya remove the chip the controller seems to function normally in the dash as well as when a game is launched and then going back to the dash. So after the 360 is up and running with the controller ‘locked in’ to a player slot the thing seems to be useless, but I didn’t go any more with it after that and I’m sure there could be something that would cause it to query the SIC again and at that point I’m sure the controller would just lock up.
I can also tell ya I’ve seen these things start to either fail or get all screwed up in some way on the Wireless controllers and Wireless Headsets and cause them to stop functioning properly. Replacing them with one from a working controller/headset (replacement has to come from the same thing) then they start working again, so something is killing some of them or they’re just failing from use/time, who knows what or just from being faulty. I haven’t had any Wired controllers with issues yet that I could trace back to the SIC, but any Wired controller that doesn’t connect to the 360 and just flashes the lights probably has a bad one in it as well.
Hope some of that was useful or at the least entertaining in some way. 
After doing a little more research, I don’t think I’ll be able to do a man in the middle attack, because the USB device controller (ISP1581) on my devboard only supports full-speed(12Mb/s) and high-speed(480Mb/s).
According to this page from the Mac Xbox360 controller driver, all the security IC information is passed through Interface 3, but there are no endpoints attached to it. The linux lsusb report for this section is interesting though:
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 253
bInterfaceProtocol 19
iInterface 4
** UNRECOGNIZED: 06 41 00 01 01 03**
NB, this report seems to change slightly depending on the version in bcdDevice, e.g. 1.14 on another site.
Why would that be a problem? Xbox controllers (both original and 360) are full-speed devices.
Whoops, my mistake. I guess I assumed that most other HID devices are low-speed, that the Xbox and PS3 controllers etc would be too. Guess I should have looked in the code.
In any case, I’m probably going to have to clean up the ISP1581 gadget driver first to get it to work correctly, before I can even write the gadgetfs Xbox 360 driver. I haven’t been able to get any of the linux-usb gadgets to work, but at least they enumerate with the dodgy driver.
Never really had the need for a device port, and it was just on the devboard.
NB, you might find usbtool useful. Someone used it with the G25 to switch it to the third USB VID/PID to support 900 degrees, three pedals, etc…
WTF?!?
am i reading this correctly??
there might be native 360 support in the near future?!?
No one said anything about ‘near’. Still very much in ‘pipe dream’ phase. And although it may be native, it will still require desoldering an 8 pin surface mount chip from a sacrificial controller and soldering onto the UPCB or a daughter on the UPCB. I doubt I’ll even get much of a chance to look into it until next summer.
Toodles, out of curiosity, is there, or will there be, an option to map the joystick (or future digital pad support) to one of the analog sticks of the controller? i.e. the directions on the joystick will correspond to max directions on the analog stick? I seem to recall there were a few games that only allowed analog stick input… but my memory is a bit fuzzy as to which ones. Think they were platformers rather than fighters tho.
Well, I can tell you for sure that that’s possible; the PC/PS3 support maps the stick to both a POV hat and a X/Y axis (read as the dpad and left analog stick by the PS3), and by holding Start or Select when plugging in, you can force it to only map to one and leave the other in neutral. Gamecube is the exact same way. Playstation currently reports as a digital pad, so there are no analogs to report as. When the PSX support gets an update to include analogs, I’ll include a similar option. For some reason, I never even thought of mapping the stick to the left analog on Xbox. I’ll try to do that on the next release.
If you can think of any others that I should do that for, please remind me.
I’m wondering about a slight problem I have… my stick casing is too small, and I can’t fit a 360 or a dreamcast pcb into it. Rather than dropping the cash and rebuilding the stick to get myself space to put them in with my UPCB, I’d like to put them externally.
From what I see, a project box with dreamcast (using neo geo pinout) would be no problem. However, the 360 project box w/ neo geo would have no guide button, correct? That’d be a problem.
So, my solution is: run wires from the x360_aux connector to a db25 connector. Padhack the 360 and dreamcast pads to match the _aux connectors on the UPCB and wire that to a db25. Then, I’d be able to connect the appropriate project box to said db25, which would connect to the UPCB, plug in the corresponding UPCB cable for the system, and I’d have functionality just as if the PCBs were in the stick. And this would apply for either 360 or dreamcast, plugged into the single _aux connector. Is my thinking correct in this?