Reverse Engineering of Xbox Security Method 3

Once I saw Brandon Wilson’s note on Xbox 360 Controller Security and become curious about how its really works and decided to take a look by myself.

It was my first Xbox 360 related work and Xbox 360 seemed for me much more simple from software and security point of view than PS3. Just a few modules, kernel (xboxkrnl.exe) and 256kb hypervisor which is used mostly for kv (key vault) management.

At PS3 there are about 400 modules (which are sharing alot of the same and unused code), big hypervisor, kernel and SPUs.

Microsoft ships XDKs (Xbox Development Kit) with zeroed root encryption key, and so updates provided with it are not encrypted and contains debug symbols, even for kernel. And kernel itself looks like a lib and can be debugged on XDK? (Not sure about that, never had one)

So it was a matter of seconds to find XSM3 algo.

After Xbox 360 gets all descriptors from controller, and interface descriptor string “Xbox Security Method 3, Version 1.00, 2005 Microsoft Corporation. All rights reserved.” it starts to send auth packets.

There 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 device type like wireless controller, wired controller, webcam, memory unit, etc. has their own category. VendorID can be 2 types: Microsoft / 3rd party.

Depending on this bytes encryption key is chosen.

The full reverse engineered algo among with my sniffed usb traffic can be found on my github.

Algo is big, obfuscated and unfortunately contains custom crypto algorithms. I tried to cheat on it: checked pc drivers, xbox sdk, windows debug symbols with hope that Microsoft used it somewhere else, but nothing of that succeeded so I ended up rewriting this algo from PowerPC asm to C.

I did this research back in 2013… who would guess back then that Hex-Rays will release PowerPC decompiler ???

The problem with it that Xbox 360 encrypts hardware serial with fixed key and sends it to usb device. From now on Xbox uses per-console key from kv (key vault) for crypto.

This keys are precalculated from hardware serial on factory, and secret part to do serial to per-console key is put to authorized devices.

Okay, so what now?

Xbox controller, Skylanders Portal etc. uses Infineon TPM chip. But what about unauthorized devices? There are so many of them! Devices like Cronus and XIM need wired controller to bypass auth. Looked at some Chinese ones but they use real MS chips. Seems Datel was the only ones who really cracked it and were selling their own controllers. In one of them I found out 2 MCU’s. One is SiTel SC14450 - a DECT phone controller, probably abused for the radio interface. The other is an unknown 16 pin microcontroller, marked ‘Raw Science’ (this is a Datel company).

DFU firmware for SC14450 can be found in updater, it is CompactRISC CR16C 16-bit microcontroller, but firmware does not contain anything interesting, all cmds are passed direct to the Datel ‘Raw Science’ chip.

Datel chip was decapped. Looks like a smart card or SIM chip, 6 wires, rom, flash & ram. But I was not able to recognize this chip. Wild guess was that MCT = MicroChip Technology, but its not PIC.

Masked rom is not big and easily recognizable so it was not hard to get bootrom dump. Its based on 8051 architecture, but it did not hold anything interesting or something that will help us acquiring secret part.

So at this moment Xbox Security Method 3 is reverse engineered but secret algo to do serial to per-console key is still secret.

To be continued in Part 2…

If you liked this post, you can share it with your followers or follow me on Twitter !