Reverse Engineering The 360 Controler

[TokyoDrift]

Hey,
I just opened an old 360 controller and I wondered if I could reverse it. I already soldered some cables to the connection between the wireless module and the main microcontroller - at least I hope so
I have also seen an EEPROM inside, and a chip called XBOX 803120 G532, i have no idea what it is, could it be some kind of voltage regulator?

however, I'll get my logic analyzer in some days, maybe I'll find something out
does anyone already have an idea of where the needed testpoints are, what protocols are used and so on?

oh, what is it good for? in the best case you could replace the main microcontroller with a programmable one, that would allow a new generation of "rapidfire"...only think of programmable macros...
TD

[FOOKz™]

its possible. I have a scrap CL board that i could tear apart since the ROM chip fried an egg and saw its last day when a friend messed with my power supply pumping 35 volts into it. *sizzle*

the board is multi-layer so you will have some trouble getting the traces: my secret is to desolder all parts and shine a 200 Watt halogen light through the board and copy down the traces you see through the board.

[TokyoDrift]

I hoped I could do everything without making a schematics of the controller

ROM chip fried an egg and saw its last day when a friend messed with my power supply

the Microsoft thing (the big one) or the EEPROM (little one that says 24C04 on it)?

well, the EEPROM is a I²C device
I'll do some checking...
TD

EDIT: that EEPROM doesn't seem to be connected to the Microsoft IC. Maybe it's connected to the wireless thing directly?
TD

EDIT: my fault, of curse it's connected to the main µc. AND it's connected to the Microsoft chip
that will be interesting to analyze.
TD

EDIT: yeah lol, the EEPROM is not connected directly to the xbox chip, I said that a little weird...it's an I²C bus that can handle more than one device on one bus, and the bus seems to connect the xbox chip, the eeprom and the main µc.
TD

I can log the I²C bus but not the wireless thing bus...it's just too fast...
TD

[RDC]

The controller boards are only 2 layers, you can just flip it over and see all of the other traces.

The on board EEPROM is on an I²C bus that's connected to the EEPROM, PnC connector for the EEPROM in the PnC pack (yup) and then the MCU. This on board EEPROM has been done away with on the Wired CL and Wireless CG and CG2 versions of controller also, most likely merged into the MCU or just done away with, you'd need a real datasheet from M$ to know for sure, and I've only ever seen it on 1 Wired Matrix version controller, so most of them don't have it either.

I've speculated the on board EEPROM is for storing the controller's 'Sync' data, as the RF board in the console and Wireless PC adapter have an EEPROM as well, just never bothered to Sync a couple up to different consoles and swap them to see or dump it with the Willem to compare the changes.

The other 8 pin IC is the Security IC, it's the one that lets the controller work on a 360 and why other USB/Wireless controllers don't, even if they used the same drivers. You'll find them in pretty much every 360 peripheral and 3rd party controllers and it connects directly to the MCU, most likely spits out some bit of code when plugged into the 360 to let the thing know it's an official/licensed controller.

Good luck with poking around in there, be interesting to see what you find out.

[TokyoDrift]

now things get interesting

I already thought the EEPROM could store information for syncing (what else should be in it!?)
the lack of eeprom in new controllers...well....the MCU could have integrated EEPROM....
I made an EEPROM reader some time ago, maybe I'll compare the data in the controllers EEPROM with the data in the PC wireless connector EEPROM

