Reverse Engineering of Xbox Security Method 3
One day I saw a post by Brandon Wilson about Xbox 360 Controller Security and I was curious about how it actually works, so I decided to figure it out myself.
This was my first experience working with the Xbox 360, and I found the Xbox 360 to be much simpler from a software and security perspective than the PS3. Just a few modules, a kernel (xboxkrnl.exe) and a 256kb hypervisor which is mainly used to manage the kv (key vault).
The PS3 has about 400 modules (which share a lot of the same and unused code), a large hypervisor, kernel, and SPU modules.
Microsoft ships XDKs (Xbox Development Kits) with the root encryption key nulled, so the updates provided for it are not encrypted and contain debugging symbols, even for the kernel. And the kernel itself looks like a library and can be debugged on XDK? (Not sure about that, never owned one)
Therefore, finding the XSM3 algorithm was a matter of seconds.
After the Xbox 360 gets all the descriptors from the controller, and the interface descriptor string “Xbox Security Method 3, Version 1.00, 2005 Microsoft Corporation. All rights reserved.” it starts to send auth packets.
Here are my sniffed packets:
UsbdSecXSM3GetIdentificationProtocolData
bRequestType | bRequest | wValue | wIndex | wLength |
0xC1 (Vendor IN) | 0x81 | 0x5B17 | 0x103 | 0x1D |
49 4B 00 00 17 04 E1 11 54 15 ED 88 55 21 01 33 00 00 80 02 5E 04 8E 02 03 00 01 01 C1
UsbdSecXSM3SetChallengeProtocolData
bRequestType | bRequest | wValue | wIndex | wLength |
0x41 (Vendor OUT) | 0x82 | 0x3 | 0x103 | 0x22 |
09 40 00 00 1C DE EB 91 87 66 B0 E3 C0 B2 6C 05 6D C8 67 E2 E7 D6 A5 DC 71 6F 21 1F B4 32 28 A0 C2 89
UsbdSecXSM3GetResponseChallengeProtocolData
bRequestType | bRequest | wValue | wIndex | wLength |
0xC1 (Vendor IN) | 0x83 | 0x5C28 | 0x103 | 0x2E |
49 4C 00 00 28 7D 66 8F 48 76 EC EB E9 61 B7 81 82 08 84 B2 7E 73 1F 7A 92 47 83 F8 5E 78 22 11 B9 9B FC AD D6 F4 D9 1E 04 7E C1 C0 0B 9A
UsbdSecXSM3SetVerifyProtocolData1
bRequestType | bRequest | wValue | wIndex | wLength |
0x41 (Vendor OUT) | 0x87 | 0x3 | 0x103 | 0x16 |
09 41 00 00 10 60 17 AC 73 E5 0F 10 D4 10 F5 C1 B5 8F 63 56 9B 36
UsbdSecXSM3GetResponseVerifyProtocolData1
bRequestType | bRequest | wValue | wIndex | wLength |
0xC1 (Vendor IN) | 0x83 | 0x5C10 | 0x103 | 0x16 |
49 4C 00 00 10 60 7E 0C 62 AE 46 94 E7 14 BA 3D 70 33 7E 93 DF 09
UsbdSecXSM3SetVerifyProtocolData2
bRequestType | bRequest | wValue | wIndex | wLength |
0x41 (Vendor OUT) | 0x87 | 0x3 | 0x103 | 0x16 |
09 41 00 00 10 47 A2 4C A3 97 DF AC CC 29 48 F1 D0 08 11 D1 FD 57
UsbdSecXSM3GetResponseVerifyProtocolData2
bRequestType | bRequest | wValue | wIndex | wLength |
0xC1 (Vendor IN) | 0x83 | 0x5C10 | 0x103 | 0x16 |
49 4C 00 00 10 49 3A E1 F9 8C 91 73 C3 FA A2 07 D3 CC 1E 2F 17 A0
Data format:
- [5 bytes - cmd header]
- [data]
- [1 byte - chksum (xor of data bytes)]
UsbdSecXSM3GetIdentificationProtocolData contains Serial, Category, VendorID and other data.
Category and VendorID are important bytes. Each type of device, such as wireless controller, wired controller, webcam, memory unit, etc. has its own category. VendorID can be of 2 types: Microsoft / 3rd party.
Depending on these bytes, the encryption key is selected.
The full reverse engineered algorithm along with my sniffed USB traffic can be found on my github.
The XSM3 algorithm is quite big, obfuscated, and unfortunately contains custom crypto algorithms. I tried to cheat: checked PC drivers, Xbox SDK, windows debug symbols in hopes that Microsoft used it somewhere else, but none of this worked out, so in the end I had to rewrite this algorithm from PowerPC asm to C.
I did this research back in 2013… who could have guessed then that Hex-Rays would release a PowerPC decompiler ???
The problem is that the Xbox 360 encrypts the hardware serial number with a fixed key and sends it to the USB device. Xbox then uses per-console key from the kv (key vault) for crypto.
The per-console keys are pre-calculated based on the hardware serial number at the factory, and the secret portion to convert the serial number to a console key is placed on authorized devices.
Okay, so what now?
Xbox controller, Skylanders Portal etc. use Infineon TPM chip. But what about unauthorized devices? There are so many of them! Devices like Cronus and XIM require a wired controller to bypass authentication. I looked at some Chinese controllers, but they use real MS chips. It seems Datel were the only ones who really cracked it and were selling their own controllers. In one of them I found 2 MCU’s. One of them is the SiTel SC14450, a DECT phone controller, probably used for the radio interface. The other is an unknown 16-pin microcontroller labeled ‘Raw Science’ (this is a Datel company).
The DFU firmware for the SC14450 can be found in the updater, it is a 16-bit CompactRISC CR16C microcontroller, but the firmware does not contain anything interesting, all commands are sent directly to the Datel ‘Raw Science’ chip.
The Datel chip was decapped. Looks like a smart card or SIM card chip, 6 wires, ROM, flash memory and RAM. But I couldn’t recognize this chip. Wild guess was that MCT = MicroChip Technology, but it is not PIC.
Masked ROM is small and easily recognizable, so getting a bootrom dump was not difficult. It is based on the 8051 architecture, but there is nothing interesting about it or anything that would help us get the secret part.
So, at this point, the Xbox Security Method 3 is reverse engineered, but the secret algorithm for converting the serial number into a per-console key is still a secret.
If you liked this post, you can share it with your followers or follow me on Twitter !