• AVR Freaks

Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config

Author
Beerman58
Starting Member
  • Total Posts : 6
  • Reward points : 0
  • Joined: 2013/09/09 21:21:33
  • Location: 0
  • Status: offline
2013/09/09 22:42:00 (permalink)
0

Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config

I am standing at a crossroad in a home project and looking for direction from someone more experienced than myself with PIC USB programming.  High-level Goal: send an un-modded Xbox 360 console exacting controller inputs (up to the resolution allowed by the USB protocol) as determined (externally) on the fly.  I’ve narrowed it down to two paths, each months-worth of development time, so I don’t want to choose a dead end.
 
Path A – Man-in-the-middle (my personal preference, if possible):  Use a PIC32 USB Starter Kit and a self-made (completely non USB 2.0 certifiable) USB Y-cable with two downstream connectors, one branch with the genuine wired controller device, toggled in-line with a couple reed relays (one each for D+ and D- USB channels), and the other more standard continuous branch with the PIC.  PIC32 simply monitors normal console/controller USB communications (not as a ‘device’ in the USB sense), without interrupting the conversation initially.  When the PIC sniffs a polling ‘IN token’ packet is sent from host (console) to the ‘button status’ device endpoint, “flip the switch” on the controller branch of the Y cable breaking the connection between controller and console, and allow the PIC itself to send the 20 byte sequence (http://free60.org/GamePad) that can yield any button or stick input the heart desires (this is the only time the PIC would ‘talk’ instead of ‘listen’).  Then “Flip the switch” back just in time for the controller to receive the handshake ACK packet from the host for the similar 20 byte sequence it simultaneously sent over a dead wire (although it doesn’t know that).  Assuming I can work out the timing and hardware (of which I am confident with my trusty logic analyzer and a soldering iron), my central question for those of you who know more about the PIC’s capabilities is this: is it even possible to do such low-level USB protocol logic by programming the PIC32 USB Starter Kit?  Or is there too much ‘proper’ USB protocol hardcoded into the PIC/Kit itself to allow for such a butchering of the 2.0 standard?
 
I’d rather not think about Path B: No hardware mods, just a straight up full device emulation of a wired Xbox 360 controller with the PIC32.  The problem with this is that Microsoft has specifically gone out of its way to discourage such ingenuity (to reap the monetary benefits of licensing no doubt), with vendor-specific classes and descriptors, and even a full-blown security chip that is polled during device configuration!  (I would probably actually have to get the PIC to poll a genuine controller to get around that one.)
 
Is it possible to silently monitor USB communications with a PIC32?  Can I push out an arbitrary 20 byte sequence to the bus, disregarding any proper protocol?
#1

9 Replies Related Threads

    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/09/10 09:29:35 (permalink)
    0
    Is it possible to silently monitor USB communications with a PIC32?

    No, it isn't possible with any PIC.

    When the PIC sniffs a polling ‘IN token’ packet is sent from host (console) to the ‘button status’ device endpoint, “flip the switch” on the controller branch of the Y cable breaking the connection between controller and console, and allow the PIC itself to send the 20 byte sequence..
    Can I push out an arbitrary 20 byte sequence to the bus, disregarding any proper protocol?

    Again, it isn't possible.

    USB spec tightly ties the packets in a transaction together in their timing.
    Your hardware has to send a DATA0/1 packet immediately after the IN token packet, within 6.5 bit time
    1 bit time = (1/12MHz) = 83.3 nano-seconds

    7.1.18.1 Low-/Full-Speed Bus Turn-around Time and Inter-packet Delay (usb_20.pdf - USB2.0 spec)
    If a function is expected to provide a response to a host transmission, the maximum inter-packet delay for a function or hub with a detachable (TRSPIPD1) cable is 6.5 bit times measured at the Series B receptacle.


    This tight timing is the reason why transactions are processed by hardware.

    You may be better to make a clone of the controller.
    I believe the information on the site ( http://free60.org/GamePad ) is almost enough to make a clone.

    Tsuneo
    #2
    Beerman58
    Starting Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2013/09/09 21:21:33
    • Location: 0
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/09/10 22:42:19 (permalink)
    +2 (1)
    Thanks for the solid answer, Tsuneo!  Very helpful, although it was not the one I was hoping for.
     
    I guess in my head I initially assumed that 92 DMIPS (~ 10.9 ns per instruction) would be enough software-based processing power in the PIC32 to do something simple yet useful in that 6.5 bit-time (542 ns) Inter-packet Turn-around Time, but I can see how additional delays related to input/output would indeed kill that possibility.  And in any case, since that software-based functionality is not at all present in a PIC like you said, whether or not it’s physically possible for a software-based solution to accomplish is a moot point.  Path A is dead.
     
    On the plus side, your comments led me to a previously-unconsidered Path C to research further: an FPGA-based man-in-the-middle.  Unfortunately I have zero experience with FPGAs, and it doesn't look like Microchip has any offerings.  This does look promising though.
     
    Thanks again!
    Beerman58
    #3
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/09/11 07:23:54 (permalink)
    0
    Ah, it's an interesting project.
    http://www.xess.com/proje...SB-V2/readmeusb-v2.php

    In quick look, a problem of the project is, it connects USB D+/D- lines directly to a FPGA port,  without any USB transceiver. It should be often suffered with noise. D+/D- lines act in differential mode while packets are going on. A differential receiver suppresses common-mode noise on the lines, working with a twisted pair USB cable.

    USB FS/LS transceiver - TUSB2551A, TUSB1106, NCN2500, USB1T11A, etc

    Antoher way with FPGA is, ULPI PHY, such as USB3300. It'll simplify the FPGA design much more.
    http://www.wvshare.com/pr...B3300-USB-HS-Board.htm

    Anyway, I'm not sure, why don't you like a clone on your PIC.
    It's much easier than FPGA. And your PIC32 USB Starter Kit is enough to start with.

    Tsuneo
    #4
    Beerman58
    Starting Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2013/09/09 21:21:33
    • Location: 0
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/09/16 12:54:06 (permalink)
    +2 (1)
    Anyway, I'm not sure, why don't you like a clone on your PIC.

    I like the idea of a full clone, but I'm worried I'll hit a dead end with the vendor-unique security features.  At a minimum I know that I would have to somehow communicate with the security chip on a real controller during (clone) device configuration.  The simplest way I can think to do this would be to write a custom driver for the controller (to use under Windows on my PC) to access the real security chip in the same manner that the Xbox console does.  When my PIC32 clone device received a (likely 256-bit) challenge 'question' from the console to the security chip's endpoint, it could pass the 'question' to the PC over the PIC's debug USB comm port, then the PC could pose that particular 'question' to the real controller via a custom USB driver interface.  The PC would receive the encrypted 'answer' from the real controller, pass it back to the PIC, and the PIC would send it on to the console, as if it had generated it internally like the real controller.
     
    But there is a lot of potential for unseen critical problems with this plan.  Does timing play a key validation role (i.e. does the console limit the turnaround time from security 'question' to encrypted 'answer')?  If so, such a long path from 'question' to 'answer' may not be allowed, and my PIC clone device could not get past the vendor-unique configuration on the console.  Are there other validation techniques hidden in the vendor-unique descriptors and protocols?  For instance, does the security chip change its 'answer' to a given 'question' based on the number of times a certain vendor descriptor has been requested by the host?  I'm sure I could eventually replicate these nuances, but there are too many unknowns to make that my favored option.
     
    By contrast, with the lower-level man-in-the-middle path, the scope of work is very well defined: insert 20 false bytes into the bus at this specific time.  Furthermore, whenever my initial development fails because of some unknown bug, I'll scope the DATA0/DATA1 packet with the 20 byte waveform directly with the logic analyzer, compare to the real signal, and instantly see the problem without having to play 'cat and mouse' regarding security features.  But I'll have to look into it more to see if it's really worth diving into such a new and deep knowledge pool as digital logic design.
     
    In quick look, a problem of the project is, it connects USB D+/D- lines directly to a FPGA port,  without any USB transceiver. It should be often suffered with noise.
      Interesting observation... the authors of that project note towards the bottom, "For reasons not yet understood, there is a problem with rapid, sustained read requests."  Perhaps the interference you mention is causing the bugs in their setup. ULPI does indeed sound like it could greatly simplify the FPGA design, while still giving be the flexibility I need to 'bend the rules' a little on the USB protocol.  I will definitely look into that more.  Any other tips or insight welcome, of course.
     
    Thanks once again!
    #5
    ajs410
    Junior Member
    • Total Posts : 97
    • Reward points : 0
    • Joined: 2011/05/19 13:08:46
    • Location: 0
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/09/17 13:53:36 (permalink)
    +2 (1)
    Why not take a 360 controller, crack it open, and solder some wires to the buttons?  Then you can use an open-drain output on a microcontroller to simulate a button press.  No worries about a security challenge, no eavesdropping on USB comms.
    #6
    Beerman58
    Starting Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2013/09/09 21:21:33
    • Location: 0
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/09/21 18:24:33 (permalink)
    +2 (1)
    Hmm... I do like that idea, ajs410.  So, do you mean solder on some ~6ft leads to the relevant buttons, like this?

     
    Then maybe put a few custom buttons on the back to communicate directly with the PIC, like this?

     
    Then put the whole controller back together so that it can be used like normal, except for the fact that the wires are hanging out of some holes you cut in the bottom, like this?

     
    Then hook the new controller wire leads up to some relays via a breadboard that are controlled by the outputs on the PIC, like this?

     
    That is an interesting idea, I'll have to try that!  wink
     
    The only problem is timing resolution... while the PIC can easily control the duration of full-envelope stick presses (full up, full down, full left, or full right) to the sub-microsecond, (which would be more than enough resolution to, I don't know, zero-in the crosshairs on the center of someone's head in a first-person shooter,) the relays bounce a little but are still predictable within the tens of microseconds.  Then the real trouble starts brewing; the USB interrupt endpoints on the controller device are only polled by the console USB host every 4 milliseconds, and finally the game engine only loops through input response every 25 to 50 milliseconds.  Now rounding the button press up to a 50 millisecond resolution may not sound like much variance (and I suppose it isn't in human terms, since I've never personally noticed any controller lag), but it's enough at a full-envelope stick press to be way off target (a distance ~10% of the screen's field of view width).
     
    So since the modded controller with shorting leads can only fully depress the analog sticks/triggers 100%, and because the timing resolution of such a press is always rounded up to the nearest 25 to 50 milliseconds or so, that method of control is too 'jumpy' for my particular project, and I need something with finer resolution.
     
    Enter hacking into the USB data itself, and having full control over the 16-bit signed integer (within a 20 byte button and stick status string of USB data) that outputs the position of a given analog stick's axis to the nearest 1/65536-th of the full range.  Then instead of always sending the input for 100% right stick, I can send the input for, say, 88.6806848353526% right stick and regain my lost resolution due to the sad frequency of the USB interrupt and game engine input.  It will definitely take a little trial and error to refine exactly where in that 25 to 50 millisecond range that a given game is operating it's input loop period, but assuming it's mostly constant, it should be very easy to correlate how much stick input value, X, yields how much pixel jump per cycle, Y, on the screen of the first-person shooter.
     
    Anyway, sorry for going slightly off topic.  But the point is that while the PIC is definitely awesome enough to accomplish what you suggest, the Xbox console, in this situation, cannot keep up.  Thanks for the suggestion though, ajs410; great minds think alike!
    #7
    ajs410
    Junior Member
    • Total Posts : 97
    • Reward points : 0
    • Joined: 2011/05/19 13:08:46
    • Location: 0
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/09/23 12:44:21 (permalink)
    0
    I did something like this back in college, but with a Playstation 2.  Much easier, since it was plain old SPI, and I was able to eavesdrop just as you intend to do.
     
    I see your issue now - it's not the buttons causing you the problem, it's the axes.
     
    The axes are probably some ratiometric potentiometer.  I suppose if you were okay with being brutal, you could cut the trace for a given axis, and run it to your PIC ADC, connect the PIC to a DAC, and connect the DAC back to the 360 controller.  Under 'normal' operation, ADC -> PIC -> DAC; value goes in one side, comes out the other.  Under 'special' operation, PIC -> DAC; PIC creates a new value out of thin air, ignoring the value from the ADC.
     
    EDIT: the DAC probably won't have the best drive strength unless you buffer it with an op amp.  If you don't buffer it I would recommend running each DAC channel as a twisted pair, the second wire tied to ground.  Otherwise, with a wire that long, your DAC might be too noisy.
    post edited by ajs410 - 2013/09/23 12:47:53
    #8
    chinzei
    Super Member
    • Total Posts : 2250
    • Reward points : 0
    • Joined: 2003/11/07 12:39:02
    • Location: Tokyo, Japan
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/09/30 23:16:00 (permalink)
    +2 (1)
    Ah, I see.
    Xbox 360 allows just USB devices with a security chip.
    I found this page for the Xbox 360 security protocol over USB.

    Xbox 360 Controller Security
    http://brandonw.net/360bridge/doc.php

    If the analysis of above author would be fine, this configuration should work,

                                    |--------- USB bridge dongle -----------|
    Genuine Xbox controller ==(USB)== PIC USB host <-(SPI)-> PIC USB device ==(USB)== Xbox body


    Tsuneo
    #9
    Beerman58
    Starting Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2013/09/09 21:21:33
    • Location: 0
    • Status: offline
    Re:Wired Xbox 360 Controller USB Emulation: man-in-the-middle vs. full USB device config 2013/12/08 23:38:06 (permalink)
    0
    I found this page for the Xbox 360 security protocol over USB.

    Xbox 360 Controller Security
    http://brandonw.net/360bridge/doc.php

    Great find!  The information there for which device control requests indicate the actual commands for dealing with the security chip will definitely be helpful.
     
    Taking a break recently on this particular project, I still haven't fully committed to either FPGA or PIC, but if I go the PIC route, I either need to buy another PIC for the host in the arrangement you mention:
                                    |--------- USB bridge dongle -----------| 
    Genuine Xbox controller ==(USB)== PIC USB host <-(SPI)-> PIC USB device ==(USB)== Xbox body

     
    Or, code up a custom interface to run on my Windows PC and extract the security 'answer' from the genuine controller:
                                     |------------------------------------------Custom PC Interface---------------------|
    Genuine Xbox controller ==(USB)== Windows PC (custom USB driver) <-(internal API)-> Custom Monitoring Program (.exe) <-(Serial)-> PIC USB device ==(USB)== Xbox console

     
    Incidentally, I already have a solid "custom program to Serial to PIC" implementation from my last attempt with the hard-wired relays, so I could reuse that part.  I would guess that creating a driver in Windows to interact with the controller would be simpler than creating a full PIC host implementation to accomplish the same, but I really don't have much experience with either; what do you think?
     
    On the other hand, it is additionally desired in this project to pass the console the genuine controller's button status (when not being overridden by external inputs), and that would be an additional interface (in addition to the security protocol) that a driver or a host would have to support, whereas in the FPGA option, that pass-through of both the security protocol and the button status would be implicit by use of a simple multiplexer design inherent to the FPGA.... decisions, decisionspink.
    post edited by Beerman58 - 2013/12/08 23:44:10
    #10
    Jump to:
    © 2019 APG vNext Commercial Version 4.5