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/1065 Thanks!
[Music]
i was looking at
media.ccc.de today to check out how many
talks of console hacking we already had
at the congress
and it it's quite a long list actually
so we had uh the xbox 360 playstation 3
at 23 c3
we had playstation portable at 24 c3 we
had a lot more it's a really really long
list and
i'm really excited to have ethan liu and
davey here today
and they're going to tell us a little
bit about the heck of the playstation
vita
and
yeah let's see how the heck it please
give a warmer blouse to
if and davey
[Applause]
so thanks everyone for coming today
so
i know some of you did this already but
show of hands how many of you own a
playstation vita
okay that's a few of you how many of you
own a nintendo 3ds
okay so that's the audience yeah well
i'm hoping by the end of this talk i can
convince you to come to the
better console
so who are we um we are
team molecule this is our mascot and
um
davey
i'm ephon for the lawyers i'm xyz
and there's also proxima who is uh not
here today
we've been hacking
playstation vita since the very
beginning
and
we've done a lot of stuff on it
so overview of the talk today
um so this is a foundational talk so we
wanted to focus more on the techniques
that we've developed rather than just
show the results so some of the parts
you know for those of you more
experienced might find it a little bit
tedious but i'm hoping that
you know you'll like go through it and
learn something anyways
um so they will be perform will be
presenting the software side and i will
come back later on and enlighten you
with some hardware stuff and here's
davey
hello
so i'm going to be talking about the
software side of hacking the playstation
view and specifically i'm going to be
talking about a certain subset of the
visa and that's the security code
yeah security code processor
so
first thing i need to talk about first
is the software the security
architecture of the playstation veto
it kind of looks like this these are the
basic privilege levels for the the
console and uh we've already worked on
the playstation view for a long time now
it was released in 2012 so we're already
up to the trust zone level
what's quite interesting about trustzone
on the vita is it's not actually trusted
at all by sony
it only works as a proxy to the
security co-processor so we can simplify
this privilege level down to this
so
really what i want to talk about today
is
how i'm going to go about
breaking into the food kernel and the
food loader levels
so food i just said that what is it
it's a security co-processor and it's a
special processor in that it's running a
proprietary instruction set we'll come
back to the actual details of the
hardware itself but let's first talk
about the two privilege levels i was
talking about
the fit kernel is the
the drm layer of the system it makes
sure that games and firmware updates are
properly authenticated and
non-authorized code coded run
the food loader
is more like the bootloader
and the startup sequence and it just
makes sure that the food kernel itself
is valid
so if we want to break into these we
need to think of a plan
on how to attack this and
uh
with a proprietary processor we really
need to start getting more information
on it
so first thing we need to look at is the
hardware architecture behind it
then afterwards we're probably going to
have to look at the software that's
actually running on the processor and
from that we can start to think of a
plan of action to break into it
so first i'm going to talk about the
architecture of the system this is the
block diagram for the main system on
chip for the vita
this is called kermit
actually named after the frog they sony
tend to name their
systems the main processors and stuff
off of
uh in this case on the vita they name
after the muppets there's also ernie
uh
there's no bert though which is
disappointing uh
on the psp for example they had a kirk
and
spock and pommel so
only those two on this and we don't
really care about the rest here the cpu
the gpu we really want to focus on food
and you can see inside food there's the
mep c5 processor
map is actually a custom risk from
toshiba
and
i'll talk a bit about the name food we
actually got that from the elf headers
of uh
executables built for the met platform
you see the alpha identifier is f00d
so we just ran with that named it food
and it's been history since
uh the met processors are normally used
in parking assist cameras
or security solutions but in this case
the sony decided to use it for the
security co-processor
there's a bunch of other stuff belonging
to food such as the crypto engine and
the key slots
uh not very important for this talk but
the it also has its own private memory
the secure sram here
only 120 kilobytes but
it cannot be accessed from armor in fact
any other subsystem in the system
so
with a custom risk here
how do we find out information about it
well
it's pretty much the same as anything
else
you google it
and what that turns up is a bunch of
data sheets
some are in
english most are in japanese so google
translate your best friend there
yeah so
following that a couple of google
searches gives you the
the
data sheets so
from there we can learn about the
instruction set we can learn about some
of the quirks and
thankfully
red hat have already ported the mep
platform to gcc and binyutils so
straight off the back we've got a
compiler we've got tools to analyze l
files
perfect
but really we we want to learn more and
the best way to learn for us at least is
to get a little hands-on so we've built
an ida plugin for it
we've built an emulator which was really
useful because it helped us learn some
of the weird quirks behind it
and we even have a decompliant
decompiler for this
so
overall what we've learned about the
hardware is that the instruction set is
heavily inspired by maps it doesn't have
any of the weird uh like delay slot or
anything like that
but the actual instruction format is
it's pretty much the same
there's no virtual memory
and there's no memory protection
whatsoever so it runs purely on physical
memory
it it's not hard enough for security so
this is very interesting there's no slr
there's no no execute bits uh
odd choice for a secured co-processor we
thought that it wasn't very secure so
whatever
next thing we're going to talk about is
the actual software running on food
and
at run time on the playstation view
there's this secure kernel that's
running at all times
and the main purpose of that is to load
applets
which
are executables that encapsulate some
sort of functionality on the system
examples of this are encryption
signature checks uh drm
and whatever you want to use like some
of the feature that needs to be
authenticated what what you do is you
load it
and once you load it you can then do
some sort of rpc calls
to then do some
calculations or decryption or
authentication or whatever
and then afterwards you unload it
because
this the applets follow a life cycle
where you load an applet you do your
stuff you unload it and only a single
applet can be loaded at once
and unfortunately for us uh
tablets are signed and encrypted so we
can't just create our own one upload it
and then have access to the food
so
let's look at the life cycle a bit more
detail specifically we'll start with
applet loading
so you see here there's three regions
here you see arm trust zone and food
as i mentioned
trust one's mostly useless it only works
as a proxy between arm and food so we
can simplify this model down and we can
start talking about how
the applet loading works between arm and
food
so arm will start off
it will read the applet into memory it
will then transfer the applet over to
food then in food it will then check the
signature of it make sure it's a valid
applet and then it'll start decrypting
and loading it
once done it will return the result
whether that was successful it failed or
something else
for apple rpc it's it's mostly the same
power in here it formats the request
sends that over to the foot secure
kernel
secure kernel will then forward that to
the applet
then
the applet will run whatever commands
needed and the result will be sent back
to arm
unloading pretty much the same thing as
you'd expect what happens is
the request is unloaded you you request
an unload food will oblige and you'll
get the result back whether that was
successful
so
knowing this
we need to start thinking how can we
actually go about
attacking this so
let's summarize what we know first
we can control all the input into food
and importantly none of this input's
checked at all
trust zone doesn't do it so we can pass
in as much or as little malicious data
as we want
we know the memory layer of food this is
mostly inferred from the datasheets we
got
but also interestingly the applets have
an elf header and they have
segment headers in there which say which
address it looks to so we can we can
build a pretty good model of what the
internal memory looks like
the secure co-processor has no security
features whatsoever so
that's really handy
we we know what the app life cycle is we
know that they're loaded we know we can
then do some rpc calls
and then
we can then query those rpc calls for
any sort of issues
what we need to watch out for is there's
a
signed executable so we can't modify any
of these executables otherwise we'll get
thrown back with an error
we can
we can read these executables they're
all encrypted so we can't do any
analysis of them beforehand
and this basically makes the system a
black box here
so ideally what we're after in order to
proceed any further is some sort of read
primitive that will allow us to go ahead
inspect the food private memory and then
from there we can start looking at the
code and we could establish a more uh
precise attack on it
so
i'm going to go back to applet loading
here and we're going to try and discuss
in detail what's happening
it's because specifically
we know that the apple is right into
memory and it's transferred over to food
where it does a signature check and then
does the rest of the loading but what
happens for this little bit in between
here
and
there's two problems here
uh
first one is the
arm operates with virtual memory and
food does not
so
uh this has this is a problem because
virtual memory is not guaranteed to be
backed by contiguous physical memory so
whenever we want to send data to food
we're going to have to make sure that
it's either copied to that or that the
memory that we don't use virtual memory
which is kind of ridiculous
so there there needs to be a better way
and and certainly have a better way of
doing this and we'll come to that
shortly
uh so this is virtual memory and this is
physical memory you could see that we
have page one through to page seven
and if you look at the physical memory
site you could see that the pages aren't
in order so if we were to pass page
one's physical address to food it won't
receive the right uh data i'll receive
page one some unknown data page four
page three not intended
what sony do here is they add a physical
address list this p adder list instead
of passing the data all it does is you
pass the p adder list of it and it will
query
it will query the list which has the
first element is the location of the
page that we want so you can see the
first element here points to page one
uh the second element in that list is
the size
so
what food will do when it wants to read
an executable is it will walk this list
and build the model up from inside
and this is the way they can get around
having to copy
a virtual memory to contiguous block
so applying this to food and to the
apple specifically the food module is an
applet
what you can see here is that the first
three bytes of this foods module is
represented by the first entry of the p
adder list
the second the
is the second of the pr list and so
forth you can see that all these data is
backed in dram
this solution fixes the copying and then
we've learned how data has passed the
food and this is
consistent throughout
transfers to food
there's a problem though
if we
go back to this model here and we can
see that all the data is backed in dram
what happens if we modify one of these
piano list entries to then point to the
food private memory
well
as it turns out
food does not blacklist its own private
memory
useful maybe
not here because uh the internal memory
if it keeps all its data internal so it
doesn't copy anything out with this
header so
no leak but
there is also signature check the apple
is also going to be checked so
this makes it useless right because
we're passing in
uh
to unknown data it's doing a signature
check it's obviously just going to fail
or is it because if we make an
assumption right if the data we're
pointing to in sram matches the expected
data that we have in the applet
we'd expect the signature check to
succeed
and then we can make a deduction here
that if that signature check succeeds we
know the contents of the sram
so
let's do this a bit better here if we
reduce the piano list entry point into
the private memory to one byte
and then simplify the pieder list with
the module to look more like this where
you have the first entry
that is
the first part of the file
the one element for the this point in
the food private memory is the zero zero
byte so
we're interested in finding infinite
private memory where all the zero zero
bytes are so every time we pass in
uh
this p adder list
what we would expect is whenever there's
a zero zero point two in this element
here that's in sram
that the signature check would succeed
so if we start by going through this so
we have the element pointing at the
first byte in the private memory
and
we can then pass it into food
it fails the signature check fails so
what we've learned here is
that that byte in memory is not zero
zero
we can go on we can go to the next byte
and query that
also not zero
and we could do this so on and so on and
so on until eventually we should expect
to see
a success so the module was loaded and
what we've learned from that is that
byte there is zero zero
it matches the one in food
the food applet so yeah we've learned
that that zero zero we can then go ahead
and apply this all the way through the
rest of the private memory
and there we go we've built up a model
where all the zeros are
so
we learned where the zeros are not very
useful what we want to do now is look
for
zero ones
so if we
then rearrange the p adder list so the
missing byte in the food applet is zero
one we can then do the same thing again
we point our entry into the food private
memory to
the start we start querying
eventually
we find another one
keep going
keep going we don't need to create the
zeros we already know they're there
then we get here again and we find
another one then you could do the same
thing again apply all the way down to
the end of memory and you find all the
ones
so imagine we've built this model so
what we want to do now is then apply it
to all the zero twos
then all the zero threes and all the
zero fours and all the zero fives all
the way up to the ffs and once you've
done that
you build a model of the fit
hram
and you get the plain text to the kernel
[Music]
this is what we're calling the
octopus exploit
don't ask why
uh
so with this we
now have the food kernel we we cannot
read access we can then do some further
analysis we can start looking for more
precise vulnerabilities we won't go into
that but
we've got the food kernel so
what's next it's the the food loader and
the food loader is the boot stage and
because it's
the boot stage it doesn't last very long
it doesn't persist through runtime
and that makes the software attack
surface very small
so
to deal with that what we're going to
have to do is
look at hardware and i'm going to pass
you back to ifan and thank you very much
[Applause]
[Music]
told you i would be back
so you know we ran to the situation
where the you know
weak little software hackers have to be
rescued by the hardware master race
um
so
what i'm gonna focus on today is
glitching and i know you know that word
is kind of a buzzword these days many of
you have heard it i think even at
congress there were a couple of talks on
it but instead of just saying hey we
glitched it i want to kind of go into
the details of you know what is
glitching how does it work and why does
it work
so
in short a
a a hardware glitch
allows you to create a software
vulnerability when none exists
and there's many ways of doing so
but we're really going to focus on one
of these methods today which is voltage
glitching and the reason is because the
other ways are much more difficult and
expensive to pull off and some of them
are only theoretical
so uh to show and concrete example i
have a bit of c code
so this code you know just does a size
check and then the processes data of the
check passes
and i went ahead and compiled it into
mip assembly so um if you haven't seen
bip assembly before and why would you um
this is what it looks like
and then you know i will just execute it
for you as the computer so uh you know
here we load the size value and then
sltu3
basically is
less than unsigned and it sets r0 to the
result of that so here is set to zero
because it
was not less than and because of that we
jump to the error branch and there's you
know
it's fully secure there's no way of
hacking it just give up
but
if we introduce a voltage glitch at this
point
what we do what happens is that this
will
create
a
mistake in the computation so as you can
see here r0 is supposed to be set to
zero but because of the voltage glitch
it's now one
which propagates the next instruction
when we're taking a branch base off of
that result and we manage to bypass this
check
why does it work though
this is something that's near and dear
to my heart because i'm the kind of
person who you know
you can tell me the high level ideas but
i'm not really satisfied until i know
the low level details
so
to explain that we unfortunately have to
look at transistors
and logic gates
so
if you don't remember this don't worry
i'll
explain it as well
so this is
nand or not
not and
and here's a truth table
and
we are going to implement this in modern
transistor technologies or cmos
it's a complementary transistor
technology what that means is there's
two different types of transistors that
implements the gate
one is as you see on top
um is
uh
used on the i guess the top part of the
diagram i'll show you the diagram later
it'll make more sense but basically this
acts as a switch the gate um activates
and then the
current will flow from the source to the
drain
so kind of like a light switch but uh
instead of you know using your fingers
it's controlled by the voltage at the
gate the only difference between these
two is that the voltage to turn on the
top gate is low so when there's no
voltage the top gate turns on and on the
bottom one it turns on when it's high so
when there is voltage it turns on and
that's what make them complementary
because one must always be on when the
other one's off
so here's what the nand gate looks like
um so you see the bottom gates are off
the top gates are on because
zero nand zero is one and you see
current flowing from the source to the
output
now
one nand zero is still one and the way
that works is that one of the top gates
is turned off but the other one is still
on so it's still flowing through
the bottom one one of them is turned on
but that doesn't matter because the
second one is turned off so the you know
it doesn't leak down to the
bottom port
now one nand one is zero and you can see
it's because the two are turned off now
why are the bottom two turned on because
you know like a uh
like when you turn off a faucet um
sometimes there's water that drips down
right so you need something to collect
that
so what happens when we glitch it right
um so here's we know back to the one nan
zero example
when we say
we introduce a glitch what we are a
voltage glitch what we do is we
essentially connect the voltage source
down to ground or zero volts um
essentially your you know you're
you're disabling the power source
and immediately that doesn't do anything
so you can see here there's still a
little bit of leakage
current um flowing to the output and
that's because you know
like i said you know it's like a faucet
right you turn it off and it doesn't
immediately all get drained so it's
still flowing a little bit but like a
tiny moment later then the output goes
to zero and that is incorrect right
because one nand zero should be one
however here's the important part right
you have to
then turn it back on and restore the
value
otherwise if you keep it off then all
the transistors in the system are going
to turn off and your system just powers
down and you can't do anything useful
so the key here is that
we have
you know an incorrect output but only
for a small amount of time because we
have to turn we can't get away it was
leaving it off
and because if we you know leave it off
for too long then it uh turns off
but
not all hope is lost because that
mistake for that tiny amount of time
will actually propagate if uh if it's
done at the right place
so
here's you know like a tree built from
multiple nand gates
and you know let's say the the voltage
glitch caused this output to be
incorrect but that's an input for these
two gates right which is input for these
two and these two are inputs for that
one so you effectively you know created
mistakes in about half the circuit
but that's the ideal case in reality you
know it's it's a lot harder to determine
like how the error is going to propagate
because if you think about the truth
table for nand logic it's there's only
one way of getting um a
a one way of getting a
one and three ways of getting a zero
or the other way around
but
my point is that
you know it's not even
even to get the right output that you
want
the you know the the upshot though is
that we can cause
an incorrect output
for short amount of time
we have to wait for it to propagate and
like i explained before because the like
you know these logic gates aren't
completely symmetric it's easier to
reach one state than the other the
system can correct itself and this is
actually by
digital system design one of the reasons
why your computer is so robust is
because it can correct mistakes like
this um like we are injecting a voltage
glitch manually but
glitches are a known thing in digital
logic and it a lot of times it happens
without any external sources so circuits
are designed to correct itself which is
why we need to find specific targets
with voltage glitch to actually get them
to
really do what we want
and the ideal case is that you know one
error propagates through much of the
circuitry and example examples of that
includes arithmetic instructions aes
hardware like you know branching like in
processors anything where you can
imagine like changing the input a little
bit will create a lot of you know gears
turning metaphorically um and
result in like a widely different output
so that's a theory you guys can wake up
now
we're going to get to the actual
practical part which uh includes you
know finding out where to attack
what to attack
and
a little bit on automation and that will
make more sense when we get to it
so what do i mean by uh where to attack
um so this here is an image of the pcb
where the vita's main system chip kermit
is laid on top of and um
with anything as complicated as this
there's dozens of different voltage
rails that power different parts of the
chip including like dram and io pads and
so on but we only care about the the
power pins that go directly to the
transistors so we need to find which pin
that corresponds to
to make things worse uh each power rail
voltage rail is actually connected to
dozens of pins so it's not just like one
pin corresponding to one thing
and there's you know 724 pins
but
i can show you a way that we can
go through this
like manually it's not
easy per se but it's doable um and it's
doable over a weekend or two
um and it's it's a process that involves
mapping out the pins on
on a pcb
and um so to backup of course we don't
have a data sheet i think it's a lot
easier if you have like a commodity chip
where you can just look up the data
sheet and see like where each pin
corresponds to but if you have a system
with a completely custom designed chip
you won't have that resource
um
so
one thing that you have to do though is
what's called pcbd layering and i think
there's been talks about in the past
which i think i recommend you guys look
up
um but the the the takeaway is that it's
relatively inexpensive and anyone can do
in their own home
was the right tool uh fortunately um
someone by the name of biteful
uploaded full
pcb scans of the vedas
board
and that's fortunate for me because i
don't have to breathe the fiberglass
particles when you start removing the
solder mask
so with the solder mask on
you you see the copper layer
corresponding to the the different pins
here
and uh one thing i want to point out
here is you can see that some of the
pins look like pins and other ones look
like you know like they're part of a
sausage or uh what do you
guys call it here um
anyways uh the
the ones near the center
is
more likely to be power related because
if you think about like designing a chip
right like you want to put your power
sources near the center so they can
dissipate evenly and um
and it's
the distance to each component should be
relatively close
so
what we want to do is we want to take
like one random pin
and we want to see where it is connected
like where what power source is
connected to and what other pins is
associated with it and to do that uh we
just uh you know we mark the pin so the
convention i'm going to be using is i
will be marking one layer in red and
then i will go down another layer and
then i will use orange to show a new
marking on that layer
so
here you see a bunch of these
small
dark
holes these are called vias they're used
to connect the metal layers
the two metal layers together so when
you have a vaya that means there's an
electrical connection from one layer to
the other and for that specific copper
pad
so we go down one more and you see
you know the vias on this layer are a
bit bigger than the last one
and then we can just keep going down
until eventually we reach
a copper plane that this vaya is
connected to
and i'll
put an outline around it so it's more
clear
so this is where the source
for that power pin um comes from and i'm
not gonna show you uh
like the actual i guess the actual power
the chip that powers that plane uh
because it's off this image what's
important here is that
there's many of these other
vias on this plane that
i've highlighted in red
so all of these are connected together
on this layer now we can work backwards
and do the same thing
and basically find you know where it's
connected each time and highlight the
copper that's associated with and then
we get to the top
and we see that all of these little
sausages are connected together and
this
these are 35 pins that are corresponds
to one voltage rail
and
that means we only have 689 more to go
but
uh good news 245 of them are not
connected and you can just see that by
looking at like layer one to layer two
there's like no connections
um 175 of them are ground which means uh
on the first or second layer you can
just easily see they connect to the
large copper pad that like most other
things are connected to
with so really there's only 269 pins
left um it's
it's not you know the the best thing to
be doing on a friday afternoon but you
know if you're me what else do you have
right
um
so this is what the
chip looks like fully mapped out the the
red ones are the different voltage rails
um the different shades
corresponds to the different voltage
rail
um and the other colors are data pins
that are not really relevant here
i just did it for extra credit
so
we found nine different voltage rails
how do we know which one is the right
one
and to do
to find out we just uh basically try
each one um you know brute forcing nine
things isn't that bad
uh we write
a
counter that increments like five
different registers
and then we just you know hook it up to
the computer and we just try
voltage glitching each one until we see
uh one of these counters change so why
why does that work well remember when we
create a voltage glitch uh it
effectively you know creates a mistake
in some computation so here because like
the most because of how tight that loop
is most of the work the processor is
doing is going to be increment or
incrementing or decrementing these
counters and um when
you know when the glitch hits it will
probably
like hit one of the
alu operations which will cause a
mistake like this
so
you know we have this tool this tool
that we found which is a voltage glitch
we found the right power rail
we can arbitrarily
create mistakes in the computation
but
what can we do with it
so from you know previous talks and from
other resources the clear
way to go is to bypass signature checks
however um on the vita that's a bit hard
for us to do and
some of the reasons include we don't
really have examples of what what the
bootloaders look like decrypted so we
don't really even know where this
signature is and we don't know if
there's like other kinds of checks like
uh and like shaw hashing or anything
like that so it was it's just hard for
us to tell if our glitch worked and it
bypassed the signature but something
else failed or if the glitch didn't work
instead
we looked at something that's that's
easier to understand which is the boot
partition headers
and the the boot partition uh contains
the bootloaders it's a special partition
format that's uh not standard however it
is easy to understand it's unencrypted
it's unsigned
and the fields you know you are not that
many and you can kind of guess what they
mean
we'll just focus on looking at the
header size field because spoilers it
worked
and the size field is checked to be less
than
0xde blocks we found this out through
basically
trial and error so we tried writing you
know 0xff and it didn't boot up then we
tried writing you know zero x four zero
and it worked then we tried writing you
know zero x e zero and it didn't work
and then through this like kind of uh
like manual binary search kind of thing
um we found that this was the largest
value
before it doesn't boot up
um
[Music]
if you know if the check fails it halts
and if it passes then
we can see that the the
the actual boot loaders are read from
the storage
so
what happens if we manage to bypass the
size check
well
the theory is that it will overflow some
buffer because you know why will you why
do you check the size if you don't have
a static buffer right
um
so the plan is we need to
sniff the the storage controller traffic
um and that's you know just some
external pins
we have a mosfet which is basically just
an electrically controlled switch that
will do the shorting that we discussed
earlier
and uh for
we need a fpga to control that mosfet
because we need very precise like
nanosecond level
timing
and the reason why is because uh so this
is you know the the process
to to find the the right parameters of
glitch with um
the the important thing here is you know
we wait until that boot partition header
is red and we know that at some time
some short amount of time after the
header is read it will do that size
check but we don't know when that is so
that's what parameter n represents is
the the offset from reading the packet
to when the size check is done
then
we do the glitch and we you know hold
the power off we we short it for up m
amount of time and
basically the reason why we vary m is
because
uh
remember when when we're glitching we
don't really know what results we're
causing so the longer you hold a glitch
the the the results vary wildly
and if you hold it
for too long then the system shuts down
so we basically you know just have a
script that looks at every possible n
and m value and you know try different
ones
so
how do we actually implement this um so
i use the chip whisperer
which is a
open source hardware hacking platform
and uh one of the reasons why it's so
nice is because you can use python to
script all
that uh
process that i talked about earlier
has an fpga
and a mosfet which is the only thing you
really need um and we added a custom
trigger for monitoring the uh storage
traffic
also we had a we designed a custom board
um and the the only reason why is really
to manage all the wires because you know
we there's all the wires to the the
different
pins for the storage controller and then
there's a couple of gpios for like
status indicator and stuff so it's
easier to just put them all on a board
and we also
use this board to dump and flash the
storage to you know
put our payload on
and it connects directly to the chip
whisperer
here's what it looks like hooked up um i
made very liberal use of
transparent tape
and
i one thing i want to point out here uh
that i haven't mentioned before is that
we actually connected
we removed the the clock of this of the
vita and we connected it directly to the
chip whisperer and the reason why is
that we found that if you synchronize
the two clocks the devices clock and the
chip wizards clock then when we are
searching for those m and m parameters
uh the there's less drift and it makes
the results more repeatable
so the the fi so this is what it looks
up hooked up um
once again i love tape
and
so the the final the final piece that
put that we had to put together um was
actually uh help
from someone in the x switch hacking
community who uh told us to slow down
the clock even more than what we already
did and it turns out you know if you're
running the clock too fast it
creates too much noise and that could
disturb the glitching process
so
you know take away if it's not working
try slowing down the clock
so ran this all night and woke up the
next morning looked at the logs and we
found a vulnerability and this is the
boot rom
shot 256 hash
[Applause]
so state of the vita in 2018
we
managed to dump every part of it
the boot rom unfortunately is not too
interesting they don't have any keys in
it
they don't have
anything that
the attack surface is just so tiny they
don't have like a usb stack in it
because that's crazy right
um
and
you know uh
we managed to dump all the code we can
find on the system
so what have we learned
um
so let me get a little philosophical for
a moment
sony had a history of crypto failures
i think most of you here know about all
of these
but
if not you know history lesson psp
didn't check code signing in the
beginning
ps3 the infamous fail overflow
ecdsa factoring
and recently we found on the playstation
classic they shipped
the private keys for the firmware
updates on every single device
but
the vita is actually
a very nice um
you know
work
in terms of security um unfortunately
you know can't speak to amount of games
or market share
key reasons includes the the
the boot
surf the the secure boot is pretty
simple
um all their you know cryptographic
stuff is relatively simple compared to
you know other sony devices
we didn't really touch on the arm
processor at all the main one that your
games run on but they do implement most
modern exploit mitigation and this was
back in 2012 which where you know a lot
of stuff like k-a-s-l-r
uh or kernel random address space
randomization isn't standard they
implemented that you know way back in
2012
and they you know instead of trusting
truststone they have a dedicated
cryptoprocessor
but
not everyone is perfect
there is a slight issue with how they
chose their bootloader description keys
and to be clear this key protects every
other key in the system
now after we dumped the boot rom
naturally uh the next thing we did was
find this key
and
it is a single bite repeating
but here's here's a little like let me
pull back the curtains a little
before we dump the boot rom a couple
months before our friend xyz
now you can decide if he has 9 iq or 9
million iq
xyz decided to brute force the aes 128
key
and
[Music]
for legal reasons
we won't share with you
but let's just show you an unrelated
picture i found on amazon
so
lots of people to thank
these are just
a few
i want a special shout out to
zurpy who managed to get linux running
on the vita last week which was very
impressive and now um they're trying to
like write all the drivers for it so if
any of you are interested in that one
want to help
i can put you in touch with with him if
you uh check us out at the
ninten bros assembly later on
everything i talked about will be posted
on github um if you want to know more
about vita hacking and reverse
engineering uh the hinkaku wiki is a
good resource and if you want to write
vita homebrew the vita sdk which
we helped with early on is a good
resource
with that i would like to open up the
questions
[Applause]
[Music]
hey great
thanks a lot um
great to see how much fun you guys had
hacking this thing uh really cool we
have uh five to seven minutes for q a so
please line up with the microphones
and we have some questions probably
so
so i think microsoft number five i see
somebody
it's the thing yeah
so the double a as the
key for the bootloader
is this
a choke
since it's totally not effective at all
in my me
so
yeah
this was interesting so at first when we
found this we thought for a long time
that we we actually so we thought we
accidentally had a debug build so we
thought we they accidentally shipped a
debug build or something and that's
where the key was from but turns out
it's it's it is the bootloader that is
used on retail devices um i think the
reason why it slipped
like out of checks is because they only
ever use this key
uh encrypted and like you know
the
they have a crypto processor so in
addition to food there's a separate
crypto processor that only food can
communicate with and
it's the one that um that does all the
uh encryption so this key is never found
in any like
text pages or anything or any code it's
only available in this secret hardware
uh crypto processor um so maybe
you know someone
accidentally left the wrong key in or
whatever and nobody found out because it
was hidden so well
great we have a question from the
internet signal angel please
thank you
can your findings be reused in some ways
for the ps4
[Music]
probably not
no it's
i think the design here is mostly
exclusive to the playstation view here
it's
i think the ps4 has some sort of
a similar security co-processor but it's
it's not the same
and also ps4
doesn't implement as many security
mitigations as the vita does
great microphone one please
for your work and for your talk you
talked about do you control the clock
from the process over the chip whisperer
did you also try to clock legit
sorry what was the last part did you try
to clock legit
so uh
i guess
okay uh
i did i didn't want to talk into this
because it's a bit technical but a clock
glitching actually doesn't work on most
modern processors because they use
something called a phase lock loop or
pll which derives the internal clocks
and when you glitch the external clock
it will be filtered out by the pll so
most modern devices have a pll now which
makes clock glitching not really useful
yes
thanks microphone three please
a question is very similar and i'm not
quite sure whether my understanding of
pls is wrong but
as far as i understand they only do
clock multiplication and division so if
you change the external clock then the
internal clock clock should also change
and um i was just curious by how much
you changed the clock
right so the so there's actually uh
it that is true but if you look at the
like the
you know the very precise like response
function the transfer function of most
pll there is something i don't remember
the technical name but it's like a delay
response so your changes in the
frequency is not instantaneous and most
plls are designed to
not change quickly was the was the clock
frequency and it's a feature that they
call filtering out jitters because
sometimes your external clock can be a
bit noisy and you don't want your
internal clock to follow that noise so
most plls are also designed specifically
to not respond quickly to frequency
changes
on the outside
thank you we continue with microphone
one please
uh since they're harder and softer is
similar closer to the moment okay sorry
since the hardware and software is
really similar does this apply to the
playstation tv2 or just to the
playstation vita
because playstation tv has uh hdmi
output and usb input output so
it will be i don't know all just to
do it on that
console too
so could you repeat that again uh
playstation tv
yeah yeah
yeah it's it's all the same yeah it's
just the same device
yeah because i have both ended just so
like
there is the error scene sometimes when
you're with a playstation tv even if it
doesn't
i actually have a place in tv so if you
come to their assembly later we can oh
okay okay i will i will okay so
invitation to the assembly later we go
to microphone three please
hi
thank you for the talk very interesting
um would you care to explain why it's
called the octopus exploit
okay i'll i'll give two quick
explanation i'll give
xyz who found the x-ray his original
explanation
is that an octopus has three hearts
and uh somehow you know when we have
these three little like
pieces of the
of the p address table one like you know
one piece pointed correctly one piece
pointing to the um
the food private memory and one piece
pointing to
the correct data
that's like three hearts
that doesn't make any sense to me
i retconned an explanation which is the
p added list is kind of like eight
octopus legs grabbing on to dram which
makes more sense to me
so you see the piano list here that's
supposed to be the three hearts
yeah
totals makes total sense right you can
make stones later
microphone number two please
yeah so my question is the initial
bootloader of the food processor where
is it actually stored is it like in
flash or is there's rom or what is that
this is actually a very interesting
question i didn't want to get into it
but the boot rom is never mapped
anywhere in memory so what the vita does
is on boot up it copies the the
instructions for the initial um you know
boot stuff from some secret hardware
area that's never accessible through
memory into the s ram and then as the
boot as the boot rom we call it boot ram
starts up it's like slowly wipes each
part
like of the key derivation and other
stuff as it's executing so yeah it's
it was kind of a pain to get
wow interesting last question microphone
number one please so while taking apart
the hardware did you figure out what the
top right port on the original vita is
for is it used anywhere so we found this
a while ago it's actually just a usb
host port a usb ehci port was a custom
connector
thanks
yeah great thank you again great
applause for ivan lewis
[Music]
[Applause]
[Music]
so
[Music]
you