The Xbox 360 Security System and its Weaknesses


>> Welcome everybody. This is a talk that involves
video game consoles. A lot of–lots of us like playing games on our video game consoles
and I have two guys here, Michael and Felix, who like playing with their consoles a bit
too much. And so much so they make them do things they were never intended to do. And
we all like doing that in some walk of life but let’s hear the story of Xbox 360 and the
security and what kind of things it can be made to do that it wasn’t intended to from.
[INDISTINCT] Welcome.>>STEIL: So, hi, I’m Michael and I’m going
to do the presentation part and later for Q and A, Felix is going to join me. So, I’m
going to do the talking and he did the actual work behind this. The Xbox 360 Security System
and its Weaknesses… [PAUSE]
>>…whatever. Okay. The purpose of this talk–we’ve given several talks about console
hacking specially Xbox 1 hacking before and it was all about bashing the security system,
bashing the work that Michael has done with that one but it’s a lot different with the
Xbox 360. The security system is really great but the problem is that few people know how
it works or how great it is and the whole industry keeps making the old Xbox 1 mistakes
over and over again because there’s just not enough documentation out there. There’s no
scientific paper or anything from Microsoft. So the idea of this talk is to educate people
on secure hardware design, to see how Microsoft did it and still the mistakes that they made,
what could be done better in the future? Yes?>>What do you mean by great [INDISTINCT]?
>>STEIN: Well, first–first of all, let’s do all the Q and A afterwards. And yes, I’ll
come to the point why it’s a great security system in the whole talk, I guess. So, let
me first talk about why it’s necessary to have a security system. On a gaming console,
it’s pretty obvious. Copied games shouldn’t be permitted. Unlicensed games, the industry
has always had this problem. Cheating is pretty interesting for online games today. And also
if you can lock out modifying consoles that’s run Linux or alternative operating systems
or Homebrew programs that you don’t want to have on your platform, that’s also a nice
thing. And what Microsoft has done and what pretty much everyone else is doing is just
have one security system that controls what software may and what software may not run
on you platform. So in order to talk about the Xbox 360 model, let’s just spend a few
minutes on revisiting the Xbox 1 model again and see what mistakes have been made there
and what has to–has to be made better for the second console that Microsoft made. The
Xbox 1 had–the problem of–they had little time developing it and just over one or two
years, they had to start from zero and get a full gaming consoles of what they took was
standard PC basically and their existing widows, software windows Kernel, DirectX and all these
technologies. And they put the system on top of it which is a chain of trust which means
anytime code hand execution to another piece of code, it will have to verify the authenticity
of the next piece of code and only in that case it can handle varied execution. So, in
the case of the Xbox, systems start up hands execution to the Windows Kernel which is in
ROM, if it’s okay, and the Windows Kernel will launch the game only if it’s also signed.
So these are typically RSA checks or caches. Let’s look at the first step here how the
ROM can make sure that the Windows Kernel is authentic and hasn’t been tampered with.
This is the main board of an Xbox 1 with the CPU, GPU, RAM Southbridge flash. Normally,
an x86 compiled CPU, as in the Xbox 1, would run–would boot from flash but, of course,
then you could just replace your flash and the first instruction would be in control
of the first instruction that is executed. So what they did is, they added some special
code–secret code 512 bytes of it into the Southbridge Chip, which on boot, gets transferred
over the bus. And which is the first code executed which does some verification, decryption
of the flash image and then jumps to the flash image. The problem with this is it travels
of a bus. Although the bus is pretty fast, there’s always someone, in this case that’s
funny, who managed to build his own hardware just sniffed that bus. So the secrets leaked
and also the code leaked. So, the first successful attempt that was made there is bus sniffing
and this is the code that was extracted. The purpose of the code is it does some basic
machine initialization which is done using a small virtual machine which takes code–which
takes its instruction from flash image, does the CPU setup, decrypts and, in theory, also
verifies but in practice doesn’t really, the flash image and if it doesn’t succeed, it
panics. So if we want to use this, we have to look at the board and what we see is this
port here which is an LPC port. We add a pin header and add a modchip, which is nothing
more than just a ROM chip which works because when an Xbox is manufactured, they have to
use this port for boot strapping. The first time they boot it, they boot it of this bus
because the internal flash is not written yet. And then switch to the internal flash
and write that. And that’s still present on a retail box and because the flash verification
in that code that was extracted wasn’t really working, this would make possible. So, the
second thing was Manufacture-Time Override, the second successful attack. So, it can run
any thing like this would loader that runs your favorite operating system. The chain
of trust; the first part with hack, but if you don’t want to go the hardware way, try
to exploit something in software. The second check from windows through the game looks
pretty secure because you have a lot of code there and it’s–I mean, by a lot of code,
I mean you have enough space to fit a real or a same implementation from the window source
code base, for example. So, this–this looks pretty secure. But games load their own data
and this data can be safe games. And there’s always the possibility of buffer exploits
there. And the nice thing is that all the games are running kernel mode on the Xbox
1. So, this is where this gentleman enters. 007 is one of many games that have string
vulnerabilities in their safe game loaders. And because as soon as we have a few bytes
of code in–in the system, in kernel mode, we can chain load as many bytes as we want.
This is this third successful attack chain loading any code which can be your own operating
system. If you want to have everything a little more permanent but not install your own hardware,
you can boot into Linux system and then rewrite your flash image by–with another boot loader.
This doesn’t work by default because the flash is write-protected. Microsoft does not–has
not planned in field upgrades of ROM chips but if you just add two wires to the main
board, this will be successful. So flash reprogramming is the fourth thing that happened which shouldn’t
have happened. And one more thing that has happened is if you don’t insert a game, it’ll
load the dash board which allows you to manage your saved games, to play CDs, DVDs and that
also load some data which also is not checked. So by installing fonts on the hard disc, we
can convert this into this, note the subtle difference. And one more hack that has actually
not been done because they have been so many other hacks, so this one wouldn’t have made
sense to do, is the DVD drive should be untrusted but the DVD drive is the one that basically
checks whether it’s an original game or it isn’t. So, the CPU trusts it. It tells–the
drive tells the CPU it can just lie and you can replace the firmware with your own firmware
which will just always lie. So this would be a fifth attack, the DVD attack. As I said,
there are no “in the field” down–upgrades by Microsoft. I mean yes, upgrades not downgrades.
So–but still if there are new revisions, new–new boxes manufactured they will come
with new system software and you can use the old software to just downgrade the newer boxes
because there’s no rev locking anywhere. So, sixth successful attack is downgrading. Let’s
look at all these attacks again; Bus Sniffing, Flash Reprogramming, Manufacture-Time Override,
Chainload Code, Downgrade, DVD Attack and there’s one more that has not been used on
the Xbox 1 because there’s no way the hardware would have supported it. There have been a
lot weaker points in the system. It’s Code Injection via DMA which means–if you look
at the buses inside a computer system, the DVD drive, the hard disc, networking, USB
and also the graphic chip, they all share the same bus so they can all read and write
arbitrary memory from the physical standpoint without all the paging, without any protection.
So if you manage to make your device write somewhere, you can change anything if you
know the address where something is but that–that seems to be pretty constant with many systems.
So, you can just modify your code to not check anything anymore. You can just attach a chip,
waits for something triggers on something and inject something into Ram when its–gets
read. For example, there’s this famous file wire hack who just attach something on a file
wire bus and you can inject anything onto that machine because the fire wire cables
pretty much sits on the bus of your computer. So, that had to do something against this
two. So, let’s look at these attacks again and let’s think about some different ideas
how to mitigate those attacks. The first thing and the major weakness of the Xbox 1 was that
it didn’t have enough ROM for start up, just this 512 bytes which weren’t nearly enough
to do any secure authentication of whatever you drain afterwards. Also, it didn’t have
any internal RAM so all the keys–everything it dealt with while decrypting, while verifying
was stored in insecure RAM. So what we need is a lot of ROM in the auto magnitude of 16/32/64
kilobytes for the decryption verification code and also little bit of machine setup
and in big enough internal RAM so that we can store all the intermediate data. This
way, we can boot up–we can make boot-up really secure so that–by keeping it minimal, its–we
can be pretty sure that nobody finds an exploit then we can chainload something that is really
trusted. So the first thing, bus sniffing, doesn’t make sense anymore if we put the ROM
and the RAM directly inside the CPU. There is no bus to sniff anymore. There are no secrets
going over any bus. Also, this way, flash reprogramming is pretty much impossible if
we implemented right. And by having like, 32 kilobytes of ROM and 64 kilobytes of RAM
we can make that possible. Then the next thing to do is decent privilege separation which
the Xbox 1 did not have, like everything ran in kernel note. Now on the 360, everything
will–well, everything will run kernel mode; two, except for the hypervisor. That will
run in hypervisor mode. And the hypervisor has some extra privileges that kernel mode
does not have. This is pretty much the same setup as kernel mode user mode just shifted
up by one level into hypervisor mode and kernel mode which has speed advantages. Otherwise,
it’s basically the same. Hypervisor mode manages your MMU. It manages the page tables and the
TLB. It can enforce W^X or execute, which means that a page in memory is either writable
or it’s executable but it cannot be both. So, whenever a program or whenever an exploit
wants to write some code somewhere, it can write it but it cannot make it executable.
So a game has no means of making data executable. It will always have to go through the hypervisor
and the hypervisor can then decide by using signature. So this way, chainloading code
is pretty much impossible. Something like return to live can still be possible but this,
yes, pretty much the best thing that can be done here. So, chainloading code can be made
impossible using this. But now, if we were an attacker, we had the system that boots
safely and has a hypervisor, how would we attack? And we use something like a DMA attack
to inject code into the hypervisor. We can’t just change some key in the hypervisor by–by
attaching something to the USB bus or to any bus. So we have to make sure that DMA injection
does not work. The way we can do this is Memory Hashing which means that this is implemented
in the–must be implemented in cache. So anytime a cache line is written back–back out to
RAM, then a hash will be stored in the CPU’s internal memory. And every time a cache line
is read back, it will be compared to the hash and if it’s wrong then the system will just
lock out. So this pretty much guarantees that every time–this guarantees that all the memory
that I ever read that is under the system has been written by the CPU and has not been
written by any device. Because id a device writes it, then there’s–then the hash will
not match. Of course, we have to do DMA in the system, so we cannot make the whole–the
whole system not all of RAM can be under the system. So this needs to be an opt-in feature
or opt out for all those pages that require a DMA. This is a nice system, it’s very effective
but the problem is we need extra storage inside the CPU, and this can be very expensive. In
order to–so a cache line on the power PC CPU as it’s used in the 360 is 128 bytes and
in order to have a secure hash of that, we need about 16 bytes. So for a 64 kilobyte
internal RAM–internal to the CPU, which is really expensive, we can only excess or we
can only secure about a megabyte of external RAM. The Xbox 360 has 512 megabytes of Ram
so there’s no way we can secure everything using this. Same practice, we can protect
the hypervisor which is way below one 1 megabyte of code. So Code Injection via DMA, we get
one star for this. If we also want to protect everything that runs in unprivileged mode
which is the Xbox kernel and the actual game, if we want to protect that as well from DMA
injection attacks then Memory Encryption can help us. It’s not as good but it’s a lot cheaper.
It also works on the cache level so every time memory is fetched, it is decrypted. And
every time it’s stored back, it’s re-encrypted. The same applies here. This cannot work with
pages that require DMA because of the very idea behind it. Whenever you have DMA it shouldn’t
be able to write anything which is marked, encrypted and therefore secured, but while
DMAing into something protected by hashing will lock up the system. In this case, it
will only destroy the data because if you DMA something then it will be in plain text
in memory but when the CPU reads it, it will try to decrypt it so it will get gobbled data.
So this can be used for some attacks, like if there a blacklist somewhere–to blacklist
some application, we can just destroy the blacklist and the compare will match anymore.
Also, some jumps on power PC or–well, a jump on power PC is, if I remember correctly, just
six bits. So six bits encode the jump and the rest is the offset. So there’s a pretty
good chance that if we try this over and over again, we might hit the correct six bits for
a jump and just jump somewhere and then can fill the whole memory with nops to catch our
jump. So, this is not perfect and not as effective as hashing but it’s cheap. We have it’s–there
is a small performance penalty but we don’t need any extra RAM. So in practice, we can
use this to protect the hypervisor and also all the game code. And what’s nice about this
is it obfuscates everything that is in RAM or everything that you want to protect in
RAM, so all the code in RAM cannot just be sniffed by DMA device. So we can make the
whole system obscured so that no code will ever be visible anywhere. If we encrypt the
games, if we encrypt the flash so an attacker will have a hard time to find any code that
can look for security vulnerabilities in. So Code Injection via DMA that gets us another
half of star. A Random Number Generator is another idea which can improve the effectiveness
of the previous techniques. The problem with the encryption that I’ve described so far
is that it is–that it would be predictable. So, I can do replay attacks. If I dump my
memory at one point and replay it at some other points, the encryption would still be
that same all the time and I could inject a different state or I could inject a state
of–of previously into some part of the system and keep the state in another part of the
system to make things miss match and to make them behave as I want them too. So by choosing–by
having a random number every time the system boots, there’s no way to replay anything anymore
and all the data will just be gobbled again. This will give us another half a star for
Code Injection. Now, eFuses is another interesting technology invented by IBM and implemented
in some of their products and the pub PC chip on the Xbox 360 is also done by IBM. And it’s
a way to–well, an eFuse they are cheap, you can have lots of them, you can have hundreds
of them on side the CPU and you can blow them at run time so there’s no way to undo this
later. So one nice feature that we–one nice way to use this would be to disable features
that we only need at production time. For example JTAG, all the things that we need
for verification, for testing in the manufacturing process can be disabled later on by blowing
a fuse. Also, we can make every CPU have its own unique per-box key by also blowing a couple
of fuses and burning the key into the CPU and that key will be inside the CPU and will
never leave the CPU if we don’t choose too. This key can be used for crypto on the flash
chip, so that the flash chip will be encrypted just for my box. I cannot swap any flash chips
and also, in directly, it’s used for DVD pairing, for keeping a secrets in flash which is a
key to pair with my DVD ROM drive so that I cannot use another DVD ROM in my systems,
I cannot swap those or I cannot manufacture just a DVD drive or device which emulates
a DVD drive but in reality it’s a hardware and just emulates those games on the hardware
because those are chained together. My DVD drive needs to have the exact same key as
the Xbox. Also, whether it’s a devkit or it’s not a devkit will be stored in eFuses. Devkits
behave a little differently. They allow a lot more games. And update revocation. Whenever
I update the system, I can blow a fuse and even if someone downgrades the flash chip
by disordering it or by doing anything fancy, it will not accept this flash anymore because
the revision count in the flash is not the same as the number of blown fuses. So, this
will give us a few nice extra features. Manufacture-Time Override, we pretty much mitigated that. Downgrading
can be made impossible if implemented properly. And DVT–DVD attacks are made a lot harder.
You’d have to dump the key of the box in order to make a device that emulates the DVD drive.
And also, Code Injection via DMA is harder using this because we have a per-box key which
can be used as a seed for the random number generator and other things. So everything
we need; hypervisor, SRAM and the CPU, some additions to–to the caching, to the–yes,
to the way addresses are generated fuses in a random number generator. The nice thing,
it can all be implemented inside the CPU. There’s no dependency on any external device.
This is an easy version of what a three-core PowerPC system would look like with the three
processes. There own MMUs each connected to the L1 cache and that’s connected to the L2
cache. And what can be done to add all the security without changing any of the actual
architecture of these components is just adding stuff outside of it. So yes, this is the standard
core and we can add a random number generator, eFuses, ROM, and SRAM to the system, external
to the actual CPU. And by adding some logic which does the hash calculations and does
the crypto for loading and storing L2 cache which is and–which is connected to SRAM because
of the hashes that it stores. We can–yes, add the whole security external to the actual
normal CPU. But what we have here is still one die so nothing travels over any causes.
Everything is inside the CPU which has to be a custom part anyway. For the Xbox 1, it
was a standard off the shelf Celeron CPU but you won’t be able to find any three core PowerPCs
out there so this has to be a custom part anyway. But still, all the modifications are
done outside of the critical regions so it is a cheap and easy modification. If we look
at the board, CPU, Northbridge, Southbridge flash, RAM, everything is contained inside
the CPU and nothing travels over any passes anymore. Now, let’s look at some details in
practice. For Secure Boot, we have 32 kilobytes of internal ROM and 32 kilobytes if you compare
that to the 512 bytes if the Xbox 1. This is really a lot. You can fit whole RSA, algorithm,
SHA 1 for verification in there to be really sure that the code there that you’re running
from flash is okay. And also, 64 kilobytes of internal RAM which should be fine for your
calculations. Hypervisor mode is something that is supported by 64 bit PowerPC processes
anyway. The Hypervisor code is about 128 kilobytes and, as I said before, it’s–it manages the
page tables, enforces, W^X or execute. All the–and practice all the pages from the Hypervisor
itself or hashed and all the code pages in the system including all the Hypervisor code
and data are encrypted too. And only the Hypervisor can make the code executable. The Hypervisor
does is–is very light weight, it pretty much only does memory management on a very low
level. It does not interact with hardware at all, that’s all the job of the kernel which
is running in untrusted kernel mode. But it has to catch all the interrupts and exceptions
and most of them, it just passes up to kernel mode. How about hashing and encryption? That
has been done in a very interesting way on top of the existing PowerPC architecture.
So a 64 PowerPC would support 64 bit physical addressing. But we don’t need 64 bit addresses
on an Xbox 360. We only have 512 megabytes of RAM and some more IO ports, so everything
should fit within 4 gigabytes which is 32 bits. So there are addresses generated which
have spare 32 bits on the top. And this is where some extra flags are transmitted. These
flags mean something to the L2 cache. For the L2 cache this–as we can see in this example,
if we have this magic value of 100 means that this page has to be encrypted and hashed.
So the CPU doesn’t know anything about it, it’s just a matter of setting up the page
tables to point, to address this like this with the upper 32 bits set to something besides
zero. And the L2 cache will take care of hashing an encryption as we choose it. Yes. So hashing
is implemented in L2 cache for every 128 bytes which is a cache line. We have a 16 bytes
SA–SHA1 and the hash is stored in 64 kilobytes internal CPU SRAM which is the same SRAM which
is used for boot up for the crypto routines that run at the very beginning of CPU start
up. So this is enough for hashing 1 megabyte. Encryption; same thing. Implemented by L2
cache which looks at those extra bits and the key has to be setup by the CPU and taken
from the random number generator at start up. We have 768 bits–768 eFuses that we can
blow individually. The features of those are, for example, JTAG disable so the CPU supports
JTAG but after all the testing is done, this is disabled. The unique key for flash decryption
and for many other things so many, many things are based on this key is also burn with the
eFUses. The devkit or retail identifier and the update sequence counter. Now, with–I’ve
just describe the whole security system in theory. Now, how does–how do some things
work? Like, let me explain some things in practice. Paging, so everything that runs
in kernel mode, which is the Windows Kernel–Windows 2000 derived kernel and the actual game, they
run in a paged environment so there are page tables setup somewhere which are controlled
by the Hypervisor. And the way encryption and hashing is managed is just by putting
those bits into the page table. So in this example, the virtual address on the left will
be mapped to the physical address on the right, which in the end is just the low of 32 bits
in this case but which also tells the [INDISTINCT] to, in this case, turn encryption and hashing
on. So the hypervisor will just enforce that every time a page is executable it will also
have the bit for encryption turned on. This is nothing that the [INDISTINCT] enforces
but the hypervisor will enforce every time it lays down a page table entry. The hypervisor
itself is not paged although it’s encrypted and hashed. So for some reason, it might be
performance, it might be simplicity. It’s–it runs without paging, which is called “real
mode”, but it can still be encrypted and hashed because of a feature called the hypervisor
real mode offset register, HRMOR. Every time you have–every time you have an address which
has the uppermost bit, bit 63, or if you think [INDISTINCT] then it’s bit 0, which has this
bit set means that the offset of the HRMOR will be added. So every time–so the hypervisor
thinks it runs at offset zero and [INDISTINCT] but this offset gets added which effectively
adds just the flags and these flags mean that hypervisor will be encrypted and hashed. At
manufactured time. So how does manufacturing work? All the eFuses when the CPU manufactures
is zero. So the ROM that is embedded in the CPU will know the special case and can behave
differently. So it can boot a generic flash image and then download some special code
for the first time. It generates its unique key and stored in the eFuses. It can personalize
the flash image and encrypted with its own key and also generate a DVD key encrypted
with its unique key and store it in flash. Loading an executable is something that the
Windows kernel cannot do by itself because it needs to be verified and verification can
only be done by the hypervisor. So while the Xbox kernel in untrusted mode loads the executable
into memory, it will hand chunk by chunk to the hypervisor which will then check the authenticity
of the code and if it’s signed properly or if it’s hashed properly and the header will
be signed, then it can make the code executable. And the way it can make the code executable
is pretty interesting. If you have an address and the same address with the upper 32 bits
set so that it’s encrypted and hashed and you just copy from that one address to the
other address, you will implicitly encrypt it. So it just goes over the whole area and
encrypted by copying it to the same address plus encryption and then lays down the page
table entry to make it executed. Firmware updates look previous straightforward. The
way it’s done is you don’t replace the Flash for safety reasons, I guess. They just append
patches to the Flash binary patches. And every time you add an extra patch, it will have
a sequence count or you can count the number of patches and every time you add a patch
you also burn one fuse. So in case the last patch is missing or one more fuse is burned,
then you have patches then the box can refuse to boot. But still–so this was the system
but there have been–there–well, there is at least one vulnerability that has been found,
which is quite interesting because it’s in one very prominent location, which is the
syscall handler of the hypervisor. On the left, you can see the disassembly. It first
compares the argument with 61. So you have roughly 100 or so syscalls. If it’s greater
or equal, then it’s illegal. Otherwise, it shifted left by two. So it indexes an array
of pointers, loads that value from the jump table and loads it into the link register
and jumps there. And the [INDISTINCT] the same thing in C. But can you see the problem?
It’s not about signed. It’s more subtle. It’s these two instructions. The compare works
on words. The rotate works on longs.
So it only compares the lower 32-bit, but then it takes the whole number and shifted
left. So if we give it something that is four billion, about 4 gig, and has something very
tiny at the end, it will pause this test but still be way above this so we can feed in
incorrect values. We can control bits 34 to 63 of the effective address. So the way this
would work normally; we have syscall number of 2A; we shifted left by two; we add that
offset, which is 1044; and then because the hypervisor runs in real mode, this offset
gets added, which is because the uppermost DMSP is clear, which means that it must be
added. We have this effective address. With exploit, we can do this. We feed in this address
or this syscall number. That’s fine. That’s lower than 63 if we only look at the lower
32 bits. But then we shift the whole thing left by two, so we have the SMP set. Now we
add the offset again, but now the base does not get added. So what we get is this address
which doesn’t have the protection bits, which doesn’t have the bits that we need to fetch
this from encrypted and hashed memory. So if we have a way to store something at the
syscall–in the syscall jump table H2A, which is not encrypted, then the code will read
from this address unencrypted. So we just need to do DMA injection into this one value
and then make it somehow that it executes the syscall with this–with these parameters.
Now, how do we do that? Shaders. Games cannot just sign everything that they come with and
it’s normally not necessary because you cannot change that anyway because you cannot copy
a game but, of course, you can copy a game if you hack the DVD drive; that’s the first
step. Then you can have your own copy of King Kong. Then all the graphics data is not signed.
That’s pretty much fine. The shader code, that’s the problem. That should be signed
because shader code is actually an executable code which runs on your graphics hardware
and that can access all the memory. And if you write good shader codes, you can just
write anything anywhere. Of course, you will not do the encryption. All those DMA attacks
won’t work, but you can write those–that syscall index unencrypted, which we later
need unencrypted. But the question now is how do we do this hypercall–this call–the
syscall into the hypervisor. The interest thing, and I [INDISTINCT] got this [INDISTINCT]
is that the thread state so the register states of the threads are safe in unencrypted data
segment. So when task switching is done, the thread state including all the registers need
to be safe and ran. Is it code? Is it a code segment so that DMA attacks don’t work? Was
it a data segment? It’s a data segment so we can just overwrite those registers. So
we overwrite those registers using the DMA attack, using the shader to–that next time
the register gets loaded from the thread state. We’ll have the registers for that syscall
and then we’ll set the program counter to some syscall instruction, which is in our
game or in the [INDISTINCT]. So what happened was this was reported to my Microsoft. It
was fixed by Microsoft in just six days, but still there are lots of vulnerable systems
which can at least be upgraded to that version so that you can run anything in your box which
includes, for example, the Linux Operating System. Now let’s look at the mistakes. What
has been made wrong here? The design looks pretty good. Also, what I like about the design
is that it’s pretty easy, pretty simple. It’s–I find it’s pretty easy to understand and it’s
all contained inside a very simple system, all very simple ideas. And also the implementation
has been quite good. But still there have been mistakes. There’s always three kinds
of mistakes that you can make: strategy mistakes, design mistakes, and implementation mistakes.
Strategy mistakes are the worst ones. Therefore let’s first start with implementation mistakes.
So the hypervisor interface, obviously that was a mistake, but we haven’t found any other
bugs although we–or actually lots of other people–have looked at a lot of code and not
found any vulnerabilities there. The implementation was really good, which might have been caused
also by the fact that the code has always been kept minimal. So it’s not just link everything
in it or looks at every case. Just keep it simple. Keep everything minimal so that you
don’t have all those mistakes. As it was shown with the Xbox one in just 512 bytes, they
managed to fit three or four security vulnerabilities. With the design, I think they have made a
few mistakes with the design. First thing is the thread state and also all the stacks
are stored in data segments. Registers are something that should be regarded as code.
They are just as valuable as code so they should not be stored somewhere where DMA attacks
as possible. They should have put this into encrypted data. It makes–in a way makes sense
to store them in unencrypted data because encryption gives you a tiny performance penalty.
And having your stack in an encrypted area, which gets read and written all the time,
might not be a good idea performance-wise but still this attack wouldn’t have been possible
if those had been in an encrypted area. Also, the hypervisor runs without the MMU. And with
this system it was possible to use that hack with the uppermost bit. If the hypervisor
had used page tables two, it would have been a lot harder. It’s–if you look at it–if
you look at it from a design perspective, you might think that the hypervisor is the
piece of software that is in control of the whole system. Why should I limit the powers
of that single piece of software which has full powers anyway or which requires full
power? But it does makes sense. That’s the principle of least privilege. Even if you–if
that code must be absolutely trusted, not every part of the code needs to do everything.
So if the hypervisor runs with an MMU and cannot just access all of memory, cannot just
access something unencrypted by just having a different pointer but would have to set
of a page table in order to do that, then it would have made this hack a lot harder
at least, if not impossible. And, well, DVD security also was pretty much absence. The–I
guess the reason was that Microsoft was not in control of the DVD drive itself. They had
several manufacturers to make the DVD drive. And the DVD drive itself is not a secure system
so it couldn’t really be trusted. So there was always this possibility of the DVD drive
lying to the system. Now the most severe mistakes that have made over and over again by pretty
much any company, which are the strategy mistakes point number one: never use a single security
system to lock out two independent groups of attackers, or in other words, don’t protect
the interesting assets with the same key as the important assets. And by interesting,
we mean interesting from a hacker’s perspective and importance as from the companies, from
the manufacturer’s perspective because this has happened a lot in the past. Let’s look
at devices since 1999. The PlayStation 2, released in 1999. I don’t really know about
how the security worked or how and when it was hacked but it was hacked for piracy and,
yeah, the effect was obviously piracy. But after that, there’s this German set up box,
DBox2 in 2000. It has [INDISTINCT] kernel. Pretty lame security from today’s perspective
but it had something. It just didn’t just run any code. It was hacked in a very small
amount of time. It was hacked in order to run Linux, but it had the side effects of
people decoding pay TV. GameCube encrypted boot. It took quite a long time because people
weren’t so interested in that platform. They were interested in running–well, it came
out the time as the Xbox, and the Xbox had a hard drive and was a PC. It would have run
anything and the GameCube was this limited small system. So it wasn’t all that interesting.
Just when the Xbox was finished, all the expert hackers went over to the GameCube. So why
it was hacked was also, yes, for Homebrew, for the good cause and the effect was piracy.
Xbox, it was hacked for Linux, for Homebrew and, yes, these hacks have been abused for
piracy because anytime you can run your own code, you can just run any game that doesn’t
have all those checks that might be embedded in the game anymore. Do you see a pattern
here? Nintendo DS, same thing: for Homebrew, used for piracy. PlayStation Portable, same
thing. It happened to the 360. It happened to the Wii. What’s pretty interesting is–it
was quite quick on the Wii. But wait. There’s one that is different. There’s the PlayStation,
PlayStation 3. The PlayStation 3 has had–it has a security which is comparable to the
Xbox 360 security but yet it has not been hacked although the Xbox 360 has been hacked.
And why is that? Well, they provide a means of running anything you want. They have this
run [INDISTINCT] and you can just run Linux or you could port your favorite operating
system to it. So the hacker community just hasn’t been that interested in it. There’s
the piracy community and there’s the Homebrew community. And the Homebrew community are
the really good people as it shows. So, yes. If someone wants to design a good system,
the first and most important thing is to keep out the hackers by just letting them do what
they want to do. Okay. We’re up for Q&A now. And as I don’t know anything, Phillip is your
man.>>DOMKE: Hey. So anybody? Well, it must be
a pretty good presentation then.>>STEIL: Where everyone is confused.
>>So there’s all this–there’s all this encryption and decryption going on at run time during
the course of playing a game. Is there any measure of what are the cost semantics behind
that? Is it–does it detract from the power of the system to have this, to encrypt and
decrypt every page of memory?>>DOMKE: In terms of performance? Yes. So,
I was told–I’m not completely sure if it’s true that there’s a cost of latency but not
really of throughput. So the memory of latency is like 500 clock cycles [INDISTINCT] something
anyway so it doesn’t met a match [INDISTINCT] like 16 addition in cycles. So that’s basically
the key like hiding the latency from the encryption because the throughput isn’t the problem,
the latency is. And that’s high enough anyway so it doesn’t really matter. So I was told
there is no real, yes, cost of this encryption because otherwise–I mean, performance cost
money especially in that consumer markets so they wouldn’t have done it if it really
cost performance. So apparently no. There’s no real cost of that encryption. Yes.
>>STEIL: Please step to the mic. Thanks.>>With all–with all this data code hiding
inside the CPU, could you tell what it took to actually find the hacks?
>>DOMKE: I knew this question would come up. So given enough time, I think our secret
can be exposed. And it was the same on the system. We don’t really want to disclose how
we initially got the hypervisor code, but it was not leaked and I think it’s not a hack
which can be repeated to something. But it was another hack so you shouldn’t rely on
the fact that something is secret or secure in a system. You should rethink that at some
point, the hacker will know every secret of at least one specific device and the security
should still work if all those things announce. So your coach should be secure even if people
know it. I mean, that’s nothing new. But I think this–the Xbox shows again that this
is an important thing. So, I’m sorry I can’t really answer your question. So, it’s a long
story.>>DOMKE: With all the increased security
in terms of hardware checking, how does that affect the cost of fixing broken parts? So
it seems that if we’ve got these eFuses linked into a DVD drive and the–excuse me–the DVD
drive stops working, how would that affect replacing that part? So, while the actual
DVD key is not encoded in the eFuses, the eFuses encode a key which is then used to
encrypt the so-called keyword which contains basically all the interesting, that the power
console stuff like the DVD key. So, because Microsoft can sign any code they want, they
could just do a binary which was signed and run that to basically dump the internal key
to decrypt then the keyword to encrypt the new one. Actually, it’s just done a bit more
intelligent. The CPU can never leave that CPU, so even while production and even while
upgrades and repair at no point, you need to know the extra key like. Like, there’s
an API to the Hypervisor where you can for example set a new DVD key provided you authenticate
yourself with the challenge which is even another API and the Hypervisor. So, it’s all
based on knowing the right keys. If you know the right private keys, you can authenticate
to the Hypervisor and basically do whatever you want. So, that’s what they do for repairs
and production and development and everything else.
>>Why is that the shader code can create all of memory?
>>DOMKE: And so, your question is why a shader can read and write memory. So, this is a unique
feature, 360 GPU. It actually can do–it has a feature called Memory Export which is–basically,
the 360 is a direct, it’s nine-based platform. So, it doesn’t have those [INDISTINCT] shaders
and stuff. But to have some new feature, they added that’s called Memory Export, which basically
allows a vertex shader–it’s–they’re going to write a data to the memories, so a later
shader can pick up that memory into a second pass over the geometry or something. So, that
was intention to have this Memory Export feature, which is actually just writing an address
to a special GPU registrant and writing the data to a special GPU registrant that would
actually put the data into memory. So, it’s used for multipass geometry and other pixel
shaders if you really want. But we abuse this feature for writing stuff we care about into
memory.>>So, what’s the current state of Homebrew,
how safe it is, and maybe a little bit about the tools that are out there.
>>DOMKE: So, the things is that, Microsoft quickly patched the problem. At first, they
just patch the single instruction, which was wrong, which is that the shift instruction
they patched it to doing just a 32-bit shift, so the other 32 bits are dropped, which fixed
the issue. In later versions, they also improve the memory protection. So now, the threat
data is actually in an encrypted memory, they added an API for this, and they did some other
things. So unfortunately, it’s not so easy to downgrade and up-to-date Xbox 360 to–back
to the vulnerability. It wasn’t–sorry. So, there has been another attack which is called
the Downgrade Attack or the Timing Attack, which is, yes, a bit complicated to explain.
But basically, it allows you to–with some small hardware hack to downgrade an existing
Xbox to an older canon, which has the problem again, so it can be exploited. Unfortunately,
the really recent Xboxes which have the reduced power like the 65-nanometer CPU don’t run
the old canon anymore. This is not an intentional fix or something, this is just because they
also have different GPU version where the old canon doesn’t know anything about. So,
old Xboxes like old hardware can be downgraded using small hardware hack, which basically
involves like some timing measurement and some flash overwrites. We can do a timing
attack on some specific data. And the newer Xboxes cannot be downgraded so there’s going
to be no way to do homebrew on this. The disadvantages of all those methods are, if you downgrade
your canon, you cannot run any recent games anymore, so you are forced to not buy any
games anymore if you to want to do homebrew. So–and you need a separate mission for homebrew
and, yes, that’s a disadvantage of the hack. You have to run the hack every time you boot
your mission because there’s no way to–we haven’t yet found the bark in the boot loader
on the RAM of the CPU or something, which can be used to automatically stop canon every
time you boot. So you–all the time you have to launch that game with the hack shader and
run our code.>>So, the Xbox 360 had a bunch of [INDISTINCT]
it’s just not as stable as the–as the original Xbox was. Do you have any clues on why that
is so or it’s because of the security different?>>DOMKE: I don’t think it’s security related.
I think they had some manufacturing trouble. I don’t know exactly. There was a lot of media
coverage about those issues, and I think nobody except Microsoft have accept numbers on this.
So, I have like 10 Xboxes at home and not a single one of them failed, so the number
is telling you that 30% or more of those are failing. They are just not true, at least
for me. I’m not sure about the greater amount of Xboxes, but it is a problem. I’m not sure
how large the problem really is, but I don’t think it’s related to security. It seems to
be related to some thermal stressing of the GPU actually. I’m not a hardware designer
so I don’t know exactly. And it took Microsoft a long time to get a real fix for this, so
it seems to be a harder problem than it–yes, than it would seem after the first side, so.
Okay. Thank you for listening.

Leave a Reply

Your email address will not be published. Required fields are marked *