Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/2850 Thanks!
[Music]
[Applause]
so we're 5 minutes late so I'm going to
have to be slightly quicker so to those
who don't know what I'm going to talk
about is the DSI it's the successor of
the DS which is you know the first dual
screen console by nint Nintendo which is
basically two gbas with a new GPU the
DSi is runs basically the same games but
it also has a cameras and a web browser
and more fancy things there's also the
successor which is the 3DS which has the
3d effect which is actually completely
new it has a new CPU new GPU and so on
but it's a middle one I'm going to talk
about
today but before I get started about the
DSi I'm first going to spend a few
minutes talking about the DS which is
going to explain why the DSi is actually
different the DS used well was the first
console by Nintendo to use cryptography
but they made a mistake of using
symmetri key cryptography which means
that the key to encrypt a cartridge is
the same key used to decrypt which has
to sit in your console so if that key
gets leaked you can make your own
cartridges which is exactly what happens
like these flash cars these are four
chords Etc got really popular and you
know Nintendo didn't like that because
know that way know just using a flash
card is really easy people are going to
use it you know compared to the GameCube
you in the GameCube you had to use a
modip which you have to solar so not
many people did that but yeah uh that
means that for that point on Nintendo
had to use public key cryptography which
does not have this problem which means
they actually completely changed and
used a completely different security
system in the DSi as compared to the
DS now of course the DS was released 15
years or so ago so of course I'm not the
first one to ever look into the
DSi and the first one to
actually console was scan with her Ram
Tracer she built this kind of impressive
setup where she could do um mitm attacks
against the external RAM bus so that way
she could you know see every read and
write happening on that bus and that way
she could extract code of games and then
fight for abilities in them and then you
have these same game vulnerabilities
which is on the small spy emmc on the
cartridge and that way you can get
easier ways of getting code execution
but that's like all that know that setup
was pretty fancy but that's still
everything that was possible to do with
that and yeah nothing else really
happened after that there's no deeper
way into getting into the console so
yeah things stall a bit another 3D yes
got released and you may have seen these
presentation at previous congresses and
yeah it got pretty badly broken and
interestingly after the 3DS got broken a
launch appeared which is a boot code
export for
DSi and you would think okay we have a
boot code exploit we can run our own
onside code right at cold boot so
problem solved right well not really un
L has some weird things it also exploits
a second stage boot loader which sits in
the emmc so it has to modify the emmc in
know people don't really like modifying
the emmc because the emmc in the DSi is
actually really bad it wears out really
quickly and then as soon as the the emmc
breaks your console is a Breck and
that's not good also the bootroom hasn't
been extracted and yeah we want to put
from so well but instead of using a
fancy attack maybe you can can just
revive a console by just replacing the
emmc chip like it's just not basic
generic nonvolatile memory right well
not quite the MMC card identifier which
is a readon ID that's unique to every
emmc chip is actually used to dve keys
that are used in a bunch of
things and also the console ID which is
Fus in the main s so that also uses uh
source for keys so that means if one of
these things change for so for example
if you replace S so on board or if you
replace the MMC on board your console
won't be able to boot so yeah that's
also a problem and it's also one of the
reasons why secure boot is just not a
good
thing anyway uh before I can continue
let's talk about Hardware the DSi has
two arm CPUs there's the arm 9 which
runs at 133 MHz it has well it runs most
of the game code it has access to to the
GPU but it's not in this diagram because
it's not super important there's also
the arm 7 which runs four times slower
but it has all access to all the io
stuff both cores communicate using a 5
interface they each have a little bit of
a private ram that only that core can
see there's also the shared PS round
which is 16 megab in size it's the
biggest memory it's also the external
memory that scan Li attacked there's
also a w RAM and W Ram is weird because
it's divided into a bunch of physical
blocks of memory and each of these
physical blocks can be separately
assigned to one of the cores at a
flexible address but it's only then
visible to that core but also the
mapping can change at run time so it
gets complicated pretty
quickly so let's talk about how the
console boots so there's the S so which
has both of the CPU cores some Ram it
has the boot ROMs and all the proofs for
example the AES engine the MMC is a
nonvolatile memory and there's also the
dam the first thing that starts running
when you boot the the SII is the boot
ROM it sits in masrom it loads the
second boot stage from raw MMC blocks it
sends it to the as engine that when
decrypted and then that gets loaded into
SRAM the second stage then gets well
also started it then loads the system
menu from the fat file system also
decrypts that loads it into Dr this time
and the system menu starts running and
this is actually the first thing that
actually turns on the screens and then
you get nice boot logo
and yeah then the system menu is able to
launch your game from a game cartridge
or maybe from
emnc and that gets to need to do around
but before the system menu actually
jumps through the game code it's going
to apply What's called the S config
registers these uh are used to parate
certain parts of the hardware and they
cannot be turned on again until the
console is reset and then the entire
boot flow happens again that's used
because there's no operating system
there's no hypervisor or anything inside
the DSi so this is the only way to make
sure that when a game is running that
you know runs from cartridge cartridge
it should not have any access to the
emmc to corrupt it or do any other kinds
of evil things so that's you know an
interesting way to do isolation
here now of course the 3DS is also not
completely irrelevant it has a backwards
compatible mode to run DS and DSI games
and the inter thing is that instead of
running a software emulator the hardware
of the 3DS actually reconfigure itself
and starts pretending to be a DSi this
switch is implemented in lowlevel
firmware so when you start a DSI game on
your 3DS it will actually shut down the
operating system of the 3DS and then run
some kind of lowlevel firmware that then
does the mode switch and once that mode
switch happens the first thing that runs
in DSi mode is actually the standard
second stage boot loader and that's
interesting because it's exactly the
same one as on the stock regular
DSis so yeah of course it's it's loaded
into SRAM so with scan lies Ram Tracer
you can't really read it out but because
it's leaked by the 3DS firmware now you
can actually read all the code and fight
vulnerabilities and that's exactly how
un launch
happened so yeah the main fakeaways here
is that if your emmc is dead your
console is a brick and every everything
that's interesting and has been hacked
already happens after the signature
check and that means that you know if
your the emmc is that any sort of hack
that's already been published for the
DSi it won't help you and you still have
a Breck so if we want to fix this we
need some way to get code execution
super
early now nobody has the boot droms yet
at least when I started on this and you
know doing blackbox trying to find
vulnerability here is not fun so we
really need a way to get uh the boot
droms now the 3DS has this interesting
thing where there's a hardware flow that
using fall injection you can actually
extract the boot ROMs and this actually
also works on the
DSi so it works as follows it's called
Vector glitch hack the both uh CPU cores
have their own separate boot ROMs these
are divided into three sections there's
the exception vectors which have things
like the reset tender which is the first
code that runs on reset it jums jumps to
the boot code there's things like the
interrupt handlers which you know fire
when a button is pressed for example
there's a sofware interrupt which jumps
to the utility routines and there are
also other things like handlers for when
an invalid uh memory access happens or
when uh an illegal uh instruction is
executed and of course the boot code can
also be disabled using the S config
registers so you need to extract the
boot code before that happens because
otherwise it's stuck until the console
is Rebo booted again just like the other
time now of course uh for some things
like the util routines or the boot code
that's fine to be hardcoded into the
bootrom but uh for the exception vectors
and the interrupt uh Vector you want to
do different things when a button is
press for example for like if you're in
a menu you want to navigate in the menu
if you're running game maybe you want
the player character to shoot something
so that has to be there needs be some
way to change the behavior of that at
run time so for that they actually made
the bootom such that some exception
handlers jump to a ram and there's
interesting thing is that this piece of
ram actually persists across resets so
if we fill this with a payload and an
uplet for a good measure and then we
reset chip uh you know the reset
exception Handler will run this jumps
through the boot codes Regular Boot code
will run everything is fine but if we
now inject the fault here and if we are
lucky this will cause an undefined
instruction exception which means it's
going to jump back to the undefined
instruction exception Handler this jumps
into RAM right right into our payload
and that way we get R code execution in
the
[Applause]
[Music]
bootrom now I wasn't the first person to
think about this there's like Forum
posts about this in like 2016 or 2017
but but they didn't really get any
success at this why is that well let's
talk about how you how glitching Works
in
practice so let's quickly talk about
voltage glitching this is a seos
inverter if you don't exactly know how
it works it doesn't really matter the
important thing is that it has an input
and output there's two transistors
there's a positive Supply voltage and
the ground if you have an input if your
input is zero the upper transistor will
turn on it will connect the outputs to
the positive power supply that means the
output is going to be a logical one now
if you short the uh positive power rail
to the ground the output will be zero
even though the input is zero which mean
there's a fault here now if you do this
for a long amount of time that
means uh know that means the Chip is
going to shut down because it doesn't
have any power so you shouldn't do that
if you do this for a very short amount
of time this chip will actually keep
running but it still has the wrong
output and it's going to use that in the
you know computations after that and may
going to store it into some kind of ram
Etc and that's going to cause all sorts
of bad things now in practice if you
look at a PCB there are these things on
it these are called decoupling
capacitors these hold a tiny amount of
charge and those will actually smooth
out any sort of glitches and the people
who tried this didn't really take this
into account they didn't really what
either they Ed way too long glitches or
way too short ones they hadn't really a
way to precisely time this and
other things so yeah that ended up not
working luckily there's a different way
to inject folds which is called
electromagnetic F injection or emfi for
short the way that works is that if you
have a coil like here on the left uh if
you run a huge voltage [ __ ] for that for
example like 400 Volts for a few
NS that's going to generate an
electromagnetic pulse uh around that
coil now at the right there's an 3D
rendering of how a chip looks like at
the bottom layer there's all the Silicon
with all transistors that get all the
attention here but above that there's
the gold color colored thing which is
the metal interconnect these are
actually the metal wires the metal
connect connections that connect all the
transistors which allows them to
actually do any useful work now if the
interconnect is hit by an
electromagnetic pulse that's going to
induce currents you know through the law
of induction Etc and all sorts of
currents are going to flow and also
cause bad things and for that you don't
need to care about the capacitors or
where on the PCB the power rails are and
so on so that's pretty easy of course
you need more specialized equipment
luckily I have that because I have
access to a fancy lab so
it in practice it look like this so you
have you know the what's left of a DSi
with the main s and right above that
there's a small coil which is then
connected to a pulse generator if we
zoom out a bit it looks like this the
pulse generator is fit on an XY Z stage
so you can actually move the rins and
Target different Aras of the chip uh at
the very bottom of the picture there is
a RedBoard with a respir Pio and a few
other things which can quickly reboot a
chip uh actually activate the pulse
generator and talk to whatever is
running on the DSi and so on and it uses
mass of wires so I actually had to use
aluminium fold to Shield it from the
pulse generator because otherwise it
wouldn't really
work so yeah but yeah eventually this
worked I was able to read out to
Boom but there's a small problem
here uh yeah the arm 7 code only has
like driver code and all the boring
stuff but if you want to make an exploit
you actually want to see what the juicy
cryptographic code is doing and yeah we
didn't have it so we're going to have to
dump the R9
boom and well on the 3DS it was pretty
easy as soon as you have code execution
on one of the cores you can basically
take over the other core and read out
whatever they have but that doesn't
quite work on the
DSi instead well maybe we can just try
the same thing again but that also
doesn't work because on the rm9 that
piece of RAM is actually does get reset
so yeah you also can't really use
that so we're going to think need to
think of a different attack
here so yeah here's a rough overview of
how the bootom works works so both cores
do some initialization stuff the arm 7
then loads whatever it has to load sends
it to the arm 9 the R9 does whatever
cryptographic verification routines it
does which you we don't really know yet
it sends the result back to the arm 7 if
everything is good if the RC signatures
are valid it the arm s will actually
lock away the boots of both cores
instead of every core doing it for
themselves and then the arm9 wait for
that locks to happen and you know as
soon as that's done they go on to the
next boot stage now if we use the vector
glitch heck to take over the r 7 as
usual but instead of just dumping the
bootom we now pretend to be the arm
seven bootrom except we quote unquote
forget to lock the boot troms that will
first get the arm n to stuck to get
stuck in an infinite Loop and it's just
going to wait for something that won't
ever happen but then we can just inject
a second
fold and that fault will hopefully make
the arm n jump out of that Loop even
though it shouldn't and then the console
will just continue boot as if everything
is fine so if we then zoom out it will
just go to the next boot stage go to the
next boot stage and eventually using
some uh simple exploit we can uh run our
own code at a low privilege level we can
just say see oh wait the wot is still
enabled and then save it Tod
card and for that I was actually not the
first one to do this so stock pixel
normat beat me to this for like one in
with like one or two weeks and now after
that I also managed to do this their
setup looks like this so they did use
voltage glitching but they had like a
really beefy transistor on there which
is connected really closely to the power
supply at the power supply chip they
also desolder the uh Crystal oscillator
and suppli their own clock to
synchronize all the glitches even more
precisely and this was all controlled
using an ice for the
fbga so a quick timeline of this attack
so you have the reset which happens
first so the console starts booting you
inject a first fault this takes over the
arm seven boot ROM so then the first uh
boot stage happens now the chips gets
stuck and you don't see any activity
anymore and then we just keep injecting
glitches until hopefully it actually
works and the R9 gets stuck out of its
infinite Loop which and then you see the
first blip of activity again that's the
second boot stage and then a lot of
activity which is you know us reading
out the bootom so yeah this
works and luckily this also the
cryptographic verification
routines now what now well now we can
finally start answering the questions
everyone has been waiting for namely
does it have Sig hacks which is the
exploit the 3s has to circumvent our sa
signatures and also does have NTR boot
which is a secret uh boot uh thing where
the 3DS can actually boot from a a DS
gain cartridge uh even though it's it's
completely undocumented and the answer
to the second question is yes it has
actually the exactly same key
combination with also the magnet trick
which you can
use uh and then you know otherwise if it
doesn't use that it's either going to
boot from emmc or from Spy
Flash and let's talk about the boot
procedure in a little bit more detail
now so there's the arm9 CPU with its
address space and the rm7 also with its
own address space the R9 has a memory
protection unit the R7 doesn't there's
also the Spy Flash and the
emmc uh the first thing that happens
after all the initialization stuff is
that the R7 loads the boot configuration
bites from the Spy Flash and then also
sends it to the R9 using the 5
interface then you know typically the
emnc is selected as the boot medium so
it's going to read the boot header from
the emnc and also send it to the ar9 now
this boot header has an interesting
format now it has the basic things like
the payloads you know how big it is
where to find it in the emmc at what
address to load it to and also has the
NW Ram mapping configuration because
it's complicated and it's it needs that
and then there's the RSA signature the
usual way an RC signature work is that
you have your data you calculate the
hash of your data and then you sign that
hash here they're doing this slightly
interesting thing where they calculate
many hashes of many blocks of data and
then sign the combined hash of that
and interestingly they know they combine
the two uh boot blobs the payload blobs
they also uh add the header also an a
key to encrypt the blobs and then also
adds an extra hash for uh extra
validation I guess but the arml is going
to check all that if it all checks out
it's going to continue it's going to
load the first payload image which gets
decrypted and then depending on some
option in the boot header it will either
know directly load it into W Ram which
is then know moves the physical block of
memory to the arm9 or there's an option
to use compression here which is going
to send the compressed data to the arm9
and then the arm9 because it's four
times faster will actually do the
decompression and that way it saves
probably like a few micros seconds of
boot
time and then you know once this know
it's going to check the hash of that
binary if it's good it's going to
continue do the exact same thing for the
second binary and if everything is nice
the console continue booting and with
the second boot
stage now this signature format is kind
of interesting because you know it's
signing many things at once and it also
contains a key which means that well the
key is never hardcoded so Nintendo can
just push out a new update and change
the key if you know in case it leaks and
the second thing is that you need the RC
public key which is hardcoded in the
bootom which is pretty hard to actually
read out so that's interesting
construction here but of course this is
also completely custom and you know the
first thing you've ever heard when imp
implementing in cryptography is don't
imple Implement your own cryptography
and the second thing is that you know
it's uses Shia one RC 1024 and that's
kind of super old like nobody should use
it but yeah it was 2005 2006
2007 but yeah after looking at this for
long amount of time I couldn't really
find a bug here to easily bypass the
signatures so yeah there's no way to
attack this luckily there's also the
Shia one thing so maybe we can attack
that well not quite we can do Collision
attacks against xiaan which means as an
attacker we are free to choose the hash
value to then generate a collision for
but that's not the case here here we
already have the hash in the signature
which we then need to find what's called
a second pre-image for and that's much
harder and there's no attack for that so
yeah we can't use that there's also R
1024 you've probably heard of the thing
where you know the public key is the
product of two large primes and if you
factor that you can get the private key
and yeah that still takes too much work
at least for
me but those keis were generated in 2005
so maybe we can do this there for
example there's the copper Smith attack
and the return of copper of the copper
Smith attack and bunch of other things
because generating good RSA Keys is
actually really tricky and if they are
vulnerable you can actually Factor the
and get the private key super quickly
there's a tool for this so you can just
check it really quickly sadly that
doesn't work now I don't have the
computer power to Brute Force this but
the NSA people think it does so you know
instead of spying on everyone maybe they
can get some public Goodwill to actually
Factor these keys so yeah here they are
here's the public Keys have
[Music]
[Applause]
fun
but of course that that doesn't mean I'm
Giving Up So let's look at code
vulnerabilities instead now the payload
size and load address are never checked
so you're just free to have like a 3
gigabyte payload and then load it to an
address that doesn't have any memory
behind it and the boot will just do that
but of course it's RSA sign so you can't
quite get around it but if you look at
the code of the RSA signature stuff well
it's its implementation is just you know
you're going to do RC operation check
the padding if the padding is correct
it's going to copy out uh all the data
and return true if it's incorrect it's
going to return false but this return
value is actually never checked so if
you just have incorrect padding it's
going to use uninitialized memory as the
signature and just continue using
it and the thing is that uh in the
bootom this uninitialized memory is
actually always zero now if you remember
there is this extra hash that checks all
the other hashes if this entire thing is
zero well a bunch of zeros has is not
going to be all zero so this check is
also going to fail so you know looking
at this there's like almost a bug so
what if we introduced
bug so time for even more glitch attacks
so there's this piece of code that has
two hatch checks which actually jump to
the same if statement that corresponds
to this move instruction on the other
side if we glitch this move instruction
we can actually bypass these two hatch
checks which is know the header check
and the redundancy Hash Hash check that
does mean we cannot bypass the payload
blobs but we can still probably use this
in some way or another so yeah what can
we do with that well we can actually put
whatever we want here now and of course
as I said before it's not going they're
not going to check if it actually makes
sense so what we can actually do is that
say okay we have a compressed payload
please just send it to the R9 but to the
r 9's stack so we can just completely
overwrite a stack now there's an mpu so
we only have Rob but luckily we can use
the simplest Dr Chain in the world there
like a call to M Copy somewhere we can
just jump to it and then we just copy
our pads to a piece of memory that's
both rable and executable and then we
have full control over the R9 and as the
r 9 we can now say to the r 7 uh well
there's nothing special to see here
don't worry about it just continue
booing the hashtag was fine the arm s
will comply and then in the boot we just
you know the second pay just put that
into the arm9 St and the arm n has no
protection at all so we can just also
take over the arm7 so that means we have
arm 7 and arm n code execution before
the boot from lockout with only one
[Music]
[Applause]
[Music]
glitch uh but yeah that all SS nice but
that's still glitching that's still kind
of annoying in practice right so first I
tested the payload in mels I had to
change it a bit I also added a GDB stuff
so I can actually debug code that's
running inside mels and that was
actually super useful and then I can
just simulate the fold by just flipping
one bit in the bootron binary and then
it works then know because the emulator
is still not really Hardware I also
tested this in lab setup and then it
basically works first try so that's
super nice but of course a lab setup is
still not something everyone has at home
so let's design a mod ship now so what
boot medium are we going to use here
well a game cartridge for some reason
the bootom is know written search that
game cartridge cannot use the
compression options which we need so
yeah that's not an option the second
option is emmc but we kind of can rely
on MMC because we still want to use it
even though the MMC is bad and replacing
the MMC needs BJ rework which is super
annoying so no last option is the Spy
fles which is you luckily much simpler
and well it would be nice to use emfi
with a modchip but no that's not super
practical so the only option here is to
use voltage glitching because emfi needs
know you saw the pulse generator it's
pretty big and yeah that's not going to
fit luckily we can also just use a Wi-Fi
interposer PCB which means you just plug
this PCB into your DSI and then solar
like these two test points and then it
should work and you know I spent some
time in Kad made the pcbs and actually
started validating them so that's how it
looks like installed with some debug
probes uh actually obscuring it a little
bit which means I can actually
demonstrate it and I have the setup over
here let's hope it
works that's so yeah we have the mod
chip installed
here and if everything's correct it
should turn on and there we go
[Music]
[Applause]
so uh can we switch back to the slides
please right okay so I also have a video
as a backup which well I don't really
need to use it anymore even though I
spent the entire time yesterday just to
get my to work because it broke at one
point and yeah it's basically going to
show the same thing but uh an
interesting thing here is that it also
shows a debug lock which I'm going to
explain for a quick second because I
still have quite a bit of time left
which is okay it froze that's not
[Music]
good uh yeah that's just not going to
work oh well yeah the thing is that it
uh snoops this SPI bus to actually know
what time to uh glitch and then it Bas
basically works from the first or second
try because it's actually super stable
which is nice and then it dumps a few
bites of the bootom and it's super s
that you can see that but the slides are
online or will be very shortly after the
presentation so you can also look at it
yourself so yeah as a quick recap uh the
arm 7 well I done the arm 7 bootom using
the vector glitch hack then the arm9
bootom was dumped using a double glitch
hack
then I analyzed these wot droms to you
know see where there's anything
interesting and there's a weak spot
Against full attacks so then I made an
exploit for that and then made a MIP to
actually make this exploit practical so
yeah that's about it uh the DSi
interestingly it has a lot of custom
things compared to the 3DS which has you
know more standard cryptography it
follows the pkcs standard and that was
actually the way it was completely
messed up the 3DS has an operating
system that the DSi doesn't so yeah it's
pretty interesting to see that you need
quite a complicated exploit to attack
the DSi even though the 3s is on paper
much stronger so that actually sort of
thickened the encryption so yeah and of
course all of this was only possible
because they also leaked the second boot
stage of the DSi in the 3DS so yeah a
few years back at another Nintendo
hacking talk people said that well
Secrets hidden are hidden in or gate
unless you give them away and that's
still a conclusion here so
yeah so I want to thank a few people for
this uh s normat who basically did
exactly the same thing I was doing but
in parallel at the same time which is
pretty interesting arur and Leonard
helped me with all the F injection
setups especially at the beginning no
cash for making on launch which was
really helpful and basically needed for
doing all this work also arra and
everyone who has helped with melanz
because that's saved me a lot of time
everyone in these chats for you know
being able to bounce of IDs and also
Nintendo because this was a fun hacking
[Music]
challenge so if you're in
no yes I'm almost done just like one or
two more minutes but
I'm more than in time so it's going to
be fine anyway so if you're interested
and want to see how the glitching setups
work there's links here the slides will
be online so you'll be able to find that
um the melon DS patches for ggb those
are already up stream so you can
actually use it and people are al
already finding this to find exploits in
the DSi browser so that's actually
really nice to see I've been updating
DSi r with all my
findings and the M firmware is going to
be public really soon
same thing with the exploit payload and
what's the start of the new init code
because of course after this you know
need to initialize all the hardware then
loads you know the homework menu or
whatever from the SD card so that people
can actually use it for practical things
like playing
games uh the mai pcbs those designs are
not going to be public immediately
because there's still a few bugs in them
and no well of course there's also bugs
in the other code but updating soft is
easy updating Hardware well you can't
really update a PCB you have to
manufacture a new one and I don't want
people to walk around with broken ones
so you're going to have to wait a bit
sorry but for people who want a Sol ring
challenge I've written up a quick DIY
guide I'm probably going to expand a bit
more it because there's no images yet
but it will be so if you want to try it
out yourself feel free to do so so now
everyone can jump a bootrom and everyone
can dump uh can revive brick DSi now
there's like a small thing of course the
mod ship firmware it currently hardcodes
the glitch parameters which is not good
because these can change with like
temperature variations and stuff it also
means you don't have Wi-Fi currently
which is also not super useful and the
payload currently well it shows a nice
screen but it doesn't do anything else
and yeah the basic thing is that you now
need to draw the rest of the hour do all
the work the second boot stage does
which is like initializing the dam
initializing the sound initi the touch
screen and everything else and then also
load some games from or home room from
the SD
card uh so yeah I oh yeah that's whoops
I'm one behind so yeah all help is
welcome here because I probably don't
have all the time to do it myself so
that's the entire presentation thank
[Applause]
[Music]
you
oh thank you poro for those already
leaving please take your junk take your
bottles you know and follow the 621 plus
rule the 621 plus rule is 6 hours of
sleep two warm wheals one hot show and
wear a mask I see a whole lot of people
not wearing any masks you should be
wearing masks anyhow we'll be taking
question there's a phone here a mic here
and a mic there this is the first
question no statements questions one
sentence
please just and please be quiet we're
still we're still in session here while
you're going out please don't
talk just uh thanks for the great talk
and I just didn't understand how you got
the modifying the W Ram in the first
place uh sorry what's the question
exactly so at the the beginning you had
to modify the w r yeah uh how did you do
that um well for that you know there's
already exploits out there that so you
can like put a file in your SD card and
that that's going to exploit like the
flit node program or the photo taking
program and that way you can get code
execution but it's at a low privilege
level but of course there's no memory
management unit so you can just write to
any piece of physical memory so just
fill WAM and then you reboot to console
okay okay thank you um yet is there a
question from the internet signal
Angel no no okay please go ahead uh yes
maybe I missed that part but could you
repeat about uh how you knew when to
perform the glitch attacks uh did you
did you use the SPI spy
or yeah so uh for the yeah so for the
very first thing the uh Vector glitch
hack for that there was like a huge
timing window and I just had to root
Force at all I try to use for example
power side channels to see when the CPUs
spin up but that didn't really do
anything so I just had to brute force it
to break out of the loop of the R9 uh
Cod uh the R9 you know infinite Loop
thing for that timing isn't critical
because it's stuck in an infinite Loops
so you just insert a glitch whenever and
for the final attack the MIP attack it's
somewhere between uh the last SPI bite
being read from the boo header and then
some kind of uh SPI thing that's sent to
the power management controller to power
the LCD screen so that it can show a
boot error number and then it's like
somewhere between that time it's not
super long and then I also just brute
forced it and I eventually found the
correct one okay thanks okay okay next
try for the internet question signal
angel
please uh
H technology
problems yeah oh now it works uh the
internet has one question uh if the
glitching did work on other devices of
the same model because they said it
sometimes it's really Hardware dependent
yeah so I have a few DSis at the lab
which I all managed to glitch so that
works fine but I mean there's like a
little little bit of variation between
the parameters like sometimes it needs
to be like a few Nan seconds longer
sometimes it's a little bit shorter uh
for that I actually need to automate the
training for this in the MIP frameware
which hasn't been done yet but it's not
going to be a huge issue and also
currently I only have DSis because those
are cheaper on the secondhand Market but
there's nothing stopping this from
working on the DSi Excel for
example okay okay you people there one
please yeah hello um say hi from the
Nintendo home bro Discord server and um
you said that the DS cartridges have
symmetric cryptography while DSi and 3DS
have asymmetric cryptography between the
console um so how do the DS um like
flash cards work on on DSi and 3DS and
uh how do DSi and 3DS flash cards work
yes so um there's this interesting thing
where uh DS games even though they don't
use the hardare of the DSi that after
the DSi was released they also include
an RSA signature and for the ones you
know released before that they of course
don't have an RSA signature but for that
uh the the DSi system menu has an allow
list where it has like a list of allowed
hashes of the binaries of a game uh
which um are then allowed to also run
for like all the older stuff and the way
that all the new flash cards work is
basically you have like Supply or ROM of
the like one of the games which just
happen to have a save game vulnerability
and then it just you know loads up the
game does a save game vulnerability and
then it gets you know takes over and
then it just shows you the menu of the
flash card all right thank you okay is
that a question right in the back there
at the microphone yes that'll be the
second to last and you'll be the last
okay
please uh thank you for the presentation
uh I've seen you you were think
I think that was a chip shouter would
you be willing to share the timings for
the attacks including the clocks and
stuff like that uh I don't know them by
heart uh yeah but just somewhere on
GitHub or something like that yeah uh
the Jupiter notebooks are like the only
one I did only things I didn't publish
but yeah I can put it online if you want
uh just the timings for the Curiosity
yeah it was like somewhere between 50
and 90
NS I needed at least 350 volts of the
poles but also no more than 400 in some
cases and how many clock Cycles is that
correlates only one or like uh it's a
few clock Cycles but not many okay thank
you please hi thank you first uh are the
boot drums the same thing as what are
called the BIOS
images uh yes and no so for the GBA and
the regular DS those are indeed the
exact same thing
uh which is kind of a misn because they
aren't really a bios but oh well uh for
the DSi you had the public half of the
boots people read that out and then
called that the BIOS because it has all
the software interrupt the utility
routines so I'm just calling the full
images the boot ROMs but you know it's
more or less the same thing so the
previous images dumped were without the
boot code yes so they only contained the
utility routines and the exception
vectors thank you okay let's wrap this
up with one final big hand for poro
[Applause]
[Music]
[Applause]
[Music]
please