The Xbox 360 employs a security mechanism that prevents people from just attaching any USB peripheral they want to it and using it. This means no aftermarket/third-party controllers, no USB keyboards/mice, and no automation of controller functions.
Devices like the XIM3 (Xbox Input Machine) get around this restriction by sitting in the middle of the console<->controller connection; it allows the security handshake to pass freely between console and controller, but sends its own button press events instead of the controller's.
This is an attempt to explain the protocol for that handshake.
I used a USB hardware analyzer to log the communication between console and controller from the moment it's plugged in. That log (slightly cleaned up) is available here, in Excel format.
I can't recall exactly which descriptors are necessary to include before the console will attempt to communicate with the device, so to be safe, it's best to duplicate everything from the real controller (as in the USB hardware analyzer log above). Interface descriptor 03 in the configuration descriptor is especially important; it references string descriptor 04, which is essentially "Xbox Security Method 3, Version 1.00, 2005 Microsoft Corporation. All rights reserved." It's critical to include this or the console will not attempt further communication.
The console requests "static data" from the controller, unique to that device and never seems to change. It uses this data to calculate two unique types of challenges, for which the controller must respond properly. If it does not, it's not considered a Microsoft approved peripheral and all communication ceases until the device is reconnected.
I have no clue how this response is supposed to be calculated, or the meaning of the data in any of the requests. That's the strength of this protection -- only a small handful of people have cracked open the security chip to see what it's actually doing with this data. All I know is that passing these requests through to a real controller is enough to fool the console.
After the console requests the static data, it sends "challenge 1", which the controller must calculate the correct response for. The console periodically checks for the status of this response, and when the controller returns that it's ready, the console reads it and validates it.
After "challenge 1", the console sends "challenge 2" -- and then tries sending another "challenge 2", which the controller STALLs on, and the console doesn't seem to care. The console tries sending it again, and the controller responds properly.
All of the following commands are standard device requests on the control endpoint. See the USB hardware analyzer log above for more details.