SN 406999554005

From Free60 Project

This page documents the teardown and evolution of box 406999554005. It is a running logbook of a work in progress, with the following goals:

• summarizing findings
• confirming speculations where possible
• sharing results
• collecting new directions for exploration (please post suggestions in the talk page)

An effort will be made to avoid repetition of existing information, and to fold new discoveries into the database of known data.

Box 406999554005 was acquired in early December 2005. It is a CORE system. According to the Xbox serial number standard, this box was the 69,995th manufactured on assembly line 4, factory 05 (China), during workweek 40 (Sep 25 - Oct 1) of 2005. The manufacturing date is 2005-09-28 as printed on the case. It has no hard drive. It is a system from the European market. As such, the power supply only works with voltages from 200-240V. Noted that the power cord connector uses a derivative of the IEC60320 (http://en.wikipedia.org/wiki/IEC_60320) inlet. The modification is a central rib underneath the ground connector. Query as to why? Perhaps the pinout is also proprietary. Advise caution on attempting to interoperate with standard IEC60320 hardware.

Prior to box power-on, a preliminary tear-down was conducted to capture mutable, measurable state to inform us on changes that happen due to user interaction (setting preferences, updating firmware, interaction with Live service, etc.). The following non-volatile memory stores were noted on the board, as mentioned in numerous other fora:

• A 128 Mbit Hynix NAND FLASH part, HY27US08281A, with laser marking M9S80219
• A 2kbit Serial EEPROM located near the processor, Atmel type 25020A

Interestingly, the NAND FLASH footprint has holes underneath it for assisting with the mounting of a socket. How convenient. Missing image
Flash_footprint.jpg
Image:Flash footprint.jpg

The following laser markings and lot codes were noted:

• CPU: XCPU / X02046-002 / D-B00 / 053300PFC / C TAIWAN
• GPU: GPU / X02056-010 / A-A32/E-C00/B / 05325GC1 / AA Taiwan / N24326.00/3B53V8055 / X02056-011 (post-fab laser marked, interesting! a re-coding of a manufactured part?)
• Southbridge: XSB / X02047-012 / B-G0 / 0530PQD3636
• Video codec (analog): Ana / X02014-007 / A-B03 / 0531FK4507.1 / AA Taiwan

Noted that a Cypress CY28517ZXC (http://www.cypress.com/portal/server.pt/gateway/PTARGS_0_2_1208_205_0_43/http%3B/sjapp20%3B7001/publishedcontent/publish/qualification_reports/content/_cy28517___microsoft_xenon_clock_generator__option_d__4.pdf) is used for clock generation (see Ana for a related discussion). The qualification report indicates 0.3um technology with 3 layers metal. It may be possible to reverse engineer this chip with optical microscopy to reveal some programming and/or configuration data that could be valuable if underclocking is desired for aiding the analysis of high speed busses (presuming the PLLs in the CPU can lock to lower speeds).

Table of contents

1 FLASH ROM Preliminary Analysis 2 Serial EEPROM Preliminary Analysis 3 Orientation Switch 4 Initial Power-On

FLASH ROM Preliminary Analysis

Facts:

The FLASH is a NAND-type memory. This is in contrast to the NOR type, which was used on the original Xbox. NAND-type FLASH has the following salient properties:

• High density (best cost per bit)
• Slower read and write times than NOR
• Block-based addressing scheme, with further subdivision into pages
• Allowance for bad blocks and/or ECC

This particular ROM features 16-kByte blocks with 512-byte pages, and each page features a 16-byte spare. The spare space is often used to store an ECC, due to the fact that this kind of FLASH wears out after 100,000 write cycles; ECC can effectively extend the life of the FLASH as single bits start failing. The key implication of a NAND FLASH is that random access is somewhat difficult; pages must be read into a page buffer within the FLASH prior to access. This implies the following about the system architecture:

• Executable code regions must be copied to RAM prior to running for good performance
• Performance sensitive data must also be copied to RAM
• The physical layout of each FLASH may vary due to the presence of bad blocks and bits

This also implies that different ROMs read out on different systems may create different binary images, depending on how the reader was configured--for example, if it skips bad blocks, if it in-lines the ECC regions, etc.

For the purpose of this analysis, the ECC blocks were skipped, and bad blocks were skipped.

The amount of data on the ROM is very large, 16 Mbytes altogether in size. Presumably, such a large-sized ROM is used because Xbox360s must operate without a hard drive, and the FLASH doubles as both a minimal file system and storage for boot code. Analyzing such a large piece of data by hand is difficult, so a histogram was used to digest the ROM into salient regions.

The FLASH ROM appears to consist primarily of ciphertext, blank regions, and some interspersed plaintext regions. The plaintext hints at a filesystem being stored on the ROM.

Reflections:

A strong implementation of security would employ, a strong (128-bit+), unique-key-per-box cipher, with the session key either stored in the CPU silicon, or encrypted with a public key matched to a master private key stored in the CPU silicon.

It is yet unknown whether a symmetric or asymmetric cipher is used. An experiment to perform is to modify the filesystem and look at basic-block sized similarities and differences in the resulting image. If a cipher like AES is used, all ciphertext modifications should fall on 128-bit (16-byte) boundaries. Furthermore, if a hash and signature are used, the hash and signature region should change with every filesystem modification. A hash and signature is probably ill-advised given a write endurance of 100,000 cycles; the use of ciphertext may aggravate average FLASH lifetime, since the chance of a bit flipping on each erase-write cycle is higher. It should be easy to determine if a signature is used on the blocks, as a small modification of a file should lead to an error. Ponder this--what happens if power is lost while the FLASH is being updated? A partial write update could be disastrous. I hope warranty return covers this scenario.

Mitigating factors against this security would include:

• Difficulties in deploying a unique-per-box encrypted 16 Mbyte filesystem. Who is doing the encrypting? How would this be correlated to the CPU key? Either they have a very expensive custom programmer, or a mechanism is in place where the native CPU in the Xbox is used to bootstrap the encryption process. In this scenario, a virgin Xbox would be loaded with a plaintext filesystem, and once the CPU was keyed, it would proceed to encrypt everything around itself. Note that it takes about 16 seconds to write the FLASH if the NAND write algorithm is fully optimized. That's 185 CPU-days to program 1,000,000 boxes worth of FLASH. Thus, if a single encrypted filesystem image is used with a secret key buried in the CPU silicon, this could be a palatable key to obtain. The single filesystem hypothesis should be confirmable if a second box is obtained for comparison study.
• If a symmetric cipher is used without a signature block (for performance and/or reliability reasons, as cited above), then a possible attack presents itself. Presumably, an instruction aligns itself on a block boundary that is finer than the cipher's granularity. Opcodes in the PowerPC architecture occupy bits 0:5 of the instruction, which means there are only 64 possible opcodes. It should be statistically likely to generate a branch opcode (1 in 64 chance or thereabouts) if the cipher is good. The branch target is unknown, but it may be possible that it lands in a "softer" region of memory that is in the clear. The feasibility of this attack depends upon how large a window of soft memory exists. Note that the immediate field of an I-form instruction is 23 bits large. The presence of a hypervisor may defeat this attack if the hypervisor cannot be deactivated and it can detect modifications such as this one.

Serial EEPROM Preliminary Analysis

Facts:

The serial EEPROM reads out as blank (all bytes 0xFF). There is a remote chance that a proprietary EEPROM modification was performed at Microsoft's request. A small modification to the SPI instruction set of the EEPROM would defeat a simple reader. This hypothesis should be verifiable by watching for any traffic on the SPI bus and observing what the CPU does with the memory.

It is possible that this serial EEPROM is the one mentioned in IBM's presentation (http://www-128.ibm.com/developerworks/power/library/pa-fpfxbox/?ca=dgr-lnxw06XBoxStory) on the Xbox360:

  The block labeled Miscellaneous IO provides a JTAG port, a POST monitor, and an interface for a serial EEPROM in case patch logic configuration was needed during bring-up.

The fact that the EEPROM is blank may lead one to conclude that no patching was required in this revision of the processor. However, the EEPROM may have been populated in case a field-patch was necessary to close up any bugs not caught prior to shipping the box.

Significantly, some boxes were noted to lack this EEPROM. It would be interesting to collect a database of box serial numbers, correlated against EEPROM presence or absence, and if possible, the manufacturing date and lot code of the CPU. It is possible that later CPU revs were solid enough to ship without the EEPROM populated.

Reflections:

It is unlikely that a box with a high standard of security would leave a backdoor such as a serial EEPROM that could override the security. Presumably, the patching data provided by the serial EEPROM is limited to non-security related functions. However, any back door is welcome for exploration, and a deeper understanding of this EEPROM is probably called for.

Orientation Switch

An entertaining feature of the Xbox360 is the incorporation of an orientation switch on the motherboard. Device SW2G1 is a ball bearing switch. Probing with a voltmeter while changing the orientation of the board reveals that the impedance of the switch changes depending upon orientation. The ball bearing in this switch lends the Xbox360 motherboard a distinctive rattle when shaken.

Presumably, the orientation switch is required because the Xbox360 can operate in vertical or horizontal orientations and certain UI parameters must be adjusted accordingly (such as the wireless controller indicator lights).

Missing image
Orientation_sw.jpg
Image:Orientation sw.jpg

Initial Power-On

Facts:

Prior to initial power on, box 406999554005 had the FLASH ROM socketed and replaced, and the system was mounted on an open-face carrier for accessibility (see photo below). Electrolytic capacitor C2E7 (100uF, 16V) was detached and re-attached sideways to accomodate hand-soldering of the socket. A logic analyzer was attached directly to the 25020A serial EEPROM part. Direct attachment was chosen over probing the nearby header because resistors were noted in the path to the header that could interfere with measurements.

Missing image
Openface.jpg
Image:Openface.jpg

Missing image
Socketed.jpg
Image:Socketed.jpg

On power-on, CS, SI, and SCK were observed to go high. 95 ms after power on, SI glitches low for approx 220 us, and then SCK drops. 140 ms subsequent, SI is observed to glitch again. The logic analyzer ceased to sample at this point. To capture this stream, the logic analyzer was set with a 0-1 threshold of 1.0V, to attempt to capture data if a 1.8V low-voltage standard was being employed (standard TTL thresholds may not capture smaller amplitude transitions).

The Xbox was allowed to reach the language customization screen, and then it was powered off.

At this point, the FLASH ROM was re-read and compared against the original image. No modification was detected in the FLASH ROM.

The Xbox was rebooted a second time (actually a third, one boot was aborted due to an unattached cable), and on this boot, the language was set to English. The system was also set to continue without a hard drive module. At this point, the Xbox was powered down atd the FLASH ROM was re-read.

Modifications were noted in the ROM from locations 0x91D400 - 0x91DFFF. Prior to setting the language, the section was blank (0xFF values). After setting the language, the modified region was occupied with sparse data (mostly 0x00, some bits set here and there), followed by a region of cryptographic-looking binary region of 492 bytes (0x91D803-0x91D9EF), and what, on trivial inspection, looks to be a second copy of the data (sparse region + crytographic-looking binary region). Upon closer inspection, differences were revealed:

offset   1st 2nd region
0x003B   00  40
0x05F0   00  10
0x0607   01  00
0x062F   01  00

Offset is computed from 0x91D400 (1st region) and 0x91DB00 (2nd region).

Further minor activity was noted on the serial EEPROM bus during this last run. Activity was noted at approx. 120 seconds. I did not note if this happened to correlate to events such as selecting the language, as I was not paying attention to that aspect.

An attempt was made to boot the Xbox without the FLASH ROM installed, while monitoring activity on the serial EEPROM bus. It was noted that once every 5 seconds for 20 seconds, the serial in line (pin 5) was raised for 150 ms, and then lowered and quickly raised again for 500 us. Thus, this pattern was repeated a total of *five* times (remember time 0 counts too).

Significantly, the SEEPROM was measured to be running off of a 1.9V power supply. Thus, logic analyzers probing the bus should be set with a threshold around 0.9V to properly capture transitions with margin.

Note there is a 150 ohm resistor on the WP pin of the SEEPROM to the SEEPROM VDD. There is also a blank spot on the board for a resistor to GND. Thus, the SEEPROM is "default" write-protected, but a sufficiently large (12 mA) driver could override this and enable writes.

Reflections:

The behavior of the SEEPROM bus without a proper FLASH ROM image attached indicates that the processor is at least aware of the fact that it has some fiduciary device attached to its side. However, the behavior noted is inconsistent with any constructive behavior toward driving the Atmel 25020A. Significantly, the SIN toggling occurs while the CS line is being held high (the flash device is deselected). This indicates that perhaps the header on J7F1 also serves a dual purpose, perhaps to interface to some equipment that is active when the CS line is high.

This data works to support a theory that the SEEPROM is there to support some kind of internal patching inside the Xbox360 CPU, but it is unclear what the mechanism is for initiating the patch sequence. Some experiments to try would be to tie various pins of the SEEPROM to supply rails and observe what the other pins do.

Next up...fuzzing the FLASH ROM. Attempt to modify single byte values in the FLASH ROM image to determine regions of sensitivity to modification. This should provide some insight into what pieces of the ROM are checked at boot time, and what pieces are ignored.

After multiple test on my xbox 360 running linux I found out the following:

I cannot access more then 190Megs of video ram,After that it starst swapping memory The proccesor is at max load around 390Bmips, which equals around 400MHz I also cannot run some binaries because of system requirements. My benchmark has set the Xbox360 under me PII, How can this be?

-Elonix