Bonjour à Tous.

[floflo]

Bonjour à tous, je suis un nouvel arrivant et je remercie tout le monde pour

ce fabuleux forum qui m'a permis de modifier ma xbox.

J'ai trouver quelque

chose sur le net (c'est en anglais et assez long désolé). Est ce que quelqu'un

pourrait me dire si il y a des choses interressantes et qui ne sont pas encore

connues?

Keeping Secrets in Hardware:

the Microsoft XBoxTM

Case

Study

Andrew “bunnie” Huang

AI Memo 2002-008 May 26, 2002

© 2 0 0

2 m a s s a c h u s e t t s i n s t i t u t e o f t e c h n o l o g y, c a m b r i d g e , m a 0 2 1 3 9 u s

a — w w w. a i . m i t . e d u

m a s s a c h u s e t t s i n s t i t u t e o f t e c h n o l o g y — a r t i

f i c i a l i n t e l l i g e n c e l a b o r a t o r y

Abstract

This paper discusses the

hardware foundations of the cryptosystem employed

by the XboxTM video game console

from Microsoft. A secret boot block overlay

is buried within a system ASIC. This secret boot

block decrypts and verifies

portions of an external FLASH-type ROM. The presence of the

secret boot block

is camouflaged by a decoy boot block in the external ROM. The code

contained

within the secret boot block is transferred to the CPU in the clear over a set

of

high-speed busses where it can be extracted using simple custom hardware.

The

paper concludes with recommendations for improving the Xbox security

system.

One lesson of this study is that the use of a high-performance bus alone is not

a

sufficient security measure, given the advent of inexpensive, fast rapid

prototyping

services and high-performance FPGAs.

2

1 Introduction and

Background

Every cryptosystem is based on some kind of secret, such as a key.

Regardless of the

cipher, the security of a cryptosystem is only as strong as the secrecy of

the key. Thus,

some of the most startlingly effective attacks on a cryptosystem involve no

ciphertext

analysis, but instead find flaws in the protocols that manage the keys.

Cryptosystems

based on symmetric ciphers are particularly vulnerable to protocol attacks,

since both

the sender and the receiver must be trusted to have a copy of the same secret

key.

Despite the difficulty of key management in symmetric ciphers, they remain

attractive

because of their algorithmic simplicity and high throughput when compared to

public

key ciphers.

Symmetric cipher key management becomes especially problematic

when the receiving

party is not trusted or is in a position that can be easily compromised.

This

is where tamper-resistant hardware comes into play; a summary of

tamper-resistance

guidelines can be found in [6]. Many systems employ tamper-resistant

hardware techniques

in varying degrees, including the Sandia National Labs’ “Stronglink”

micromechanical

24-bit lock [2], the Clipper chip [1], IBM’s 4758 PCI Cryptographic

Coprocessor

[3], Cryptographic Smartcards [5] [4], Automatic Teller Machines (ATMs),

and

now, video game consoles. However, trusting inadequate physical security measures

to

protect important secrets is risky. [14] and [15] present examples of how some of

the

aforementioned tamper-resistant systems can be defeated with surprisingly simple

and

direct methods.

In the case of the XboxTM video game console from Microsoft,

the secret being

protected is a key and an algorithm for decrypting and verifying a

bootloader. This

bootloader then decrypts and verifies a kernel image. Both the bootloader

and kernel

image are contained in an unsecured FLASH ROM. The kernel then verifies

the

authenticity and integrity of the applications it runs. Thus, a chain of trust is

grown,

bottom up, from a seed of trust. This seed–the secret key and an algorithm–is

planted

in a physically secure, secret boot block.

The Xbox architecture results in the

deployment of large number of identical devices,

all of which contain the same secret

information. As the analysis below illustrates,

the security of such a system can be readily

compromised, even if the secret is

protected by tamper-resistant hardware and obscured

by algorithmic complexity.

2 Xbox Hardware Cryptosystem Overview

The Xbox crypto

protocol presents a strong defense in the face of unsecured FLASH

ROM-based

modifications. Please refer to figure 1. The Xbox boots from a 512-byte

secret boot block

that is hard-coded into the southbridge system ASIC (the “MCPX”).

This boot block

performs the following functions, in order:

loads the “jam tables”, i.e., initializes the console

chipset

turns on the processor caches

decrypts the kernel bootloader, contained in

FLASH ROM

verifies that decryption was successful

jumps to the decrypted kernel

bootloader

3

The bootloader then performs some more system initialization, decrypts a

kernel

image from FLASH ROM, decompresses and verifies the decrypted image, and

enters

the kernel. The kernel decryption key is stored within the bootloader image. Note

that

the secret boot block code is structured so that the bootloader decryption key is

never

written to main memory, thus defeating an attack that involves eavesdropping on

the

main memory bus.

The bootloader is encrypted with RC-4 using a 128-bit key. The

decryption algorithm

and key are stored in the secret boot block and executed by the

Pentium CPU;

the busses between the secret boot block and the CPU are not encrypted

but assumed

to be secure due to their high speeds. The decryption of the bootloader

image is veri-

fied by checking for a 32-bit magic number near the end of the plaintext

stream. This

check only ensures that the ciphertext stream was not corrupted; one with

knowledge

of the secret key and the magic number can easily create original bootloader

images.

It is fairly clear from the code structure of the secret boot block that such a

simple,

unreliable check was employed because there was not enough space for anything

else.

The magic number check might also confuse efforts to create original bootloader

code

based on a key obtained without full knowledge of the secret boot block’s

contents,

such as through a personnel leak or brute force. However, a brute force

approach to recovering

the bootloader is probably out of the question, since

distributed.net’s “bovine”

effort, running for over 4 years and currently capable of testing

over 100 gigakeys/s, is

still working on a 64-bit RC-5 cipher at the time of writing

[7].

Given this secure boot protocol, modifying the contents of the FLASH ROM

alone

will stand a very low chance of revealing anything useful about the console1.

This

is compounded by the fact that the FLASH ROM contains a decoy boot block

with

halfway reasonable looking decryption and initialization code. The algorithm in

the

decoy boot block is a bastardized RC-4, and of course applying this algorithm on

the

ROM contents yields nothing but white noise. Further discussion on how the

secret

boot block was discovered is contained in the next section.

3 Breaking the

Physical Security

This section provides a chronology of how the Xbox’s physical security

was reverse

engineered.

Reading out the FLASH ROM contents and tracing the

processor’s execution starting

from the boot vector proved to be futile, as the contents of

the boot block in the

FLASH ROM were a decoy, cleverly designed to thwart such activity.

The code within

the FLASH ROM boot block followed the same general flow as the code

within the

secret boot block, but the decryption algorithm, the keys and the ciphertext start

location

were incorrect. This initially resulted in a great deal of confusion but was

later

explained by the discovery of the secret boot block overlay.

The realization of the

existence of a secret boot block happened as a result of the

observation that overwriting

the processor reset vector in the FLASH ROM has no

effect on the Xbox boot sequence.

This led to a series of experiments that mapped out

1An important exception recently

discovered is described in section 6.

4

controllers

key-locked

hard

disk

(executeables,

cached data,

save

games)

pentium

CPU

NV2A

northbridge

+

gfx

MCPX

southbridge

SDRAM

64

MB

FLASH

ROM

(bootloader

+ OS kernel)

secret boot

ROM

DVD

drive

(game data /

executeables)

game

controllers

dongles

w/

executeables

(DVD

player,

etc.)

IDE

HyperT

SSTL-2

GTL+

64/

32+

128/

21+

r>8/

2

legacy

8/

24+

133

MHz

200

MHz

DDR

200

MHz

DDR

MHz

secure hardware boundary

security

relationship

not yet known

trusted code

and data:

digitally signed

with

Microsoft

private key

bus width:

data/others

bus

clock

rate

100Base-T

USB

Figure 1: Overview of the Microsoft Xbox

hardware.

5

the extent of the secret boot block. The block is believed to be 512 bytes

in length,

situated at the highest location in processor physical memory.

The following

approaches were then considered for extracting the secret boot block

contents:

decapping the MCPX southbridge ASIC

using the JTAG boundary scan on the Pentium to

step through the “real” boot sequence

probing the main memory bus for any portions of

the boot block that were written

to memory

probing the processor-northbridge bus

using a logic analyzer or custom hardware

probing the HyperTransport

northbridge-southbridge bus using custom hardware

The direct approach of decapping the

MCPX southbridge ASIC was rejected because

this ASIC appears to be manufactured in a

0.13 process with perhaps 6 or 7

metal layers (figure 2). Extracting the bootblock from this

ASIC would require a delayering

facility and access to an electron microscope. While there

are companies such

as Chipworks that specialize in these kinds of services, it is a difficult,

expensive, and

time-consuming task.

Figure 2: Die shot of the MCPX Southbridge

ASIC

The JTAG boundary scan approach was rejected on the grounds that the

TRST#

pin, used to hold the JTAG chain in reset, was tied active in a manner that was

difficult

to modify without removing the processor. Removal and socketing of the

processor

was considered to be prohibitively expensive and time consuming; the cost of a

BGA

socket for the Pentium III is estimated to be in the hundreds to thousands of dollars.

In

addition, the JTAG boundary scan codes for the Pentium III are largely proprietary

and

would have to be reverse engineered as well.

SDRAM probing was rejected on

the grounds that far too many pins (128 data pins

6

alone) had to be simultaneously

probed, and on the grounds that the decryption routine

and/or key could be held entirely in

processor cache and never written to SDRAM.

Also, the cost of solder-on

TQFP-100-to-logic-analyzer adapters is prohibitive (around

$600 per adapter; four are

required). Probing the processor-northbridge bus was rejected

for similar reasons: at least

64 data pins had to be probed, and tapping such a

large number of GTL+ signals without

causing signal integrity issues was thought to

be very difficult.

The

northbridge-southbridge bus, however, showed promise because of its simplicity.

The bus

has a low signal count (10 unique) and all the signal traces are laid

out on the console’s

motherboard in a straight flow-through fashion (12-mil center-tocenter

spacing within a

differential pair, 13-mil spacing between differential pairs, see

figure 4). In addition, the

clock and strobe signals for both the transmit and receive

directions are clearly labeled on

the motherboard, perhaps for manufacturing debug

and test reasons (figure 3). Data on the

nVidia nForce chipset [9], a close relative to

the Xbox chipset, indicates that the bus uses

the HyperTransport (formerly known as

Lightning Data Transport (LDT)) protocol. The

specifications for the HyperTransport

protocol are open and readily available. [8]

Figure

3: HyperTransport bus layout showing silkscreen information

The primary difficulties in

tapping the HyperTransport bus are its high speed (200

MHz DDR) and its use of

differential signaling (few logic analyzers come with support

for differential signaling). It is

interesting to note that HyperTransport bus protocol

7

analyzers are commercially

available from vendors such as FuturePlus, but they cost

upward of $25,000. This

price does not include the high-end logic analyzer required to

drive the protocol

analyzer.

The alternative solution to tapping the northbridge-southbridgeHyperTransport

bus

was to build a relatively cheap, fully custom, differential-to-single-ended “Tap

Board”,

and to connect the output of this board to an FPGA. A Xilinx Virtex-E part was used

in

this study because it was readily available, as it was used as part of the author’s

thesis

work; however, a better choice would be any of the new Xilinx Virtex-II FPGAs.

A

suitable Virtex-II FPGA would cost about $50 in single quantities.

The custom

Tap Board uses a two-layer, 6 mil trace/space, 15 mil hole process from

Advanced

Circuits, offered at a price of $33 per board in small quantities. A Texas

Instruments

SN65LVDS386 LVDS-to-TTL converter was used to turn the differential

HyperTransport

signals into a single-ended format. It turns out that the HyperTransport

physical signaling

specification is similar to LVDS, but with a different common-mode

offset. The output of the

converter drives a cable to the FPGA board. The FPGA

is configured to receive the high

speed signals with the CTT (Center-Tap Terminated)

“Select I/O” option. CTT is chosen

because it allows the single-ended TTL drivers to be

terminated with a low impedance to

1.5V and still function properly. Note that although

Virtex-E FPGAs support LVDS directly,

the target FPGA board was not originally

designed to support the LVDS

configuration.

12 mil

13 mil

12 mil

differential signal pair

6

mil

trace

Figure 4: Dimensions of the HyperTransport signal traces on the

motherboard.

The Tap Board has on one edge a pattern of traces with no soldermask that

matches

the pattern of traces on the Xbox motherboard. The Tap Board was soldered

directly

to the Xbox’s northbridge-southbridge bus. Only the receive-direction Tap Board

was

mounted for this study. The mating edge was shaped using a belt sander, so that

the

tapping traces were flush with the edge of the board, and the board could be

mounted

at a reclined angle to enhance solderability. The soldermask on the Xbox was

removed

with fine-grit sand paper, and the Tap Board was carefully aligned by hand, and

then

held roughly in place by soldering a coarse piece of wire between the Tap Board and

the

motherboard. A hard-setting adhesive, such as Miller-Stephenson Epoxy 907, was

applied

to fix the angle and mating distance of the Tap board to the motherboard; once

the

epoxy was cured, the holding wire was removed, and the traces between the Tap

Board

8

and the Xbox motherboard were easily soldered using a fine-tip iron and a

microscope.

Figure 5: Tap Board connected to the FPGA board. The FPGA board was

originally

developed by the author for another work.

The polarity of the HyperTransport

bus signals was determined by probing the idle

state of the wires, assuming that their idle

state had a value of 0x00. Those signals that

had the positive and negative pairs swapped

relative to the Tap board layout idled to

a “1”. Signals with inverted polarity were restored to

their true value within the trace

capture FPGA.

Figure 6: Close-up of the Tap Board

mounted in the Xbox

A Xilinx Virtex-E FPGA was used to capture traces of HyperTransport

bus activity.

It was difficult getting the FPGA to manage the 200 MHz DDR data rates

with

9

low skew. However, careful hand-layout of the input registers, post-layout timing

simulations

at nominal temperature and voltage, and iterations to manually tweak

delays

and skews eventually centered the clock signal within the data signal on the

FPGA’s

input registers. The retimed data was then demultiplexed to a very manageable

100

MHz single-data rate 32-bit wide bus and written into a bank of FIFOs, along with

a

sequence count that recorded at what cycle relative to a reset signal the data

was

captured. Some additional logic was incorporated into the FPGA that discarded

idle

values (0x0000 0000) from the trace FIFOs and formatted the deserialized data

relative

to the strobe signal, clearly identified on the Xbox motherboard as “RXD8 /

RXD*8”

(figure 3) in sector 5D (the Xbox motherboard has a coordinate system printed on

its

periphery).

The reset signal can be determined by probing traces near the

HyperTransport bus

that behaved like a reset signal. In reality, it is possible that some

signal that was not

the true reset signal was used to trigger the trace capture, but that is

irrelevant as the

signal chosen seemed to display a consistent timing relationship with

respect to the

bus. In fact, the signal used to trigger the trace capture exhibited a 350 ns

runt pulse

about 67 ms after power-on-reset; this runt pulse was filtered out by a state

machine,

as it was erroneously restarting the trace capture.

Once traces of data were

captured by the FPGA, the order of the bits on the HyperTransport

bus relative to the Tap

Board layout could be determined. This can be

done by correlating known values in the

FLASH ROM with data values captured on

the HyperTransport bus. A 1’s count can be

used to identify candidate patterns and

data sequences for manual correlation. Fortunately,

very early on in the trace several

distinctive, sequential values are grabbed from the

FLASH ROM: a few values from

the lowest address in FLASH ROM, followed by a few

values from the boot vector,

which happens to be identical between the decoy FLASH

ROM contents and the secret

boot ROM contents. The order of the traces for the

receive-direction bus on the motherboard

are believed to be, from the outside to the inside,

bit 8 (CTL strobe), 4#, 0#,

7#, 2#, 3#, CLK#, 5, 6#, and 1#. Signals with # after them are

inverted with respect to

the Tap Board layout.

The raw trace data captured by the

FPGA was then dumped to files and manually

processed. An example illustrating the format

of trace data can be found in figure 7.

The sequence numberwas critical in determining the

boundaries of cache traces; blocks

of 8 or 16 words are fetched by the processor, even

when the caches are off. Trace data

was differentiated between secret boot code and

FLASH ROM data by searching for

the first word of the candidate trace in a dump of the

FLASH ROM; if the data could

not be found in the FLASH ROM, it was guessed to be

secret boot code. Because the

processor boots with its caches off, the first roughly 24

million bus cycles contained

repeated line fills of the “jam table” initialization code, and were

ignored as they just

performed the wrote initialization of the chipsets. The caches were

then turned on

by the boot code, and very clear and simple to read blocks of instructions

and data

were found. These instruction traces were mapped into the secret boot block

using

the decoy FLASH ROM boot block as a template. The recovered block of code

was

then disassembled, and the decryption algorithm was determined to be 128-bit

RC-4.

Because the location of the 128-bit key within the secret boot block was

ambiguous

(the Tap Board only provides data traces without addresses), a brute-force

search was

10

00000097 : 664A1D55 ::: E : 000000C6

00000D5C : 05F108F6 :::

F : 01000000

00000DE0 : 2A1A2841 ::: 1 : CC003000

00000E5D : B6FE7F68 ::: E :

A0552C01

00000EDA : 5932C662 ::: 1 : 000000FD

00000F57 : F9FBA4C1 ::: E :

C7C94000

00000FD4 : F7F9B6AE ::: 1 : 000000C6

00001051 : 73376133 ::: E :

9EC49400

000010CE : FD0127AD ::: 1 : 000000D6

0000114B : 34E8FD29 ::: E :

C7C94000

00001245 : 1814A022 ::: 1 : 000000C6

000012C2 : 38EBD672 ::: E :

C7C94000

00022526 : C6C0847E ::: 1 : 000000C6

00022527 : A26216BB ::: E :

C7C94000

00022528 : 99DA5F80 ::: E : 000000C6

00022529 : 453862E3 ::: 1 :

C7C94000

000226D5 : B6DF18C0 ::: E : 000000C6

000226D6 : DA562768 ::: 1 :

C7C94000

000226D7 : 0F1D66E3 ::: E : 000000C6

000226D8 : DDC59B59 ::: 1 :

8D42CBCD

Figure 7: An example illustrating the format of trace data captured by the

FPGA.

Format of the data is “sequence : data ::: aligner : unaligned data”.

utilized to

help isolate the key. A 16-byte sliding “guess key” window over the captured

data trace

was used as input to an RC-4 decryption engine, and a histogram of the data

outputwas

used to determine when the key was found. This information helped resolve

some

ambiguities in the placement of the data within the secret boot block, and a full

picture of

the important code within the secret boot block was assembled.

Now that the secret boot

procedure is understood, it is possible to encrypt a new

ROM for the Xbox console, and to

further study the structure of the Xbox bootloader

and kernel. Given the RC-4 algorithm,

the 128-bit key, and the magic check number at

the end of the decrypted segment, one

can run original code on the Xbox.

4 Lessons Learned

One lesson of this study is that

the use of a high-performance bus alone is not a suf-

ficient security measure; the advent

of cheap, fast rapid prototyping services and high

performance FPGAs allows even poor

students to create devices that can tap the bus.

However, encrypting a bus introduces its

own problems. A secure cipher on a high performance

bus significantly impacts latency,

power consumption, and reliability. Power

consumption is increased because the activity

factor for the bus approaches 100%, if

the encryption scheme is any good. In this case, the

power consumed driving the bus

11

would increase by over an order of magnitude, as

the observed activity factor on the

northbridge-southbridge bus was well below 10%.

Reliability is hurt because a single

bit error, even during an idle cycle, can corrupt large

blocks of data; with a stream

cipher, the corruption would extend until the stream is

resynchronized.

A compromise solution to the problem is to simply not trust any bus in the

system.

In this case, the secret boot block might employ a digital signature protocol, such

as

Authenticode R

, using public key algorithms and one-way hashes. [10] Then, all

security

rests in the secrecy of the private key, and the strength of the public key

algorithm.

In order to prevent employee leaks from spreading a private key, a system similar

to the

BBN SignAssureTMcould be used to manage the key so that no human ever has

knowledge

of the private key. The principal drawback of this method is that it requires

extra

silicon area to be spent on storing a larger secret boot block, as it is probably

difficult,

if not impossible, to code a full public key encryption algorithm plus key storage

and

hardware initialization code within 512 bytes.

The above suggestion does not

prevent someone from eavesdropping and obtaining

the plaintext of the operating system

code, but it does effectively defeat any attempt

to run original code. The public key

scheme could be defeated, however, by a mechanism

that snoops the main memory bus

and patches plaintext in main memory. As

discussed previously, this approach is possible,

but difficult; however, the tenacity of

an attacker should not be underestimated. For

example, a known attack on the Sony

Playstation2 console was developed that is rumored

to work by dynamically patching

its high-performance RAMBUS memory system. The

difficulty of a memory patch attack

could be increased by using a simple periodic hash and

check of the critical code

regions in memory.

Buffer overrun exploits are also a point of

weakness, and they work regardless of

the secret boot protocol. An attacker sniffing an

insecure bus could obtain the decrypted

kernel code and analyze it for weaknesses.

However, any machine architecture

that employs guarded pointers [11] is much more

difficult, if not impossible, to attack

using buffer overruns. A fast, efficient guarded pointer

scheme with a simple hardware

implementation is described in [12]. This scheme can easily

be adapted to work in a

64-bit architecture.

A. Kerckhoffs (1835-1903) once stated

that the security of a cryptosystem must not

depend on keeping the algorithmsecret; this is

referred to as Kerckhoffs’ Principle. [13]

Another way of stating this is that there is no

security through obscurity. In particular,

it is an error to assume that a secret, distributed

along with the information it guards, is

never revealed. For example, the Sega Dreamcast

uses a proprietary GD-ROMsoftware

format; but, the drive can read CD-ROM disks. The

discovery of a back door in the

Dreamcast OS allowed executables to be run directly from

a standard CD-ROM, thus

nullifying the barrier presented by the proprietary

GD-ROMformat. Other systems that

rely on well-hidden secrets, including the Clipper chip

[14] and the smartcards used

widely throughout Europe to control access to services such

as pay-TV, cell phones and

gas, have been shown to be surprisingly vulnerable. [15] In

this case, the Tap Board

and trace capture FPGA design was developed in spare time

over the duration of three

weeks–including the 5-day turn time for board fabrication–for a

total cost of around

$50 per board. In other words, if you ship your secrets in your

hardware, it is a good

assumption that the users will eventually–and perhaps quickly–know

your secrets.

12

The failure of the Microsoft Xbox console security protocol is

compounded by the

fact that, as a console manufacturer, design-for-test and

design-for-manufacturability

is paramount. Creating a console with too much security makes

it difficult to debug

and manufacture. For example, the backside of the Xbox motherboard

is populated

with test points–including test points for every pin on the FLASH ROM. These

were

originally installed because of the desire to quickly test for faults during

manufacturing.

The flip side is that one could build a custom “bed-of-nails” tester jig that

uses the

the FLASH-ROM test points to reprogram Xbox motherboards with any desired

code.

This method would be fast, inexpensive and solder-free. The lesson here is that

even if

a manufacturer is very confident about their trust model and security protocols, it

must

guard against the possibility that they may someday be broken. To this extent, a

simple

physical security measure, such as a spray-on conformal coating, would

severely

hamper the re-use of test structures for improper purposes. This of course greatly

complicates

the repair of hardware failures in the field, but that is a business trade-off

the

manufacturer must make.

A more radical alternative would be to design the gaming

system using proprietary

hardware and proprietary media formats, thus limiting the practical

impact of any attack

on the console. Game consoles are manufactured in very high

volumes, so the cost

of developing a simple but effective proprietary format can be

amortized. The format

could then be patented, providing protection against unauthorized

use without the need

for secrecy. This approach was taken by Nintendo with their

Nintendo 64 console. [16]

Although patents have a 20 year lifetime, this is an eternity in the

video game console

industry: the original Nintendo Entertainment System (NES) had its

debut in 1985.

5 Future Work

Understanding the secret Xbox boot protocol is just the

first step in understanding

the Xbox. It is now possible to investigate the kernel and

bootloader in more detail.

It has been determined that the kernel is also encrypted with

RC-4/128, and it is also

believed to be compressed using LZX compression, a scheme

employed byMicrosoft’s

canonical distribution format, the “Cabinet” file. The structure and

function of the

kernel is still being investigated.

One important issue to investigate is the

privacy of users who use the Xbox for online

tasks. It is known, through a parallel effort of

the author, that information such as

the serial number of the console is stored electronically

and is probably accessible to the

kernel. What happens to this information when the Xbox

is plugged into the internet?

Because of the encryption used to secure the Xbox, the

nature of the information that is

relayed toMicrosoft’s on-line game servers is unknown.

Thus, important future work is

to try to determine what the Xbox reveals about the user’s

identity and personal gaming

habits.

13

6 Addendum

It has recently been called

to the author’s attention that the hardware initialization procedure

of the Xbox contains a

significant weakness. [17] Recall from section 2 that

the first step in the Xbox boot process

is to load the “jam tables” that configure the

console’s chipsets. This jam table initialization

procedure involves a lengthy and complex

sequence of writes to various memory-mapped

hardware register locations. As a

result, the initialization procedure is implemented using a

simple bytecode interpreter

that reads initialization commands and data from the FLASH

ROM. These bytecode

commands–stored as plaintext–can be manipulated to cause the

initialization procedure

to abort before the kernel decryption/verification routine is

executed, and to instead run

insecure code directly out of the FLASH ROM. In other

words, with plaintext-only

modifications in the FLASH ROM, one can entirely bypass the

Xbox’s security mechanism.

One could easily fix this security hole, however, by verifying

the jam table’s

contents prior to bytecode execution with a one-way hash function, or by

explicitly

coding all initialization functions within the secure boot block. Both of these

solutions,

however, would require the secure boot block to grow significantly from its

current

512-byte size, and neither solution allows easy changes to the initialization

procedure

in case a bug is found or in case the hardware evolves as a result of cost

reduction

efforts.

Acknowledgments

The author would like to acknowledge the

support of the on-line electronic community.

The author would also like to thank the

Electronic Frontier Foundation for providing

legal counsel. Hal Abelson and Tom Knight

also provided invaluable moral support.

Finally, the author would like to thank Nikki Justis

for all her love and support, and for

giving him such an interesting toy for

Christmas.

References

[1] Federal Information Processing Standards Publication, FIPS

PUB 185: Escrowed

Encryption Standard (EES)

href='http://www.itl.nist.gov/fipspubs/fip185.htm'

target='_blank'>http://www.itl.nist.gov/fipspubs/fip185.htm

[2] Thomas W.

Krygowski, Jeffry J. Sniegowski, M. Steven Rodgers, Stephen

Montague, James J. Allen,

Jerome F. Jakubczak, Samuel L. Miller, Infrastructure,

Technology and Applications Of

Micro-Electro-Mechanical Systems

(MEMS), Sandia National Laboratories, Intelligent

Micromachine Department,

http://www.mdl.sandia.gov/Micromachine, also appears in Sensor

Expo 1999.

[3] IBM, IBM 4758 PCI Cryptographic Coprocessor,

href='http://www.ibm.com/security/cryptocards/'

target='_blank'>http://www.ibm.com/security/cryptocards/

[4] Gemplus (a

smartcard vendor), Gemplus Corporate Website,

http://www.gemplus.com

14

[5] Pil Joon Lee, Eun Jeong Lee,

Yong Duk Kim, How to Implement Cost-Effective

and Secure Public Key Cryptosystems

Proceedings of the First InternationalWorkshop

on Cryptographic Hardware and

Embedded Systems (CHES), August 1999.

[6] Federal Information Processing Standards

Publication, FIPS

PUB 140-2: Security Requirements for Cryptographic Modules,

href='http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf'

target='_blank'>http://csrc.nist.gov/publications/fips/fip...-2/fips1402.pdf

[7]

distributed.net, distributed.net: Project RC5, http://www.distributed.net/rc5/

[8] HyperTransport Consortium,

HyperTransportTMI/O Link Specification, Version

1.03,

href='http://www.hypertransport.org'

target='_blank'>http://www.hypertransport.org

[9] nVidia Corporation, nForce MCP

Product Overview, 06.01v1,

http://www.nvidia.com

[10] Microsoft Developer Network,

Introduction to Code Signing,

href='http://msdn.microsoft.com/workshop/security/authcode/intro'

target='_blank'>http://msdn.microsoft.com/workshop/securit.../authcode/intro

authenticode.asp

[11] Nicholas P. Carter, StephenW. Keckler, andWilliam J. Dally,

Hardware support

for fast capability-based addressing, Proceedings of ASPLOS VI,

October 1994,

pp. 319-27.

[12] Jeremy Brown, J.P. Grossman, Andrew Huang, and

Thomas F.

Knight, Jr., A capability representation with embedded address

and

nearly-exact object bounds, Project Aries Technical Memo 5,

href='http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-05.pdf'

target='_blank'>http://www.ai.mit.edu/projects/aries/Docum...os/ARIES-05.pdf

[13

] Auguste Kerckhoffs, La cryptographie militaire, Journal des sciences militaires,

vol. IX, pp.

5-38, Jan. 1883, pp. 161-191, Feb. 1883.

[14] R. Anderson and M. Kuhn, Tamper

Resistance - a Cautionary Note, Proceedings

of the Second Usenix Workshop on

Electronic Commerce, pp. 1–11, November

1996.

[15] R. Anderson and M. Kuhn, Low

Cost Attacks on Tamper Resistant Devices,

IWSP: InternationalWorkshop on Security

Protocols, LNCS, 1997.

[16] Van Hook, et al., High Performance Low Cost Video Game

System with Coprocessor

Providing High Speed Efficient 3D Graphics and Digital Audio

Signal

Processing, U.S. Patent 6,239,810, May 29, 2001.

[17] Private conversation

with visor. visor can be reached by sending a personal message

to visor on

www.xboxhacker.net

[Invité LaBoulette]

Arff tu methone c super grand jregarde un peu de mon coté

++

LaB

[fredstyle]

cellspacing='1'>

CITATION (LaBoulette @ Thursday 09 October 2003, 17:35)

Arff tu methone c super grand jregarde un peu de mon coté ++ LaB je capte rien à ton trip mec

[Invité LaBoulette]

Bah je voi pas ou je trip !! ?? Il demande si

y'a kk chose d'interressant dans donc truc !! Franchement je voi pas ou

je trippe, tu ferai mieu d'essayé de l'aidé

++

LaB

[floflo]

Je trippe pas, mais j'ai réussi à comprendre tout ça avec un

traducteur.

Bilan: rien de de bien neuf . désolé pour ce post inutile et trop

long.

suggestion: WC on tire la chasse d'eau. merci

[Invité LaBoulette]