Slashdot Mirror
Keeping Secrets in Hardware: Xbox Case Study
BS405397 writes "Here is the just released MIT whitepaper on the security holes in the MS X-Box, and for those who are interested, opens up the X-Box pretty nicely." Update: 06/04 17:13 GMT by M : The server appears to be down at the moment. There is a copy of the paper mirrored here. Reuters and other news outlets have now picked up the story, two days after Slashdot.
Doesn't this violate the DMCA?
Mr. Smoove
Did anyone get it ?
Or found a google cached link ?
When the xbox first came out I wondered about the security holes it would have once they rolled out the internet service. Does anyone know if it is setup in a way that it can receive software updates?
Hacker Media
3 comments and already /.'ed.
I wasn't aware security was a big issue in gaming consoles. Is this just related to hacking into the hardware and getting the OS off of it or what? (I can't get to the PDF because of the /. effect I think)
Everything I say is a lie.
Except that. And that. And that. And that.
not a computer, big deal if there are security holes, you won't be saving your documents, you won't be using it as a gateway, you won't be using it as a firewall, it's to play games......oh no!! you've hacked in and stolen my halo save....
--fetch daddy's blue fright wig, i must be handsome when i release my rage
OUCH!...looks like the server went kaboom...ok, who's gonna be the first with a mirror?
Here is the guys website (bunnie), with a ton of other hacking information not in the whitepaper.
He also has an alternative link to the paper.
the byproduct of years of oppression by the white man
Inconceivable!
I quote from a posting to XBOXHACKER that quotes "I did the work in february, but it took about three months to get it positioned and cleared with both MIT and Microsoft."
I guess that means the DMCA was not violated although the posting mentions that Microsoft intend on addressing these 'holes' in future revisions of XBOX hardware.
[)amien
While the rest of the world waits for the site to come available...
Let's all go to the lobby,
Let's all got to the lobby,
Let's all go to the lobby...
To get ourselves a drink!
you don't have to outrun the bear, just the slowest person in your group.
My favorite game protection of all time was quake 2. First Id software makes this incredible game, with 0 protection against copying, and then release quake 3 with online copy protection and online gameplay only. Thus, suckering in a bunch of people into buying the new version. I wonder if the struggle between companies and consumers will ever end, because the companies always lose :P
- tristan
Hopefully, this is yet one more step in fully hacking the X-Box (can't tell because the site's been /.ed)
And I don't meant the usual Playstation-like hacking. I couldn't care less about not having to pay for games...
What I can't wait for are things like a DiVX player (DivX movies on TV!), Linux -> and with it all those wonderful applications, DVD Movies without the hardware adapter, etc. and all of this for only 200 bucks!
Many Dreamcasts were sold because of their hacking potential...just imagine what an X-Box is capable of! This, more than any reason, is why I'm hoping the X-Box pulls through and "makes it" among the video game platforms...
Why don't you guys host files that you are /.ing, so that we don't have to suffer with endless Connection Refused messages. Or you could at least make it available from your /., after the site has *ahem*.... gone /..
For instance, look at this story! 3 comments and its already inaccessible!!
here is a mirror
I put on my robe and wizard hat.
For those who where unable to see the .PDF, due to the ./ effect... :) probing the LDT/Hyper Transport Bus via an hardware tap board linked to a FPGA based custom sniffer. It seem a bit like a magic... but the only magical thing is the mind operating those (cheap!) hardware! :)
It is about searching for magic numbers
Very intresting read!
Bye!
Should we start taking bets as to when the "xbox update" web site and service packs start coming out?
Karma: Food Fight (Mostly affected by Date Plate).
That's pretty impressive, guys. How big is that PDF anyway? I timed out with 7 replies showing.
It's possible, pig! err... moose
Does this mean I can hack into some little kid's (Insert-Name-Of-Stupid-Video-Game-Char-Here) and upload a patch to display all opposing characters as completely nude, full-figured women?
Or bust my way over to a Middle-East gaming area and put the head of Osama on all the bosses? Wait, do they still have electricity over there?
PDF is /.ed, but wow, never would've guessed Microsoft would've put out an insecure product.... I'm shocked.
Reverse engineering is legal under most circumstances. Prohibiting it would create a new form of intellectual property, which, unlike patents, would not have to be disclosed. Trade secrets are limited in scope; trade secret law is mostly about disclosure by people authorized to know the trade secret.
the "security holes" this paper are about refer to the authors techniques for breaking the protection of the "secret" boat loader that MS employs.
it's just his take on where the security could have been improved. all in all MS looks to have relied on the security through obscurity approach (hiding the true boot loader behind a dummy boot loader), just that their obscurity fails when you monitor traffic over a bus with a simple card.
PS: dreamcasts and playstations have always been hackable, as is the xbox, no real surprise there.
Who cares? Its a GAMING platform, not something your going to store your banking statements on.
The worst that can happen is you'll have to reinstall a few games.
And lets be realistic here, who wants to break into a gaming system?
social sciences can never use experience to verify their statemen
I like this part about MS guy:
The speaker at this talk also indicated that the kernel on the Xbox is a much-stripped-down Win2k derivative (from 12 MB to around 23kB).
(from their website)
What is there to study about the Xbox case? Its butt ugly ;)
We are above the law here. Even if the MPAA, RIAA and Microsoft decided to waste money trying to sue every single one of us, we'd still be able to get by.
People would then start hacking into major infrastructure computers. The whole world would collapse. Microsoft know this. They know its possible to do this because they wrote the software. This is why they will not risk a fight.
http://www.chrisfernando.com/slash/AIM-2002-008.pd f
He frequents the Xbox hacker msesage boards. Heres what else he had to say about Microsoft in this post...
... hmm...patent search turns up nil on the Xbox...guess we'll just have to reverse engineer it. (FTR, Nintendo has patented what looks to be the entirety of the N64 console, thus perchance making reverse engineering an N64 illegal--not yet court tested.)"
"To answer some specific questions:
no, I will not publish the encryption key or the boot block. That's Microsoft copyright material, and I respect their copyright.
Microsoft is not particularly happy about the paper, but they seemed to concede that well, reverse engineering is protected by law, so there's nothing they can do about it. Let's hope they don't change their opinion...they've been known to go back on their word before. "
also, from his website...
"You are actually allowed by law to reverse engineer copyrighted code so long as it is necessary to discover the ideas or functional elements behind the code (still, I'm not allowed to post copyrighted code for free distribution). Hey, microsoft...what are the ideas and functional elements behind your BIOS ROM?
the byproduct of years of oppression by the white man
Microsoft probably has nothing to do with this "hole"(I am hesitent to call it that). NViDIA is almost certainly the one who laid out the spec that used the bus. MS probably just signed off on it.
I'd do something interesting, but my server can't handle a slashdotting.
...that we will be able to play NetHack on the xbox?
This post will enter the public domain 70 years after my death, unless Disney buys another extension.
When I first saw this story. I thought this guy has found some way to get to another Xbox over a network.
After reading the paper, I see all he has found was the secret book block and the non-encrpted bus.
He is yet to decrypt the kernel.
So we are a long way from using he XBox as a cheap PC.
I guess it means he didn't find any security holes that would compromise you system over a network; or any holes would require a service pack from Microsoft.
Page 1 2
.This
/
::: E : 000000C6 ::: F : 01000000 ::: 1 : CC003000 ::: E : A0552C01 ::: 1 : 000000FD ::: E : C7C94000 ::: 1 : 000000C6 ::: E : 9EC49400 ::: 1 : 000000D6 ::: E : C7C94000 ::: 1 : 000000C6 ::: E : C7C94000 ::: 1 : 000000C6 ::: E : C7C94000 ::: E : 000000C6 ::: 1 : C7C94000 ::: E : 000000C6 ::: 1 : C7C94000 ::: E : 000000C6 ::: 1 : 8D42CBCD
::: aligner : unaligned data".
Keeping Secrets in Hardware:
the Microsoft XBox TM 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
@ MIT 1
1 Page 2 3
Abstract
This paper discusses the hardware foundations of the cryptosystem employed
by the Xbox TM video game console from Microsoft. A secret boot block over-lay
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 2
2 Page 3 4
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 re-ceiving
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 tech-niques
in varying degrees, including the Sandia National Labs' "Stronglink" microme-chanical
24-bit lock [2], the Clipper chip [1], IBM's 4758 PCI Cryptographic Copro-cessor
[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 Xbox TM 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 ker-nel
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 de-vices,
all of which contain the same secret information. As the analysis below illus-trates,
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 3
3 Page 4 5
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 algo-rithm
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 re-covering
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 console 1
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 start-ing
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 loca-tion
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
1 An important exception recently discovered is described in section 6.
4 4
4 Page 5 6
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+
8/
2
legacy
8/
24+
133
MHz
200
MHz
DDR 200
MHz
DDR
10
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 5
5 Page 6 7
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 se-quence
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 be-cause
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 de-layering
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 6
6 Page 7 8
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 re-jected
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 sim-plicity.
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-to-center
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 7
7 Page 8 9
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 ap-plied
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 8
8 Page 9 10
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 activ-ity.
It was difficult getting the FPGA to manage the 200 MHz DDR data rates with
9 9
9 Page 10 11
low skew. However, careful hand-layout of the input registers, post-layout timing sim-ulations
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 Hy-perTransport
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 moth-erboard
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 number was 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 10
10 Page 11 12
00000097 : 664A1D55
00000D5C : 05F108F6
00000DE0 : 2A1A2841
00000E5D : B6FE7F68
00000EDA : 5932C662
00000F57 : F9FBA4C1
00000FD4 : F7F9B6AE
00001051 : 73376133
000010CE : FD0127AD
0000114B : 34E8FD29
00001245 : 1814A022
000012C2 : 38EBD672
00022526 : C6C0847E
00022527 : A26216BB
00022528 : 99DA5F80
00022529 : 453862E3
000226D5 : B6DF18C0
000226D6 : DA562768
000226D7 : 0F1D66E3
000226D8 : DDC59B59
Figure 7: An example illustrating the format of trace data captured by the FPGA.
Format of the data is "sequence : 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
output was 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 per-formance
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 11
11 Page 12 13
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 secu-rity
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 SignAssure TM could be used to manage the key so that no human ever has knowl-edge
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 mech-anism
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 at-tack
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 de-crypted
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 cryptosystemmust 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 12
12 Page 13 14
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 manufactur-ing.
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 sim-ple
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 com-plicates
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 at-tack
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 by Microsoft'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 on-line
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 to Microsoft'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 13
13 Page 14 15
6 Addendum
It has recently been called to the author's attention that the hardware initialization pro-cedure
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 com-plex
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 mech-anism.
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) 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, Infras-tructure,
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,
http:// www. ibm. com/ security/ cryptocards/
[4] Gemplus (a smartcard vendor), Gemplus Corporate Website,
http:// www. gemplus. com
14 14
14 Page 15
[5] Pil Joon Lee, Eun Jeong Lee, Yong Duk Kim, How to Implement Cost-Effective
and Secure Public Key Cryptosystems Proceedings of the First International Work-shop
on Cryptographic Hardware and Embedded Systems (CHES), August 1999.
[6] Federal Information Processing Standards Publication, FIPS
PUB 140-2: Security Requirements for Cryptographic Modules,
http:// csrc. nist. gov/ publications/ fips/ fips140-2/ fips1402.pdf
[7] distributed. net, distributed. net: Project RC5, http:// www. distributed. net/ rc5/
[8] HyperTransport Consortium, HyperTransport TM I/ O Link Specification, Version
1.03, 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,
http:// msdn. microsoft. com/ workshop/ security/ authcode/ intro authenticode. asp
[11] Nicholas P. Carter, Stephen W. Keckler, and William 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,
http:// www. ai. mit. edu/ projects/ aries/ Documents/ Memos/ 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: International Workshop on Security Protocols, LNCS, 1997.
[16] Van Hook, et al., High Performance Low Cost Video Game System with Co-processor
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 mes-sage
to visor on www. xboxhacker. net
I didn't get to see the paper, due to /. effect. However, a few ideas how it could be dangerous.
Packet Sniffer
Distributed Denial of Service attacks
Remote hacking
Not so much taking my personal info... but what about attacks...? Norton for Xbox... Zonealarm for Xbox?...etc.... think about it!
HSH
OK, I've skimmed the PDF, and while the words "security holes in the XBox" in the article may lead you to think about traditional software buffer-overflow-I've-r00ted-your-box types of security holes... this article is about HARDWARE!! The PDF talks about hacking the hardware and getting around the encryption on the bootloader to be able to load your OS of choice, for example.
Meanwhile I'm reading posts from people who are nearly soiling themselves afraid to plug their XBox into a network for fear of being r00ted. What a joke. I bet when michael saw the words "XBox" and 'security hole' in the same sentence, he became so excited and nervous that he could hardly move his finger to click the button on the mouse. Sheesh.
I got a grudging thumbs up, so to speak, from Microsoft on my Xbox reverse engineering work
I think I'd much rather he post what must've been a very entertaining conversation with a Microsoft spokesperson than the bios to the XBox.
So no need to worry about DDoS or lost savegames. This is about playing unauthorized games, making a DiVX player etc.
Do those who make it care?
Do those who will empty-minded buy it care?
Do I, running Linux and happy as a clam, care about it, since I'd probably buy a PS2 + Linux Kit?
Well, I care. It's a curiosity. The other day I saw this female elephant giving birth, kinda beautiful...
Another beer, please... Ah, Links pre 6, wow, just downloaded pre3!
Don't these guys know about girls?
(in case you're a geek, check it at www.everything2.com)
What I can't wait for are things like a DiVX player (DivX movies on TV!), Linux -> and with it all those wonderful applications, DVD Movies without the hardware adapter, etc. and all of this for only 200 bucks!
I keep wondering if an Xbox with keyboard, mouse & montior, running Linux, might not make a good, inexpensive classroom computer? I mean, the box is already rad-hardened against hyperactive game-playing children, right?
Is there any chance this would work?
If you say, "now I'll be modded down because of X", I'll happily oblige.
Microsoft, not content with just SOFTWARE security holes, has now moved on to HARDWARE security holes.
I read that article and found it very interesting. It seems there's always a weakness in any security system, and a clever person with time on their hands can find it.
But then it hits me: this "security" is to keep THE OWNER, the PAYING CUSTOMER, out of the product he bought. This "security" doesn't protect my family, me, or my possessions from absolutely anything. It serves no purpose except to make work for somebody at Microsoft and then somebody at MIT. If they left it out, they'd save both parties a lot of effort. I'm sure someone will build on this article and figure out how to easily run arbitrary code on the Xbox, and so the security will be a total waste. So why is it there?
I'm one of the sysadmins at the AI lab - we had a power shutdown in our building last night through much of today, but the site is back up and ready to get slashdotted.
I can't wait to play this game I downloaded years ago called "Pie Gates". It is a classic game that every X-Box owner should have.
Document Body Page Navigation Panel
.This
::: E : 000000C6 ::: F : 01000000 ::: 1 : CC003000 ::: E : A0552C01 ::: 1 : 000000FD ::: E : C7C94000 ::: 1 : 000000C6 ::: E : 9EC49400 ::: 1 : 000000D6 ::: E : C7C94000 ::: 1 : 000000C6 ::: E : C7C94000 ::: 1 : 000000C6 ::: E : C7C94000 ::: E : 000000C6 ::: 1 : C7C94000 ::: E : 000000C6 ::: 1 : C7C94000 ::: E : 000000C6 ::: 1 : 8D42CBCD
::: aligner : unaligned data".
Pages 1--15 from E:\paperailab\paper.dvi
Page 1 2
Keeping Secrets in Hardware:
the Microsoft XBox TM 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
@ MIT 1
1 Page 2 3
Abstract
This paper discusses the hardware foundations of the cryptosystem employed
by the Xbox TM video game console from Microsoft. A secret boot block over-lay
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 2
2 Page 3 4
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 re-ceiving
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 tech-niques
in varying degrees, including the Sandia National Labs' "Stronglink" microme-chanical
24-bit lock [2], the Clipper chip [1], IBM's 4758 PCI Cryptographic Copro-cessor
[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 Xbox TM 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 ker-nel
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 de-vices,
all of which contain the same secret information. As the analysis below illus-trates,
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 3
3 Page 4 5
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 algo-rithm
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 re-covering
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 console 1
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 start-ing
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 loca-tion
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
1 An important exception recently discovered is described in section 6.
4 4
4 Page 5 6
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+
8/
2
legacy
8/
24+
133
MHz
200
MHz
DDR 200
MHz
DDR
10
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 5
5 Page 6 7
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 se-quence
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 be-cause
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 de-layering
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 6
6 Page 7 8
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 re-jected
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 sim-plicity.
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-to-center
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 7
7 Page 8 9
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 ap-plied
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 8
8 Page 9 10
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 activ-ity.
It was difficult getting the FPGA to manage the 200 MHz DDR data rates with
9 9
9 Page 10 11
low skew. However, careful hand-layout of the input registers, post-layout timing sim-ulations
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 Hy-perTransport
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 moth-erboard
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 number was 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 10
10 Page 11 12
00000097 : 664A1D55
00000D5C : 05F108F6
00000DE0 : 2A1A2841
00000E5D : B6FE7F68
00000EDA : 5932C662
00000F57 : F9FBA4C1
00000FD4 : F7F9B6AE
00001051 : 73376133
000010CE : FD0127AD
0000114B : 34E8FD29
00001245 : 1814A022
000012C2 : 38EBD672
00022526 : C6C0847E
00022527 : A26216BB
00022528 : 99DA5F80
00022529 : 453862E3
000226D5 : B6DF18C0
000226D6 : DA562768
000226D7 : 0F1D66E3
000226D8 : DDC59B59
Figure 7: An example illustrating the format of trace data captured by the FPGA.
Format of the data is "sequence : 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
output was 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 per-formance
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 11
11 Page 12 13
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 secu-rity
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 SignAssure TM could be used to manage the key so that no human ever has knowl-edge
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 mech-anism
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 at-tack
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 de-crypted
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 cryptosystemmust 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 12
12 Page 13 14
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 manufactur-ing.
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 sim-ple
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 com-plicates
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 at-tack
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 by Microsoft'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 on-line
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 to Microsoft'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 13
13 Page 14 15
6 Addendum
It has recently been called to the author's attention that the hardware initialization pro-cedure
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 com-plex
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 mech-anism.
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) 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, Infras-tructure,
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,
http:// www. ibm. com/ security/ cryptocards/
[4] Gemplus (a smartcard vendor), Gemplus Corporate Website,
http:// www. gemplus. com
14 14
14 Page 15
[5] Pil Joon Lee, Eun Jeong Lee, Yong Duk Kim, How to Implement Cost-Effective
and Secure Public Key Cryptosystems Proceedings of the First International Work-shop
on Cryptographic Hardware and Embedded Systems (CHES), August 1999.
[6] Federal Information Processing Standards Publication, FIPS
PUB 140-2: Security Requirements for Cryptographic Modules,
http:// csrc. nist. gov/ publications/ fips/ fips140-2/ fips1402.pdf
[7] distributed. net, distributed. net: Project RC5, http:// www. distributed. net/ rc5/
[8] HyperTransport Consortium, HyperTransport TM I/ O Link Specification, Version
1.03, 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,
http:// msdn. microsoft. com/ workshop/ security/ authcode/ intro authenticode. asp
[11] Nicholas P. Carter, Stephen W. Keckler, and William 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,
http:// www. ai. mit. edu/ projects/ aries/ Documents/ Memos/ 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: International Workshop on Security Protocols, LNCS, 1997.
[16] Van Hook, et al., High Performance Low Cost Video Game System with Co-processor
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 mes-sage
to visor on www. xboxhacker. net
15 15
Page Navigation Panel
1 2 3 4 5 6 7 8 9
10 11 12 13 14 15
"Never, never suspect the dreams within the dreams of dreaming children." ~The Amazon Quartet
He now understands the boot process, and can mess with it via hardware mods. But he has only the decryption key, which is the public key of the pair. To make a bootable disc, you need the encrypting (private) key, which is nowhere in the XBox. That key probably exists only in a vault in Redmond.
I don't really care all that much about the XBox, but if the RIAA and MPAA have their way, all audio and video equipment will be protected like this.
I guess I am naive here. What is the point of making the X-box or any other game console hard to hack?
I used to believe the old saw that compared game consoles to razors; lose money on the console, make up for it on the games. But I read something recently which seemed (to me) to prove that everyone except M$ was making money on consoles too. So although it might make sense for M$ to prevent hacking for use as other than a game console, why would others do so?
Is it to prevent people from playing ill-gotten copies of games?
Is it to prevent cheating while playing a game?
Is it to prevent reverse engineering of a game?
I guess I just don't get it!
Infuriate left and right
from section 5:
"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 to Microsoft'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. "
Does anyone here doubt that M$ is rewriting their "Xbox Live" code as a result of this paper. I don't doubt for a second that this guy's discoveries will delay M$ online plans.
"I assumed blithely that there were no elves out there in the darkness"
If you are looking for the FLASH ROM contents of the Xbox, you won't be able to download them even though I've extracted them. I got a call [recording edited to protect sensitive info] from Microsoft within 12 hours of posting this page regarding the binaries...I fear...
There is a 256, maybe 128 byte EEPROM on the Xbox which stores, among other things, your serial number, time zone settings, MAC address, and there is some speculation that hard drive keys and encryption keys are stored there as well.
(say hello to big brother--he can track your Xbox wherever you may be!). You can see the "EST" and "EDT" settings as well. I am thinking it's okay to post this (I hope)...I didn't see any copyright notices...
and we thought XP activation was bad...
From the paper:
"...it is an error to assume that a secret, distributed along with the information it guards, is never revealed."I don't know about that. It seems to have worked for the Word file format.
Not only do you make a pathetic joke about something being bad just because its MS (and their FTP proggy was lifted from BSD, so really its BSD that sucks, turd burglar) but you've also stolen your nick from a Supersuckers song. You are not cool enough to be associated with this band, smegma. I POOP ON YOU!
Why for fuck's sake to people INSIST on using the shitty PDF format? What ever happened to plain text?
[game of questions]
Are you playing hobbit rules, or Ros and Guil rules?
My XBox web server is vulnerable? I guess I'll just have to download a patch from windows update!
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
it's to play games
This opening of the Xbox may eventually a fellow run independently developed game software on the Xbox hardware. ("Independently developed" means that Microsoft doesn't get a cut of the revenue. So much for razors and blades business model.) With a port of the GNU/Linux system to Xbox hardware, such games would potentially include the whole gnome-games suite, the freepuzzlearena suite, Tetanus On Drugs, Tux Racer, Quake III Arena, and every NES and Game Boy Advance game in existence.
Will I retire or break 10K?
I have a mirrior up at http://www.mentalfusion.org/XBOX.pdf
Got Athlon?
Actually, while you're right... everyone (besides MS) does make money off their consoles... they also make a lot of money off something else: licensing. In fact, while you can make a pretty penny off your console, the main draw is that you get an even larger percentage from the license royalties off every game your console sells. You only sell one console per person. You sell lots of games.
Naturally, if everyone could write code for a console and burn their own CDs or DVDs, large game houses would have little reason to buy licensed development kits and publishing contracts with their respective console manufacturer, and thus you lose a lot of your revenue.
Interestingly enough, though, in the old days, unlicensed games happened every so often. I recall that Taito reverse-engineered the NES cartridge and put out their own games...
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
It might not be as much as you think.Microsoft recently told shareholders that the X-Box was just only losing 20% of what Sony was initially losing on the PS2. A friend put that to end up somewhere in the $20-$30 range. ...And the SEC tends to get a bit grumpy with companies that mislead investors...
Hopefully, you are a long way from wanting to do such a thing. For $100 or so, you can have a nice Athlon mobo with a 700MHz processor. Buying a used system would be even cheaper. Of course, any other option would be much less encumbered by silly things M$ likes to put on junk, like the serial number he found.
The point is that stupid M$ and others are working to make hardware that the user has no control over but fail. It's just another proof that Senator Holling's wet dream of control of all digital devices can only be implimented by foolish laws. Inailienable rights are those which require vast expendatures to violate.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
You have it backwards.
No, you have it all wrong. The Xbox encrypts the flash with RSA's RC4 symmetric cipher (i.e. not a public key cipher). The remainder of this post is (strictly) off-topic because the Xbox boot process does not use public-key encryption.
The private key decrypts.. the public key encrypts.
In a public-key secrecy scheme, you're correct. But in a public-key authentication scheme, the private key encrypts the hash into a signature, and the public key decrypts the signature for comparison with the hash.
He has the private key. And you can derive the public key from the private key.
No, you can't do that in (for example) RSA.
Will I retire or break 10K?
As was mentioned in several posts, this is bad (for MS) because it may allow two things - non-authorized software development and pirated software. (don't mark me as redundant yet, keep reading :)
That's why Nintendo stuck with cartridges and why they now have a non-standard format for Gamecube games. I am really surprised other console developers haven't done this.... the slight increase in costs to slow piracy is a good trade-off.
Anyone know if it would be possible to burn those mini-dvd's that Nintendo uses?
Robots are everywhere, and they eat old people's medicine for fuel.
Interestingly enough, though, in the old days, unlicensed games happened every so often. I recall that Taito reverse-engineered the NES cartridge and put out their own games...
That wasn't Taito (a licensed publisher of Arkanoid and Bubble Bobble); it was Atari, under the Tengen brand. (By the way: Tengen's NES port of Klax had some of the best music on the NES. They were able to squeeze bass out of that system that not even Nintendo probably knew was there.)
Most of the independently published games published by companies other than Tengen sucked. Color Dreams/Wisdom Tree games really weren't all that playable, except for Crystal Mines (aka Exodus) and the "King of Kings" 3-in-1. Hacker/Panesian had only one hit, Bubble Bath Babes (aka Soap Panic), and it was a puzzle game somewhat similar to Kirby's Avalanche.
However, in the modern era (post-NESticle), a new NES scene has sprung up. (Read More...)
Will I retire or break 10K?
So a LinuX-Box is a little closer to reality now, but with even with that possibility, I still won't buy an X-Box. Microsoft doesn't deserver an another cent of my money.
You've beaten my Windows, which means you're exceptionally strong, so you could have put the poison in your own goblet, trusting in your strength to save you, so I can clearly not choose the wine in front of you. But, you've also bested my X-Box, which means you must have studied, and, in studying, you must have learned that man is mortal, so you would have put the poison as far from yourself as possible, so I can clearly not choose the wine in front of me!
Anybody notice the author's name: Andrew "Bunnie" Huang. Wonder if he's the notorious defacer Fluffi Bunni.
Keeping Secrets in Hardware: /2 +0 0 ::: E : 000000C6 ::: F : 01000000 ::: 1 : CC003000 ::: E : A0552C01 ::: 1 : 000000FD ::: E : C7C94000 ::: 1 : 000000C6 ::: E : 9EC49400 ::: 1 : 000000D6 ::: E : C7C94000 ::: 1 : 000000C6 ::: E : C7C94000 ::: 1 : 000000C6 ::: E : C7C94000 ::: E : 000000C6 ::: 1 : C7C94000 ::: E : 000000C6 ::: 1 : C7C94000 ::: E : 000000C6 ::: 1 : 8D42CBCD ::: aligner : unaligned data".n e, also appears in Sensor Expo 1999.a rds/f ips140-2/f ips1402.pdfr ity/authco de/intro authenticode.asps /Mem os/ARIES-05.pdf
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
@ MIT
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/
3
128/
21+
8/
2
legacy
8/
24+
133
MHz
2
MHz
DDR 200
MHz
DDR
10
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
00000D5C : 05F108F6
00000DE0 : 2A1A2841
00000E5D : B6FE7F68
00000EDA : 5932C662
00000F57 : F9FBA4C1
00000FD4 : F7F9B6AE
00001051 : 73376133
000010CE : FD0127AD
0000114B : 34E8FD29
00001245 : 1814A022
000012C2 : 38EBD672
00022526 : C6C0847E
00022527 : A26216BB
00022528 : 99DA5F80
00022529 : 453862E3
000226D5 : B6DF18C0
000226D6 : DA562768
000226D7 : 0F1D66E3
000226D8 : DDC59B59
Figure 7: An example illustrating the format of trace data captured by the FPGA.
Format of the data is "sequence : 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) 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/Micromachi
[3] IBM, IBM 4758 PCI Cryptographic Coprocessor,
http://www.ibm.com/security/cryptoc
[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,
http://csrc.nist.gov/publications/fips/
[7] distributed.net, distributed.net: Project RC5, http://www.distributed.net/rc5/
[8] HyperTransport Consortium, HyperTransportTMI/O Link Specification, Version
1.03, 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,
http://msdn.microsoft.com/workshop/secu
[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,
http://www.ai.mit.edu/projects/aries/Document
[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
15
No. The XBox is a PC designed to work like a console.
Basically it's a PC with these specs:
733MHz Celeron
64MB PC100 RAM
GeForce 2.5...halfway between GeForce 2MX and 3.
8GB HD.
cheap 10/100 base T NIC
non-standard USB (based on 1.1 spec) connections for controllers.
However, for all the efforts to try to hax0r the XBox...and I wish them all well...they are going to have to find a way to make a keyboard work with it. With the tweaked non-standard USB it's not gonna be easy.
Knowledge is power. Knowledge shared is power multiplied.
how long have you been reading /.?
Because the "jam buffers" are initialized by the flash eprom *in the clear*, it is possible to initialize them to a faulty state, which causes the boot sequence to abort, and you can then run anything you can put into the eprom.
Karma: Food Fight (Mostly affected by Date Plate).
Well, it's black, and has a big "X" on it.
Have you read my journal today?
He does far more than reverse-engineer the XBox. Read this guy's project list. He's cranked out an incredible list of hardware projects. His own RISC CPU. A DES cracker. A controller for a midget submarine. An all-new design PBX for his frat house. Keyboard pedals for EMACS. A Linux-based computer that fits in a Star-Tac phone case (in progress.) Plus he's in a fraternity, plays guitar and violin, and has a blonde girlfriend. And all this while doing a thesis at MIT.
Ms cannot stand to lose money by not making back what they lose on the consoles, anyone who makes independant games will most likely be sued into oblivion... Although I'm sure most people on slashdot want to sabatoge MS anyway.
Sure - but one could easily argue that its main purpose is to keep pirates from running unauthorized (copied) programs on it
and to keep developers from building their own executables without real dev kits (and depriving ms of royalties)
and it keeps game hack systems out - like the gameshark and the codebreaker like devices from running.
And before you bitch and moan about MS being a bunch of bastards - almost every game system that ever came along has had some system to keep developers, hackers, and users from explointing the technology inside. Even Atari was that way - mostly through Atari not releasing all the specs for programming it so their games could look better in comparision - and they sued the first company who dared defy them (I think it was sierra).
spelling error.. go Microsloth!
s /s erialnumber.jpg
http://web.mit.edu/bunnie/www/proj/anatak/image
The point of "security" on a console is to be an anticompetitive measure to control the software market for the device. The people who make video game home systems are bare knuckle capitalists. They want to extract the maximum profit from the system--by taking a toll from every piece of software sold, by limiting the number of titles and copies that ship to customers, by using product supply as a cudgel in negotiations with retailers, by controlling the mass media coverage of their systems.
Slashdot is all about being angry at MS; appropriate, since MS is the monopolist controller of the PC world. But we should be mindful of the fact that MS's business practices are nowhere near as bad as those of computer monopoly pioneers like IBM and Univac. At one time everything was bundled: software, hardware, support. Your one vendor had you by the balls and was in a position to extract every possible dollar from you, just short of driving you away. That's what the video game market is like. When someone has a monster platform like Sony Playstation, they can just milk it and milk it, since there really is no competition for those PS software dollars.
As it is your opinion to hate something because you simply don't enjoy it, I find it very retarded to hate the xbox because it's made by the same company that (apparently) killed your parents with it's OS, judging by the negitive comments about it. It's a game console, and a damn good one at that. I judge consoles by what they are supposed to be judged on, thier games and funfactor. All you idiots scoffing at it for these asinine reasons (and obviously haven't played on one for fear of supporting the live ruining windows OS, really REALLY need to get a life.
Besides, if linux is so superior, why hasn't it taken over the world yet? Windows got to where it is because it made it easy for people who spend more time with actual humans to interact with computers. When my mom boots linux, that's when linux will be superior in the big picture.
And in the when you learn about the xbox, its booting proces, its copy/developer-licence protection system(dmca protected monopoly enformcement!), the fake booting code and the filesystems/formats used on the game media. You could now rip a model of a game character, load it up in your favourite 3d editor and replace the clothed skins with..... nudity!, place it on blank media, hack you x-box to run unlicenced code (you run the linux kernel for testing this ofcourse) and watch the nvidia gpu take care of rendering those bumb maps and curved surfaces on an ugly old tv....
;-)
/. that while microsoft might have problems learning from the recent digital history we should not make the same mistakes twice
Oh, and while you used to dream of... well.. nude game characters, you now dream about that perfectly laid out pcb that allows you to capture a 200 MHZ 128 bit fsb.
Does anyone else think its really ironic that microsoft got rich becouse the rom bios of the ibm pc was reverse enginered, which lead to hundreds of cheap clones running microsoft dos, the cheap cpm clone bill licenced, microsoft did basic and edlin (We should really thank them for the inovation they bring). This same microsoft might now be ruined becouse the very same booting code of the very same (ugly and old) computer architecture (die x86 die!) gets cracked (no mather how paranoid they where about protecting it, I mean putting a flash rom with a fake code in every unit?) These will now be put into cheap linux/bsd/apacke webserver duty, they sponsor the platform that might ruin them the same way the ibm pc fiasco effected ibm
I guess at this moment I should remind all coders on
http://www.xbox-scene.com/xbox1data/news-archive-1 7-3-2002.php
Interact is putting this out. News bite is buried almost at the bottom of the page.
Knowledge is power. Knowledge shared is power multiplied.
Why reverse engineer a game machine....
To create a cheap cluster computer... Beowulf or other. It would make an awesome rendering farm. At $200 each you get 10 for $2000. Connect the 100 baseT ethernet to a switch and you get a cluster with: 10 5chan Dolbly Sound chips, 10 NVidia graphics chips, 10 P3-733's and a combined 1 G of RAM (The RAM could be bigger). Anybody want to do cheap animation?
Today morning i read a very interesting article about the way M$ supposedly mucked it up with their X-Box calculations (http://red-mercury.com/mmceo/mmceo_current.html), and an even more interesting reply in a german netmagazine (www.heise.de/tp), that (only half joking) proposed that M$ would never be able to produce a low-cost computer themselves (so's not to piss off Hardware companies), but they could sell a very cheap plaything that - after being cracked by Dr. Evil - could operate on, say, WinXP. Of course, I would never want to imply that a responsible company would ever resort to that kind of scheme, so this is only wild speculation for the fun of it.
Far beyond reality.
Nowhere near the truth.
Stopp ripping consumers off. The main reason why people pirate games is that simply (like ink cartridges), they are a rip off. You sell a product to a crowd with little money (teenagers) and expect them to cough up $50 for every game - come on, that's horse crap. The profit margins for game developers are ludicriuos. Doesn't matter on the platform - people are tired of paying $50 for a game, when half the time they only get a few hours of enjoyment out of it. Heem, lety's see - Store cost at CompUSA for Halo is $45, MSRP is $50. Who's making the cash? Manufacturing costs (I'm not counting development costs) are less than $1 for most games. I've only purchased a FEW games that have been worth the money (like FFX or Metal Gear Solid 2) - most are not. If you want to sell allot of games and keep profits up, LOWER YOUR MSRP on games! $29 is a fair price for a great game and $20 is good for an average game. Until game prices go down, I will continue to copy PS2 games and use them with my PS2 mod chip. Crash Bandicoot for PS2 sucks majorally with 5 minute load times, and they expect $50 for this game? Give me a break....
...cripes...