Xbox-hack.pdf
(
515 KB
)
Pobierz
@ MIT
massachusetts institute of technolog y — artificial intelligence laborator y
Keeping Secrets in Hardware:
the Microsoft XBox
TM
Case
Study
Andrew “bunnie” Huang
AI Memo 2002-008
May 26, 2002
©
2002
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
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
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
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
. 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 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
secure hardware boundary
pentium
CPU
bus width:
data/others
bus clock
rate
133
MHz
GTL+
64/
32+
200
MHz
DDR
100Base-T
USB
game
controllers
controllers
dongles w/
executeables
(DVD player,
etc.)
HyperT
security relationship
not yet known
NV2A
northbridge
+ gfx
8/
2
128/
21+
SSTL-2
200
MHz
DDR
SDRAM
64 MB
trusted code
and data:
digitally signed
with Microsoft
private key
MCPX
southbridge
secret boot
ROM
IDE
key-locked
hard disk
(executeables,
cached data,
save games)
legacy
< 10
MHz
8/
24+
FLASH
ROM
(bootloader
+ OS kernel)
DVD drive
(game data /
executeables)
Figure 1: Overview of the Microsoft Xbox hardware.
5
Plik z chomika:
WMatrixie
Inne pliki z tego folderu:
O'Reilly - Google Hacks.pdf
(63260 KB)
Game Hacking Developing Autonomous Bots for Online Games.epub
(20247 KB)
Absolute OpenBSD.pdf
(11252 KB)
Android Security Internals.pdf
(7630 KB)
Mastering Android Game Development.rar
(22986 KB)
Inne foldery tego chomika:
Cracking_For_The_Beginner
Forbidden Knowledge
Guide_on_Cracking
Kali tuts
No.Starch.Metasploit.Jul.2011
Zgłoś jeśli
naruszono regulamin