xboxdevwiki - User contributions [en]

Xbox Memory Unit

2021-05-18T19:33:37Z

Billy549: /* Compatible USB sticks */

The memory units are typically formatted with [[FATX]].

{| class="wikitable"
! Product name !! VID !! PID !! Capacity !! Notes"
|-
| Microsoft Corp. Xbox Memory Unit (8MB) || 0x045e || 0x0280 || 8MB || Official one
|-
| ThrustMaster, Inc. || 0x044f || 0x0f0c || 8MB || Green logo Xbox and white "Trustmaster
|}

== Unlicensed Xbox Memory Units ==
Some unlicensed Memory Units where made.

{| class="wikitable"
! Product name !! VID !! PID !! Capacity !! Notes
|-
| Weltrend Semiconductor XBOX Xploder || 0x040b || 0x6520 || 8MB || Green sticker "Gamesaves"
|}

== Compatible USB sticks ==

Aside from the official licensed Memory Units, some standard USB storage devices can be reformatted as Xbox Memory Unit. (It is rumored that the capacity should not exceed 4GB)
However, not all devices are compatible, so the following table gives a list of known devices:

{| class="wikitable"
! Product name !! VID !! PID !! Capacity !! Notes
|-
|BESTRUNNER 256MB Speicherstick || 0xABCD || 0x1234 || 256MB ||
|-
|USB Mass Storage Device || 0x058F || 0x9381 || 64MB || Generic Mass Storage Device
|-
|[https://www.aliexpress.com/item/33007483881.html Generic Aliexpress Flash Drive] || 0xABCD || 0x1234 || 128MB||
|-
|}

== Protocol ==

=== USB Descriptor (Offical Memory Unit) ===

<pre>
Bus 002 Device 003: ID 045e:0280 Microsoft Corp. Xbox Memory Unit (8MB)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x045e Microsoft Corp.
idProduct 0x0280 Xbox Memory Unit (8MB)
bcdDevice 0.0e
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 60mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 66
bInterfaceProtocol 80
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
</pre>

== References ==

* [http://imgur.com/a/8QmDA Thrustmaster XBOX Memory Unit images by DarkGabz]
* [http://imgur.com/gallery/M0PZ6 3 XBOX memory units images by CodeAsm]

Xbox Hard Drive Locking Mechanism

2021-05-11T14:30:46Z

Billy549: Redirected page to Hard Drive#Locking Mechanism and Basics

#REDIRECT [[Hard Drive#Locking_Mechanism_and_Basics]]

{{retrieved|https://web.archive.org/web/20100617023052/http://www.xbox-linux.org/wiki/Xbox_Hard_Drive_Locking_Mechanism}}

by ''SpeedBump'' (original version: 13 August 2002)

The hard drive in the MS Xbox(tm) is a standard ide drive, which implements a rarely used security feature to restrict access to its data. This document will describe in full the security features, and the algorithms required to access the data on an xbox drive.

==The IDE (ATA) commands==

The ATA spec defines a feature subset which allows for the user to limit access to the drive's data behind a hardware implemented locking mechanism. There are several commands in the SECURITY feature subset, but the command of most interest is the SECURITY_UNLOCK command.

SECURITY_UNLOCK requires that the user provide one of two 32 byte passwords, either a user or master password. The Xbox uses the user password. Details on the data formats and timings for the data to be sent to the ide drive can be found in the ata specs (see [[https://web.archive.org/web/20100617023052/http://www.t13.org/]]).

==The password==

The drive password is generated in two distinct phases. The first phase extracts a key (referred to as the HDKey) from the eeprom data on the Xbox. The HDKey is unique to each Xbox making this first phase dependant only on the Xbox eeprom of the unit. The second phase uses this HDKey to generate a password which is specific to the drive being unlocked (keyed to the model and serial numbers of the drive).

==Drive Data==

During the second phase, the serial and model numbers are needed. These values are available in the response data from the DEVICE_IDENTITY ata command. However, the data needs to be properly reorganized. It is read in big endian words, and needs to be byte swapped first to get the byte ordering correct. Then, starting from the end of the data (serial == 20 bytes, model == 40 bytes) ignore ASCII spaces (byte value of 0x20) at the end of the data. Zeros are *not* trimmed, *only* spaces. Do not be fooled into believing that this data is a string. On some drives this is the case, but on others there are non-ascii values in the fields.

==Basic Security algorithms==

There are two primary crytography routines needed when generating an XBox drive password, SHA1 and RC4.

SHA1 is a hashing algorithm. It's primary purpose is to take an input message and create a (relatively) small signature (called a digest) which is unique to the original message. One of the goals of SHA1 is to make it difficult to alter the input message in such a way as to result in the same output digest.

RC4 is a symmetric cipher. This means that the algorithm for encryption is the same as that for decryption. The purpose is to make one key work in both directions.

There is an algorithm called HMAC which uses a hashing algorithm (in this case SHA1) to generate a cryptographically "strong" signature. I'm sure there is a mathematical basis for this, but I'm not willing to try to understand it :)

==The Password Algorithm==

(some syntax notes, key data is shown entering functions from the side, data is shown entring from above or below, in order of presentation from left to right)

<pre> RC4_key >--(second)-->--,
/|\ |
| |
.-<--|__eeprom_key__|-->-----------> HMAC_SHA1 |
| /|\ |
| | |
| .--->-----------' |
| | |
| eeprom_data = |__data_hash___|__enc_conf__|__enc_data__| |
| | | | |
| | \|/ | |
| | rc4_decrypt <----|---------<|
| | | | |
| \|/ | | |
| (must be equal) | \|/ |
| /|\ | rc4_decrypt <---'
| | | |
| | \|/ \|/
| | |_confounder_|____data____|
| | / / |
| | / / |
| | / / |
| | / / |
| | \|/ / \|/
`--->-----------------> HMAC_SHA1 / |__HDKey__|__|
/|\ / |
\______/ |
|
.-------------------------<--------'
|
| model_number serial_number
| \ /
| \ /
`--->-----------------> HMAC_SHA1
|
\|/
HD_password
</pre>
 
This seems to be the easiest way to show the required calculations.

Basically there are several intermediate steps. First, generate the RC4_key from the eeprom_key and the data_hash (first 20 bytes of eeprom_data). Use the RC4_key to decrypt the encrypted confounder (8 bytes 20 bytes into eeprom_data) and the encrypted data (20 bytes 28 bytes into eeprom_data). Now generate an HMAC_SHA1 hash from the eeprom_key and the decrypted confounder and data. Verify that this hash matches the data_hash stored in the eeprom. If they don't match then the eeprom data is not correct. If the hashes match then the first 16 bytes of the decrypted data field is the HDKey.

Once you have the HDKey get the model number and serial number from the ide drive. Generate an HMAC_SHA1 hash from the HDKey, model and serial numbers. The resulting 20 bytes are the HD password. The remaining 12 bytes needed for the password are zeros.

==Remaining Questions==

The algorithm is well known, however it is dependant on the eeprom_key. It would be ideal if this key could be compiled into a driver to perform the generation and the unlocking. However noone appears to be able to answer the question of legality. Is it legal to privide the eeprom key? Either way, the drive can be unlocked. The ability to distribute the key will only help people use the drive outside the xbox (plus make it simpler to unlock the drive in the xbox).

Xbox Hard Disk Partitioning

2021-05-11T14:29:48Z

Billy549: Redirected page to Hard Drive#Partitions

#REDIRECT [[Hard Drive#Partitions]]

{{retrieved|https://web.archive.org/web/20100617023145/http://www.xbox-linux.org/wiki/Xbox_Hard_Disk_Partitioning|ours=Hard Drive}}

by ''Michael Steil'' (original version: 8 May 2002)

The Xbox uses a hard disk partitioning scheme that is hardwired into the kernel. The hard disk consists of a header, 3 game cache partitions, a system partition and a data partition:

{| class="wikitable"
|-
! Offset
! Size
! Description
|-
| 0 MB <code>0x00000000</code>
| 0.5 MB
| '''Disk Config Area''' This partition contains no filesystem. Various configuration data is stored on fixed offsets. Linux device: <code>none</code>
|-
| 0.5 MB <code>0x00000400</code>
| 750 MB
| '''Game Cache A''' (Drive X:) FATX volume containing temporary data of a game for faster access. Linux device: <code>/dev/hda52</code>
|-
| 750.5 MB <code>0x00177400</code>
| 750 MB
| '''Game Cache B''' (Drive Y:) Linux device: <code>/dev/hda53</code>
|-
| 1500.5 MB <code>0x002EE400</code>
| 750 MB
| '''Game Cache C''' (Drive Z:) Linux device: <code>/dev/hda54</code>
|-
| 2250.5 MB <code>0x00465400</code>
| 500 MB
| '''System Files''' (Drive C:) FATX volume containing menu code, graphics, sound, DVD player, music import, ... Linux device: <code>/dev/hda51</code>
|-
| 2750.5 MB <code>0x0055F400</code>
| 4895 MB
| '''Data''' (Drive E:) FATX volume containing saved games and imported CD audio tracks. Linux device: <code>/dev/hda50</code>
|-
!
!
! '''Non-Standard partitions on disks >8GB'''
|-
| 7645.5 MB <code>0x00EE8AB0</code>
| 1896 MB - 130 GB
| '''Unused/Additional''' (Drive F:) The first xboxes had a 8GB disk, later versions came with a 10GB disk. This the space difference between the two and not used. Some tools allow it to be used as additional FATX filesystem Linux device: <code>/dev/hda55</code> (only present if signature of formatted FATX found) Linux assumes that all remaining space on the disk belongs to this partition unless another FATX filesystem is detected at the LBA28 boundary. See below.
|-
| 137 GB <code>0x0FFFFFFF</code>
| remaining space
| '''LBA28''' (Drive G:) If you install a very big disk some tools are limited by the LBA24 boundary. The drive G allows this space to be used in a separate drive, only accessible to LBA48 capable tools and BIOS'es. Linux device: <code>/dev/hda56</code> (only present if signature of formatted FATX found at LBA24 boundary) Linux assumes that all remaining space on the disk belongs to this partition.
|}

This table has been completed by Markus Baertschi with lots of stuff. There might be errors and misconceptions, caveat emptor !

{| class="wikitable"
|-
! '''Missing image''' ''Icon-admonition-tip.png'' Tip | For a more detailed description of the format and contents of the partitions see [https://web.archive.org/web/20100617023145/http://www.xbox-linux.org/wiki/Xbox_Partitioning_and_Filesystem_Details Xbox Partitioning and Filesystem Details].|}

Xbox Manufacturing Process

2021-05-11T14:26:44Z

Billy549: Add redirect to the new page.

#REDIRECT [[Manufacturing Process]]

{{retrieved|https://web.archive.org/web/20100617013616/http://www.xbox-linux.org/wiki/Xbox_Manufacturing_Process}}

by ''Michael Steil''

There are many different Xboxes. Although they all look the same (except for the "Special Edition"), and all of them work with all games, they have been produced in three different factories and may contain different components.

This article describes the "reverse-engineered" internals of Xbox manufacturing.

==The Serial Number==

Every Xbox has a sticker on the bottom that looks like this:

<img src="https://web.archive.org/web/20100617013616im_/http://www.xbox-linux.org/pic/serial-sticker.jpg" alt="serial-sticker.jpg" />

It contains the manufacturing date and the 12-digit serial number:

<pre>1166356 20903
|| | |||||__
|| | ||||___ factory number
|| | |||____
|| | ||_____ week of year (starting Mondays)
|| | |______ last digit of year
|| |________
||_____________ number of Xbox within week and factory
|______________ production line within factory
</pre>
 
Three factories have produced the Xbox. Mexico (Guadalajara) is "02", Hungary (S�rv�r) is "03" and China (Doumen) is "05".

So this Xbox has been manufactured in week #9, 2002 in line 1 of the factory in Hungary, and it was number 166,356 of this week.

==Factories==

{| class="wikitable"
|-
| '''Date'''
| '''Mexico'''
| '''Hungary'''
| '''China'''
|-
| 10/2001
| Production of 110V 1.0 Xboxes with Thomson drives is started for the USA/Canada market.
| Production of 110V 1.0 Xboxes with Thomson drives is started for the USA/Canada market.
|-
| 01/2002
| Production gets extended for Japan.
| Complete switch to 220V European/Australian models.
|-
| 04/2002
| Production lines #1 and #6 get closed and get moved to China. The other four lines continue production. The first Xboxes with Philips DVD drives are made, now 50% of all Mexican devices have Philips, and 50% have Thomson.
|
|-
| 05/2002
|
| Production stops after only less than 9 months, and after about 3 Million Xboxes. All four production lines get moved to China.
|-
| 08/2002
|
|
| Production of the 220V 1.1 Xbox for Europe and Australia only begins, with mostly Philips and sometimes Thomson DVD drives.
|-
| 09/2002
|
|
| First Samsung DVD drives. Most Xboxes now contain Samsung devices, a few contain Philips ones, and very few still contain Thomson ones.
|-
| 10/2002
| Switch the remaining four lines to version 1.1.
|
|
|-
| 11/2002
|
|
| Production gets extended by 110V USA/Canada/Japan models.
|-
| 12/2002
| Production ends after 14 months, and after nearly 7 Million Xboxes.
|
| First line changes to version 1.2
|-
| 02/2003
|
|
| Last line changes to version 1.2
|-
| 03/2003
|
|
| First line changes to version 1.3
|-
| 04/2003
|
|
| Last line changes to version 1.3
|-
| 07/2003
|
|
| First line changes to version 1.4
|-
| 08/2003
|
|
| First line changes to version 1.5
|}

Look at the <a href="/web/20100617013616/http://www.xbox-linux.org/wiki/Xbox_Versions_HOWTO" title="Xbox Versions HOWTO">Xbox Versions HOWTO</a> for details on when which Chinese line switched to a new version.

==Manufacturing Process==

(Please note that a lot of this information has been concluded from implicit information, it may contain errors.)

When a computer such as the Xbox is manufactured, three very different tasks have to be done:

* assemble the hardware
* copy the software on the hardware
* test the device

The most interesting part about this is when the software is copied, and when and how the device is tested, because there is a lot of room for optimization.

Not counting the firmware of independent components such as the HD, the DVD and the SMC, the Xbox contains three pieces of software:

* The Xbox kernel in Flash ROM
* The hard disk contents (and hard disk key)
* The EEPROM contents

It depends on the device whether it is more convenient to program it before putting it into the Xbox or doing in-system-programming.

===Putting the System together===

The Flash ROM chips gets programmed externally with the final Xbox kernel and then gets soldered onto the Xbox motherboard. The EEPROM is empty when it gets soldered onto it. So is the hard disk when it gets connected.

===The Installation CD===

So when the Xbox is complete, but the EEPROM and the hard disk are still empty and the hard disk is not locked yet, an optical media gets inserted into the DVD drive (this needn't be an Xbox DVD), which contains a properly retail-signed default.xbe built with the XDK that has the allow eject flag set and has the region code set to 0x80000000 ("DEBUG").

When the Xbox kernel initializes, it checksums the EEPROM. If it fails, the Xbox will be in DEBUG mode, i.e. the region code is set to 0x80000000. With the region code set to this value, the kernel ignores it if the hard disk is not locked. Because the region code matches, the kernel will run the executable from CD, which does the following:

* format the three swap partitions
* copy XMTAXBOX.XBE from CD to the first cache partition and run it

Then the DVD can be ejected and put into the next Xbox.

===XMTAXBOX.XBE===

This XMTAXBOX.XBE is an XBE retail-signed for hard disk, also with the region code set to 0x80000000, that does the following:

* retrieve the EEPROM contents from a network server
* retrieve the contents of the system and data partitions from a network server
* lock the hard disk
* make some self tests and send the report to the server

A new Xbox still contains the file XMTAXBOX.XBE on the first cache partition, as well as some temporary files on the third one.

Xbox kernels since version 4034 have another backdoor that even works if the EEPROM check succeeds: If bit 30 of the media flag of an XBE is set, the condition of the hard disk is ignored as well. This change allows Microsoft to replace broken hard disks without replacing a valid EEPROM on an Xbox sent in for repair. Before this change, they had to rewrite the EEPROM whenever they replaced the drive.

<img src="https://web.archive.org/web/20100617013616im_/http://www.xbox-linux.org/pic/repairdvd.jpg" alt="repairdvd.jpg" />
<img src="https://web.archive.org/web/20100617013616im_/http://www.xbox-linux.org/pic/xboxqc.jpg" alt="xboxqc.jpg" /> [https://web.archive.org/web/20100617013616/http://www.amcham.hu/BusinessHungary/16-01/articles/16-01_26.asp]

== Further Reading ==

* [https://web.archive.org/web/20100617013616/http://www.xbox-linux.org/wiki/Xbox_Manufacturing_Process_Pictures Xbox Manufacturing Process Pictures]
* [https://web.archive.org/web/20100617013616/http://www.ifm.eng.cam.ac.uk/ctm/idm/cases/xbox.html] Innovation and Design Management case study
* O'Brien, J. [https://web.archive.org/web/20100617013616/http://www.wired.com/wired/archive/9.11/flex_pr.html The making of the Xbox], Wired, Issue 9.11, November 2001
* Shah, J. and Serant, C. [https://web.archive.org/web/20100617013616/http://www.ebnonline.com/story/OEG20020311S0076 Microsoft's Xbox sets supply chain standard], EBN Online, 11 March 2002
* Olavsrud, T. [https://web.archive.org/web/20100617013616/http://www.internetnews.com/bus-news/article.php/1129171 Flextronics relocates Xbox manufacturing facility], Internetnews.com, 15 May 2002
* Penz, B. [https://web.archive.org/web/20100617013616/http://www.amcham.hu/BusinessHungary/16-06/articles/16-06_27.asp Game Over? Xbox production heads east], Business Hungary, Vol 16 No 6, June 2002
* Carbone, J. [https://web.archive.org/web/20100617013616/http://manufacturing.net/pur/article/CA237778?stt=001&pubdate=08%2F15%2F02 Outsourcing the Xbox], Purchasing Magazine Online, 15 August 2002
* Neilley, R: [https://web.archive.org/web/20100617013616/http://www.immnet.com/articles?article=1763 Molding is big man on this campus]

Xbox Live/Connection Test

2021-03-25T22:00:57Z

Billy549: Add information about the second page from XBL's old page

The network settings screen on the Xbox Dashboard will perform a connection test to Xbox Live when a user edits settings, to ensure that it can still connect to the Internet.

If the user has not connected to Xbox Live before, this will be where the Xbox first connects to create a Machine Account via MACS (Machine Account Creation Service). Then, it will use this account to authenticate the machine and perform a ping test as well as a speed test on dashes before 5960(? double check if this was the first dash to change behaviour).

=== Extra Info ===
Pressing Y once the connection test has finished will show some extra info;

Pressing A on 5960 or later will perform another test using <pre>xds.xboxlive.com</pre> - this server is still up (CNAME'd to xds.gtm.xboxlive.com, IP 65.55.42.21). This will then return three more results:
MT - MTU test, if 1 your MTU is 1365+ and works with Xbox Live, if 0 then <1365
IC - ICMP test, if 1 your router is properly forwarding ICMP, if 0 then not
NT - NAT test, where 1 is open, 2 is moderate, and 3 is strict.

This info is from [https://web.archive.org/web/20040621040049/http://www.xbox.com/en-US/live/connect/Diagnosing.htm Xbox Live's archived diagnostics page]

=== Packet Log ===
Pressing the Black button on the controller once the connection test has finished will save a packet log to the hard drive as a save [FIXME: add more info] - [https://github.com/insignia-live/xbcap2pcap xbcap2pcap] can convert this DAT file into a standard PCAP.

The DAT's structure is as follows:
<pre>
uint32_t total packet length
uint32_t timestamp in ms
total packet length - 8 bytes of Ethernet packet data
</pre>

Xbox Live/Machine Account

2021-03-20T14:14:05Z

Billy549:

All Xboxes that communicate on Xbox Live will have a Machine Account - it's generated the first time a user performs a connection test from the factory on an Xbox Live dashboard (4920 or later).

== Machine Account Creation Service ==

The first time an Xbox connects to Xbox Live from the factory, it'll connect to MACS.XBOXLIVE.COM and use a pre-shared key based from the Online Key, HDD Key, and a unique key present in all Xbox Live binaries. The server will either return an error message, or return a valid machine account for future authentication.

{| class="wikitable"
|+Xbox PA-DATA
|-
! padata-type
! description
|-
|131
| ?
|-
|204
| ?
|-
|206
| Information about Xbox Version, Title, and Title version
|}

Main Page

2021-03-20T14:13:02Z

Billy549:

{{:Main Page/Header}}
__NOTOC__

== Hardware ==

* [[Chihiro]]
* [[Xbox]]

* [[Hardware Revisions]]
* [[Motherboard]]
* [[CPU]]
* [[NV2A]]
** [[NV2A/Vertex attributes]]
** [[NV2A/Fixed Function Pipeline]]
** [[NV2A/Vertex Shader]]
** [[NV2A/Pixel Combiner]]
** [[NV2A/Surface Formats]]
* [[Memory]]
* [[Flash ROM]]
* [[MCPX]]
** [[LPC_Debug_Port|LPC]]
** [[APU]]
*** [[DSP]]
** [[ACI]]
** [[Network]]
* [[PCI]]
* [[SMBus]]
** [[EEPROM]]
** [[SMC]]
** [[Video Encoder]]
*** [[AV Cables]]
* [[DVD Drive]]
** [[Xbox Game Disc]]
* [[Hard Drive]]
** [[Config Sector]]
* [[USB]]
** [[Xbox Input Devices]]
** [[Xbox Memory Unit]]
** [[Xbox Live Communicator]] 
** [[Xbox DVD Movie Playback Kit]]
* [[Power Supply]]
* [[Development Kits]]
** [[Super I/O]]
** [[DVD Emulator]]
* [[Manufacturing Process]]

== System Software ==
* [[MCPX ROM]]
* [[BIOS]] / [[Kernel]]
** [[Boot Process]]
** [[XBE]] (Executable file format)
* [[FATX]] (Filesystem)
* [[Xbox ADPCM]]
* [[Dashboard]]
** [[Soundtracks]]
** [[Fatal Error]]
* [[Exploits]]

== Development Kits and Tools ==
* [https://github.com/xqemu/nxdk nxdk (New Xbox Development Kit)]
* [[OpenXDK]]
* [[Microsoft XDK]]
** [[Xbox Title Libraries]]
** [[Direct3D]]
** [[DirectSound]]
** [[System Link]]
** [[Xbox Live]]
*** [[Xbox Live/Connection Test|Connection Test]]
*** [[Xbox Live/Machine Account|Machine Account]]
** [[Xbox Debug Monitor]]
** [[Xbox Neighborhood]]
** [[Kernel_Debug|Xbox Kernel Debugging]]

== Games ==
* [[:Category:Games|Games]]
* [[Engine List]]

== Emulation ==
* [[Emulators]]
** [[XQEMU]]
** [[Fusion]]
** [[Fission]]

== Historical Pages ==
(archived from the xbox-linux wiki)
* [[Xbox Hard Drive Locking Mechanism]]
* [[Xbox Savegame System]]
* [[Xbox Hardware Overview]]
* [[Xbox Hard Disk Technical_Details]]
* [[Xbox Hard Disk Partitioning]]
* [[Xbox Manufacturing Process]]
* [[The Hidden Boot Code of the Xbox]]
* [[PIC]]
* [[SMBus]]
* [[NForce]]
* [[17 Mistakes Microsoft Made in the Xbox Security System]]
* [[Porting an Operating System to the Xbox HOWTO]]

== Other ==
* [[Patents]]
* [[Resources]]

Xbox Live

2021-03-20T14:12:43Z

Billy549:

Xbox Live is an online multiplayer gaming and digital media delivery service created and operated by Microsoft. It was first made available to the Xbox system in November 2002. ([https://en.wikipedia.org/wiki/Xbox_Live Wikipedia]) Xbox Live support for the original Xbox ended in April 15, 2010.

The Xbox Live architecture consists of Kerberos-based authentication tickets, with a Secure Gateway used to then access services (such as Matchmaking, Statistics/Leaderboards, and custom game servers)

Authentication and access to Xbox Live services is controlled using the Kerberos protocol with a few proprietary customisations for the Xbox. When an Xbox first connects, the server gives it a [[Xbox Live/Machine Account|Machine Account]] which it uses to access the service; this machine account is always sent, but it can only be used alone to access UACS (User Account Creation Service) to create a user account - with both a machine account and user account, all other services are accessible.

=== XDK Functions ===

{| class="wikitable"
|+XOnline* Functions
|-
! function
! description
|-
|XOnlineGetUsers(XONLINE_USER* XBLAccountusers, DWORD* numOfXBLiveAccounts)
|The XOnlineGetUsers function will enumerate both the hard disk and any attached memory units looking for user accounts
|-
|XOnlineTaskClose(XONLINETASK_HANDLE logonHandle)
|Called to abort the authentication process.
|-
|XOnlineStartup( XONLINE_STARTUP_PARAMS* )
|
|-
|XOnlineLogon(XONLINE_USER* XBLLoggedOnUsers, DWORD* XBLservices, DWORD SERVICE_COUNT, NULL, XONLINETASK_HANDLE &logonHandle)
|When a title calls XOnlineLogon to sign in, instead of blocking until the authentication completes, an asynchronous task handle is returned. As part of the authentication process a title must specify which services it will be using (XBLservices, SERVICE_COUNT).
|-
|XOnlineTaskContinue(XONLINETASK_HANDLE logonHandle)
|Called to check the status of XOnlineLogon. It will return XONLINETASK_S_RUNNING while the login process has not been completed.
|-
|XOnlineLogonTaskGetResults(XONLINETASK_HANDLE logonHandle)
|Will return XONLINE_S_LOGON_CONNECTION_ESTABLISHED when the task is successfully completed. Otherwise it will return an error code.
|-
|XOnlineGetLogonUsers()
|This returns a pointer to an array of XONLINE USER structures. This array is similar the XONLINE USER array we populated and passed into XOnlineLogon, but is updated with error status and permission flags for each user.
|-
|XOnlineSetUserGuestNumber(dwUserFlags , 1)
|
|-
|XOnlineTitleUpdate(DWORD)
|The XOnlineTitleUpdate function will boot into an updater application, which performs the actual update
|-
|XOnlineGetServiceInfo(Service, ?)
|XOnlineGetServiceInfo returns the connection status for a service
|-
|XOnlineNotificationSetState
|
|}

== Discontinuation of service ==

The service was officially discontinued on April 15th, 2010.

12 players decided to stay in a lobby of ''Halo 2'' 24/7 to keep a server running.
The final player, Apache N4SIR was streaming the entire event, as the player count of 12 twindeled down to just him. At 11:40 PM PDT, on May 11th 2010, Apache N4SIR was booted from the game[http://i.imgur.com/oQw6k5H.jpg].

Xbox Live/Machine Account

2021-03-20T14:12:34Z

Billy549: Create Machine Account page

All Xboxes that communicate on Xbox Live will have a Machine Account -

== Machine Account Creation Service ==

The first time an Xbox connects to Xbox Live from the factory, it'll connect to MACS.XBOXLIVE.COM and use a pre-shared key based from the Online Key, HDD Key, and a unique key present in all Xbox Live binaries. The server will either return an error message, or return a valid machine account for future authentication.

{| class="wikitable"
|+Xbox PA-DATA
|-
! padata-type
! description
|-
|131
| ?
|-
|204
| ?
|-
|206
| Information about Xbox Version, Title, and Title version
|}

Main Page

2021-03-20T14:03:07Z

Billy549: /* Development Kits and Tools */

{{:Main Page/Header}}
__NOTOC__

== Hardware ==

* [[Chihiro]]
* [[Xbox]]

* [[Hardware Revisions]]
* [[Motherboard]]
* [[CPU]]
* [[NV2A]]
** [[NV2A/Vertex attributes]]
** [[NV2A/Fixed Function Pipeline]]
** [[NV2A/Vertex Shader]]
** [[NV2A/Pixel Combiner]]
** [[NV2A/Surface Formats]]
* [[Memory]]
* [[Flash ROM]]
* [[MCPX]]
** [[LPC_Debug_Port|LPC]]
** [[APU]]
*** [[DSP]]
** [[ACI]]
** [[Network]]
* [[PCI]]
* [[SMBus]]
** [[EEPROM]]
** [[SMC]]
** [[Video Encoder]]
*** [[AV Cables]]
* [[DVD Drive]]
** [[Xbox Game Disc]]
* [[Hard Drive]]
** [[Config Sector]]
* [[USB]]
** [[Xbox Input Devices]]
** [[Xbox Memory Unit]]
** [[Xbox Live Communicator]] 
** [[Xbox DVD Movie Playback Kit]]
* [[Power Supply]]
* [[Development Kits]]
** [[Super I/O]]
** [[DVD Emulator]]
* [[Manufacturing Process]]

== System Software ==
* [[MCPX ROM]]
* [[BIOS]] / [[Kernel]]
** [[Boot Process]]
** [[XBE]] (Executable file format)
* [[FATX]] (Filesystem)
* [[Xbox ADPCM]]
* [[Dashboard]]
** [[Soundtracks]]
** [[Fatal Error]]
* [[Exploits]]

== Development Kits and Tools ==
* [https://github.com/xqemu/nxdk nxdk (New Xbox Development Kit)]
* [[OpenXDK]]
* [[Microsoft XDK]]
** [[Xbox Title Libraries]]
** [[Direct3D]]
** [[DirectSound]]
** [[System Link]]
** [[Xbox Live]]
*** [[Xbox Live/Connection Test|Connection Test]]
** [[Xbox Debug Monitor]]
** [[Xbox Neighborhood]]
** [[Kernel_Debug|Xbox Kernel Debugging]]

== Games ==
* [[:Category:Games|Games]]
* [[Engine List]]

== Emulation ==
* [[Emulators]]
** [[XQEMU]]
** [[Fusion]]
** [[Fission]]

== Historical Pages ==
(archived from the xbox-linux wiki)
* [[Xbox Hard Drive Locking Mechanism]]
* [[Xbox Savegame System]]
* [[Xbox Hardware Overview]]
* [[Xbox Hard Disk Technical_Details]]
* [[Xbox Hard Disk Partitioning]]
* [[Xbox Manufacturing Process]]
* [[The Hidden Boot Code of the Xbox]]
* [[PIC]]
* [[SMBus]]
* [[NForce]]
* [[17 Mistakes Microsoft Made in the Xbox Security System]]
* [[Porting an Operating System to the Xbox HOWTO]]

== Other ==
* [[Patents]]
* [[Resources]]

Xbox Live/Connection Test

2021-03-20T14:01:31Z

Billy549: Add Connection Test page

The network settings screen on the Xbox Dashboard will perform a connection test to Xbox Live when a user edits settings, to ensure that it can still connect to the Internet.

If the user has not connected to Xbox Live before, this will be where the Xbox first connects to create a Machine Account via MACS (Machine Account Creation Service). Then, it will use this account to authenticate the machine and perform a ping test as well as a speed test on dashes before 5960(? double check if this was the first dash to change behaviour).

=== Extra Info ===
Pressing Y once the connection test has finished will show some extra info, and on 5960 dash and later will also perform an MTU test(? plaintext in the packet says MTU test) using the domain XXXXX.XBOXLIVE.COM (which the 360 also uses)

=== Packet Log ===
Pressing the Black button on the controller once the connection test has finished will save a packet log to the hard drive as a save [FIXME: add more info] - [https://github.com/insignia-live/xbcap2pcap xbcap2pcap] can convert this DAT file into a standard PCAP.

The DAT's structure is as follows:
<pre>
uint32_t total packet length
uint32_t timestamp in ms
total packet length - 8 bytes of Ethernet packet data
</pre>

17 Mistakes Microsoft Made in the Xbox Security System

2020-10-30T19:29:52Z

Billy549: Change URLs - remove web archive (CCC keeps their data up for old congresses) and change Google Video links to YouTube (asked in Discord)

{{retrieved|https://web.archive.org/web/20100617003620/http://www.xbox-linux.org/wiki/17_Mistakes_Microsoft_Made_in_the_Xbox_Security_System}}

by [https://web.archive.org/web/20100617003620/http://www.xbox-linux.org/wiki/User:Michael_Steil Michael Steil]

{| class="wikitable"
|-
|

This [https://events.ccc.de/congress/2005/fahrplan/attachments/591-paper_xbox.pdf paper], dated 2005-10-25, has been submitted to the [http://events.ccc.de/congress/2005/ 22nd Chaos Communication Congress] and has been on [https://events.ccc.de/congress/2005/fahrplan/events/559.en.html December 29th 2005, 18:00], at the Berliner Congress Center, Berlin, Germany.

A '''recording''' of the presentation is available here: [https://www.youtube.com/watch?v=VdeciDTCCLQ YouTube: Team Xbox-Linux at 22C3].

'''Another recording''' of a slightly updated talk is available here: [https://www.youtube.com/watch?v=9NqLljaHc80 YouTube: Deconstructing The Xbox Security System]

|}

== Introduction ==

The Xbox is a gaming console, which has been introduced by Microsoft Corporation in late 2001 and competed with the Sony Playstation 2 and the Nintendo GameCube. Microsoft wanted to prevent the Xbox from being used with copied games, unofficial applications and alternative operating systems, and therefore designed and implemented a security system for this purpose.

This article is about the security system of the Xbox and the mistakes Microsoft made. It will not explain basic concepts like buffer exploits, and it will not explain how to construct an effective security system, but it will explain how ''not'' to do it: This article is about how easy it is to make terrible mistakes and how easily people seem to overestimate their skills. So this article is also about how to avoid the most common mistakes.

For every security concept, this article will first explain the design from Microsoft's perspective, and then describe the hackers' efforts to break the security. If the reader finds the mistakes in the design, this proves that Microsoft has weak developers. If, on the other hand, the reader doesn't find the mistakes, this proves that constructing a security system is indeed hard.

=== The Xbox Hardware ===

Because Microsoft had a very tight time frame for the development of the Xbox, they used off-the-shelf PC hardware and their Windows and DirectX technologies as the basis of the console. The Xbox consists of a Pentium III Celeron mobile 733 MHz CPU, 64 MB of RAM, a GeForce 3 MX with TV out, a 10 GB IDE hard disk, an IDE DVD drive, Fast Ethernet, as well as USB for the gamepads. It runs a simplified Windows 2000 kernel, and the games include adapted versions of Win32, libc and DirectX statically linked to them.

Although this sounds a lot more like a PC than, for example, a GameCube with its PowerPC processor, custom optical drive and custom gamepad connectors, it is important to point out that, from a hardware point of view, the Xbox shares ''all'' properties of a PC: It has LPC, PCI and AGP busses, it has IDE drives, it has a Northbridge and a Southbridge, and it includes all the legacy PC features such as the "PIC" interrupt controller, the "PIT" timer and the A20 gate. nVidia sold a slightly modified Southbridge and a Northbridge with another graphics core embedded for the PC market as the "nForce" chipset between 2001 and 2002.

=== Motivation for the Security System ===

The Xbox being a PC, it should be trivial to install Linux on it in order to have a cheap and, for that time, powerful PC. Even today, a small and silent 733 MHz PC with TV connectivity for 149 USD/EUR is still attractive. But this is not the only thing Microsoft wanted to prevent. There are three uses that should not have been possible:

* '''Linux''': The hardware is subsidized and money is gained with the games, therefore people should not be able to buy an Xbox without the intent to buy any games. Microsoft apparently feels that allowing the Xbox to be used as a (Linux) computer would be too expensive for them.
* '''Homebrew/Unlicensed''': Microsoft wants the software monopoly on the Xbox platform. Nobody should be able to publish unlicensed software, because Microsoft wants to gain money with the games to amortize the hardware losses, and because they do not want anyone to release non-Internet Explorer browsers and non-Windows Media Player multimedia software.
* '''Copies''': Obviously it is important to Microsoft that it is not possible to run copied games on the Xbox.

Microsoft decided to design a single security system that was supposed to make Linux, homebrew/unlicensed software and copies impossible. The idea to accomplish this was by simply locking out all software that is either not on the intended (original) medium or not by Microsoft.

On the one hand, this idea makes the security system easier and there are less possible points off attack. But on the other hand, 3 times more attackers have a single security system to hack: Although Open Source and Linux people, homebrew developers, game companies as well as crackers have little common interests, they could unite in this case and jointly hack the Xbox security system.

Of the three consoles of its generation, Xbox, Playstation 2 and GameCube, the Xbox is the one whose security system has been compromised first, the one that is now easiest to modify for a hobbyist, the one with the most security system workarounds, and the one with the most powerful hacks. This may be, because the Xbox security is the weakest one of the three, but also because Open Source people, homebrew people and crackers attacked the Xbox, while the Open Source people did not attack the Playstation 2, as Linux had been officially supported by Sony, so the total number of hackers was lower, buying them time.

=== Idea of the Security System ===

In order to allow only licensed and authentic code to run, it is necessary to build a TCPA/Palladium-like chain of trust, which reaches from system boot to the actual execution of the game. The first link is from the CPU to the code in ROM, which includes the Windows kernel, and the second link is from the kernel to the game.

There are several reasons that the operating system is contained in ROM (256 KB) instead of being stored on hard disk, like on a PC. First, it allows a faster startup, as the kernel can initialize while the hard disk is spinning up, furthermore, there is one link less in the chain of trust, and in case verification of the kernel gets compromised, it is harder to overwrite a ROM chip than modify data on a hard disk.

== Startup Security ==

When turned on, x86-compatible CPUs start at the address 0xFFFFFFF0 in the address space, which is usually flash memory. For the Xbox, this is obviously no good idea, as flash memory can be

* replaced, by removing the chip, fitting a socket and inserting a replacement chip.
* overridden, by adding another flash memory chip to the LPC bus. This override functionality is necessary, because during manufacturing, an empty flash memory chip gets soldered onto the board, an override LPC ROM chip gets connected to the board and the system boots from the external ROM, which then programs the internal flash memory. This procedure is significantly cheaper than preprogramming the flash memory chips.
* reprogrammed, because flash memory can be written to many times. It would be possible to use ROM instead of flash memory, but ROM is more expensive than flash memory.

Thus, the machine must not start from flash memory.

=== Microsoft's Perspective ===

It would be possible to make two of the attacks impossible, by using ROM chips instead of flash. There would be no way to reprogram them, and it would be possible to disable the LPC override functionality in the chipset, because it is not needed for the manufacturing process any more.

==== The Hidden ROM ====

There is a solution between flash memory and ROM that combines advantages of both these approaches. This trick is rather old and had already been used in previous gaming consoles like the Nintendo 64: Use a tiny non-replaceable startup ROM, and put the bulk of the firmware data (i.e. the Windows kernel) into flash memory. The "internal" ROM checks whether the contents of the flash memory are authentic, and if yes, it passes execution to it.

This way, there will be another link in the chain of trust, but the ROM code can be trusted (if it is non-replaceable), and if, in addition, it is non-accessible, an attacker may not even have a clue how verification works.

==== Location of the ROM ====

But where can this ROM be put? It cannot be a separate chip, as it would be replaceable. It would have to be included into another chip. The CPU would be ideal, as the ROM contents would not travel over any visible bus, but then it would be impossible to use cheap off-the-shelf Celerons. Including it in any other chip would make it non-replaceable, but data would travel over a bus. It seems to be a good compromise to store the ROM data in the Southbridge ("MCPX"), as it is connected via the ''very'' fast HyperTransport bus, so it is very hard to sniff. A former Microsoft employee confirmed that the developers tought that nobody was able to sniff HyperTransport.

==== Verification Algorithm ====

This secret ROM stored in the Southbridge must verify the Windows kernel in the external flash memory before executing it. One idea would be to checksum (hash) the flash contents using an algorithm like MD5 or SHA-1, but this would mean that the hash of the kernel has to be stored in the secret ROM as well, which would make it imposible to ship updated versions of the kernel in future Xboxes without also updating the ROM contents - which would be very expensive.

A digital signature algorithm like RSA would be better: It would be possible to update the kernel without changing the ROM, but an RSA implementation takes up a lot of space, and embedded ROM in the Southbridge is expensive. It would be ideal if the algorithm fit in only 512 bytes, which is impossible for RSA.

==== Second Bootloader ("2bl") ====

A solution for this problem is again to introduce another link in the chain of trust: The ROM only hashes a small loader ("2bl", "second bootloader") in flash memory, which can never be changed. It is then the job of this loader to verify the rest of flash, and as the second loader can be any size, there are no restrictions.

So the final chain of trust looks like this: The CPU boots from the secret ROM embedded into the Southbridge, which cannot be changed. The secret ROM verifies the second bootloader in flash memory using a hash algorithm, and if it is authentic, runs it. The second bootloader checks the kernel, and if authentic, runs it.

Now the second bootloader and the Windows kernel would be stored in flash memory in plain text, which is a bad idea: An attacker can immediately see how the second bootloader verifies the integrity of the kernel, and even analyze the complex kernel for possible exploits. Encrypting all the flash contents will not solve possible vulnerability problems, but it will buy us time until the decryption of the flash contents is understood by hackers.

The decryption key would have to be stored in the secret ROM, and the 2bl verification code would also have to decrypt the flash contents into RAM while reading it.

==== RAM Initialization ====

Decrypting flash memory contents into RAM is a challenge if we are living inside the first few hundred bytes of code after the machine has started up: At this point, RAM might not be stable yet. The reason for this is that Microsoft bought cheap RAM chips; they just took everything Samsung could give them to lower the price, even faulty ones, i.e. chips that will be unstable when clocked at the highest frequencies specified.

The Xbox is supposed to find out the highest clock speed the RAM chips can go and run them at this frequency - this is the reason why some games don't run as smoothly on some Xboxes as on others. So the startup code in the secret ROM has to do a memory test, and if it fails, clock down the RAM, do another memory test, and if it fails again, clock down again, and so on, until the test succeeds or the RAM cannot be clocked down any further.

The problem now is that it is impossible to do complex RAM initialization, data decryption and hashing in 512 bytes. This code would need at least 2 KB, which would be significantly more expensive, if embedded into the Southbridge.

We could put the RAM initialization code, which is the biggest part of what the startup code needs to do, into flash memory, and call it from the secret ROM, but this would kill security, as an attacker could easily see the unencrypted code in flash, modify it and have the control of the machine right at the startup.

The developers at Microsoft had a brilliant idea how to solve this problem: They designed an interpreter for a virtual machine that can read and write memory, access the PCI config space, do "AND" and "OR" calculations, jump conditionally etc. The instruction code has one byte instructions and two 32 bit operands, it can use immediate values as well as an accumulator.

The interpreter for the virtual machine is stored in the secret ROM, and its code ("xcodes") is stored in flash memory. This code does the memory initialization (plus extra hardware initialization, which would not be necessary). This program cannot be encrypted, as there is again no space for it in the secret ROM, but as the virtual machine is unknown to the hacker, encryption should not be that important. It also cannot be hashed, as this would make it impossible to change the xcodes for later revisions of the Xbox hardware. Therefore we have to make sure that, if the hacker knows how the virtual machine works, it is impossible to do anything malicious with the xcodes.

==== The Virtual Machine ====

There are several ways an attacker could exploit the xcodes, which are by definition untrusted, because they reside in "external" flash memory. Microsoft included some code to make sure there were no possible exploits.

===== Read the Secret ROM =====

The xcodes can read memory and access I/O ports. This way an attacker could place xcodes into flash memory that dump the secret ROM, which must be mapped into the address space somewhere, to a slow bus, like the LPC or the I2C bus, or write it into CMOS or the EEPROM, so that we can read it later.

The xcode interpreter has to make sure that the xcodes cannot read the secret ROM, which is located at the upper 512 bytes of the address space. The simplest way to accomplish this is to mask the address when reading from memory:

<pre> and ebx, 0FFFFFFFh  ; clear upper 4 bits
mov edi, [ebx]  ; read from memory location op1 into di
jmp next_instruction
</pre>

This way, the xcodes can only ready from the lower 256 MB, which is no problem, as there are only 64 MB of RAM, and memory mapped I/O can be mapped into this region using PCI config cycles.

===== Turn off the Secret ROM =====

The xcodes may also not turn off the secret ROM, or else the CPU, while executing the xcode interpreter, would "fall down" from the secret ROM into the underlying flash ROM, which is also mapped to the top end of the address space. The turn off functionality is important: As soon as the second bootloader takes over, the secret ROM has to be turned off, or else an attack against a game, which makes it possible to run arbitrary code, could dump the secret ROM, making additional attacks against it possible.

The secret ROM can be turned off by writing a value with bit #1 set to the PCI config space of device 0:1:0, register 0x80. So the xcode interpreter always clears this bit in case there is a write to this PCI config space register:

<pre> cmp ebx, 80000880h  ; ISA Bridge, MCPX disable?
jnz short not_mcpx_disable ; no
and ecx, not 2  ; clear bit 1
not_mcpx_disable:
mov eax, ebx
mov dx, 0CF8h
out dx, eax  ; PCI configuration address
add dl, 4
mov eax, ecx
out dx, eax  ; PCI configuration data
jmp short next_instruction
</pre>

==== Encryption and Hashing ====

For the decryption of the second bootloader, Microsoft chose the RC4 algorithm, which is pretty small, as it fits into 150 bytes. It uses a 16 bytes key, which is also stored in the secret ROM. Microsoft's engineers also chose to use RC4 as a hash, so that no additional algorithm had to be implemented for this. Differential decryption algorithms feed the decrypted data into the generator of the decryption key stream, so if the encrypted code is changed at one byte, all the following bytes will decrypted incorrectly, up to the last bytes. This way, it is possible to only test the last few bytes. If they have been decrypted correctly, then the encrypted code has been authentic. (If you are getting suspicious now - read on!)

In practice, the secret ROM in the Xbox compares the last decrypted 32 bit value with the constant of 0x7854794A. If it is incorrect, the Xbox has to panic.

==== Panic Code ====

So far, the code in the secret ROM does this:

* Enter protected mode, and set up segment descriptors, so that we have access to the complete flat 32 bit address space.
* Interpret the xcodes.
* Decrypt and hash the second bootloader, store it in RAM
* If the hash is correct, jump to the decrypted second bootloader in RAM, else panic.

There is another possible attack here: A hacker could deliberately make the hash fail. If the Xbox then halts and flashes its lights to indicate an error, the attacker can attach a device to dump the secret ROM after the CPU has shut down and the bus is idle. Although HyperTransport is fast, it would be a lot easier to attach a device that actively requests the data from the Southbridge than sniffing it when the CPU requests it.

One solution would be not to halt but to shut down the Xbox in case of a problem. The support chips have this functionality. But incorrect flash memory does not necessarily mean that there has been an attack, it could also be a malfunction, and the machine should use the LED to blink an error code.

So we should leave the Xbox running, but just turn off the secret ROM, so that it cannot be read any more. But there is a problem: We have to do this inside the secret ROM. So if we disable the ROM, we cannot have the "hlt" instruction after that, because the CPU will "fall down" into flash memory - where an attacker could put code. On the other hand, if we halt the CPU, we cannot turn off the secret ROM afterwards.

We cannot put the disable and halt code into RAM and jump there, because RAM might not be stable, and might even have been tampered with by an attacker (e.g. by turning off the memory controller using the xcodes) so that the secret ROM does not get turned off. We cannot put the disable and halt code into flash either, as again, an attacker could simply put arbitrary code to circumvent the complete system there.

The Microsoft engineers used yet another brilliant trick: They jump to the very end of the address space (which is covered by the secret ROM) and turn off the secret ROM in the very last instruction inside the address space. This is a simplified version of the idea:

<pre>FFFFFFF1 mov eax, 80000880h
FFFFFFF6 mov dx, 0CF8h
FFFFFFF9 out dx, eax
FFFFFFFB add dl, 4
FFFFFFFC mov al, 2
FFFFFFFE out dx, al
</pre>

After the last instruction, the program counter (EIP) will overflow to 00000000, which, according to the CPU documentation, causes an exception, and as there is no exception handler set up, it causes a double fault, which will effectively halt the machine.

=== The Hacker Perspective ===

So much for the theory. The design looked pretty good, although the trade off between cost and security as it has been decided, might give some people headaches. Let us now have a look at the Xbox from the hackers' point of view.

It has been well known that the Xbox chipset is a modified version of nVidia's nForce chipset, so we knew that it was standard IDE, USB, there was an internal PCI bus and so on. Two hackers from Great Britain, Luke and Andy, checked the hard disk and found out that it uses a custom partitioning scheme, a FAT-like filesystem, that there is no kernel on the hard disk, but there is the Xbox Dashboard on the fourth partition, the main program that gets executed if there is no game in the DVD drive, which allows changing settings, playing audio CDs and managing savegames.

==== Extracting the Secret ROM ====

Andrew "bunnie" Huang, then a PhD student at the MIT, disassembled his Xbox, saw the flash memory, de-soldered it, extracted the contents, put it on his website and got a phone call from one of Microsoft's lawyers.

The flash memory image was obviously encrypted, but there was x86 binary code in the upper 512 bytes! Obviously, there should be no code in the upper 512 bytes, as this gets overridden by the secret ROM, which contains the actual machine setup and flash decryption code.

Bunnie found out that this code was an interpreter for tables in flash memory, plus a decryption function that looked like RC4. He rewrote the crypto code in C and tried it on the data - but the resulting data was random, obviously something was wrong. The interpreter didn't make much sense either. The code used opcodes that were unknown to the interpreter.

In order to find out what was wrong, bunnie rewrote the top of flash with his own code, and later even completely erased the upper 512 bytes, but the Xbox still booted! So it was obvious to him that this region gets overridden by some internal code. As it turned out later, the code in the upper 512 bytes of the flash image was a very old version of the secret ROM code, which had been unintentionally linked to the image by the build tools. It seems like nobody had looked at the resulting image at the end, before they shipped the consoles. This mistake was very close to a fatal one, and Microsoft was lucky that they didn't link the actual version of the secret ROM.

But it didn't make that much of a difference, as bunnie sniffed the busses, and eventually dumped the complete secret ROM, including the RC4 key from HyperTransport, using a custom built sniffer - after all, he was working on his PhD degree about high performance computing, and he could use the excellent resources of the MIT hardware lab.

When he published his findings, other people found out quite quickly that the validity check did nothing at all: The combination of decryption and hash with a cypher that feeds back the decrypted data into the key stream is a good idea, but unfortunately, RC4 is no such cypher. It decrypts bytes independently, so if one byte is wrong, all the following bytes will still be decrypted correctly. So checking the last four bytes has no effect: There is no hash.

It turned out that the cypher used in the old version of the secret ROM as found in flash memory used the RC5 cypher. In contrast to RC4, RC5 does feed the decrypted stream back into the key stream. So they seem to have replaced RC5 with RC4 without understanding that RC4 cannot be used as a hash. Bunnie's theory why they abandoned RC5 is that RC5 was still a work in progress, and that Microsoft wasn't supposed to have it, so they went for the closest relative - RC4.

==== Modchips ====

Now that the encryption key was known and there was effectively no hash over the second bootloader, it was possible to patch this code: People added code to the second bootloader to patch the kernel after decryption (and decompression) to accept executables even if on the wrong media (DVD-R instead of original) or if the RSA signature of the executables was broken (i.e. unsigned homebrew software).

Modchips appeared: Some of them had a complete replacement flash memory chip on them, others only patches a few bytes and passed most reads down to the original flash chip. All these modchips had to be soldered in parallel to the original flash chip, using 31 wires.

Now other people found out that, if the flash chip is completely missing, the Xbox wants to read from a (non-existant) ROM chip connected to the (serial) LPC bus. This is of course because of the manufacturing process: As it has been explained before, the flash chip gets programmed in-system, the first time they are turned on, using an external LPC ROM chip. Modchip makers soon developed chips that only needed 9 wires and connected to the LPC bus. It was enough to ground the data line D0 to make the Xbox think that flash memory is empty.

Lots of these "cheapermods" appeared, as they only consisted of a single serial flash memory chip. They could be installed within minutes, especially after some companies started shipping chips that used pogo pins, so that no soldering was required.

Some groups wrote applications like boot menus that made it possible to copy games to hard disk and run them from there. Patched Xbox kernels appeared that supported bigger hard disks. Making the Xbox run copies from DVD-R or hard disk as well as homebrew applications written with the official Xbox SDK was now easy.

==== Backdoors ====

The Xbox Linux Project was working on two ways to start Linux: Either run the Linux kernel from a CD/DVD as if it was a game, or run it directly from flash memory, or from HD/DVD using a Linux bootloader in flash memory, so that the Xbox behaved like a PC. For the latter, Xbox Linux was working on a replacement firmware.

It would have been no problem to write a replacement firmware that took over execution instead of the second bootloader, as it was possible to completely replace this second bootloader, as well as encrypt it, using the well-known key from the secret ROM. But the firmware developers felt very uncomfortable with the idea of using this secret key in their GPL code. Other hackers felt the same, and thus were looking for bugs and backdoors in the secret ROM code, in order to find a way to be able to implement a replacement firmware without having to deal with encryption.

===== The Visor Backdoor =====

A hacker named visor, who never revealed his real name, wondered whether the rollover to 00000000 in case of an incorrect 2bl "hash" really caused a double fault and halted the CPU. He used the xcodes to write the assembly instruction for "jmp 0xFFFF0000" to the memory location 00000000 in RAM and changed the last four bytes in 2bl, in order to make the secret ROM run the panic code. The Xbox happily continued executing code at 00000000 and took the jump into flash.

When appending these instructions to the existing xcodes, he could make sure that RAM had been properly initialized and was thus stable. So there was no need to encrypt the Xbox Linux bootloader firmware with the secret key any more. It was enough to add the memory write instruction to the end of the xcodes and make sure that 2bl decryption fails - which will automatically happen, if the firmware replacement does not contain the 2bl code.

Now why is there no double fault? Hackers from the Xbox Linux team checked with AMD employees and they explained that AMD CPUs ''do'' throw an exception in case of EIP overflows, but Intel CPUs don't.

The reason that Intel CPUs don't is because of... 1970s stuff. Execution on x86 CPUs starts at the top of the address space (minus 16 bytes), but some computer makers wanted to have their ROM at the bottom of the address space, i.e. at 0, so Intel implemented the instruction with the encoding 0xFFFF, which is what you get when reading from addresses not connected to any chip, as a No-Operation ("nop") and made the CPU throw no exception in case of the address space wraparound. This way, the CPU would "nop" its way up to the top, and finally execute the code at 0.

AMD did not implement this behavior, as it had not been necessary any more by the time AMD entered the x86 market with it own designs, and because they felt that this behavior was a security risk and fixing it would not mean a significant incompatibility.

But why did Microsoft do it wrong? This can be explained with the history of the Xbox: AMD offered to design and manufacture both the CPU and the motherboard (including the chipset), and nVidia was contracted to contribute the graphics hardware. The first developer systems, even outside of Microsoft, were Athlon-based, but then Intel came in and offered their chips for less money, as well as the complementary redesign of the existing AMD chipset to work with their CPU. Consequently, nVidia licensed the AMD chipset so that the AMD name vanished. This also means, that nVidia nForce chipset is essentially AMD technology, closely related to the AMD-760 chipset.

So when Microsoft switched from AMD to Intel, they apparently forgot to test their security code again with the new hardware, or to read the Intel datasheets.

===== The MIST Hack =====

Soon after the visor hack, another vulnerability was found in the secret ROM code, attacking the code that checks whether an xcode wants to disable the secret ROM. Let us look at this code again:

<pre> cmp ebx, 80000880h  ; ISA Bridge, MCPX disable?
jnz short not_mcpx_disable ; no
and ecx, not 2  ; clear bit 1
not_mcpx_disable:
mov eax, ebx
mov dx, 0CF8h
out dx, eax  ; PCI configuration address
add dl, 4
mov eax, ecx
out dx, eax  ; PCI configuration data
jmp short next_instruction
</pre>

The PCI config address is stored in the EBX register in the beginning. This address has to be sent to I/O port 0x0CF8, and the 32 bit data has to be sent to I/O port 0x0CFC. The address is encoded like this:

<pre>0-7 reg
8-10 func
11-15 device
16-23 bus
24-30 reserved
31 always 1
</pre>

The attack is pretty obvoius: there are seven reserved bits in the address, and the code tests for a single exact value. What happens if we write to an alias of the same address, by using an address with only some of the bits 24 to 30 changed? While the instruction

<pre>POKEPCI(80000880h, 2)
</pre>

will be caught, the instruction

<pre>POKEPCI(C0000880h, 2)
</pre>

will not be caught - and works just as well, because the PCI bus controller just ignores the unused bits.

This instruction disables the secret ROM, that is, the interpreter disables itself when sending the value to port 0x0CFC, and the CPU falls down to flash memory. We can put a "landing zone" into flash, by filling all of the top 512 bytes with "nop" instructions, and putting a jump to the beginning of flash into the last instruction, so that we do not have to care where exactly the CPU lands after falling down, and we are independent of possibly hard to reproduce caching effects.

It is hard to find a good reason for this bug other than carelessness. It might be attributed to not reading the documentation closely enough, as well as not looking at it from the perspective of a hacker well enough. After all, this code had been written with a specific attack in mind - but the code made hacking easier, by giving hackers a hint how to attack.

===== Another PCI Config Space Attack =====

There is a second sequence of xcode instructions that can disable the secret ROM just as well, which are not caught by the interpreter: The interpreter supports writing bytes to I/O ports, so it is possible to put together the code to disable the secret ROM using 8 bit I/O writes:

<pre>OUTB(0xcf8), 0x80
OUTB(0xcf9), 0x08
OUTB(0xcfa), 0x00
OUTB(0xcfb), 0x80
OUTB(0xcfc), 0x02
</pre>

This hack has been unreleased until now. It has been found not long after the MIST hack, but kept secret, in case Microsoft fixed the MIST bug. In the meantime, they have implemented a fix that makes all hacks impossible that are based on turning off the secret ROM. This will be described in detail later.

===== More Ideas =====

There have been more ideas, but few of them have been pursued, as long as other existing backdoor existed. One possible idea is to base a hack on caching...

== Startup Security, Take Two ==

When bunnie hacked the secret ROM, Microsoft reacted by updating the ROM. Thousands of already manufactured Southbridges were trashed, new ones made. The hacker community called these Xboxes "version 1.1" machines.

=== Microsoft's Perspective ===

Microsoft had now understood that RC4 cannot be used as a hash, so they implemented an additional hash algorithm, which was to be executed after decryption. As there were only few bytes left, the hash algorithm had to be tiny - so the "Tiny Encryption Algorithm" ("TEA") was used. Every encryption algorithm can be changed to be used as a hash, and TEA seemed to be a good choice, as it is really small. While they were at it, they also changed the RC4 key in the secret ROM, so that hackers would not be able to decrypt 2bl and the kernel without dumping the new secret ROM.

=== The Hacker Perspective ===

The extraction of the secret ROM was done by members of the Xbox Linux Project this time, only days after they got their hands on the new 1.1 boxes, and only two weeks after they first appeared.

==== The A20 Hack ====

To date, Microsoft does not know how the Xbox Linux Project did it. But since there will most probably be no future revisions of the Xbox, as the Xbox 360 has already taken over, we can release this now.

Let us start with some PC history. The 8086/8088, the first CPU in the x86 line, was supposed to be as closely compatible to the 8080, which was very successful on the CP/M market. The memory model therefore was similar to the 8080, which could access only 64 KB, by dividing memory into 64 KB blocks. Intel decided that the 8086/8088 could have a maximum of 1 MB of RAM, which would have meant 16 "segments" of 64 KB each. But instead of doing it this way, they decided to let the 64 KB segments overlap, and have 65536 of these segments, starting every 16 bytes.

An address was therefore specified by a segment and an offset. The segment would be multiplied by 16, and the offset would be added, to result in the effective address. As an example, 0x0040:0x006C would be 0x40*0x10+0x6C=0x46C. An interesting side effect of this method is that it is possible to have addresses above 1 MB: The segment 0xFFFF starts at the effective address 0xFFFF0, so it should only contain 16 bytes instead of 64 KB. So the address 0xFFFF:0x0010 would be at 1 MB, and 0xFFFF:0xFFFF would be at 1 MB plus roughly 64 KB.

The 8086/8088 could not address more than 1 MB, because it only had 20 address lines, so addresses above 0xFFFF:0x000F were wrapped around to the lower 64 KB. But this behavior was different on the 286, which had 24 address lines: It was actually possible to access roughly 64 KB more using this trick, which was later abused by MS-DOS as "high memory".

Unfortunately there were some 8086/8088 application that broke, because they required the wraparound for some reason. It wasn't Intel who found that out, but IBM, when they designed the IBM AT, and it was too late to modify the behavior of the 286, so they fixed it themselves, by introducing the A20 Gate ("A20#"). An unused I/O pin in the keyboard controller was attached to the 20th address line, so that software could pull down address line 20 to 0, thus emulating the 8086/8088 behaviour.

This feature was later moved into the CPUs, and all Pentiums and Athlons have it - and so does the Xbox. If A20# is triggered, bit 20 of all addresses will be 0. So, for example, an address of 1 MB will be 0 MB, and if the CPU wants to access the top of RAM, it will actually access memory that is 1 MB lower than the top.

Keeping this in mind, the attack on the Xbox is pretty straightforward: If we connect the CPU's A20# pin to GND, the Xbox will not start from FFFFFFF0, but from FFEFFFF0 - this is not covered by the secret ROM, but is ordinary flash memory, because flash is mirrored over the upper 16 MB. So by only connecting a single pin, the secret ROM is completely bypassed.

What is cool about this, is that the secret ROM is still turned on. So we could easily dump the secret ROM trough one of the low speed busses (we used the I2C bus), by placing a small dump application into flash memory.

==== The TEA Hash ====

After reading Bruce Schneier's book on crypto, we learned that TEA was a really bad choice as a hash. The book says that TEA must never be used as a hash, because it is insecure if used this way. If you flip both bit 16 and 31 of a 32 bit word, the hash will be the same. We could easily patch a jump in the second bootloader so that it would not be recognized. This modified jump lead us directly into flash memory.

But why did they make this mistake? Obviously the designers knew nothing about crypto - again! - and just added code without understanding it and without even reading the most basic books on the topic. A possible explanation why they chose TEA would be that they might have searched the internet for a "tiny" encryption algorithm - and got TEA.

==== Visor Backdoor and MIST Hack ====

The Visor Backdoor was still present, so again, for the replacement Linux firmware, the Xbox Linux developers did not have to exploit the crypto code, but could simply use this backdoor. Microsoft obviously released the updated secret ROM much too quickly, just after bunnie dumped it and people saw that RC4 was no hash, but before the visor backdoor had been discovered.

The MIST hack had been discovered after the visor bug - but it no longer worked on the Xbox 1.1. Not because they fixed the comparison - they didn't -, but because they changed the address logic: If you accessed the upper 512 bytes of the address space, and the secret ROM was turned off, the Xbox would just crash, thus making all "fall down" hacks impossible. This way they closed both possible attacks, writing to an alias, and using 5 OUTB instructions.

Microsoft obviously discovered the turnoff vulnerability themselves, closing at least one backdoor, but keeping another one open, and not really closing a second one. It was too expensive to trash the 1.1 Southbridge chips again for yet another update, so Microsoft still uses these chips in today's Xboxes.

=== Today ===

In later revisions of the Xbox, Microsoft removed some pins of the LPC bus, making modchip design harder, but they could not remove the LPC bus altogether, because they needed it during the manufacturing process.

In the latest revision of the Xbox hardware (v1.6), they finally switched from flash memory to real ROM - and even integrated the ROM with the video encoder. The LPC bus is not needed for manufacturing any more, as the ROM chips are already preprogrammed. So now it is impossible to replace or to overwrite the kernel image, and because of the missing LPC bus, it also seems impossible to attach a ROM override.

But modchips are still possible. The obvious LPC pins are gone now, but the bus is still there. If you find the LPC pins on the board, you can attach a ROM override just as before, the modchips are only a bit harder to install. This is because the Southbridge still has the LPC override functionality, since they did not make a new revision of it - as so often, obviously for monetary reasons.

== Xbox Kernel Security ==

Let us have a look at the chain of trust again:

* The CPU starts execution of code stored in the secret ROM.
* The secret ROM decrypts and verifies the second bootloader.
* The second bootloader decrypts and verifies the Windows kernel.
* The Windows kernel checks the allowed media bits and the RSA signature of the game.

This last link is a complete software thing, so all the attacks have been pretty much standard. Some people tried to brute force the RSA key used for the game signature - no joke! But what is more likely, successfully brute forcing RSA 2048, or finding a bug in Microsoft's security code? After the experience with the first links of the chain of trust, the Xbox Linux Project focused on finding bugs in the software.

We found no bug in the RSA implementation. It is taken straight out of Windows 2000 and looks pretty good. But there are always implicit additional links in the chain of trust: All code reads data, and data can cause security risks if handled incorrectly.

=== Game Exploits ===

What data do games load? Graphics data, audio data, video data... - but we cannot alter them, because it is not easily possible to create authentic Xbox DVDs, and the Xbox won't boot originals from DVD-R etc.

But most games can load savegames, and these can easily be changed: The Xbox memory units are more or less standard USB storage devices ("USB sticks"), so it is possible to use most USB sticks with the Xbox, and just store hacked savegames on them.

Plenty of Xbox games had buffer vulnerabilities in their savegame handlers. It was often as easy as extending the length of strings like the name of the player, and the game would overwrite its stack with our data and eventually jump to the code we embedded in the savegame.

The procedure for the user was then to simply copy a hacked savegame from a USB stick onto the Xbox hard disk, run the game and load the savegame. But after a buffer exploit, we would normally only be in user mode - not on the Xbox, as all Xbox games run in kernel mode. The reason for this is probably a slight speed advantage, or, less likely, a simpler environment for the game, but Microsoft tried to make the environment as similar to the Windows/DirectX environment as possible, so user mode would have actually made the environment "simpler" for many Windows/DirectX developers.

Now that we have full control of the machine, we can overwrite the flash memory chip. It is write protected by default, but disabling the write protection is as easy as soldering a single bridge on the motherboard. After all, this bridge has to be closed temporarily during manufacturing when programming flash memory for the first time. Using this hack, it is possible, only with a USB stick, one of several games (007 Agent Under Fire, MechAssault, Splinter Cell, ...) and a soldering iron, to permanently modify the Xbox, just as if a modchip was installed. Because early Xboxes had a 1 MB flash chip, although only 256 KB had been used, it was even possible to install several ROM images in flash and attach a switch.

But the Xbox Linux Project did not blindly release this hack. The first savegame proof of concept exploit had been finished in January 2003. After that, a lot of energy was invested in finding out a way to free the Xbox for homebrew development and Linux, but not allowing game copies. Microsoft was contacted, but without any success. They just ignored the problem.

Finally in July, the hack was released, with heavy obfuscation, and lockout code for non-Linux use. It was obvious that this would only slow down the "hacking of the hack", so eventually, people would be able to use this vulnerability for copied games, but since Microsoft showed no interest in finding a solution, there was no other option than full disclosure. The suggestion of the Xbox Linux Project would have been to work together with Microsoft to silently close the security holes and, in return, work on a method to let homebrew and Linux run on the Xbox.

=== Dashboard Exploits ===

The problem with the savegame hack was that, if you didn't want to overwrite the flash memory chip, you had to insert the game and load the savegame every time you wanted to run unsigned code. But having full control of the machine using the savegame exploit also meant we could access the hard disk without opening the Xbox. This way, it became interesting to closely examine the hard disk contents for vulnerabilities.

The Dashboard is the main program on hard disk, executed every time the Xbox is started without a game in the DVD drive. The dashboard may even be the very reason the Xbox ships with a hard disk: While the settings menu and savegame management on the Nintendo GameCube fit well into 2 MB of ROM, the Xbox Dashboard, which is roughly comparable in its functionality, occupies more than 100 MB. So the original idea why to include a hard disk might have been initiated by the inability to compress the Dashboard into typical ROM sizes - and they might have decided to make the best out of it, and find additional uses for the hard disk.

The dashboard loads its data files, like audio and graphics, from hard disk. With the savegame exploit, we can now alter the hard disk contents, even without opening the Xbox. Of course the dashboard executable is signed and can therefore not be altered, and all data files are hashed, with the hashes stored inside the dashboard executable. Well, all files, except for two: the font files.

Consequently, there was an integer vulnerability in the font handling routines, so that we could run our own code by replacing the font files. Combined with the savegame exploit, it was as easy as transferring the savegame and loading it, which would run a script that modifies the fonts.

Now every time the Xbox is turned on, the Dashboard crashes because of the faulty fonts and runs our code embedded in these files. Our code reloads the Dashboard with the original fonts, hacks it, and runs it. Hacking the Dashboard meant two things: Modifying one menu entry to read "XBOX LINUX" instead of "XBOX LIVE" and running the Linux bootloader instead of the Xbox Live setup executable, and modifying the kernel to accept both applications signed with Microsoft's RSA key as well as those signed with our RSA key, from hard disk and from CD/DVD. We called this "MechInstaller", as it was based on the "MechAssault" savegame exploit.

Only accepting code either signed by the original key or by our key, keeping our key secret, and using heavy obfuscation again, meant that nobody could easily abuse this solution for copied games.

This hack shows several things: Hackers have phantasy, the combination of flaws can lead to fully compromising the security system, powerful privileged code should be bug-free and security code should really catch ''all'' cases.

Oh, and there is another vulnerability, an integer vulnerability in the audio player code. The attack was developed independently of the font attack, but was inferior because it would have required the user to enter the audio player every time to run Linux.

==== Microsoft's Fixes ====

The history of Microsoft's reactions to the font vulnerability is the perfect lesson of how to do it wrong.

# After MechInstaller had been released, Microsoft fixed the buffer vulnerability in the Dashboard and distributed this new version over the Xbox Live network and shipped it with new Xboxes.
# For the hackers, this was no major problem: It was possible to downgrade the Dashboard of a new Xbox to the vulnerable version. Just run Linux using a savegame exploit, and "dd" the old image. Some people felt downgrading on new Xboxes was not piracy, because after all, Microsoft upgraded Xbox Live users' hard disks to the new version without asking.
# As the next step, Microsoft blacklisted the old Dashboard in the new kernel. It was impossible to just "dd" an old Dashboard image onto newer Xboxes.
# Still no major problem for hackers: The second executable on the hard disk, "xonlinedash", which is used for Xbox Live configuration, had the same bug, so it was possible to copy the old "xonlinedash" and to rename it to "xboxdash" to make it crash because of the faulty fonts.
# Microsoft consequently blacklisted the vulnerable version of "xonlinedash".
# Again, no major problem for hackers: All Xbox Live games come with the "dashupdate" application, which adds Xbox Live functionality to the Dashboard for the first Xboxes which came without it. This update application has the same font bug, and it can be run from hard disk. So it is possible to copy the file from any Xbox Live game DVD, rename it to "xboxdash" and let it crash.
# Microsoft could not blacklist this one. Xbox Live enabled games run the update application every time they start, making sure the Xbox has the Xbox Live functionality. Blacklisting "dashupdate" would break these games.

We won.

== The Mistakes that Have Been Made ==

Microsoft obviously made a lot of mistakes. But it would be too easy to just attribute all these to stupid engineers. There have been good (and different) reasons for most of these mistakes, and one can learn a lot from them.

There are 17 kinds of mistakes they made, several of which have been made more than once. I will group the 17 mistake types into three categories: Design mistakes, implementation mistakes and bad policy decisions.

=== Design ===

==== #1: Security vs. Money ====

Be very careful with tradeoffs between security and money. There are rarely sensible compromises. Keep in mind that the very reason for the security system is to make more money, or to prevent money losses. Security systems cannot be "a little better" or "a little worse". Either they are effective - or they are not. By saving money on the security system, you may easily make it not effective at all, not only wasting the money spent on the security system, but also making losses because it is not effective.

Microsoft made many compromises.

* In-system programming of flash memory is cheaper than preprogramming, but an attacker can also override the firmware with an LPC ROM.
* Buying all of Samsung's RAM chips is cheaper than only buying those within the specs, but it made RAM initialization more complex, using up space that could otherwise be used for better security code.
* They chose to put the secret ROM into the Southbridge instead of the CPU, because the Southbridge was a custom component anyway and having a custom CPU would have been a lot more expensive, but keys travel over a visible bus if the secret ROM is outside the CPU.
* They saved money choosing not to update the Southbridge a second time, which would have fixed the TEA hash and removed the visor backdoor. This would have made modchips virtually impossible.

==== #2: Security vs. Speed ====

Don't trade security for speed. Although it may be true that the product in question must be as fast as possible in order to be able to compete with similar products on the market, remember that in IT, computers aren't slower or faster by some percentage - but by factors! Besides, you might lose more money because of a security system that does not work than because of a product that is 10 percent slower than it could be.

Most probably for added speed (one address space, no TLB misses), Microsoft chose to run all code in kernel mode, even games that interacted with untrusted data that came from the outside. This made it possible to have complete control of the machine once a game crashed because of a prepared savegame, including complete control of the hard disk and the possibility of booting another operating system.

==== #3: Combinations of Weaknesses ====

Be aware of the fact that a combination of security flaws can lead to a successful attack. Don't think that a possible security hole (or "only" a security risk) cannot be exploited because there are so many barriers in front of it. Attackers might break all the other barriers that block the vulnerability, and fixing that one hole would have stopped them.

MechInstaller is a great example for that. It was only possible because of the combination of several security weaknesses:

* The boot process was vulnerable, so we could use a modified kernel to analyze games.
* Some games are not careful enough with savegames, so that we can run our own code.
* Games run in kernel mode, so we have full control of the hardware.
* The Dashboard does not verify the integrity of the font files.
* The Dashboard has a vulnerability in the font code.

If any of these weaknesses had not been there, then MechInstaller would not have been possible. Also note that hackers have enough fantasy to find out these combinations.

==== #4: Hackers' Resources ====

Understand that hackers may have excellent resources. Hobbyists may use resources from work or from university, and professional attackers can also be very well-equipped. It is a big mistake to underestimate them. So never think you are safe because it would be too much work or too expensive to exploit a weakness. If it is a weakness, it will eventually be exploited. Also understand that hackers may have excellent human resources. Not only in number, but also in qualifications.

Microsoft put the secret ROM into the Southbridge instead of the CPU, which meant that the secret key would travel over a visible bus. This is the very fast HyperTransport bus, which, at that time, could not be sniffed using logic analyzers any mortal could afford. But with help of the resources of the MIT and using all of his expertise, bunnie could build his own hardware that could sniff the bus.

==== #5: Barriers and Obstacles ====

Don't make anything "harder for hackers". Instead make it "impossible for hackers", or, if it cannot be made impossible, don't care about it. Because of the potential great number and excellent qualifications of hackers, no obstacle will have any effect or slow down hacking significantly. But instead, in security design, you might make mistake #3, because you think you are safe as there are so many obstacles in the hackers' way. Use the resources you would invest into building obstacles into building or strengthening barriers instead - possibly at a different location.

Microsoft built obstacles into the system at many different locations.

* Savegames will only be accepted if they are signed, but the private key is of course stored inside the game, so this is no barrier. Instead, they should have made sure the games contain no buffer vulnerabilities in their savegame handlers.
* The hard disk is secured with an ATA password, different for every Xbox and stored on an EEPROM inside the Xbox, but an attacker can just "hotswap" an unlocked hard disk from a running Xbox to a running PC. Instead, they should have put that energy into verifying whether the Dashboard really hashes all data it reads from the hard disk.
* The 512 bytes of security startup code were embedded in a custom chip to make it hard to sniff. Instead, they should have made sure that there are no bugs in that security code.

==== #6: Hacker Groups ====

Don't use one security system for different purposes, or else attackers with very different goals will jointly attack it, being a lot more effective. Instead, try to find out who your enemies really are and what they want, and design your security system so that every group gets as much of what they want so that it does not hurt you.

There were three possible goals for Xbox hackers: Run Linux and use it as a computer, run homebrew software like media players and emulators, and run copies. Although there were some overlaps between Linux and homebrew people, as well as between homebrew people and people interested in copies, these were essentially three very different groups. Because they were all locked out by the same protection, they worked together, either explicitly, or implicitly, by using the results of each other. No Linux hackers ever attacked the Playstation. When you are fair, people don't fight you.

==== #7: Security by Obscurity ====

Security by obscurity does not work. Well-proven algorithms like SHA-1 and RSA work (of course given your implementation is well-proven as well).

Microsoft hid the secret ROM, the Windows kernel, the game DVD contents (no way to read them on a standard DVD drive) and the hard disk contents using different methods. None had any effect. Also see #5.

==== #8: Fixes ====

When your security system has been broken, don't release quick fixes, for two reasons: Your fixes may be flawed and may not actually correct the problem, and even worse holes may be found not much later, which you must fix again - and ship yet another version. Instead, every time a security vulnerability is found, audit your complete security system and search for similar bugs, as well as other bugs in the same part of the system, based on the knowledge you gained from the successful hack.

Microsoft failed to correct the hash problem in the second version of the secret ROM, and didn't fix the visor vulnerability, which was found just weeks later. After trashing thousands of already manufactured v1.0 Southbridge chips, which was very expensive, they decided not to update the Southbridge a second time. Another example is the dashboard odyssey: Instead of blacklisting the vulnerable executables at a time, they released three updates, none of which was effective.

=== Implementation ===

==== #9: Data Sheets ====

Know everything about the components you use. Do read data sheets. Be very careful with components that have legacy functionality.

Microsoft did not notice the A20# legacy functionality as a security risk. It seems that they did not completely analyze the functionality of the Pentium III Celeron, or else they should have noticed. They also apparently did not read the Pentium programmers' manual, or else they would have noticed that Intel CPUs do not panic on a FFFFFFFF/00000000 wraparound.

==== #10: Literature ====

Read (at least!) standard literature. If you are dealing with cryptography, this means you have to read at last Schneier's "Applied Cryptography".

Microsoft's engineers did not know that TEA must not be used as a hash, and that RC4 does not feed the decrypted stream back into the key stream.

==== #11: Pros ====

Get experienced professionals to work on your security system, both on the design and the implementation. If it's a money issue, see #1.

Looking at mistakes #9 and #10, it seems very probable that at least some of Microsoft's engineers had no prior experience with cryptography or the design of a security system. We also know that people on an internship were working on Xbox security.

==== #12: Completeness ====

Check whether your security code catches all cases. If it does not, you did not only waste time implementing all of it, but you may also give hints to hackers: If there are many checks at one point of the code, it looks a lot like code that is relevant for security and an attacker can check whether all cases are caught.

Microsoft made this mistake twice: The xcode interpreter tests for the secret ROM turnoff code, and doesn't catch all cases. And the Dashboard hashes all files it is going to read, except for two. This gave us the ideas where to attack.

==== #13: Leftovers ====

Look at the final product from the perspective of a hacker. Hexdump and disassemble your final builds. There could be leftovers!

The Xbox flash memory image contained an old version of the secret ROM, giving us not only hints about the contents of the actual secret ROM, but also an insight into what Microsoft planned and why some mistakes have been made.

==== #14: Final Test ====

Test your security system when you have the final parts and with the final software components in place. Changing something may very well open holes somewhere else. When you change something, rethink the complete system, and check all assumptions that you made.

The visor hack was only possible because Microsoft failed to adapt their security system, designed for the AMD CPU, to the Intel CPU. The "hash" in the secret ROM had no effect because they changed RC5 to RC4 without thinking about the implications.

=== Policies ===

==== #15: Source ====

Keep your source safe. Find engineers you can trust.

The complete Xbox source code has leaked, including the kernel and libraries source. Groups interested in copies could easily modify it to support running games from hard disk, support for hard disks bigger than 137 GB, custom boot logos etc. This had been previously done by patching the binary.

==== #16: Many People ====

Have many good people have a look at both your design and your implementation. Keeping your source code safe means having engineers you can trust, and not letting none of your engineers see the source code. As stated at #7, your system should not rely on the source code being safe. Unless you did #7 completely wrong, a bug in the security system is typically a lot worse than a leak of the source code.

It seems a lot like very few people have actually seen the Xbox security code.

==== #17: Talk ====

Know your enemy - and talk to them. They are not terrorists that you are not supposed to negotiate with. Their intent is not to harm you but to reach their goals. Working on their goals on their own might harm you indirectly, because the hackers may not care about the same things as you do. Seek the contact to hackers, know what they are doing and have them inform you about a vulnerability before publishing it. Make them know your position and why they should respect it, but also respect their position. Offer them to loosen the security system for what they want in exchange for the non-disclosure of their findings.

Microsoft refused to talk about the savegame and font vulnerabilities. If we had been bad hackers, we could have released both of them as-is, immediately making it possible to run copies on Xboxes without the use of a modchip. Instead, we sought contact to Microsoft: We would have preferred to see a backdoor for Linux in the Xbox security system, instead of a solution based on our findings that would allow running copies. But as they refused to talk, we were forced to release the exploits, and they were lucky we heavily obfuscated our solutions so in order to slow down people interested in using it for copies.

== Conclusion ==

The security system of the Xbox has been a complete failure.

Xbox Live

2020-10-24T06:30:38Z

Billy549:

Xbox Live is an online multiplayer gaming and digital media delivery service created and operated by Microsoft. It was first made available to the Xbox system in November 2002. ([https://en.wikipedia.org/wiki/Xbox_Live Wikipedia]) Xbox Live support for the original Xbox ended in April 15, 2010.

The Xbox Live architecture consists of Kerberos-based authentication tickets, with a Secure Gateway used to then access services (such as Matchmaking, Statistics/Leaderboards, and custom game servers)

=== Authentication servers ===

Authentication and access to Xbox Live services is controlled using the Kerberos protocol with a few proprietary customisations for the Xbox.

The first time an Xbox connects to Xbox Live from the factory, it'll connect to MACS.XBOXLIVE.COM and use a pre-shared key based from the Online Key, HDD Key, and a unique key present in all Xbox Live binaries.
The server would then return a machine account that is then used for all further authentication (for example, to authenticate for the service to create a new Xbox Live user account).

{| class="wikitable"
|+Xbox PA-DATA
|-
! padata-type
! description
|-
|131
| ?
|-
|204
| ?
|-
|206
| Information about Xbox Version, Title, and Title version
|}

=== Matchmaking servers ===

=== Game servers ===

=== XDK Functions ===

{| class="wikitable"
|+XOnline* Functions
|-
! function
! description
|-
|XOnlineGetUsers(XONLINE_USER* XBLAccountusers, DWORD* numOfXBLiveAccounts)
|The XOnlineGetUsers function will enumerate both the hard disk and any attached memory units looking for user accounts
|-
|XOnlineTaskClose(XONLINETASK_HANDLE logonHandle)
|Called to abort the authentication process.
|-
|XOnlineStartup( XONLINE_STARTUP_PARAMS* )
|
|-
|XOnlineLogon(XONLINE_USER* XBLLoggedOnUsers, DWORD* XBLservices, DWORD SERVICE_COUNT, NULL, XONLINETASK_HANDLE &logonHandle)
|When a title calls XOnlineLogon to sign in, instead of blocking until the authentication completes, an asynchronous task handle is returned. As part of the authentication process a title must specify which services it will be using (XBLservices, SERVICE_COUNT).
|-
|XOnlineTaskContinue(XONLINETASK_HANDLE logonHandle)
|Called to check the status of XOnlineLogon. It will return XONLINETASK_S_RUNNING while the login process has not been completed.
|-
|XOnlineLogonTaskGetResults(XONLINETASK_HANDLE logonHandle)
|Will return XONLINE_S_LOGON_CONNECTION_ESTABLISHED when the task is successfully completed. Otherwise it will return an error code.
|-
|XOnlineGetLogonUsers()
|This returns a pointer to an array of XONLINE USER structures. This array is similar the XONLINE USER array we populated and passed into XOnlineLogon, but is updated with error status and permission flags for each user.
|-
|XOnlineSetUserGuestNumber(dwUserFlags , 1)
|
|-
|XOnlineTitleUpdate(DWORD)
|The XOnlineTitleUpdate function will boot into an updater application, which performs the actual update
|-
|XOnlineGetServiceInfo(Service, ?)
|XOnlineGetServiceInfo returns the connection status for a service
|-
|XOnlineNotificationSetState
|
|}

== Discontinuation of service ==

The service was officially discontinued on April 15th, 2010.

12 players decided to stay in a lobby of ''Halo 2'' 24/7 to keep a server running.
The final player, Apache N4SIR was streaming the entire event, as the player count of 12 twindeled down to just him. At 11:40 PM PDT, on May 11th 2010, Apache N4SIR was booted from the game[http://i.imgur.com/oQw6k5H.jpg].

Xbox Live Communicator

2020-05-22T21:23:23Z

Billy549: Add PCB images directly on-wiki, remove Imgur link

The Xbox Live Communicator is the headset which is used for Xbox Live.
[[File:Xbox_Live_Communicator.png|thumb|200px|Headset / Xbox Live Communicator]]
[[File:XBCommunicator-front.jpg|thumb|200px|PCB Front]]
[[File:XBCommunicator-back.jpg|thumb|200px|PCB Back]]

== Protocol ==

=== USB Descriptor ===

<pre>
Bus 003 Device 006: ID 045e:0283 Microsoft Corp. Xbox Communicator
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x045e Microsoft Corp.
idProduct 0x0283 Xbox Communicator
bcdDevice 1.58
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 45
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 120
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0030 1x 48 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 120
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0030 1x 48 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
</pre>

=== Microphone ===

{{FIXME}}

=== Speaker ===

{{FIXME}}

==== Links ====

* [https://github.com/JayFoxRox/xbox-tools/tree/4bc808e187311010f850d7fbd9af4b76bed90727/communicator-tool Code for accessing the communicator microphone and speaker]
* [https://web.archive.org/web/20200521011406/http://www.kako.com/neta/2005-009/uac3556b.pdf Datasheet for UAC 3556B (close to the 3560B that the Xbox Communicator uses]

File:XBCommunicator-front.jpg

2020-05-22T21:20:06Z

Billy549: Front shot of the XBCommunicator - licensed by Billy549 under CC-BY-SA 4.0

Front shot of the XBCommunicator - licensed by Billy549 under CC-BY-SA 4.0

File:XBCommunicator-back.jpg

2020-05-22T21:17:59Z

Billy549: Back shot of the XBCommunicator - licensed by Billy549 under CC-BY-SA 4.0

Back shot of the XBCommunicator - licensed by Billy549 under CC-BY-SA 4.0

Xbox Live Communicator

2020-05-21T02:19:20Z

Billy549: Add data sheet for UAC 3556B

The Xbox Live Communicator is the headset which is used for Xbox Live.
[[File:Xbox_Live_Communicator.png|thumb|200px|Headset / Xbox Live Communicator]]

== Protocol ==

=== USB Descriptor ===

<pre>
Bus 003 Device 006: ID 045e:0283 Microsoft Corp. Xbox Communicator
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x045e Microsoft Corp.
idProduct 0x0283 Xbox Communicator
bcdDevice 1.58
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 45
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 120
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0030 1x 48 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 120
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0030 1x 48 bytes
bInterval 1
bRefresh 0
bSynchAddress 0
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
</pre>

=== Microphone ===

{{FIXME}}

=== Speaker ===

{{FIXME}}

==== Links ====

* [https://github.com/JayFoxRox/xbox-tools/tree/4bc808e187311010f850d7fbd9af4b76bed90727/communicator-tool Code for accessing the communicator microphone and speaker]
* [https://imgur.com/gallery/mJmP5Ys Billy549's CC-BY-SA shots of the internal PCB]
* [https://web.archive.org/web/20200521011406/http://www.kako.com/neta/2005-009/uac3556b.pdf Datasheet for UAC 3556B (close to the 3560B that the Xbox Communicator uses]

Xbox Live Communicator

2020-05-21T01:55:51Z

Billy549: Add link to PCBs

Xbox Input Devices

2020-04-29T18:55:34Z

Billy549: /* USB Adapters */

== XID Overview ==

XIDs are USB devices.

The hardware side is USB with a different plug while the software side is USB without HID-descriptors.
Technicly a XID is a USB-hub for the Memory-Units and the XBL Communicator.
The logical XID gamepad USB device is internally connected to that hub.

=== USB Adapters ===
The Xbox's Input devices are USB devices. As such, you can connect a keyboard to the Xbox, or a gamepad to your PC. In fact, Linux already has drivers for the gamepad. In order to preserve Xbox hardware, please do not cut OEM Xbox cables to make an adapter; decent adapters can be acquired cheaply (~$10 USD ea. on 2017.04.30).

[[File:Xboxmaletousbfemale.png|thumb|right|Wiring diagram to show how male Xbox controller plug maps to standard female USB connector. White cable color is depicted as gray for better visibility. The yellow cable is not connected to the USB side, as it's exclusive to Xbox.]]

{| class="wikitable"
|-
! Port (From)
! Plug (To)
! Link
|-
| Xbox
| USB-A
| [https://www.amazon.com/gp/product/B000RT2868 Amazon] [https://www.aliexpress.com/item/32948906701.html Aliexpress]
|-
| USB-A
| Xbox
| [https://www.amazon.com/gp/product/B00F52LQHO Amazon] [https://www.aliexpress.com/item/4000452932782.html Aliexpress]
|}

=== Wiring ===

Untested / unverified! Take this with a grain of salt.

{| class="wikitable"
!Pin
!Typical cable color
!Description
|-
|1
|Red
|VCC
|-
|2
|White
|USB D+
|-
|3
|Green
|USB D-
|-
|4
|Yellow
|VBlank signal from video output (for Lightguns)
|-
|5
|Black
|GND
|-
|}

=== Protocol ===

XID are similar to HID but have custom Vendor requests

==== Control Transfers ====

===== GET_DESCRIPTOR =====

* bmRequestType: 0xC1
* bRequest: 6
* wValue: 0x4200
* wIndex: Interface number
* wLength: <length of respective report; typically 16>

Actual length is truncated to size of descriptor or wLength. Whichever is smaller.

<pre>
typedef struct XIDDescriptor {
uint8_t bLength;
uint8_t bDescriptorType;
uint16_t bcdXid;
uint8_t bType;
uint8_t bSubType;
uint8_t bMaxInputReportSize;
uint8_t bMaxOutputReportSize;
uint16_t wAlternateProductIds[4];
};
</pre>

bDescriptorType is probably always 0x42.

====== bType = 1: Xbox Gamecontroller ======

* bSubType:
** 0x01 = Gamepad (Duke)
** 0x02 = Gamepad (Controller-S)
** 0x10 = Steering wheel

===== GET_CAPABILITIES =====

* bmRequestType: 0xC1
* bRequest: 1
* wValue:
** 0x0100 for input
** 0x0200 for output
* wIndex: Interface number
* wLength: <length of respective report>

* STALL if wValue not supported.

Actual length is truncated to size of report or wLength. Whichever is smaller.

<pre>typedef struct XIDGamepadCapabilities {
uint8_t bReportId;
uint8_t bLength;
<Data>
}</pre>

The data will be similar to the GET_REPORT, but instead of storing actual values, it will have bits set (1) where the bit is valid in the respective report.
If the bit is auto-generated, it will be cleared (0).

===== SET_REPORT =====

* bmRequestType: 0x21
* bRequest: 9
* wValue: 0x0200
* wIndex: Interface number
* wLength: <length of report; typically 6>

* STALL if wValue not supported.

====== Typical report ======

<pre>typedef struct XIDGamepadReport {
uint8_t bReportId;
uint8_t bLength;
<Data>
}</pre>

===== GET_REPORT =====

* bmRequestType: 0xA1
* bRequest: 1
* wValue: 0x0100
* wIndex: Interface number
* wLength: <length of report; typically 20>

* STALL if wValue not supported or if wLength is greater than report size.
* ACK if supported.

====== Typical report ======

<pre>typedef struct XIDGamepadOutputReport {
uint8_t report_id; //FIXME: is this correct?
uint8_t length;
<Data>
}</pre>

==== Interrupt transfers ====

Alternatively interrupt-in and interrupt-out transfers can be used for GET_REPORT and SET_REPORT respectively.

In case of the interrupt-in, there is another status which can occur now:

* NAK if supported but no changes since last ACK.

== Standard Gamepads ==

=== Microsoft Hardware Variants ===

There are a few hardware re-designs of the Microsoft Gamepad.

{| class="wikitable"
!Controller Name
!Part Number
!Board Model
!Notes
!Datasheets
|-
|Xbox Game Controller (AKA "Duke")
|X08-17160
|23-0819B
|Earliest known model{{FIXME|Reason=Small sample size (5), can't confirm}}. 3 IC's: Dedicated ST 92163/JFL Micro Controller, dedicated AT43USB401 USB Controller, 4 Channel Analog Mux LW052A.
|[https://archive.org/details/ST92163 ST 92163/JFL], AT43USB401{{FIXME|Reason=Can't find datasheet}}, [https://web.archive.org/web/20191230174412/https://www.rockbox.org/wiki/pub/Main/DataSheets/TexasInstrumentsLW052ADataSheet.pdf LW052A]
|-
|Xbox Game Controller (AKA "Duke")
|X08-17160
|K023B121
|Same as 23-0819B, but manufactured in China. Only Board Model that does not follow naming conventions. Hardware identical. Easily identified by a serial number that starts with "KD".
|[https://archive.org/details/ST92163 ST 92163/JFL], AT43USB401{{FIXME|Reason=Can't find datasheet}}, [https://web.archive.org/web/20191230174412/https://www.rockbox.org/wiki/pub/Main/DataSheets/TexasInstrumentsLW052ADataSheet.pdf LW052A]
|-
|Xbox Game Controller (AKA "Duke")
|X08-17160
|23-0819C
|Last known Duke model.{{FIXME|Reason=Small sample size (5), can't confirm}}. Identical to 23-0819B in hardware, new silkscreen markings show this model is [https://en.wikipedia.org/wiki/UL_94 UL-94 V-0 compliant]. All boards after this are V-0 compliant.
|[https://archive.org/details/ST92163 ST 92163/JFL], AT43USB401{{FIXME|Reason=Can't find datasheet}}, [https://web.archive.org/web/20191230174412/https://www.rockbox.org/wiki/pub/Main/DataSheets/TexasInstrumentsLW052ADataSheet.pdf LW052A]
|-
|Xbox Game Controller (Looks like an S, with green Xbox jewel)
|X08-19383
|23-0923A
|Japan and Australia exclusive model{{FIXME|Reason=Speculation, no hard source for this}}.Minification of "Duke" PCB Design. Has exact same IC's as the Duke, only in an S controller design.
|[https://archive.org/details/ST92163 ST 92163/JFL], AT43USB401{{FIXME|Reason=Can't find datasheet}}, [https://web.archive.org/web/20191230174412/https://www.rockbox.org/wiki/pub/Main/DataSheets/TexasInstrumentsLW052ADataSheet.pdf LW052A]
|-
|Xbox Controller S
|X08-69873
|23-0923B
|Minification of "Duke" PCB Design. Has exact same IC's as the Duke, only in an S controller design
|[https://archive.org/details/ST92163 ST 92163/JFL], AT43USB401{{FIXME|Reason=Can't find datasheet}}, [https://web.archive.org/web/20191230174412/https://www.rockbox.org/wiki/pub/Main/DataSheets/TexasInstrumentsLW052ADataSheet.pdf LW052A]
|-
|Xbox Controller S
|X08-69873
|23-0923H
|Entirely new PCB design. Single IC on the board, AT43USB355M-AC
|[https://archive.org/details/AT43USB355 AT43USB355M-AC]
|-
|Xbox Controller S
|X08-69873
|23-0923I
|PCB Design almost exactly the same as H revision. Only difference is the IC is smaller: AT43USB353M-AC
|[https://archive.org/details/AT43USB353M-AC AT43USB353M-AC]
|}

There are also dedicated Part Numbers for color variants:
{| class="wikitable"
!Controller Part Number
!Controller Description
!Board Model
|-
|X02332-001
|Crystal S Controller
|23-0923I
|-
|X09-64240-01
|Transparent Green Controller
|23-0923I
|-
|X800679-100
|Black S With Halo Jewel
|23-0923I
|}

=== USB Descriptors ===

See https://github.com/xboxdrv/xboxdrv/blob/stable/src/xpad_device.cpp for a list of devices.

==== 23-0819B ====

<pre>
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x045e Microsoft Corp.
idProduct 0x0202 Xbox Controller
bcdDevice 1.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 88 Xbox
bInterfaceSubClass 66 Controller
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
</pre>

==== K023B121 ====

Identical to 23-0819B {{FIXME|Reason=Confirm with xid-dumper tool}}

==== 23-0819C ====

Identical to 23-0819B {{FIXME|Reason=Confirm with xid-dumper tool}}

==== 23-0923A ====

Changes from 23-0819B

<pre>
Device Descriptor:
idProduct: 0x0285
</pre>

==== 23-0923B ====

{{FIXME|Reason=No Descriptor Dump}}

==== 23-0923H ====

Changes from 23-0819B

<pre>
Device Descriptor
bMaxPacketSize0: 8
idProduct: 0x0289
bcdDevice: 1.20
Configuration Descriptor
Interface Descriptor
Endpoint Descriptor
bEndpointAddress: 0x81
</pre>

==== 23-0923I ====

Changes from 23-0923H

<pre>
Device Descriptor
bcdDevice: 1.21
</pre>

=== Controller to Xbox ===

20 bytes

{| class="wikitable"
!Field
!Offset (Bytes)
!Mask
!Notes
|-
|{{input-dy+}}
|2
|0x01
|
|-
|{{input-dy-}}
|2
|0x02
|
|-
|{{input-dx-}}
|2
|0x04
|
|-
|{{input-dx+}}
|2
|0x08
|
|-
|{{input-start}}
|2
|0x10
|
|-
|{{input-back}}
|2
|0x20
|
|-
|{{input-ls}}
|2
|0x40
|
|-
|{{input-rs}}
|2
|0x80
|
|-
|{{input-a}}
|4
|0xFF
|Button is analog
|-
|{{input-b}}
|5
|0xFF
|Button is analog
|-
|{{input-x}}
|6
|0xFF
|Button is analog
|-
|{{input-y}}
|7
|0xFF
|Button is analog
|-
|{{input-black}}
|8
|0xFF
|Button is analog
|-
|{{input-white}}
|9
|0xFF
|Button is analog
|-
|{{input-lt}}
|10
|0xFF
|Trigger is analog
|-
|{{input-rt}}
|11
|0xFF
|Trigger is analog
|-
|{{input-lx}}
|12
|0xFFFF
|Negative = Left; Positive = Right
|-
|{{input-ly}}
|14
|0xFFFF
|Negative = Down; Positive = Up
|-
|{{input-rx}}
|16
|0xFFFF
|Negative = Left; Positive = Right
|-
|{{input-ry}}
|18
|0xFFFF
|Negative = Down; Positive = Up
|}

=== Xbox to Controller ===

6 bytes

{| class="wikitable"
!Field
!Offset (Bytes)
!Mask
!Notes
|-
|Left actuator strength
|2
|0xFFFF
|
|-
|Right actuator strength
|4
|0xFFFF
|
|}

Xbox games use the full range from 0x0000 to 0xFFFF for both the left and right actuators.

The Microsoft Controller S will not react to packets which don't have a value of 6 in the <code>length</code> field of the header.
The Fanatec Speedster 3 ForceShock will still react to those. Further testing is necessary with other gamepads.

== Steering wheels ==

=== MadCatz Wheel ===

{{FIXME}}

=== Fanatec Speedster 3 ForceShock ===

==== Pedals ====

The Pedals are ''not'' a USB device.

Note that the cable going to the pedals is also ''not'' a USB port despite using the Xbox controller breakaway plug.
Likewise, plugging the pedals to a PC / Xbox won't provide a USB / XID (it is detected as garbage):

<pre>
new full-speed USB device number 14 using xhci_hcd
device descriptor read/64, error -71
device descriptor read/64, error -71
new full-speed USB device number 15 using xhci_hcd
device descriptor read/64, error -71
device descriptor read/64, error -71
new full-speed USB device number 16 using xhci_hcd
Device not responding to setup address.
Device not responding to setup address.
device not accepting address 16, error -71
new full-speed USB device number 17 using xhci_hcd
Device not responding to setup address.
Device not responding to setup address.
device not accepting address 17, error -71
unable to enumerate USB device
</pre>

==== Internal HUB ====

===== USB Descriptors =====

Power not connected, pedals not connected, not in Tuning mode:

<pre>
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 8
idVendor 0x3767
idProduct 0x0102
bcdDevice 0.01
iManufacturer 0
iProduct 1 End
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 64mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x000d
Per-port power switching
Compound device
Per-port overcurrent protection
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 64 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0103 power enable connect
Port 2: 0000.0100 power
Port 3: 0000.0100 power
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
</pre>

==== Steering wheel (and Pedals) ====

Always connected to port 1 of the internal HUB

===== USB Descriptors =====

<pre>
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x3767
idProduct 0x0101
bcdDevice 2.80
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 88 Xbox
bInterfaceSubClass 66 Controller
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
</pre>

== Light guns ==

=== EMS TopGun II ===

''This is an unlicensed / unofficial Xbox accessory.''

The website for this product can be found at http://www.hkems.com/product/xbox/EMSTopGun2.htm

The gun presents itself as a standard Xbox gamepad. It uses a different USB descriptor for Xbox (X) and the other mode (P).
There is no internal hub in this device.

{| class="wikitable"
! EMS TopGun II !! Xbox Gamepad !! Notes
|-
| Stick || {{input-d}} ||
|-
| Trigger || {{input-a}} || rowspan="4" | Digital only, either 0 or 255
|-
| Grip || {{input-b}}
|-
| A || {{input-x}}
|-
| B || {{input-y}}
|-
| START || {{input-start}} ||
|-
| SE/BA || {{input-back}} ||
|-
| Aim Left / Right || {{input-lx}} || rowspan="2" | Absolute position using the full stick range
|-
| Aim Up / Down || {{input-ly}}
|}

There is no right thumbstick, thumbstick presses, black/white button or trigger buttons (All of those read constant zeros).

===== Turbo Mode =====

* Turbo mode 0 keeps {{input-a}} pressed while trigger is held
* Turbo mode 1 toggles {{input-a}} rapidly while trigger is held
* Turbo mode 2 toggles {{input-a}} rapidly and once in a while {{input-b}} while trigger is held

===== Force Feedback =====

The upper part of the gun is moveable and should push back to simulate recoil (possibly hurting your thumb while you are using the stick).
I could not get the force feedback working, but I'm sure I've had it working in the past on PC.{{citation needed}}

==== USB Descriptors ====

This is the descriptor in the Xbox mode (X).

<pre>
Bus 003 Device 016: ID 0b9a:016b
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0b9a
idProduct 0x016b
bcdDevice 4.57
iManufacturer 1 EMS̖E
iProduct 2 EMS TopGun
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 88 Xbox
bInterfaceSubClass 66 Controller
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
</pre>

=== Joytech Sharp Shooter ===

''This is an unlicensed / unofficial Xbox accessory.''

The third party light gun from Joytech reports itself as 2 devices and mentions pattent [http://www.google.com/patents/US6287198 US6287198]
it came with a detachable viewfinder scope without any magnification. a red dot apears in the viewfinder, its a reflection of a red led, powered by the gun over usb.

model numer: JS-901D

{| class="wikitable"
! Joytech Sharp Shooter !! Xbox Gamepad !! Notes
|-
| Stick || {{input-d}} ||
|-
| Trigger || {{input-a}} || rowspan="6" | Digital only, either 0 or 255 {{citation needed}}
|-
| B (Left side) || rowspan="3" | {{input-b}}
|-
| B (Right side)
|-
| B (Magazine button)
|-
| x || {{input-x}}
|-
| y || {{input-y}}
|-
| START || {{input-start}} ||
|-
| BACK || {{input-back}} ||
|-
| Aim Left / Right || {{input-lx}} || {{citation needed}}
|-
| Aim Up / Down || {{input-ly}} || {{citation needed}}
|}

There is no right thumbstick, thumbstick presses, black/white button or trigger buttons {{citation needed}}

===== Fire/Reload Mode =====

* Normal mode does nothing, normal operation
* Auto reload mode toggles {{input-b}} rapidly to rappidly reload {{citation needed}}
* Auto fire+reload mode toggles {{input-a}} + {{input-b}} rapidly {{citation needed}}

==== USB Descriptors ====

<pre>

Bus 003 Device 025: ID 1292:3006 Innomedia
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1292 Innomedia
idProduct 0x3006
bcdDevice 1.50
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 1 (error)
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 88 Xbox
bInterfaceSubClass 66 Controller
bInterfaceProtocol 0
iInterface 2 (error)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4

Bus 003 Device 024: ID 1292:3006 Innomedia
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 8
idVendor 0x1292 Innomedia
idProduct 0x3006
bcdDevice 1.50
iManufacturer 1 (c) 2004 R0R3 Inc.
iProduct 2 US Patent 6,287,198
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 (c) R0R3 Devices Inc. US Patent 6,287,19Ē
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 64mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 5 (error)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x000d
Per-port power switching
Compound device
Per-port overcurrent protection
bPwrOn2PwrGood 32 * 2 milli seconds
bHubContrCurrent 64 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0x0e
Hub Port Status:
Port 1: 0000.0103 power enable connect
Port 2: 0000.0100 power
Port 3: 0100.0100 power
Device Status: 0x0000
(Bus Powered)
</pre>

== Steel Battalion Controller ==

[[File:SBC.jpg|thumb|200px|Steel Battalion Controller Layout]]

=== USB Descriptors ===

<pre>
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0a7b
idProduct 0xd000
bcdDevice 1.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 88 Xbox
bInterfaceSubClass 66 Controller
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
</pre>

=== Controller to Xbox ===

From http://steelbattalionnet.codeplex.com/SourceControl/latest#SBC/SteelBattalionController.cs

26 bytes

{| class="wikitable"
!Field
!Offset (Bytes)
!Mask
!Notes
|-
|RightJoyMainWeapon
|2
|0x01
|
|-
|RightJoyFire
|2
|0x02
|
|-
|RightJoyLockOn
|2
|0x04
|
|-
|Eject
|2
|0x08
|
|-
|CockpitHatch
|2
|0x10
|
|-
|Ignition
|2
|0x20
|
|-
|Start
|2
|0x40
|
|-
|MultiMonOpenClose
|2
|0x80
|
|-
|MultiMonMapZoomInOut
|3
|0x01
|
|-
|MultiMonModeSelect
|3
|0x02
|
|-
|MultiMonSubMonitor
|3
|0x04
|
|-
|MainMonZoomIn
|3
|0x08
|
|-
|MainMonZoomOut
|3
|0x10
|
|-
|FunctionFSS
|3
|0x20
|
|-
|FunctionManipulator
|3
|0x40
|
|-
|FunctionLineColorChange
|3
|0x80
|
|-
|Washing
|4
|0x01
|
|-
|Extinguisher
|4
|0x02
|
|-
|Chaff
|4
|0x04
|
|-
|FunctionTankDetach
|4
|0x08
|
|-
|FunctionOverride
|4
|0x10
|
|-
|FunctionNightScope
|4
|0x20
|
|-
|FunctionF1
|4
|0x40
|
|-
|FunctionF2
|4
|0x80
|
|-
|FunctionF3
|5
|0x01
|
|-
|WeaponConMain
|5
|0x02
|
|-
|WeaponConSub
|5
|0x04
|
|-
|WeaponConMagazine
|5
|0x08
|
|-
|Comm1
|5
|0x10
|
|-
|Comm2
|5
|0x20
|
|-
|Comm3
|5
|0x40
|
|-
|Comm4
|5
|0x80
|
|-
|Comm5
|6
|0x01
|
|-
|LeftJoySightChange
|6
|0x02
|
|-
|ToggleFilterControl
|6
|0x04
|
|-
|ToggleOxygenSupply
|6
|0x08
|
|-
|ToggleFuelFlowRate
|6
|0x10
|
|-
|ToggleBuffreMaterial
|6
|0x20
|
|-
|ToggleVTLocation
|6
|0x40
|
|-
|
|6
|0x80
|
|-
|
|7
|0xFF
|
|-
|
|8
|0xFF
|
|-
|AimingX
|9
|0xFF, maybe 0xFFFF at offset 8?
|"Aiming Lever" joystick on the right. X Axis value.
|-
|AimingY
|11
|0xFF, maybe 0xFFFF at offset 10?
|"Aiming Lever" joystick on the right. Y Axis value.
|-
|RotationLever
|13
|0xFF, maybe 0xFFFF at offset 12?
|"Rotation Lever" joystick on the left.
|-
|SightChangeX
|15
|0xFF, maybe 0xFFFF at offset 14?
|"Sight Change" analog stick on the "Rotation Lever" joystick. X Axis value.
|-
|SightChangeY
|17
|0xFF, maybe 0xFFFF at offset 16?
|"Sight Change" analog stick on the "Rotation Lever" joystick. Y Axis value.
|-
|LeftPedal
|19
|0xFF, maybe 0xFFFF at offset 18?
|
|-
|MiddlePedal
|21
|0xFF, maybe 0xFFFF at offset 20?
|
|-
|RightPedal
|23
|0xFF, maybe 0xFFFF at offset 22?
|
|-
|TunerDial
|24
|0x0F
|The 9 o'clock postion is 0, and the 6 o'clock position is 12. The blank area between the 6 and 9 o'clock positions is 13, 14, and 15 clockwise.
|-
|
|24
|0xF0
|
|-
|GearLever
|25
|0xFF
|The gear lever on the left block.
|}

=== Xbox to Controller ===

From http://steelbattalionnet.codeplex.com/SourceControl/latest#SBC/SteelBattalionController.cs

34 bytes

{| class="wikitable"
!Field
!Offset (Bytes)
!Mask
!Notes
|-
|EmergencyEject
|2
|0x0F
|
|-
|CockpitHatch
|2
|0xF0
|
|-
|Ignition
|3
|0x0F
|
|-
|Start
|3
|0xF0
|
|-
|OpenClose
|4
|0x0F
|
|-
|MapZoomInOut
|4
|0xF0
|
|-
|ModeSelect
|5
|0x0F
|
|-
|SubMonitorModeSelect
|5
|0xF0
|
|-
|MainMonitorZoomIn
|6
|0x0F
|
|-
|MainMonitorZoomOut
|6
|0xF0
|
|-
|ForecastShootingSystem
|7
|0x0F
|
|-
|Manipulator
|7
|0xF0
|
|-
|LineColorChange
|8
|0x0F
|
|-
|Washing
|8
|0xF0
|
|-
|Extinguisher
|9
|0x0F
|
|-
|Chaff
|9
|0xF0
|
|-
|TankDetach
|10
|0x0F
|
|-
|Override
|10
|0xF0
|
|-
|NightScope
|11
|0x0F
|
|-
|F1
|11
|0xF0
|
|-
|F2
|12
|0x0F
|
|-
|F3
|12
|0xF0
|
|-
|MainWeaponControl
|13
|0x0F
|
|-
|SubWeaponControl
|13
|0xF0
|
|-
|MagazineChange
|14
|0x0F
|
|-
|Comm1
|14
|0xF0
|
|-
|Comm2
|15
|0x0F
|
|-
|Comm3
|15
|0xF0
|
|-
|Comm4
|16
|0x0F
|
|-
|Comm5
|16
|0xF0
|
|-
|
|17
|0x0F
|
|-
|GearR
|17
|0xF0
|
|-
|GearN
|18
|0x0F
|
|-
|Gear1
|18
|0xF0
|
|-
|Gear2
|19
|0x0F
|
|-
|Gear3
|19
|0xF0
|
|-
|Gear4
|20
|0x0F
|
|-
|Gear5
|20
|0xF0
|
|}

== Related links ==
[https://github.com/xqemu/xqemu/blob/xbox/hw/xbox/xid.c XID emulation in XQEMU]

[https://docs.google.com/spreadsheets/d/1-c1tXfOMvaWuno3ixQyI_rPCQVAZA24N4v9OPZUSrCk/edit?usp=sharing Compilation of Xbox Controller Hardware Research]