Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/44 Thanks!
OK, everyone, welcome to this next
talk console hacking 2013
by Sven Marchin and
Comics'.
Please give a warm round of applause to
our speakers.
All right, good evening and
thanks for attending this talk.
So as already mentioned, I'm certain of
that that's comics and that's Mark here.
And we'll be talking about
that with you.
That's with you. For those of you who've
never seen, it
was released last year in November.
And we bought it on the launch date
and it pretty much took us around a month
to break most of the security apart.
And that's essentially what we'll be
presenting right now
are some of you may know the
Wii U is pretty much just an upgrade from
its previous console, the Wii, which
was released all the way back in 2006.
The Wii itself was also just an update of
the Game Cube released even earlier.
We we we all have also
been working on the Wii itself back then
with called team tweezers.
And what a pretty good run.
A pretty good run on the Web itself, and
because the security architecture mostly
stayed the same.
I'll be giving a very brief introduction
about how the Weebles was broken
arm for those of you who are more
interested in the war itself.
There's a talk at the 25
three called We Fail, which
explains a lot more detail.
So the first thing we did back then,
estimate reserves, was that we used the
Game Cube compatability amount.
We could only see a fraction of the rim.
Then we used a pair of tweezers directly
on the to bridge if you Etta's lines and
move that frame around to be able to dump
code that was left over from our full
remote.
And back then probably is
probably the most prominent was
that they used a string
comparison function to compare
binary hash and all of that signature
verifications,
thus rendering them completely useless.
And what we did in the end was
we built our own custom game like
channel on the we called the Homebrew
Channel, which is pretty much
the most famous launcher used on the we
installed on their own 5.2 million
wheels.
And we later ported over to.
And when they departed over to the
backwards compatibility mode and that we,
you and I, we have around 20 of 27000
installs as well.
And yeah, so we had a pretty,
really good run of the week.
Let's see if we can do that on the way
up. Well,
just a quick introduction. How do we look
like it has a PowerPC processor
running at around seven seven hundred
thirty megahertz, its code
name to Broadway.
And on top of that, it also has that
whole system on a chip that contains
the rest of the hardware.
And that thing was code named Hollywood.
I'm in there. There's the memory
controller. So you get 64 megabytes
of RAM, 24 megabytes
of really, really fast ram.
And there's the old GPU called the Jex,
which is just a custom fixed function
repu that was also used back in the Game
Cube.
And on top of that, they have a second
code processor in their arm, which
is an arm which is based on the
architecture and does all the security.
We nicknamed that one Starlite, because
it's part of Hollywood.
All right, so that's all that we look
like. Let's take a look at what they've
changed for the way you
are most in all, the most important
changes are marked in red.
As you can see, the PowerPC processor is
now called Espresso.
And instead of just containing one car,
it now has three cars it can use.
All of them have an individual to cash.
One of them has a larva and L2
cushion the other two on top of that.
They also up the clock
frequency to around one point two
gigahertz.
Then they edit the
game out of the way, you the one the you
saw on the first slide, it looks like a
console itself has its own screen and
so on.
And if you interested in that army,
there's another talk on day three done
by Dell.
That thing is called the DARPA H.
They're still the ultra deepu in their
arm, but that one's only used for
backwards compatibility reasons
and the memory can be repurposed as some
really fast on
general purpose as well.
And this time the system
on on the ship is called the Latza
because they want to stick with the whole
coffee theme and that's why we nickname
the security process at the Starbucks.
I know that it's talked about the
hardware, there's also the software side.
There's also the softer side of
the games running on the Broadway are
running on the Bamidele, and
there's no operating system, absolutely
nothing except for the game itself.
So there's no shared libraries,
no linking, no memory protection,
nothing. It's really just take
the executive out of the game, put it
into memory and run it
on the Wii U. They learned a little bit
from there from the past, and
they are running a custom cafe OS
on the PowerPC.
It does real process
separation, memory, management,
privilege, separation and so on.
So it's really their own custom custom
operating system running on their doing
its own part of the security.
Arm now on the we
the security was all done on this arm
that it was running iOS,
which was also a custom micro kernel only
related to security, cryptography and
various hardware.
This is still true for the Wii U.
So they have two parts that are taking
care of the security.
And but it's significant.
It's significantly changed.
It's been completely rewritten.
It's a lot larger.
And we've just called it called it you
because it's still performing most of the
same same tasks as the original
one.
Then games and software can be loaded
either from the disk, from a disk, you
insert the console or from an integrated
NAND flash.
But RSA signatures were
only checked when you installed a
title on your intent on your NAND flash.
If it was later on, there was no
signature signature verification
performed whatsoever.
So as soon as you gained some,
as soon as you gained the ability to
modify the NAND file system, you are
able to run your own custom code and
actually get a persistency as well.
Across reboots again
on the Wii U, they learn from this.
They are at an EMC storage for user
software and games as well.
But this time whenever you launch
an application, it will be signature
checked. So you can't just put something
on the file system and get away with
it. Are the IRS
you running on this topic will catch you
doing that?
One interesting thing about this is
the reason I've been talking about the
war so much is that the new
features fully backwards compatibility.
So if you buy any game, you can plug it
into Yueyue and it will run it.
And this is done.
We call this because come to
belittlement, the virtual WI.
And the interesting thing is that we have
the software called the impersonator,
which all it does is it pretends to
be a we connect it to Nintendos update
service and tries to get the latest
software version, download them, install
them on your computer.
And we ran we ran this
even before the launch and figured out
that there's a new console type there,
which was the backwards compatibility
remote.
And, well, we couldn't decrypt any
of the data that was downloaded because
they changed all the keys around.
We could see that the hashes of certain
files still stayed the same.
This was what you see in the bottom
there, like Info's or 0002
is already in cash.
So this means that we
backwards compatibility mode is
not emulated or anything like that.
It's actually sandbox.
So it's so they turn just turn off all
the new hardware, then
switch back to weemote and it's running
mostly the same software.
That's been a few tweaks here and there.
But we have the code for all of this.
And iOS was also
kind of like a Swiss cheese.
So if you just looked at any kind of
function, you would probably find
exploitable exportable back in there.
So we could just use one of those old
things to break
into the virtual we into the virtual.
We
just understand at which point we break
in. Here's how the we looked like.
So you had the starlit the security
code processor, which would boot from
zero. That's an environment which can
never be changed.
It would to run
and verify the SHA one against
an ash start and fuzes,
but one would then perform a full RSA
signature verification on Bhuto, which
would later train lotuses.
The system in your iOS and
only at that point is the
PowerPC enabled.
Before that, the Broadway, which is the
PowerPC arm, was pulled and reset.
So until then, the system in your boots
and it just from some hot reset jumps to
the system and you then the system
anyway, which is like your default
homescreen arm of
the user, maybe clicks on on some game he
wants to play and then
I will reload to the one required
for that game and the Parvizi will be
reset again.
So all the handling is all done on the
arm CPU.
The power is really only running the
games itself.
And since we're in the virtual we
expected this to be mostly the same,
the only thing we didn't know is how the
system eventually ends up running.
We just know that it does end up running
and they're still the hot reset happening
if the system in your boots.
But there's been a small change
because if you do a game, it will
not be put it directly.
It will first shoot a different type of
ferment, which then trainloads the game.
So this is all because
it should be working mostly the same.
But as it turns out, if we try to get the
popular with our old code, we
never get code execution, so we
use that old thing, we did find it to the
right memory location, but nothing
happens
then. If you take at the binaries that
are launched by the new virtual
iOS, they seem to be encrypted.
And.
There are also two new encrypted binaries
with which other special end loaders
and they can be booted directly, there's
no decryption happening in iOS
or anything. It really fits those
encrypted binaries to the PowerPC.
And just a little bit of experimentation
by trying to load those binaries,
changing bits here and there, we figured
out that the espresso, which
is the PowerPC with three now, will only
boot if you feed an encrypted
and signed binary.
So they add an additional layer of
security there. You can't just take over
the privacy. As soon as you own the arm,
the arm processor, you still have to
figure out a way how you can get in
there.
But this means that there has to be some
kind of code running on the property that
does all this, so there's an additional
goodrum and additional
Bucaram on there, because this Firmat
for the binaries is new and the princess
is always in another castle and we call
them the uncomfort Imagists.
So you just what I just mentioned checks,
how the process works, it checks if the
target had the system and if it is
encrypted one from the end, if it isn't,
it will be proxy through those new
special encrypted titles.
Yes, so this is how that how the chain of
trustable actually looks like
there's an additional step for the bajram
in their.
And right, so there's
an additional step for the Buderim,
everything has to go through their.
But what we can do, no, we can break
into iOS using one of those old parts,
we still head around from the days
and then we can just sit there, we can
read all the memory.
The ARM processor has access to the same
memory as the power PC.
So we can check what's happening while
the Buderim is running because the arm
will be running at the same time.
The first thing we noticed was that the
signature and hash of the image is
verified before it's being decrypted,
which makes sense.
On top of that, the image decrypted in
place from the beginning to the end
have sort of memory at first, the first
block will change into the second one,
the third one and so on until they reach
the last one.
And there's a third thing that's a little
bit odd, because just before the entry
point of your encrypted image, an
additional PowerPC instruction will
appear as the very last thing before
your code is running.
But this means that
if we can observe from the army,
we can also try to see what happens if we
try to override some kind of memory
while the Buderim is running to trick it
in doing something else.
Again, the Buttram and verifies or NKE
image decrypts the image
and then it jumps to the decrypted image.
So if you take a look
at that decrypted image, for example, I
just dumping memory, you
will see that the very beginning turns
back the espresso into broderie
compatability mode.
So the Buderim is running in full
espersen mode.
If you reset the power of for a hotter
set, it will start as an espresso,
then the boot from run and it will run
the heat and then loader, which
will only at that point downgrade the
whole thing to what it used to be on the
we.
And decrypting an image
takes quite some time because as isn't
really insanely fast algorithm, and this
is to minutos a few megabytes large.
So what you can do is you can raise it.
So you reset the prophecy and wait
until the very first instruction has been
decrypted, so you just have a very tight
loop that's shaking. Is it still the
same? Is still the same.
Still the same. As soon as it changes
you. Right. The decrypted instruction
with your own code.
And the very first block is never
verified again by the room, just
verifies the whole thing at the
beginning.
So this is a classic time of
trick to time of use.
The result is overwrite the
first instruction, so that means you're
an unsigned code and on top
of that, you're still in virtual remote.
So it should be a Broadwood, but it isn't
yet. It's still a full espresso
processor.
Because the downturn is only happening,
Nater overrode that, and
if you're an espresso moed, you can still
you can just bring up the two additional
PowerPC first and use them.
Now, what this means, this isn't even
exploit, this is a complete design flaw
because the boot from is running on one
processor and it has absolutely
no way of telling what that other
processor that can be perfectly used as a
glitching device is doing.
As I mentioned, you can just reduce the
drum to as an article to decrypt
binaries, because all you do is
you're on it. Wait until the last block
is decrypted.
Reset the whole PowerPC again and the
injunct just a memory.
You get your full decrypted binaries
and implosive on a silver platter for
you.
So the Buderim is mostly pointless,
it doesn't prevent you from
enabling the course, it doesn't
hide any kind of code you shouldn't be
seeing.
It's just a minor annoyance.
It's nothing you there's
no reason that it is there at this point
or we can't get to human binaries,
but we don't have them anyway at this
point.
Obviously, it's no fun if we stop here
because we know there is a Buderim, so we
want to dump that thing.
Yeah, let's just dump it anyway.
The problem is that rebooting is really
annoying on you because you boot it up.
It takes like a man.
They are. Then you click on the virtual.
It takes another minute and so on and so
on and so on.
And every time you make a single mistake,
which is bound to happen when you're
trying to make something, this can really
add up a lot of time.
So we've been
we've been trying to build a remote agent
from the PC, which which which
is what we're always doing when we're
making some kind of šemeta device.
So what this really is, you build a
serial park between the console and your
computer so that you can send
our PC commands from some Python script
over the serial port to the console so
you can really interactively Hector
console directly from your computer
without having to compile a binary and
reboot that thing over and over and over
again.
This is pretty much this is really nice
because it cuts down your whole
development time.
But there's a small problem because we
can't communicate yet.
You have no serious part on the way, we
could just use the memory cards used to
be just a spy of us so we could just,
you know, just plug in some custom
hardware. And we had a full serial port.
But those are gone now.
So we started with something we call old
Serial.
I mean, the picture pretty much shows
what it is you can turn on and off the
cereal, the sensabaugh,
which is just a bunch of infrared, let's
you can turn them on and off from from
Archerd so you can just bang cereal
over that power line.
It's really slow.
It's only an output, but
it's good enough for you.
Very early print debugging.
Let's take this a step further with
this really awesome thing called get to
HCI.
So this is a really, really questionable
LGC stick, essentially
subparts one single entity idea
that should already be in when it's
running and otherwise it will just
completely fail.
It can also only send one type of
messages, but.
To get bidirectional ironworking,
you don't even need to open your console,
you just plug it into the USB port.
Hook it up to another FBI agent.
Put that up to your computer and you have
to see the console.
But that's still slow.
And even worse, we didn't even open up
our console yet.
Oh, apparently it's mostly still intact.
So let's let's use are our final
solution, which is the echo,
and that's the one we're still using
today, I'm the U.S.
gecko as an old device that we use.
And the way you could plug it into the
memory card slot this time,
we just found some random guy on the
main board.
And we're now banging the Wiess memory
card protocol over those
Jipé also that we can reduce the old
hardware to get a really,
really Fostoria console.
And most importantly, the warranty is
finally wide.
As I mentioned, we want to dump that
Boudreau, and this is why we did the
whole thing with the serial consoles, and
I also mentioned that one instructions
that appears just before the decrypted
code.
And for those of you who are not familiar
with you, see this.
This is a move to special purpose,
register instruction and
a special purpose register.
It makes a lot of sense to contain a bit
to disable the Buderim.
So our hypothesis is, which later turned
out to be true, that this single
instruction there will disable the boot
from.
So can we just use the same approach we
used to get to
get the PowerPC and Express emote?
Can we use the same approach to dump the
boot from.
Turns out that that certainly doesn't
work because no matter how hard we try,
how hard we try to race there on the
periphery, we will always execute the
original instruction.
We even wrote a very tight and assembled
assembly loop and it still would just
still disable the boot from where they
were. It turns out there was absolutely
nothing we could do at this point
anyway,
because in order to understand why this
didn't work, we're going to cheat a
little bit and explain what the
Buderim is doing first and then how we
managed to dump it.
And that's Merkins part.
OK, so I'm going to take you through a
Buttram, walk through the Woodrum
does some really interesting tricks with
memory management and cash management,
and it's almost a little piece of art
the way it does things.
So this is going to touch into the
intricate details of PowerPC caches
and PowerPC memory management.
So hold on to the right.
This is going to be interesting.
So we're interested in
looking at mostly memory management.
So we're going to have four columns
here. We're going to look at different
parts of memory, different addresses,
what the data is in REM, the physical ram
chips, what the data is
in the CPU is able L2 cash, which may or
may not be the same as RAM because the
Wii U is not a coherent system.
So there may be times when
these two do not match and then
the CPU has two operating modes.
It can operate in real mode where virtual
addresses and correspond to physical
addresses. So there's no address
translation.
Or it can operate in translated mode,
which is when the memory management unit
is turned on and there can
be arbitrary mappings between
where the addresses that the code uses
and the addresses and physical memory.
So let's set the stage first.
We start up with the binary image
or the system menu or whatever the
uncashed images at that address,
there is zero one three three four
and we have often zero as the header
for that. And also text 100
is the start of the ciphertext.
We're also interested in ages zero
because that's where the PARP is the
exception vectors are.
It's also with the reset the vector is.
So let's look at what happens there.
But to start with, there's nothing really
in that area of memory.
So first we hard reset the PowerPC
and it comes up in real mode like
every other possibility.
And the first thing that we noticed is
that in real mode, the Parvizi is
executing the butcher, not memory.
The Buttram is built into the espresso
and it overlays memory at zero.
So whenever it fetches instructions,
it'll do so from the buttram.
There's no amamou set up yet, so there's
no translated mode. The catches are off.
So it's pretty simple.
And you can also see how the
system menu encrypted blob with the
youngest blob maps to reload.
The first thing the Buderim does is it
clears the menu of the caches, the
registers, you know, it wipes everything
to get a nice, clean slate.
Nothing interesting there.
And then it maps itself.
It maps the Buttram using
a PowerPC feature called The Block
Address. Translation The PowerPC
has a memory management unit and it can
either map things using the
usual page tables, which can do complex
mappings.
But it has a very simple memory mapping
feature. The blockaders translation
is just a bunch of registers.
Let's say, you know, take a big block of
memory here, map it to a big block of
memory there. It's really stupid.
It's really easy.
So it maps itself to translated mode with
this feature of of the of the espresso.
It also maps to other
sections. It maps address to
zero zero zero zero to that one
sixty address there, which is in
the middle of room.
You know, there's nothing special about
it. I don't know why they picked that.
And there doesn't seem to be a reason for
it to map this. But it does.
We'll see in a second why.
And it also maps E zero zero zero
BARBELLA to the same
location. And that's not even physical
memory. Like that's an invalid address.
So that makes no sense.
But we'll see what happens
then. It switches to translate it notes
and it's running in translated mode,
still running the ROM and
this is what enables the caches.
Now, you'll notice the really interesting
thing here is the ultra cache
column is now clear because that's
initialized and empty, but in real
mode. Certainly we get the reset vector
instead of the Buttram.
So we're leaking main rame
from, you know, the actual ram
chips to real mode.
The reason for this is because the
butcher from a special it only
works when you perform uncashed memory
accesses. So if there's a cache in the
way you don't see the BAJRAM anymore
and the reason why it works and translate
that mode is because when it set up this
bad mapping, it did so with caching
inhibitor. There's a bit of the Ibbett
and that forces it to keep using the key,
bypassing the caches for the Buttram,
but in real mode.
Now we're back to main memory.
It also enables a feature of the espresso
that goes way back to the Game Cube days
called the locked L1 cache.
The old one Casaus thirty two kilobytes
put it down the middle and it sets up
sixteen kilobytes as dedicated on chip
memory that only it can see it's
only useful for data.
So it now has 60 kilobytes of private
room mapped out.
This is a zero thing which explains that
now the next thing it does is it sets up
exception vectors that just infinite loop
and memory and uses a temporary
mapping for this. And the reason for this
is that in case something happens
and it ends up executing an exception
vector and ram, it doesn't want to
follow through and execute code from a
random place and run.
So it just sets up instructions that jump
to themselves at that address.
And it's an infinite loop.
So now, up until this point, the buttram
is running with no stock, no nothing,
it's all hardcoded assembly, really
low level stuff.
None of it has memory that it can use
privately. It sets up a stack.
Copies of its data sections, gets
prepared to run real code.
But before this, it copies itself.
And the reason why it does this is
because the boogeyman now is running in
uncashed mode, because it has to be
uncashed, but it's a crappy,
slow buttram that is, you know,
very far removed from because
you don't want to be running crypto code
from a crappy slow memory, a terrible.
So it makes it a copy to this
address, you know, two zero zero zero
zero. And you're thinking, well, that's
going to copy the budget around, but
it doesn't, because when it copies itself
to that address, it mostly ends up in the
L1 cache because the cache,
of course, will try to cache values
before getting them addicted to memory.
Then it uses a really neat trick to
flush that one cash into the L
to cash it, basically just write a bunch
of garbage. The other one is guaranteed
to evict all the cash lines, send
all that data over to be able to cash.
But it can't just flush it with a normal
flush instruction because then it would
all ram and you don't want the goodrum to
end up in RAM.
So it's using this really hacky trick
to keep itself from going to RAM while
using the L2 cache as memory, which is
not designed to be used as memory.
And then it just jumps to this new
location and that's what starts doing the
main execution, it copies the
attacks from the secret
futures are up to the
private memory.
It disables those keys to make sure
nobody ever gets access to them again.
It will hash and decrypt the
image.
And the really interesting thing here is
that it can't just
read it because it would end up using the
L2 cache. So it goes back to another
feature of the Game Cube
where it can as a DMA engine
that can copy data straight from external
memory into and back out of its
locked L1 cache without
doing anything else, without going
through the ultra cache or anything.
So it's moving data
between, you know, that Red Square there
and on the bottom right corner
where there is a DMA buffer.
So it it does
that with a header. It takes that
signature, then it hashes and decrypt the
ciphertext. And it's doing this by ping
pong data through the locked L1 cache,
bypassing everything else.
So I jumped back to the boardroom, it's
done, you know, presumably the hashtag
succeeded so it doesn't looks up
and now that everything is ready, you can
clean up.
It jumps back to the boardroom not to
copy.
It wipes this section where it was
keeping its own copy of the of the code.
It makes sure that gets wiped in 02 to
it wipes its data in
one, cache it
on maps. All of this.
It's just undoing basically the start up
process and finally it
finally maps the payload.
So up until this point, the
ciphertext were plaintext section wasn't
even mapped in translated mode.
So you couldn't see it except through the
DMA system.
But now it's mapped
and the next thing it does is that
disables and invalidates the one and L2
caches.
So now they're are other data that used
to be that is completely gone
and that when it writes this special
Bajram disable instruction, it writes
that that makes it through to the L2
cache and it flushes it to make sure it
makes it up to run.
It jumps there and the media to
the point where it hits the construction,
the butcher is disabled permanently
and it starts running the the payload
code. And this is why you can see why
overwriting this instruction in RAM did
not work, because even if you override
this instruction in RAM, it's still in
the air to catch the brainteasers, not in
the ultimate cache, because we made that.
So if you raise it there, you can gain
execution. But that one instruction at
F.C. is in the cache.
It doesn't matter what you put in RAM, it
still runs the disabling instruction.
So this is really clever and it actually
writes it and reads it and verifies it,
makes damn sure it's in the ultimate
cache.
So this is a really clever trick.
I mean, this it's kind of a horrible
hack, but in a way, it's really cute
execution.
It keeps the ROM isolated,
but there's a whole
the PowerPC has to external reset lines
when it's called reset, which does a full
hard reset that the chip runs the Buderim
again. You know, it's like starting from
scratch. The other one is this reset,
which is a soft reset.
Basically, this is really just an
unmistakable interrupt.
It just makes it Parvizi take an
exception to its reset vector.
But it doesn't really clear anything.
It doesn't re-enable anything.
Both of these are controlled by the
Starbuck. They're just bits and register.
We can turn on and off to bootstrap
the part B, C, there's separate bits.
So we come to the reset.
What happens if we assert as reset,
if we reset the PowerPC the espresso
while the BAJRAM is running?
Well, if you just pick a random point,
let's say when it's hashing and
decrypting the ciphertext, we
sort of reset whenever it takes an
exception.
Whenever you get an interrupt or in this
case, a soft reset, it switches back to
real mode. But it's got this annoying
infinite loop instruction there.
So all that's going to happen is it's
going to get stopping an infinite loop.
Even if we change REM, we
jump to our own hoshko, to our own
dumper, whatever.
It's still in the cache.
So we have the same problem.
It's still going to get stuck in an
infinite loop no matter what we do to
run.
But what happens if we wait a little bit?
So at some point, the goodrum is
disabling and validating and enabling the
one Enel to catch us.
So at this point, the L2 cash
is empty.
If we change RAM to jump to our dumper
code, suddenly that's visible in real
mode now because the cache doesn't have
the data anymore.
Then we assert, as we said,
and then the part B C jumps to our code.
And since the Buderim is still mapped, we
can just read it.
So this happened eight days after
the release, by the way, unfortunately,
it's too late to get the keys other
European release just to make sure I'm on
the same page. But it's too late to get
the keys because the OTP is already
disabled. The lotto one is already wiped.
Keys are gone. We want the keys.
So let's look at the other recent line.
It's called Reset.
It resets the whole espresso, it restarts
Buttram execution.
It's reset this level sensitive.
So you bring it low to get, you
know, start resetting the part.
See, it does whatever it needs
to clear, you know, create internal state
registers, all that fun, top level
design stuff that I know nothing about.
And then you release it to begin
execution the
data sheet for the PowerPC 750 S.L,
which is really close to the Broadway
used on the we and presumably close
enough to your espresso, says that
that must be held low for at least 255
bust cycles.
What happens if we try narrower pulses?
So the Starbuck runs out the clock rate
coincidentally, and it can control its
reset with single cycle accuracy?
Because we are not on our nine one
cycle, you can make a little timing loop.
So we fill all the round with jump start
dumping code just to make sure that if
anything weird happens, hopefully
it goes to where we want to
remember we're doing this python thing
from a PC. We don't want to be timing
reset from a Python script.
So we upload a little snippet of code
to do a really accurate cycle level
reset timing and say, well, interrupts
all that fun stuff.
Then we start the PowerPC normally
just to make sure it's into the same
state and then we reset
it right in the middle of the Buttram
doesn't actually matter that much where
we try different widths for use.
Let's see what happens.
And we hope that some at some point
something will blow up, it'll screw
up and it'll end up jumping some more in
Rowman run our code
and then something will happen,
hopefully, and then we get profit.
So what happened?
Well, the Barbaresi crashes, if we
do a very short period
for a very long period that restarts
normally, if around the middle
it just fails and deadlocks.
But for one of two specific person
widths, really weird stuff happens.
And what's vary from unit to unit, it's
an analog thing.
It seems to be running our code because
we got some response from our dumper.
But let's let's look at a cat version
of the PowerPC.
So it's running, it's running, but
something's screwed up real bad, it's
skipping instructions sometimes it
doesn't issue, writes the memory like
we're dumping stuff and there's stuff
missing in the dump.
And it's like they have to search for
offsets. And some of the values are
weird. It looks like some functional
units in the core are totally fucked up.
I have no idea what's going on, but it's
really fun. It's running our code.
But drugs is good enough
because all we have to do is read each
key word and write it to memory four
times and cross our fingers.
And then you're going to have that one.
That one. That one.
That one.
And we have keys.
So that was 11 days after the
release, and that's a hash that we posted
as a hash of linked file, which
has the hash of the keys, because we must
go deeper.
So this person was found in virtually no
time for the Starbucks and we unmowed
that we started Cats' Boonsboro, which
is this Boutcher on that? Boutte's the we
the virtual he doesn't have a zero
because it runs from Weemote.
How does we unmowed?
But we have no idea.
We can't find out from Virgil Weemote
or Canwe
so on the web browser was mapped to that
address. It gets disabled by Boota.
Not good one for some reason by writing
to a register, not register is
not clear. Only you can, you can
re-enable that register.
Probably see where this is going.
It still exists in V Weemote for
compatibility you know, because I was two
years old and all that stuff.
What happens if you said the enabled.
But again
I wildwoods zero.
It does not look like the Web zero.
I don't even know what the hell they were
thinking.
This is just ridiculous.
It just shows up.
And we found this out 14 days because we
didn't think they'd be that stupid.
So that's the house we posted.
The we you, Butros, much more interesting
than the wee one. It does real signature
checks. It supports booting a recovery
image because the WI was notoriously
breakable and they just throw away
motherboards and put new ones in when
they break them. There were no recovery
mechanism, but unfortunately,
we haven't found an exploitable bug in
Boonsboro,
at least yet. So this is all we have for
every weemote.
Now, let's look at Wii U mode
and about hand it over to comics or that.
According to the paper that just got
pulled up, it doesn't seem
we're getting the full hour here and
let's try to hurry here.
So how to postpone
we human soul for a virtual we mode?
There was a lot of reference to go on.
There was all the old software and
we could see how it changed.
There's the there's the hardware,
all of that.
But that was
only able to go so far.
So in order to open
a new mode, we had to do it
just like any other console.
That is by treating it as a
black box.
So how how do you have
any embedded device?
Well, any large
embedded device with the user interface,
that's vaguely modern? Well, you go after
the Web browser because
just about.
You know, just about just about
everything uses Web kit, Web kit is
legal, they have to provide the source.
You can go get the source.
It's not like we care very much usually
about what's actually in the source.
It's usually almost identical to the
some version of this van.
But we can look at the changelog and see,
well, how old is this?
And because Web kit
has vulnerabilities fixed constantly.
So if it's old and four embedded
devices often is,
we have a huge menu to select from.
So the last changelog
entry from the open source version of
Web kit.
As for the release that was
current last year at the end of 2012
is from 2011
October. So it's a year out of date
theory. There should be a lot of
vulnerabilities.
So how do we actually find these old
bugs? A lot of them are reported, but
they're also kept secret,
in fact.
Well, with some other projects, once
the bugs are old enough,
they get protected.
The public can view them.
Web kit, that doesn't seem to happen.
It's still all those old bugs are still
restricted.
But the bug numbers are mentioned
in Svenne comments
with unit tests for what used to crash.
Oh, what do I do?
I prefer to be oh,
no, you know,
OK, so all we have to do is
grab the SUV and log for bugs
and we try to view all these bugs and the
bug tracker and which ones are we not
authorized to see? Those are the
interesting ones,
not a new idea. A lot of people are doing
this, but it's the first time I've
done it.
So tuned in to credit they did recently.
A few months ago, they updated Web
to a version as of late 2012.
So now it's now it's well, it's about
the same amount of data as it used to be.
Now, that doesn't mean that exploitation
is necessarily easy, because
we don't have there are a lot
of things we don't have. We don't have
crash logs, for one thing, some with some
platforms. In fact, a surprising number
does give you the cross leg and
then you can sort of see what's going on.
We don't have that
structure and vegetable layout.
We don't really know anything about the
compiler.
We might be able to find out.
And there's some amount that you can get
from the source code, but it's still
limited. Like if you have a use after
free, you're often going to want to
overlap the one V table
with another and like the wrong function
will be called. But we don't really know
what's going to happen there.
We don't know about the allocator.
So for use after free.
That the behavior of the heap depends
on the precise algorithms used by the
allocator, but we don't know about
that.
So although it's certainly possible,
I mean, once
once they used an old
Web conversion, they pretty much Nintendo
pretty much guaranteed that we were going
to get code execution this way
eventually. And you could consider
this a serious
flaw.
I mean, a serious
lapse in security, even if Web kid
is going to be vulnerabilities
eventually. But by making it easy to find
old vulnerabilities, you're pretty much
guaranteeing that code execution
is going to be achieved
pretty soon.
Now in a good, well designed security
system, whether the Wii U counts is
debatable, but there's many
layers of security and just compromising
the Web browser isn't going to give you
that much, but still going to give you
infinitely more than just poking
at the user interface.
So you really should try to make this as
hard as possible.
And they didn't.
But anyway, I was saying
there are many bugs to choose from and
there are plenty of hard use after fees
and overflows and all this.
But I found a nice heap overflow that let
me override a pointer to
an array buffer view or something and
then let me specify an arbitrary address
and I could dump memory.
And then we got to look at
the Cafe OS and IDA
and Giant database found because Ida
has giant database files
and allemande.
It was a dump of all the modules loaded
into memory at the time.
So how is it compared to the old WI
OS? Well, this has been partially covered
earlier, as I said,
no longer running on bare metal on the
PowerPC.
This is it's running under a kernel.
This is necessary for one thing, for
processor isolation that we can actually
run multiple things, multiple
applications like you can run the Web
browser while a game is on.
Another reason to do this is that there
is kernel enforced, no execute or
data execution prevention.
So on the we everything was just read,
write, execute on the we, you
not only is
non code not executable,
you can jump to it, but the kernel
enforces that. So you can't just say,
hey, here's some memory, I want to
protect it. Proteaceae.
No, it won't let you do that
with a special exception for the Web
browser.
This interesting policy
is shared with the iPhone,
it is this way because Web browsers
need git's to run fast and
for you need to run code.
And so there needs to be a way to do
that.
But it's somewhat paradoxical.
So downsides
or missing things?
No, ASALA, it's 2012
was when he was released and there's no
asala.
There are also lots of bugs
on a cursory examination.
It seems to be there are a lot there
turned out to be a lot of bugs in various
levels. The operating system, they this
isn't exactly a security measure like
some kind of mitigation, but it means
that it wasn't carefully audited
and that could be considered very
important mitigation.
So in general, this reminds
me of like last generation
of consoles, like the Wii U is in some
other ways, like the PS3 also
had no execute and it had
no arsala.
But I think
that the newer ones are better on that.
So unfortunately not
this one. So another interesting
feature, not exactly a security measure,
but as
previously mentioned, the
Cafe OS uses dynamic linking
for everything
that we use to static, linking up
everything, the whole SDK into every
game, plug it into memory.
This feels more like a real system.
In fact, it almost uses lf the
the the binaries look like elfs,
except there are some gratuitous
differences, like the sections
are compressed with some custom thing in
the simple tables are all different and
it's changed to be sort of more like the
windows linking model for some reason.
And it's all different, but
it's close enough.
So I guess they get credit for that.
So the benefits are function,
names are visible for reverse
engineering with the weed, there is some
leaks of function names and some weird
cases, like some symbol map going onto a
disk once and but
those were closed and those were out of
date for the week.
There just always going to be function
names visible, always useful whenever you
need them, separated,
functionally separated by library.
So you can sort of see what does what
and if this is a bit of a historical
note. But I'll be quick lib
for the way there was eventually
a port of Linux.
But since that didn't run very
well, since there wasn't very much memory
on the weekend, most people
just use Libonati, which is a custom
library, which sort of did the same thing
as the STK. But unfortunately, it didn't
only do the same thing as the K,
it meant many of the functions were just
lifted straight from the SDK, like
manually translated from assembly to C,
and there are eventually worries that
this would be a copyright violation.
It's hard because you have these random
register rights.
You can try to figure out what they can
do, what they actually do, and maybe
have some nice functionality or you can
just copy them and there are a lot of
them anyway.
This avoids the need for that
anyway.
So while
Marken was doing all the stuff with
reset that he mentioned,
because once he got the keys,
it was possible the keys he dumped
included both the virtual we in the new
mode keys for the PowerPC.
So since it was pretty
easy to end up reading data
from the file system, that meant that I
would have been able to use that
potentially to get
to decrypt the PowerPC kernel
and be able to see what's in it
and find vulnerabilities, white box
or than black box.
But I didn't know this was going to
succeed if it hadn't been done.
So I decided
to try to dump it
with a blind exploitation.
So, you know, pretty basic stuff.
I tried to pass a bunch of test calls,
the take addresses and do something with
them. Memory addresses.
I tried to pass invalid addresses and see
what they do.
Most of them, they just returned errors
or did something predictable.
One of them froze
some Andres's works that were not
accessible normally and
basically it was a
straight read from the colonel, took the
pointer and read it without doing any
kind of check, printed it to a
log. You could get the log with some
other way to do it.
So I printed one bite at a time,
check the log, and very slowly dumped
whatever kind of data from Colonel Space
than I wanted.
But data and context,
no matter where I tried and I
could not get any text.
And there's a reason for that.
As previously mentioned, there's both
stables and blockaders translation, but
interestingly,
the bat registers are completely separate
for instruction and data.
They're just separate registers.
This is use of one thing.
It's usually used to implement or execute
for these memory because
you can just put it in a data bat, but
not an instruction bat, and then
it'll only be able to read it with the
data fetch.
But the colonel did the opposite.
It only mapped it in instruction based
not on a date about.
So if you try to read from this memory
with some load instruction, it won't do
anything.
That means you can't have any data in
text, which a lot of
other systems use for various things.
But it means that it's pretty interesting
security measure because you can still
run it fine. You just can't dump it
on. The one thing is that I'm not quite
sure whether it was intended as security
or just because they were running out of
bat registers, but.
Well, that wasn't enough, though, it was
nice, but eventually I was able to
find a way to write data and then I was
able to do some DMA thing to dump
the the kernel
and get all this nice stuff
in order.
This was useful for a few hours, I think
about that. And then Markand showed up on
Aracy saying, oh, I got the key and
then the whole thing became useless, but
well it was fun.
All right. So quickly about iOS, which
as you mentioned, is running on the arm
processor, which incidentally
makes it automatically five times easier
to reverse engineer because x rays works
on ARM.
I'm not sure whether that's a good thing
or a bad thing.
So I tried to blindly
exploit the IO as usual.
And I always exposes like it did on the
we as sort of active
Unix like interface with like IO
control calls and something like
that. Um, I
managed to do something.
I got some romp fun
stuff. From there.
I tried to exploit a different module
that was only accessible from that
from within iOS.
And then I did some
random call to some
IO control in the crypto module
and then we wouldn't turn on.
You know,
I wasn't expecting that it was
stay away from like NAND
writing any kind of that, but
just oops.
Giesbrecht sorry.
So I had to sit out
for a while, but
still I borrowed someone else's WiiU and
promised very much not to try
anything like that again.
But eventually I
was able to exploit the colonel
and once we got code running
in the Iowas colonel, we were able to
dump the OTP or almost all of
it, which contains a bunch of different
things, including the common key, which
is the key needed to decrypt what you can
download from the Internet
into what goes
on the file system.
So now there's no need to like
anything on the PowerPC or anything.
It's not separately encrypted.
You can just download it
and also the virtual WI because
all the updating and downloading for the
virtual we actually happens and we human
and the Starbuck
and Kasky.
So that's pretty
much everything except for one
thing.
So there's one thing missing here,
so we mentioned that the OTP, we want to
donate most of the OTP, but not all.
There is a booth, one encryption key used
by Booth Zero to decrypt booth, one
that's disabled permanently separately
early in the booth process.
And there's no way to get it back.
We haven't found a way to get this key
yet. So we're trying some really cool
stuff, some side channel attacks.
Expect to hear from us if we are
successful, but so far we don't
have it.
What about other approaches we don't care
about? We use software.
All we want is access to the hardware for
homebrew.
So the question is, can we escape the
virtual sandbox and go back and enable
WiiU hardware so we can use it?
So this takes us to cafe to Week Cafe to
we as the name of the we use Tarbuck code
that switches to virtual remote.
It contains interesting low level code.
It's really cool because it doesn't
have iOS, it doesn't have a kernel, it's
just low level code.
It has all the modules it needs.
It's, you know, very dense and useful
information and code to reverse engineer
instead of a bunch of, like, system
called crap that we don't care about.
It tells us what we have to undo to go
from virtual we mode to you mode.
And now that we have the keys, the
We, You and Kasky and the Tucumán key,
we can just download it and decrypted.
But Nintendo had a holiday gift for us
last year when we did
this and gave it to me as an elf
executable of course
run file on it.
It's an executable, statically linked,
not stripped.
This is the only unstrapped binary that
I've found other than the Cafe OS
blinking stuff.
So, yeah, they left the symbols and they
left full dwarf debugging information,
including all the structures.
Plenty of strings, apparently, they call
them the thing that does the system
control and security stuff is called
MCP or someone like stron over there.
There's the Setu W section, which is
the capital. We main
the main file, the main object file
there. And there's a bunch of really cool
symbols, MCP hardware set,
HP compatibility mode said Ganpat mode
set mem one Campath mode sets Seasprite,
which is a really interesting register
launch. We ionis finalized Kafe,
which is the kind of the last thing that
happens before we we mode and
set espresso pll config GPO,
which is what presumably switches the
espresso frequency
multiplier and does the espresso speed
also. Apparently they use cygwin.
Unfortunately, this was a mixed bag.
The sandbox is a little bit leaky, we can
partially reconfigure the bus to a new
mode.
We can have enable the extra eight
megabytes of men one.
But it kind of breaks Starbuck at the
same time because the bus is messed up.
So it's not really useful.
It shows that it's there. But, you know,
it's not actually usable by homebrew.
And we can mess with some Gio's.
We can like change the fan speed and some
other miscellaneous crap.
But unfortunately, that's not enough.
Most of the new cool hardware, the new
GPU, separate USB controllers
that you talk to, the game pad, all that
fun stuff, that's all gated
and powered off and the registers that
you need to turn that back on seem to be
locked off by something called Seasprite,
which is one shot and cannot be reset as
far as we can tell.
So I actually tried flipping every bit
and every register in the whole area to
hope that something would let me, you
know, it would turn on in, let me change
things, but no dice.
So we tried, but unfortunately, that
won't work. It would be possible for
Nintendo to enable the homebrew sandbox
that, you know, turns off the Wii.
You say filesystem and security
and keys, but let's just use the hardware
while keeping their DRM safe.
This is kind of like other OS and it
would be better than other OS because
other OS depended on a
hypervisor, which is of course riddled
with bugs while this useless hardware
lockout's, which are fairly solid.
Unfortunately, Nintendo is not interested
in this as far as we
know anyway.
So we have a little bit of an epilog.
I wrote a blog post about this.
And so, you know, at this point we've
broken most of the security, but we
would remain at work to develop the open
frameworks. We need to write an SDK
or report Linux or something like that.
And we thought we were going to do this.
And then we kind of sat on it like maybe
tomorrow, maybe tomorrow.
No one seemed to be really interested in
it.
And the thing is, there's an internal
clash between the homebrew community and
those interested in pirating games.
Back in the day when the consoles were
simple, you just ran your own code and
started talking registers and it was all
good fun.
These days, you need a lot more code to
do. Interesting stuff.
Meanwhile, piracy, as you know, you patch
the function to load code from disk
and send it somewhere else and you can
pirate games. So piracy almost gets
easier with complex OS is gets
harder.
And this is kind of the conclusion that
we reached that it's possible that
it's the you know, the return on
investment isn't really worth it anymore
on on homebrew because it takes a lot
of work.
And meanwhile, you get to watch, you
know, people download games the moment to
get the code execution because, you know,
someone figures I don't look, you know,
DVD read.
How about I redirect that to flash read
or to USB Reed or something like that?
It's usually pretty stupid.
The PS3 loading stuff is like a
few bytes short function.
So, you know, with with the
Wii is really cool because everyone has a
Wii and it's got to be the TV.
Whether we you, you know, people have
smart TVs, the steam box
is coming out. There's a lot of more
open, easy to use devices that you can
hack. So this is kind of the question,
right? Is it worth to continue with this?
I don't know.
But what I do know is that we we
set out a challenge to tell people that,
you know, we wanted to gauge interest
and see if they could put Linux through
that three core espresso, which
we could enable with that really trivial
design flaw.
And that's for forty six pages
on this forum thread.
I mean, they're trying and they give
given a lot of credit for trying, but you
know that they don't have the kind of
people to to really pull this off
in a reasonable amount of time.
I haven't we haven't really seen, you
know, some part developer
or some, you know, old school homebred
say, you know, well, I'll I'll do this.
I'll I'll get this working.
And and, you know, I really want
to have with you homebrew.
So this is where we are today.
Thank you very much.