Tip:
Highlight text to annotate it
X
MALE SPEAKER: It is my pleasure to
introduce Michael Steil.
I've known him for a while.
I've known him since he and I were both independently
working on getting the Intel Macintosh hardware when
nothing else ran on Intel Macintosh hardware.
And he beat us to the punch.
He was the first one to do it.
And he's an interesting guy.
He's a current engineer for a Fortune 500 company.
And he does all kinds of hacking, and a lot of it is
incredible.
So he's going to talk about one of those things today, and
I hope you enjoy it.
MICHAEL STEIL: Thank you.
[APPLAUSE]
MICHAEL STEIL: Yeah, I'm Michael Steil.
I founded and I'm maintaining the Xbox Linux project, and in
this function I participated in lots of the hacking that
was going on, not in all of it, because we
started a bit late.
But I know quite a bit of what has been done on that.
As you know, at 24 slides a second, that will be a
flicker-free picture, so I will have many, many slides.
And I'm going to talk really fast, because I have lots of
information, because personally, there's nothing
more I hate than talks that don't have enough information.
Let's start.
Whoa.
[LAUGHTER]
MICHAEL STEIL: OK, just kidding.
[LAUGHTER]
MICHAEL STEIL: Anyway, let's start with a quotation of
Bruce Schneier.
He read a paper I wrote about the Xbox security system, and
his comment on it was, "lots of kindergarten security
mistakes." So the question is, is the Xbox
security really that bad?
Is it that's uninteresting?
Is it that badly done or--
well, I can tell you it is interesting, but does it
really include so many mistakes, so
many obvious mistakes?
Therefore, we are going to look at it from Microsoft's
point of view.
We will be constructing the security system now, and then
you can ask yourself whether these mistakes that have been
made by Microsoft--
have they been obvious; would you have noticed.
If they are obvious, then Schneier is right, and--
yeah, "lots of kindergarten security mistakes." And if
they are not obvious, then maybe it's not that's trivial
to construct a security system.
So let's start.
[LAUGHTER]
MICHAEL STEIL: Now, we are Microsoft.
We wants to create a gaming console, a video game console.
How do we do that?
Now, we mentioned it's 1999, and within two years of time,
we have to release a gaming console.
So what do we do if we want it cheap and we want it fast?
We take PC hardware; we take Windows 2000 software; we all
have this already.
We take the DirectX libraries, and put it in a small
enclosure, so that it looks nicer.
And this is fast; this is cheap.
The problem is that marketing has to make sure that the
press doesn't see it as a small PC, but sees it as a
real gaming console, because people associate all bad
things with PCs like long startup times or instability.
So what came out of this was some Celeron processor, well,
not too much RAM, GeForce, it even has a hard disk, DVD
drive, fast ethernet, USB, speed and as an operating
system, it's based on the Windows 2000 kernel.
So it really is a PC, or in other words today, you could
say the Xbox is also a Mac, because a Mac is a PC.
But what actually makes a PC?
Is it if you have an Intel CPU, and have an x86
compatible CPU, is it already a PC?
If you have VGA-style hardware?
Not necessarily.
What about all these technologies?
Do they define what is a PC?
Certainly not, because Sun hardware, SGI hardware, also
has all these technologies.
But the point is the Xbox also has the old 1982 Interrupt
Controller, the old 1982 timer, and even
IBM's A20 gate hack.
All these legacy components can be found in the Xbox.
So if it is a PC, shouldn't it be trivial to run anything on
it, like Linux?
We want to prevent that.
We, as in we are Microsoft, because with a security system
we don't want people to run Linux on it, because the
Xboxes are sold at loss, and money is made with the games.
So people shouldn't buy them and run Linux on it and use
them in a cluster of something.
Homebrew software is a bad thing, trademark-wise, copied
games are a very bad thing, and also unlicensed games,
because money is made with the games, and Microsoft gets a
fair share of these.
So we can address all these four threats against our
strategy with the Xbox with a single security system.
The idea of the security system is obviously to run
only authentic code on this.
So we have to choose which code runs on it, and every
code that is not authorized by us may not run on the Xbox.
So execution may only be passed from one part of
trusted code to the next part of trusted code.
This is called the Chain of Trust, which reminds us of
what the industry has been after for quite awhile, and
which is still interesting right now,
which is trusted computing.
So the Xbox, in a way, implements these trusted
computing principles and takes away control from the user and
leaves all control to, actually, Microsoft, because
only they have the keys to authorize
software to run on it.
So how does this Chain of Trust work?
At system startup we must make sure that the Windows kernel,
which is stored in ROM for faster boot
up times, is authentic.
It must be checked whether this is the authentic kernel.
And then the Windows kernel, in turn, must make sure that
the game is authentic and there is another check.
Game can be from hard disk or from DVD.
How can we implement this first one from startup?
Right on startup, only authentic code may run.
Let us look at the Xbox hardware.
Now I happen to have one here.
If you want to have a closer look at it,
I'll pass it around.
This one is a bit broken; all the chips are missing.
I turned it in for warranty, but they wouldn't accept it.
[LAUGHTER]
MICHAEL STEIL: Anyway, for those who can see it right
now, you have it on the slide that--
this is a standard PC.
You have a CPU there, which is the
Intel Celeron 733 megahertz.
You have an Nvidia Northbridge with integrated GPU.
That's exactly what they sold as the nForce
1 chipset as well.
They have a Southbridge there.
There's RAM, 64 megs of it, and there is Flash, because
computers tend to boot off some ROM, which
is typically Flash.
This is how x86 six systems start.
At the bottom of memory, there is RAM, and at the top there
is Flash memory, and an X86 starts from this address.
This is the uppermost address of RAM minus 16 bytes.
And this must reside in Flash or somewhere to make the
machine go.
Typically, this looks a little like this, sets up the CPU and
jumps to some other location to the beginning
of Flash, for example.
But a hacker could easily just modify the Flash or put their
own code there, and then just do anything with the system
what they want-- for example, run a hacked version of the
original Windows kernel that will allow
copied games, for example.
So how would a hacker do this?
Let's look at the main board again.
One thing is they could just replace the Flash chip.
It's a chip that people could just put a socket in and have
their own Flash chip there.
They could also overwrite the Flash chip, because this is an
interesting thing--
it is better to put empty Flash chips onto the board
than boot them once in the factory from an external Flash
chip and Flash the internal chip.
That's a lot cheaper than having them pre-programmed and
put them in.
Therefore, we must have some overwrite functionality, so
that it can boot off another bus.
So we need this bus for manufacturing purposes, and of
course, we must make sure later that nobody else could
use this functionally.
The third possibility is, of course, to overwrite, to
reprogram the Flash chip, because it is writeable.
So Flash might not be such a good idea.
We just cannot start directly from Flash.
What possibilities do we have?
Possibility 1 is we don't start from Flash; we put a ROM
chip in there.
ROM is expensive, but it buys us that it cannot be
reprogrammed, but he can still be replaced.
That overwrite functionality is also not necessary, because
it is pre-programmed, we don't need that functionality; but
it can still be replaced.
So not a good idea either.
Another possibility is to put the ROM chip inside some other
chip or Flash.
Well, let's say it's ROM.
Put it in some other chip, and then this is very effective,
because nobody can replace it anymore unless they want to
replace the whole CPU.
But there's no point in that in a cheap gaming console;
that will be more expensive than the whole gaming console.
But also it will be expensive for us in manufacturing,
because we cannot use off-the-shelf Intel Celeron
processors, but we need custom processors,
also not a good idea.
But there is a compromise between these two ideas, which
is put a small ROM chip somewhere.
We'll talk later where, maybe not into a CPU, but in a
cheaper chip.
This small ROM chip is quite cheap to put in something if
it's just like a K or so of memory, and this ROM chip will
then verify the contents of Flash and pass execution to
Flash if everything is OK.
This is both effective and cheap.
Now this is what this looks like.
We have some secret ROM integrated into some
component, which is half a K of memory.
At the very top of the address space it overlays the Flash
region, so when the CPU starts, it will start in our
secret ROM and not in Flash.
It can then verify the integrity of Flash, and if
it's OK, pass execution to there.
Now, the question is where to put it.
The CPU is expensive, because the CPU is the most expensive
part in the system, and custom ones--
that's not a good idea.
Southbridge would be great.
The Southbridge is the cheapest chip, but it's still
fast. Data will travel over a bus, because the CPU has to
read the instructions from the ROM in the Southbridge, but
this bus is really, really fast; it's HyperTransport.
And we're talking about 2001; nobody is able to sniff data
this fast, well, almost nobody.
We just put other ideas in there, so that even if it gets
sniffed, nobody can do anything with it.
Just let's be on the safe side.
OK, but the problem with Flash verification is checking and
having a signature, an RSA signature with public key
cryptography just doesn't work in 512 bytes.
You cannot fit RSA into there.
Just checking a hash, that would fit in there, but if we
just had a hash, then the kernel could never change.
So as long as we manufacture the same Southbridges with the
same secret ROM, we would never be able to update the
kernel in later revisions of the Xbox.
So what we do is we introduce yet another link in the Chain
of Trust. We have a second stage boot loader of the 2bl,
which gets hashed by the secret ROM.
The secret ROM only needs a hash, so
the 2bl cannot change.
But the 2bl does nothing more than verify the kernel with an
RSA signature.
OK, so what does the secret ROM have to do?
It has to verify the 2bl for integrity, and it has to pass
control to the 2bl, if it's OK.
What also would be a good idea--
to decrypt 2bl.
So if 2bl is encrypted and also the kernel is encrypted,
then any attacker would see nothing but cyphertext in the
Flash, so they have no place to start hacking.
But for decrypting, we have to initialize RAM, because the
decrypted contents have to be stored somewhere, and we
really have to initialize RAM.
It doesn't work when we start, because Microsoft chose to
ship even bad RAM chips, which couldn't do the spec and which
just couldn't do the 200 megahertz, so they get clocked
down to up to--
down to, I think 180 megahertz.
So some games don't run that well on every Xbox, but these
chips are cheap, so we have to do a stress test and see how
fast RAM goes.
But then again it won't fit into 512 bytes if we have to
do this RAM initialization.
What we can do is put all non-security critical code
outside of the secret ROM and put it in Flash.
But of course, this cannot be x86 code, because if we call
some x86 code in Flash, and a hacker could just go overwrite
that with their own code and never return then.
Therefore, if we cannot put x86 code there, that's one of
Microsoft's greatest ideas was use a virtual machine.
And I actually think that is a really good idea.
On the right, you can see how this interpreter looks.
It's not all of it.
It has instructions like memory accesses, hardware
accesses and some control flow instructions.
So you cannot exit this virtual machine, so an
attacker could initialize the hardware differently, but
that's all a hacker could do it if we do our job right.
The byte code is called the Xcodes.
I'll refer to them as the Xcodes in the future.
So memory initialization could look like this in Xcodes.
We set the memory speed to 200 megahertz, then write
something to memory, read it back from memory.
If it's OK, then go to end.
Otherwise, try 5 megahertz less and so on.
That's what that can do.
Now, if a hacker has access to the virtual machine or
understands the virtual machine, but maybe doesn't
have the whole secret code and the decryption and the keys
yet, an attacker might still already benefit from that.
Therefore, we must make sure that an attacker cannot
exploit the virtual machine somehow if they write Xcodes--
because they're not verified for integrity, there's just no
space in these 512 bytes to verify them as well.
And of course, they have to be flexible for future versions
of the Xbox.
So when people hack the Xbox interpreter, there are several
possible attacks that we have to think about and that we
have to prevent actively when writing the virtual machine.
That's one of the attacks.
The secret ROM is at the very top of memory,
so that's this address.
We could just use the Xcodes to read the secret ROM, all of
the secret ROM, including the keys and send them to some
low-speed bus, like the LPC bus or even the I2C bus, which
is on the Xbox.
We must prevent that, and that is easy by just masking the
high addresses, and this is the assembly
code that does that.
It's just clears the upper 4 bits, if we do a memory read,
which is OK, for hardware initialization, we don't have
to read from there.
A second attack would be to turn off the secret ROM.
There is a functionality in the Xbox to turn off the
secret ROM, because as soon as the Windows kernel is running,
the secret ROM must be turned off, because if there is some
vulnerability in the game, then the code, the exploit
code, the shell code that would run could read all of
the secret ROM, and there go our keys.
But the Xcodes may not turn off the secret ROM, otherwise
secret ROM would just disappear and execution would
fall down into Flash.
So we have to check for this code as well.
We compare just this simple poke command, and we just do
nothing in this case.
OK, that was the virtual machine.
Now let's talk about the encryption.
We don't have that much space.
We just have half a K of instructions.
So there is a possibility to combine hashing and
decryption.
Let's look at stream cyphers.
We have a secret key.
This secret key gets expanded to a seed.
This seed will generate a sequence of pseudo-random
random numbers, and these get XOR'd with a stream of
cyphertext, so that we have the
resulting plain text again.
Now one great thing you can do about this is you can feed
back the decrypted data into the seed.
So in case one of these bytes, one of the cypher text bytes
changes, also the resulting plain text changes, the
feedback makes the seed change and all the future
psuedo-random numbers will also change, so the decrypted
text will change as well.
So all we have to do to get a hash is look at the last few
bytes as soon as something has changed in there, the last few
bytes will also have changed, so we can decrypt and hash in
one, by just having that feedback functionality.
OK, so with just perhaps 100 bytes of code we can do these
two things.
There's one more thing that we really have to do, which is
the panic code.
What happens if the Flash check fails?
We have to panic.
We cannot just turn off the Xbox, which would be the
safest thing.
We have to keep it turned on and blink some LEDs to tell
the user that something is wrong.
The CPU has to be off, but also the secret
ROM has to be off.
Otherwise, if the CPU is off, but the power is on, someone
could attach them sniffer device and pretend they are a
CPU and read the secret ROM.
So we have to disable the secret ROM and halt the CPU,
but that is a big problem.
That's the same problem as crashing a car while
the motor is off.
[LAUGHTER]
MICHAEL STEIL: Because if you turn off the CPU and then turn
off the secret ROM--
who would do that?
If you first turn off the secret ROM, and then the CPU,
where would that code come from?
So there is a possibility, and that was a really, really
great idea of Microsoft.
I really love this idea.
We drive against the top of memory.
This is the very top of memory.
These are the last few instructions
off the secret ROM.
They prepare turning off the secret ROM, and the last
instruction, this "out" instruction
actually does the turnoff.
And also this instruction, it will drive against the upper
limit of memory, and this will lead to an
exception, a double fault.
and the CPU will be halted.
[LAUGHTER]
MICHAEL STEIL: I find that a really, really great hack.
Now this is the summary of how the whole security system in
this first step of verification works.
The interpreter interprets the initialization Xcodes, which
are in Flash; then the 2bl gets decrypted and hashed;
gets jumped to; and 2bl then decrypts and checks the kernel
and jumps there.
This is what the code looks like.
You're not supposed to be able to read that, but you should
have an impression how much code it is, and it's not all
that much code.
It would fit on one piece of paper, and it shouldn't be too
hard to eliminate all bugs of that.
So the Xcode interpreter is pretty large.
We have some CPU set-up code.
This is the decryption code, and of course, at the end of
this there's the panic code and some more panic support
code in the middle.
OK, this is what Microsoft thought; now we're hackers.
[LAUGHTER]
MICHAEL STEIL: Speaking of hackers, I don't know whether
you're familiar with that whole hacker culture, maybe
that's not what's hacker culture really is, but many
people think--
let me show you a few pictures of typical hackers.
[LAUGHTER]
MICHAEL STEIL: That was us meeting in Berlin.
As you can see, most of them have degrees in computer
science or-- so it's they're pretty fine people.
Three more people that I don't have a picture of-- especially
Visor, I have no idea who he is, but he did great
contributions.
OK, so let's start with "bunnie." Bunnie is the great
Xbox hacker, because he started it all.
He did the first extracting of the secret code.
So first he looked at the Xbox he saw there was Flash ROM, so
he dumped the Flash ROM.
He put it on his website.
He got a call from Microsoft.
[LAUGHTER]
MICHAEL STEIL: He pulled it down again.
[LAUGHTER]
MICHAEL STEIL: Act 2.
He did an analysis on the Flash that he had.
Of course, he knew that the Xbox or any x86 CPU would
start at the top of memory-- minus 16 bytes--
he looked there.
And what was there?
There should be nothing, because the-- after 512 bytes
of Flash are unused, because secret ROM that he cannot see
will be mapped there.
But what he saw was this.
[LAUGHTER]
MICHAEL STEIL: Someone made a mistake there.
Well it wasn't that bad, because it's turned out that
this is not the actual code; this was an old version of the
code, but somehow they linked it there.
Bunnie found out that this was not the real code; he put his
own code there, and the Xbox just behaved the same.
So it was an old version of the secret ROM.
It had different decryption.
it had different keys.
The XOR interpreter was slightly different, and it
cannot be used to decrypt anything.
So he moved along and tried to find where that secret code
was, because it was sure that there must be
some secret code somewhere.
And he built this small device himself and sniffed
HyperTransport.
Bunnie can do that.
Yeah, and he had the secret ROM.
So he had the actual virtual machine, the actual RC4
decryption, the panic code; he had all of that.
But how does this help us?
Because the second stage boot loader is hash, so we cannot
just change the second stage boot loader.
What can we do?
So let's look again how this decryption and hashing works?
Maybe there is some attack there?
This is how it's supposed to work with the RC5 cypher.
Now the problem is Microsoft used the RC4 cypher without
the feedback.
So without the feedback, if you change one byte of
cyphertext, the resulting plain text byte will change,
yes, but there's no feedback.
So the key stream will not change from thereon, and the
last few bytes will just remain the same.
RC4 cannot be used as a hash, but they try to.
They check for the last few bytes,
whether they are authentic.
The reason why they did it was, as I think, they used RC4
in the beginning.
RC4 behaves like this--
RC5, RC5 does behave like this, and the old version of
the secret ROM that we had from Flash worked like this
and did it correctly, but they updated it to RC4 for some
reason, and yeah, they broke it.
So there was no hash.
We had the RC4 key; it is in the secret ROM.
We had no hash, so we can just encrypt our own stuff, put it
in there, let it decrypt.
The 2bl check will not fail.
It will just succeed, and our code will run.
So great, people did that.
That was before the Xbox Linux project actually started, and
made Modchips, Modchips with just replacement ROM chips,
which had different software on them, hack software that
could run copies of games.
The first generation of Modchips disabled the onboard
ROM by shortening something and added just a ROM parallel
to the onboard Flash chip.
Then people found out that when disabling the onboard
ROM, the Xbox would default to booting off an external ROM on
the LPC bus.
So everything they did was pretending that the onboard
ROM is empty by grounding a single data line, and it will
boot off these 9 wires, and you can easily attach a
Modchip there.
So after half a year, when the Xbox came on the markets,
there were already Modchips with 9 wires, which were
really, really easy to fit.
But for Linux that wasn't that great.
For Linux we had to find something else, because we
just cannot ship the RC4 key with our build tools.
We would have to re-encrypt our boot loader, and that's
just not a good idea to ship that key with our tools.
So we had to find a better way.
And if we look at the secret ROM again, perhaps there are
some other attacks possible.
Let's look at the panic code again.
I told you, I love this, but the question is
does it really work?
Does it really double fault at that location?
That's also what Visor wondered.
Well the earth is a sphere.
Yeah, memory is also a sphere.
[LAUGHTER]
MICHAEL STEIL: So what happens if you go over the upper
boundary of memory, you might start at the beginning of
memory again.
It's just the 30 second address line that is
unconnected.
So what if memory really starts at zero again there?
Visor, that hacker that I know nothing about, thought that it
might roll over to zero, so he wanted to put code at zero and
let that check fail to make the system panic.
How do we put code at zero?
That's RAM, we cannot put code there.
We can put code in Flash; we cannot put code in RAM.
Yes, we can.
The Xcodes can write into memory, and the
Xcodes are not verified.
We can just add two extra Xcodes, which write this jump
instruction at zero.
So, it would look like this.
We have these two extra instructions, which definitely
reside in memory.
So does it work?
Yes, it works.
It does not crash; it just executes that.
That's a big, big backdoor.
But why?
Why did this happen?
And that's the greatest story, a short history lesson on why
this happened.
Let's look at old, ancient processors.
Let's look at x86 started processors.
They start from the top of memory, as I've said.
And there are other processes, which start from
the bottom of memory.
ROM must be at zero.
But the x86, the original x86 had a great feature so that it
could boot both off the top or off the bottom, depending on
how you wanted to configure your system.
Because if you had a memory setup like this on an x86
system, then the unconnected region there would read back
"FFFF," which is NOP.
So it would roll around to zero and execute your ROM
residing at zero.
And this is something that still a Pentium III does, and
the Pentium III Celeron.
But why did Microsoft not know about this?
There are data sheets that say that.
The point is Xbox prototypes had AMD CPUs.
[LAUGHTER]
MICHAEL STEIL: And they switched to Intel the very
last minute, and AMD CPUs don't have this behavior, and
they did not check again.
So AMD CPUs do halt on this transition.
Well, there might be another hack.
It's just 512 bytes of code, but there are several
vulnerabilities in there.
We looked at this instruction, which is supposed to turn off
the secret ROM, so code would fall down into Flash.
The interpreter would be shut off, and execution
would go on in Flash.
This is the code, again.
It compares this single value.
But if we look at the data sheet again, we see that there
are several reserve Bits, and these Bits don't do anything.
So we can just poke any value up there.
These 8 bits, we can use anything, and they do not get
caught by this compare.
So yeah, we can do that.
In order to exploit this, we have to prepare a landing zone
underneath the secret ROM, with lots of NOPs and a jump
at the end.
And this--
whoa, is it me?
MALE SPEAKER: Yeah.
MICHAEL STEIL: Yeah, OK.
So if this code gets executed and hits that single
instruction that turns off the secret ROM, and the secret ROM
goes away, execution falls down, lands in the NOPs, and
executes our own code.
And that's not the only attack.
This is another way to put it.
They didn't catch it.
OK, now Microsoft has to react.
These hacks have been published.
Microsoft saw RC4 is now hash, so they finally understood it.
So they reacted.
Now the question is how did they react?
[LAUGHTER]
MICHAEL STEIL: How did Microsoft react to finding out
that RC4 cannot be used as a hash?
A: complete code audit; B: fix the hash; C: wait for more
attacks; or D: do nothing.
Now I'm going to ask you, I'll ask the audience.
Who who would do A?
Well that's quite many people, perhaps a third.
B, fix the hash?
That's more people, almost half.
C, wait for more attacks?
One.
Do nothing?
One, OK.
So they fixed the hash, and I'm not saying that
this was a good idea.
I'll tell you later what would have been the
right thing to do.
OK, Microsoft saw that RC4 is no hash; RC5 is not an option.
I don't know for what reason, maybe licensing, maybe some
other reason.
So they added another hash, but they didn't have any
memory left, just a few bytes.
They needed a tiny hash.
They needed--
well, many encryption algorithms
can be used as hashes.
So what they needed was a tiny encryption algorithm.
And what do you do if you're looking for a
tiny encryption algorithm?
[LAUGHTER]
MICHAEL STEIL: Google helps.
[LAUGHTER]
MICHAEL STEIL: You'll get TEA, TEA, the tiny encryption
algorithms. I have no proof that it really happened like
this, but it seems somewhat obvious.
[LAUGHTER]
MICHAEL STEIL: They fixed the secret ROM.
They kept RC4 for decryption.
They added a TEA hash, which is really, really tiny.
They updated the RC4 key, because it's trivial to update
it, while they knew that Bunnie could just dump
everything again; but if there's a
hash, they are secure.
They trashed thousands of Southbridge chips; that's why
Nvidia had a really, really bad quarter of 2002.
They had to throw away lots of these chips with the
integrated ROM and make new ones.
Obviously Microsoft blamed that on Nvidia, and they had
to throw them away.
It was their loss, not Microsoft's loss.
OK, let's hack them again.
Yeah?
AUDIENCE: You didn't say this, but I presume that the secret
ROM was in there within the chip?
MICHAEL STEIL: Yeah, that was in the Southbridge chip that
Nvidia did.
Nvidia did the Southbridge and the Northbridge.
Actually, it was AMD technology;
Nvidia licensed that.
AUDIENCE: So why what was it Nvidia's fault if Microsoft
shipped them the code?
I don't get this.
MICHAEL STEIL: I don't get it, either.
I don't know why Nvidia had to trash the chips.
AUDIENCE: Because it's Microsoft.
AUDIENCE: Because Microsoft is bigger.
AUDIENCE: Microsoft is bigger than Nvidia, yeah.
MICHAEL STEIL: But it was Nvidia who had the losses.
So let's hack it again.
It should be trivial to extract that ROM again and
find out whether there are some other attacks possible.
We could have let Bunnie do it, but we
preferred to do it ourselves.
Now that's the Xbox Linux project;
that's where we started.
There is an easier way to hack all this.
And there is some legacy functionality in x86 based
CPUs that you might have heard of that's really, really old
and bad legacy stuff that nobody would need anymore
today, but it breaks lots of things.
It broke many boot loaders.
The Intel Macs also have it, and it broke boot loaders.
A20, the A20 gate, I'm not sure whether you are
familiar with it.
Therefore, a short history lesson, Part II--
the 8080, that's mid-1970s.
The 8080 had 64 kilobytes of RAM.
The 8086 had to be somewhat compatible to that.
It also has 16 bit registers for addresses, so pointers
could also only be 16 bits.
Also it had a whole meg of RAM.
So they had segments of 64 kilobytes each.
They could have done it this way, by just having 16
segments, but they chose to have a segment register, which
was 16 bits wide so segments could actually overlap.
So at the beginning of memory, if you're at segment zero, you
would have this segment and 16 bits--
every 16 bytes, a new segment starts.
There is one interesting side effect about this--
that at the top of memory, this is actually the last
segment that you could use, but is not the uppermost
segment number that there is.
If you go one step beyond that, then memory--
that segment will go into nothing, and lest you look at
the last one--
yeah.
But it doesn't go into nothing, of course, it wraps
around as always-- we've learned that already.
So if you have this segment, then you will get 16 bytes off
the top of memory and 64 K minus 16 bytes off the bottom
of memory again.
Because if you add this, and you leave away the 20th
address bit, you will just have zero again.
But when the 286 came out--
on the right, you can see the same calculation with the 286,
that is different.
The 286 isn't compatible, because the 286 could address
16 megabytes of memory, so that didn't have the
wraparound.
You could really address that memory, and Microsoft used
that with high memory in MS-DOS.
The 286 was incompatible; it doesn't wrap around.
So IBM added a hack, because there was the software that
relied on this.
There was software who wanted to have a segment that was
halfway up and halfway down.
Intel did not implement this hack; IBM did, because Intel
didn't notice it.
But IBM did when they constructed the IBM AT.
They added an option to their systems to have the 20th
address bit always be zero.
That looks like this.
The 286 is connected to RAM, with its address bits, and the
286 keyboard controller happened to
have a spare pin left.
So they connected that spare pin with the 20th address line
to pull it down to zero if code wanted to do that.
So the AT booted off with that hack enabled, and software
which wanted to use more than 1 megabyte had to
enable the A20 gate.
Yeah, this emulated the wraparound.
Effectively, all addresses are ended with this value.
[LAUGHTER]
MICHAEL STEIL: Ah, someone is seeing where this is going.
All x86 CPUs still have this functionality, including the
Pentium III Celeron; and even the Itanium has it.
So what we did was connect that line, which is now a pin
of the CPU, to ground.
All addresses get ended with this value.
So the CPU does not start anymore at this address, but
at this address.
But where is this address?
Where would it start from?
Normally, it starts from the top minus 16.
Now it should--
and there's the secret ROM--
and now it starts from somewhere there.
But what is there in address space--
mirrors of Flash.
It is mirrored over 16 megabytes.
So that's exactly the same spot where originally an x86
would boot off.
That's exactly that spot in Flash that we
can now boot off.
So all we have to do is put the ROM code there.
We connected a standard old Modchip for an old Xbox before
the fix; we put our code in there and wrote code that
dumped it to some slower bus; and we have new secret ROM.
OK, we saw there was a new TEA hash; there was a new key, OK.
But there was also the TEA hash.
Digging around in some scientific publications, this
means that each TEA key has three other equivalent keys.
In particular, it is easy to construct collisions for TEA
when used in Davies-Meyer hashing mode.
So TEA cannot be used as a hash either.
It is insecure, and look at who wrote that--
[LAUGHTER]
MICHAEL STEIL: --who co-authored that,
and it was in 1996.
That was six years before Microsoft used TEA, so they
should have read the documentation or should have
read something.
So we could change some JMP to jump to our code.
Let's look at the other hacks.
We verified whether they still work, the "mist" hack.
When the secret ROM went away, then Flash would be there on
the old Xbox; they fixed that.
Now if secret ROM goes away, there is nothing below.
Nothing will be mapped there, and whatever way we used to
turn off the secret ROM we will never be running again;
the system will just crash.
So they fixed that.
They didn't know about our hack.
They fixed that themselves; they found that themselves.
And there is still a "Visor" vulnerability.
The Visor backdoor with the wraparound.
We also checked that, and it turned out that Microsoft
acted too quickly.
They didn't know about the Visor hack.
They didn't know that there was a problem.
If they had waited for two months, or they had checked
their security system once again, they
would have found out.
Yeah, so just fixing it wasn't the solution.
Waiting or a code audit; that would have been the solution.
So we had no need to hack TEA.
We just could use the old visor wraparound around trick,
so that wraparound trick would run on all Xboxes, and we
could have a single ROM that ran on all machines.
So Microsoft never trashed Southbridge chips again,
Nvidia was happy about that.
And in the latest revision--
the latest written revision now has a real ROM chip.
But yeah, it's integrated into some chip.
They did some things right now, but the LPC overwrite is
still there, because the Southbridge is still the same,
and the Southbridge has this overwrite functionality in it.
They never trashed Southbridges again, so we can
still connect more chips, even on the latest Xbox.
Yeah, that was the hardware attacks.
Now I'm continuing with the non-hardware attacks.
There were also some for those people who didn't want to open
their Xboxes.
There is another check from Windows to the game.
We have hacked the first part, and now let's look at the
second check.
Yeah, it looks pretty secure.
It's RSA public key cryptography; there's nothing
to do there.
But games have data, and data might not be so secure.
There may be some vulnerabilities there.
And it is not checked, and sometimes it cannot check.
So we checked--
sent it there for buffer exploit methods.
So what do games load?
Typically from DVD they load graphics, audio, video, all
that stuff, but we cannot hack that, because we
cannot alter them.
We cannot burn a DVD again that will be accepted by the
Xbox, so that's not a possibility.
Savegames is a good idea, because savegames cannot be
hashed or assigned or anything, because they are
written by that very software, and they are stored on hard
disk or even USB storage.
All the memory cards on the Xbox are USB devices, USB
storage devices.
So David Jilli from Switzerland tried all the
games he had or all the games he could get for rent,
alphabetically.
And what's the first game on the alphabet?
007.
[LAUGHTER]
MICHAEL STEIL: And whoa, 007 had a vulnerability in the
savegame handler.
So everything that someone had to do was "dd" a hacked game
on a USB stick, copying is not enough.
You have to--
it's its own fire system, yeah.
AUDIENCE: So I actually worked on that game.
MICHAEL STEIL: Huh?
AUDIENCE: I worked on that game.
And I know the guy who wrote the code.
MICHAEL STEIL: Oh.
AUDIENCE: And the irony was, the buffer overrun was in a
function called SSC, Save Screen Copy.
[LAUGHTER]
AUDIENCE: Needless, to say, it wasn't a Save Screen Copy.
MICHAEL STEIL: Oh, you have to introduce me to that guy.
We will talk later.
[LAUGHTER]
MICHAEL STEIL: I know some people who would
like to meet him.
[LAUGHTER]
MICHAEL STEIL: OK, so everything that
had to be done was--
too bad we didn't have the source code, or else we would
also have had the possibility to laugh.
Yeah, someone just has to load the savegame of some USB
stick, and that's it.
And that's not the only game; there are lots of games; and
there are several more that we haven't published.
Lots of vulnerabilities, so you can just run Linux.
Yeah.
AUDIENCE: So you're telling me that 007 is my boot disk?
MICHAEL STEIL: Yes.
[LAUGHTER]
MICHAEL STEIL: 007 is your boot disk.
You can run Linux off 007 by just loading a savegame.
You can call that savegame "run Linux." 007 is a nice
boot loader.
[LAUGHTER]
MICHAEL STEIL: And the game is of no use otherwise.
No offense to your friend, but the game sucks.
[LAUGHTER]
MICHAEL STEIL: But how is that possible?
We should be in user mode.
It's just a user mode, a data exploit.
But all games are in kernel mode, and
we have full control.
But why did they do kernel mode?
That makes little sense to me, possibly speed or something.
But there is a problem using 007 as a boot loader.
So you need the game.
You have to buy it; you cannot rent it.
You have to run the game every time.
You have to look at that video at the beginning, but there is
an application on the hard disk.
This is the Xbox dashboard.
You can manage your savegames; you can listen to music,
change your settings.
This thing is always stored on the hard disk, and it also
load some data.
And we could change that data by connecting the hard disk to
a PC or something.
So what it does, it loads audio files; there are 3D
meshes; there are fonts that it loads.
But it checksums, of course, audio, 3D meshes--
[LAUGHTER]
MICHAEL STEIL: It does not check fonts, and there is a
vulnerability in the font handler, naturally.
So what, Stefan Esser was the guy who found that, German
security expert.
And Jeff Mears actually implemented this hack then, so
when the dashboard loads, it loads our hacked fonts, the
dashboard crashes, our code runs, our code can then load
the dashboard again and patch it in memory, so that some
keys are replaced, that our public key's in there, so that
we can sign, and so many entries are, perhaps, changed,
and we can run the dashboard again.
I have a video here that shows--
aw, not too loud--
this is an Xbox booting up with a Megaswords
game in the DVD tray.
The game is starting up right now, showing some more video,
showing some animation, the game is loading right now.
We have already attached a USB stick and copied the savegame
onto the hard disk.
The game is loading.
You will see the title screen now.
We say load a savegame, "install Linux" is the name of
the savegame.
And now the exploit inside that Megasword savegame has
started and that is now our code running.
Actually, it's Microsoft's update code with a game that
ships an update application, which updates the
dashboard on hard disk.
And we are in charge of the system.
We loaded this update application, patched it to
copy our data on it, and now we're getting
an update with Linux.
It takes a minute.
It's finished.
It will eject the DVD and reboot.
Now that's the boot up animation of the Xbox again.
Now we'll start off hard disk.
The hard disk is now spinning up.
When you see Microsoft, that means the RSA check was OK.
Now the dashboard has just crashed, is reloaded again,
and now you have--
[LAUGHTER]
MICHAEL STEIL: --Linux there.
[APPLAUSE]
MICHAEL STEIL: If you have 20 more seconds, when the music
stops, then you can see how they boot Linux.
The idea was there was another menu entry that said Xbox
Live, which is their online service.
We replaced that one, because using Linus and Xbox Live at
same time makes no sense, because if you're on XBox
Live, they can verify what you have on your hard disk anyway.
So Xbox Live and Linux will never match.
So we just installed Linux.
Yeah?
AUDIENCE: So you obviously had to have
Linux, the data, somewhere.
Was that already on the hard drive?
And--
MICHAEL STEIL: That patch installer also copied a small
Linux image.
A really tiny Linux image, it was just some, I think 5
megabytes Linux image or something.
AUDIENCE: Off of the savegame--
MICHAEL STEIL: Off of the savegame.
It was stored inside the savegame.
Xbox savegames are, actually, just a folder with anything.
You can put anything there.
And if you just use the empty kernel to file
copy the data on there.
And our boot loader also can use the empty kernel to load
the data and all that.
But people can, of course, install a real Linux then.
If there is another Linux, it will prefer the full
installation.
So here's a better screenshot of that again.
So what people had to do was just dd to USB sticks, load
the savegame, the hacked fonts will be installed.
And every time you turn on the Xbox, the hacked dashboard
will run and Linux will work.
The interesting thing about that is that there was a chain
of many, many mistakes and any point of these could have made
it impossible, or at least very, very hard
for us to hack it.
They used USB storage for memory cards.
That was easy.
That made everything so easy.
Games run in kernel mode.
If they hadn't done that, it would have been not so easy,
maybe even impossible to do that.
There was a game exploit.
Yeah, you can never avoid that other than, I don't know.
There was no font checksum.
There was also a font exploit.
All these contributed to that this work-- so, so many bugs.
And of course, if there hadn't been the dashboard bug, there
would have been another one in the dashboard with the music
playlist, not just the font one.
Then Microsoft fixed it again, and Microsoft did it the same
way as they always fix things, or as they had fixed things in
the past. They shipped a fixed version of the dashboard.
They even shipped it over Xbox Live, and new Xbox versions
had that dashboard.
But what we could do was just downgrade to the old
dashboard, which would still work, if you
have a copy of that.
Then Microsoft blacklisted that old dashboard in their
new Xbox kernels with newer hardware.
But there was another executable on hard disk that
had the same exploit; we just copied that one back, that
wasn't blacklisted.
Then they blacklisted it.
Then we used yet another executable--
dashupdate.xbe, which comes with every Xbox Live game DVD
because the first Xbox a shipped without Xbox Live, and
then they had this update.
So that was the same executable with
the same font bug.
And there where plenty of games out there, and it wasn't
blacklisted.
And they cannot blacklist this one, because all games have to
work on all Xboxes.
So the hackers had won.
So still today on any Xbox you can find, you can permanently
mod them to run anything and still dual boot into games.
You don't have to open it.
If you open it, that's also fine, then you can
replace the hard disk.
It looks like this when you modify more than
one Xbox at the time.
This is something I did for a hotel in Munich.
They have one Xbox for every room with Linux on it to show
video content.
They are cheap, $150.
OK, let me summarize.
Let me look at the clock, OK.
I don't have too much time; I'll run through this.
And the 17 classes of mistakes they have made--
8 design mistakes, 6 implementation mistakes, and 3
policy mistakes.
Let me just summarize them again.
And I want to remind you that these are classes of mistakes,
not individual mistakes.
Several mistakes have been made more than once, and other
mistakes are a combination or what they did have was a
combination of multiple mistakes.
Design mistakes.
There's no such thing as more secure or less secure.
Either security is effective or it isn't, and there is no
sensible compromise.
You do want to spend money on security to avoid losses if
you don't have an effective security system.
In-system programming of Flash-- that was because of
money, made the system insecure.
Cheap and faulty RAM chips made the system insecure,
because of the extra in it, the virtual
machine that they had.
The secret ROM room in Southbridge, if they had put
it into a CPU, we wouldn't have been able to sniff it.
They never did a second Southbridge update that would
have made it secure afterwards.
Also don't trade security for speed, because something like
10% faster doesn't make much sense if it is less secure,
because there is no such thing as less secure.
It's just insecure.
And 10%, that's not worth it.
If it's 200%, yes, but in this case, that all games run in
kernel mode, it's not worth it.
Also be aware of a combination of weaknesses.
Don't think of one single weakness,
whether it can be exploited.
Think of combinations, that's what they didn't do.
Adding extra barriers might not make sense, better to fix
each individual component as well.
For example, who would have thought that with a 007 game
and the dashboard exploit or some other game and the
dashboard exploit, you could, effectively, and with user
mode and all that, effectively run Linux.
Also never underestimate the resources of hackers.
There are commercial hackers, and they have money.
They want to spend money on making Modchips, but they are
not that good.
Those people, hobbyists that have access to hardware from
work or from university are even better.
For example, Bunnie at MIT, he had lots of resources there.
And never think that it would be too expensive or too much
work to hack something.
I know someone who knows someone who did that, who had
the idea of putting it in the Southbridge so it went over
the HyperTransport bus, and I know that Microsoft really
thought nobody would be able to sniff that-- that's just
too expensive to sniff.
So think about barriers and obstacles.
Never make something harder for hackers; you must make it
impossible for hackers, because time is not an issue,
or there are just so many monkeys typing Shakespeare.
Obstacles never slow down anything, and if you have
many, many obstacles there, you might think that's a
psychological thing that your security system is stronger,
but it isn't.
Instead use these resources into real barriers.
Savegames must be signed made no sense, because anyone can
sign savegames with the games can.
The hard disk is password protected, but you can hot
swap it into a PC while both systems are running, so it
didn't make a difference.
The secret ROM was hidden, but hiding it wasn't the point,
the hash would have been the point.
the games are not readable in a PC drive also made little
sense, because you also could hot swap the DVD drive.
Then don't use one security system against all attackers,
because hackers with different goals will unite.
There were four different hacker groups with four
different interests--
the Linux people hacking, the piracy people, on
the homebrew people.
And you must find out who your enemies are, and you have to
handle them separately.
Otherwise, either directly or indirectly
they will work together.
In our case, the Linux, the homebrew and the copy guys
worked together indirectly by just publishing their results
and working on what others had already done.
Security by obscurity doesn't work; that's obvious, but
Microsoft did it.
And of course, something like RSA or SHA
works, if used correctly.
Hiding the secret ROM was obscurity, encrypting Flash
contents, hide DVD contents--
that's all obscurity and didn't have any effect, but
they thought it would make it more secure.
It didn't.
When you are dealing with hardware-- with software you
can roll out fixes every day, but not with hardware.
With hardware, it's expensive to roll out fixes, so you
don't want to do quick fixes.
Those fixes may be flawed.
More holes tend to be found soon after one hole is found,
so either wait or audit the complete system, because you
have new knowledge, maybe you find more and look
what the others do.
With the secret ROM hash function they should have
waited and also with the dashboard, they should have
thought a bit before fixing.
Then there were several implementation mistakes.
Do read data sheets.
Microsoft didn't do that; they didn't want to do that.
Don't hack around, assume anything.
And especially be careful with components with legacy
functionality like A20 gate.
That is documented.
It is in the data sheets, and its legacy stuff and also the
wraparound if it's also legacy stuff, but it is well
documented.
Now this sounds all so obvious.
But that's mistakes they have made.
Do read standard literature.
For crypto, that's Schneier, for operating
system that's Tanenbaum.
Wikipedia is a good start, not the article, but the
references that you have there.
OK, Wikipedia wasn't available back then.
RC4 as a hash was a bad idea.
They should have read all the data that is out there just as
well with TEA.
Get experienced professionals.
They must have a background in security systems. I know that
some people from the WebTV team of Microsoft worked on
the Xbox, and they had no security background.
They did a set-top box.
It didn't have a security system.
And also don't get students.
There are maybe good students, but you want to get pros with
lots of experience, and the implementation of the secret
ROM was just so bad.
These were not pro people.
Also make sure that your code catches all cases, because if
it doesn't, then it will have the exact opposite effect by
giving hints to attackers, and this happened twice.
The secret ROM turnoff check, which was just too specific,
which gave us the hint where to look.
We didn't know what this instruction meant; we
understood it by seeing that code.
And hashing everything but the fonts gives us a
clue where to look.
Also look for leftovers.
We have to look at the final product from the perspective
of a hacker and hexdump and disassemble the final system,
if you look at the old version of the secret ROM, which is
still linked into the Flash image.
And also have a final test on your hardware when the final
components are in place, because even every small
change can break everything, including security.
The AMD to Intel switch was one such thing, and the switch
from RC5 to RC4.
They couldn't just leave everything else in place.
They should have changed everything significantly.
There's three more policy mistakes.
One thing is you have to keep your source code secure or
safe so that nobody can see it, because the source code
leaked off the Xbox.
It leaked after the hacks had been done, but still you want
to make sure that the source code doesn't leak, so you have
to find engineers that you can trust. But this does not mean
that you don't want as many people as possible to have a
look at your source code.
It's important that many people have a look at the
source code, because obviously it wasn't many people that
looked at the security code of the Xbox.
You just have to find people you can trust. Yeah, weak QA
on many, many parts.
And you have to talk to your enemy, because there's no such
thing as an enemy.
Not talking to terrorists is stupid.
These enemies, the Xbox people or the homebrew people, they
have their goals; you have your goals; and compromises
are a good thing.
There would have been the possibility for Microsoft and
the hackers to find good compromises, but Microsoft was
unwilling to talk.
So the worst case happened.
They didn't talk about 007; they didn't talk about the
font exploit.
OK, so this was a short summary of the
Xbox security system.
There's lots of more to talk about, and there is one paper
that has more details in there, which is available on
the internet on xbox-linux.org or do it your way.
Thank you.
[APPLAUSE]
MICHAEL STEIL: I don't know whether we have for a time for
questions, but anyway, I'll start answering.
AUDIENCE: Have you given this talk at Microsoft?
[LAUGHTER]
AUDIENCE: They're just down the block.
MICHAEL STEIL: I use an employee of Microsoft, and he
tried to convince the managers to invite me there,
but he had no luck.
But I have given a similar talk before, and it's on
Google video already, so Microsoft has the chance to
look at that.
Yeah?
AUDIENCE: So what about the Xbox 360?
MICHAEL STEIL: I can only refer you to a talk that will
be given between December 27th and 30th--
I don't know the exact date-- at the Chaos Communication
Congress in Berlin, by a friend of mine.
And I guess there are some new things about that.
The current official state is that there is nothing to do
there yet, because the 360 security is very, very good.
It's out for a year now, and there hasn't been
a major hack yet.
You can run copygames, OK, that was one flaw in the
security system, but you cannot run Linux or anything.
They implemented a hyper visor encrypted memory--
encrypted--
per box encrypted Flash chips.
That's a pretty good architecture.