the security IC? omg that's interesting!
what could it do...
output hardcoded values? too easy...decrypt the EEPROM data? mhm not rly usefull...the only thing I can think of is that the 360 sends some data to the controller, the security IC (let's call it...umm...SU for SecurityUnit) encrypts or decrypts it and data is being sent back to the xbox
however, this doesn't help...that wireless unit is too fast for me and without knowing how to send data to the XBOX the SU won't help...

so how could we use the facts we have? the PSP uses a battery with a special serial code to go into service mode -xbox controller won't offer any service mode
can't think of anything else regarding battery's eeprom

controller's eeprom...holds syncing data...a console-unique ID...maybe this is the console's drive key too..that would be awesome....
oh sorry I was dreaming...syncing data...mhm no, no real application for this either....

misterious SU...no...nothing to do there...


what else is in the controller...a UART with a protocol noone understands....19200 baud...

Command From Controller
   Answer From Chatpad
   Every Answer is being repeated 4 Times
   Every Answer Is Split In Two Groups
   Group 1 Is Always 0xA5 X5
   X Is 0, 4 or 8
   Group 2 Is Always 0xF0 04 00 XX XX YY
   XX Is Counting Up Every Answer
   YY Is Some Number I Can't Seem To Figure Out What It Is
   Command Is Being Sent Every Second


0x87 82 1E 8C 4D
   0xA5 45   0xF0 04 00 06 06 16
   0xA5 45   0xF0 04 00 06 06 16
   0xA5 45   0xF0 04 00 06 06 16
   0xA5 45   0xF0 04 00 06 06 16
      
0x87 C2 1F 8C 0C
   0xA5 85   0xF0 04 00 07 07 D4
   0xA5 85   0xF0 04 00 07 07 D4
   0xA5 85   0xF0 04 00 07 07 D4
   0xA5 85   0xF0 04 00 07 07 D4
      
0x87 02 1E 8C CD
   0xA5 05   0xF0 04 00 08 08 52
   0xA5 05   0xF0 04 00 08 08 52
   0xA5 05   0xF0 04 00 08 08 52
   0xA5 05   0xF0 04 00 08 08 52
      
0x87 42 1F 8C 8C
   0xA5 45   0xF0 04 00 09 09 10
   0xA5 45   0xF0 04 00 09 09 10
   0xA5 45   0xF0 04 00 09 09 10
   0xA5 45   0xF0 04 00 09 09 10
      
0x87 82 1E 8C 4D
   0xA5 85   0xF0 04 00 0A 0A CE
   0xA5 85   0xF0 04 00 0A 0A CE
   0xA5 85   0xF0 04 00 0A 0A CE
   0xA5 85   0xF0 04 00 0A 0A CE
      
0x87 C2 1F 8C 0C
   0xA5 05   0xF0 04 00 0B 0B 4C
   0xA5 05   0xF0 04 00 0B 0B 4C
   0xA5 05   0xF0 04 00 0B 0B 4C
   0xA5 05   0xF0 04 00 0B 0B 4C
      
0x87 02 1E 8C CD
   0xA5 45   0xF0 04 00 0C 0C 0A
   0xA5 45   0xF0 04 00 0C 0C 0A
   0xA5 45   0xF0 04 00 0C 0C 0A
   0xA5 45   0xF0 04 00 0C 0C 0A

this is some idle data...i can see some system but it's weird...
mhm
TD

[Hazer]

You may be thinking way too much about this. The contorller needs EEPROM for two reasons: Store a unique ID for the controller only and to store startup data for the blue-tooth module. Most wireless modules use EEPROM for boot-up in stand-alone systems.

There is no reason for the controller to store any information from the main console. Drop the idea about getting any kind of useful information from the console. The console itself is the only place you would need to store the controllers unique ID.

That MS chip is not a standard chip. Its 99% likely to be an ASIC. That means MS designed the chip from the ground-up, instead of using a chip the gets programmed/fused after its manufacture. When dealing with large quanitites of ICs that all have the same design, its much cheaper to setup a manufacuring line to make ASICs instead of purchasing a generic programmable FPGA that then needs the added step of being programmed. Since the chip is an ASIC, it will be highly unlikely anyone will ever see a datasheet for it. If it became public knowledge, controller clones would be much easier to make and would then flood the market.

The concept of this thread is trying to interface directly to the ASIC with some hidden port that you could over-write the internal logic and add code/programming for a non-hardware rapidfire solution. I have no idea if this is possible or not. I will say it is highly unlikely. MS has no reason to allow re-programming of the controller. There is no value in it. If they decide to add functionality to a peripheral, they will simply force people to buy new hardware. That is thier business model. They would never install future functioinality in any product as it only creates more work for them in the present (to design the ability to get reprogrammed) and in the future (the new program) while not making any profit.

But, we do know there is the peripheral connection. You may not be able to reprogram the controllers ASIC, but you can still send it inputs of some kind. The bad thing is I believe it is too slow, and there may be no commands to simulate the pressing of the contrllers buttons, just commands for the ASCII text from the pad.

Honestly, it would be easier to sniff the communication of the blue-tooth module and create the controller from the ground up than it would be to reverse engineer the main MS chip. Its functionality is rather simple to begin with.

-Check button press.
-Send out sync request.
-send unique ID signature.
-Create status packet and send.
-monitor button presses.
-A2D conversion..
-Listen for 'off' command.
Post Merge: March 21, 2010, 06:16:26 AMOh, those commands you posted earlier, I know what the YY is:

modified bit checking calculation.

Take all the byte from the line and add them up:

0xA5 45  0xF0 04 00 06 06 = 0x1EA  -> dump the 1 as we keep data in byte format and lose the carry.

THen take this value and subtract from 0 (2's compliment?):

0x00 - 0xEA = FFFFFFFFF16  or simply 0x16 if you only keep the 8 bit data byte format.

You get the same results for each and every line.


Looking at the strings without manipulating the button presses does not tell a whole hell of alot. You need to compare the idle data to the button pressses of the chatpad.

[PspKicks316]

Hey Hazer...there's no bluetooth in 360 controllers.

[Hazer]

Yeah yeah. They use a proprietary 2.4GHz protocol. The difference being using a standard protocol vs a closed one. If you shop around for wireless interface chips, you can choose a few things. Even though I blurped 'Bluetooth' since it is commonly used with all other controllers, the hardware chip used for creating the RF wireless signal can be used stand-alone with a EEPROM interface.

Regardless, the 'meat' of my previous statement is still correct.

[TokyoDrift]

You may be thinking way too much about this. The contorller needs EEPROM for two reasons: Store a unique ID for the controller only and to store startup data for the blue-tooth module. Most wireless modules use EEPROM for boot-up in stand-alone systems.

I know. I was just kidding before
I also know that there is most likely no way of reprogramming the chip inside the controller
still you could replace it with a normal µc that offers enough ports and is fast enough

Oh, those commands you posted earlier, I know what the YY is:

modified bit checking calculation.

Take all the byte from the line and add them up:

0xA5 45  0xF0 04 00 06 06 = 0x1EA  -> dump the 1 as we keep data in byte format and lose the carry.

THen take this value and subtract from 0 (2's compliment?):

0x00 - 0xEA = FFFFFFFFF16  or simply 0x16 if you only keep the 8 bit data byte format.

that's awesome
I know that comparing idle data won't help but I was just messing around ^^
TD

EDIT: btw, I can't test anymore bc I accidently deleted the firmware of my chatpad...if those are readable, could someone please send me a firmware dump of it?