#rC3 - Hacking the Nintendo Game & Watch

rC3 Opening Music

Herald: So about our next speaker. He's a
security researcher focused on embedded

systems, secure communications and mobile
security. He was nominated by

Forbes for the 30 under 30 in technology
and also has won a OWASP Appsec CTF.

He has also found and disclosed responsibly
multiple vulnerabilities. And especially

for you Nintendo aficionados I want you to
watch out for the next intro, which is

really amazing and you will all love.
Thank you very much.

shows nintendo cartridge

plugs cartridge

nintendo start sound plays

Thomas: Oh, damn it.
retrieves cartridge

blows into cartridge
plugs cartridge again

nintendo start sound plays

music plays

Thomas Roth: Uff, what a trip.
Welcome to my talk on

hacking the new Nintendo Game & Watch
Super Mario Brothers. My name is Thomas

Roth and I'm a security researcher and
trainer from Germany. And you can find me

on Twitter at @ghidraninja and also on
YouTube at stacksmashing. Now, this year

marks the 35th anniversary of our favorite
plumber, Super Mario And to celebrate

that, Nintendo launched a new game console
called the Nintendo Game & Watch Super

Mario Brothers. The console is lightweight
and looks pretty nice, and it comes

preinstalled with three games and also
this nice animated clock. The three games

are Super Mario Brothers, the original NES
game, Super Mario Brothers 2 The Lost

Levels and also a reinterpretation of an
old Game & Watch game called Ball. Now, as

you probably know, this is not the first
retro console that Nintendo released. In

2016, they released the NES Classic and
2017 they released the SNES Classic. Now,

these devices were super popular in the
homebrew community, because they make it

really easy to add additional ROMs to it.
They make it really easy to modify the

firmware and so on. And you can basically
just plug them into your computer, install

a simple software and you can do whatever
you want with them. The reason for that is

that they run Linux and have a pretty
powerful ARM processor on the inside. And

so it's really a nice device to play with
and so on. And so when Nintendo announced

this new console, a lot of people were
hoping for a similar experience of having

a nice mobile home brew device. Now, if
you were to make a Venn diagram of some of

my biggest interests, you would have
reverse engineering, hardware hacking and

retro computing. And this new Game & Watch
fits right in the middle of that. And so

when it was announced on the 3rd of
September, I knew that I needed to have

one of those. And given how hard the NES
and SNES classic were to buy for a while,

I preordered it on like four or five
different sites, a couple of which got

canceled. But I was pretty excited, because
I had three preorders and was supposed to

ship on the 13th of November. And so I was
really looking forward to this. And I was

having breakfast on the 12th of November,
when suddenly the doorbell rang and DHL

delivered me the new Game & Watch one day
before the official release. Now, at that

point in time, there was no technical
information available about the device

whatsoever. Like, if you searched for Game
& Watch on Twitter, you would only find

denouncements or maybe a picture of the
box of someone who also received it early.

But there were no teardowns, no pictures
of the insides and most importantly,

nobody had hacked it yet. And this gave
me, as a hardware hacker, the kind of

unique opportunity to potentially be the
first one to hack a new Nintendo console.

And so I just literally dropped everything
else I was doing and started investigating

the device. Now, I should say that
normally I stay pretty far away from any

new console hacking. Mainly, because of the
piracy issues. I don't want to enable

piracy. I don't want to deal with piracy.
And I don't want to build tools that

enable other people to pirate stuff,
basically. But given that on this device,

you cannot buy any more games and that all
the games, that are on there, were basically

already released over 30 years ago. I was
not really worried about piracy and felt

pretty comfortable in sharing all the
results of the investigation and also

the... basically the issues we found that
allowed us to customize the device and so

on. And in this talk, I want to walk you
through, how we managed to hack the device

and how you can do it at home using
relatively cheap hardware. And, yeah, hope

you enjoy it. Now, let's start by looking
at the device itself. The device is

pretty lightweight and comes with a nicely
sized case. And so it really... for me, it

sits really well in my hand. And it has a
nice 320 by 240 LCD display, a d-pad, A

and B buttons and also three buttons to
switch between the different game modes.

On the right side we also have the power
button and the USB-C port. Now, before you

get excited about the USB port, I can
already tell you that unfortunately,

Nintendo decided to not connect the data
lines off the USB port. And so you can

really only use it for charging. Also,
because we are talking about Nintendo

here, they use their proprietary tri-point
screws on the device. And so to open it

up, you need one of those special tri-
point bits. Luckily, nowadays, most bit

sets should have them, but it still would
suck, if you order your unit and then you

can't open it up, because you're missing a
screwdriver. After opening it up, the

first thing you probably notice is the
battery. And if you've ever opened up a

Nintendo switch joycon before, you might
recognize the battery, because it's the

exact same one that's used in the joycons.
This is very cool, because if down the

line, like, let's say in two or three
years, your battery of your Game & Watch

dies, you can just go and buy a joycon
battery, which you can have really

cheaply, almost anywhere. Next to the
battery, on the right side, we have a

small speaker which is not very good. And
underneath we have the main PCB with the

processor, all the storage and so on and
so forth. Let's take a look at those. Now,

the main processor of the device is an
STM32H7B0. This is a Cortex M7 from

STMicroelectronics with 1.3 MB of RAM and
128 kB of flash. It runs at 280 MHz and is

a pretty beefy microcontroller. But it's
much less powerful than the processor in

the NES or SNES classic. Like this
processor is really just a microcontroller

and so it can't run Linux. It can't run,
let's say, super complex software. Instead

it'll be programed in some bare metal
way. And so we will have a bare metal

firmware on the device. To the right of
it, you can also find a 1 MB SPI flash.

And so overall, we have roughly 1.1 MB of
storage on the device. Now, most

microcontrollers or basically all
microcontrollers have a debugging port.

And if we take a look at the PCB, you can
see that there are five unpopulated

contacts here. And if you see a couple of
contacts, that are not populated close to

your CPU, it's very likely, that it's the
debugging port. And luckily, the datasheet

for the STM32 is openly available. And so
we can check the pinouts in the datasheet

and then use a multimeter to to see
whether these pins are actually the

debugging interface. And turns out they
actually are. And so we can find the SWD

debugging interface as well as Vcc and
ground exposed on these pins. Now this

means that we can use a debugger. So, for
example, a J-link or ST-link or whatever

to connect to the device. And because the
the contacts are really easy to access,

you don't even have to solder. You can
just hook up a couple of test pins and

they will allow you to easily hook-up
your debugger. Now, the problem is, on most

devices, the debugging interface will be
locked during manufacturing, this is done

to prevent people like us to basically do
whatever with the device and to prevent us

from being able to dump the firmware,
potentially reflash it and so on. And so I

was very curious to see, whether we can
actually connect to the debugging port.

And when starting up J-link and trying to
connect, we can see it can actually

successfully connect. But, when you take a
closer look, there's also a message that

the device is active read protected. This
is because the chip, the STM32 chip,

features something called RDP protection
level or readout protection level. This is

basically the security setting for the
debugging interface and it has three

levels. Level zero means no protection is
active. Level one means that the flash

memory is protected and so we can't dump
the internal flash of the device. However,

we can dump the RAM contents and we can
also execute code from RAM. And then

there's also level two, which means that
all debugging features are disabled. Now,

just because a chip is in level two,
doesn't mean that you have to give up.

For example, in our talk wallet.fail a couple
of years ago, we showed how to use fault

injection to bypass the level two
protection and downgrade a chip to level

one. However, on the Game & Watch, we are
lucky and the interface is not fully

disabled. Instead, it's in level one. And
so we can still dump the RAM, which is a

pretty good entry point, even though we
can't dump the firmware yet. Now, having

dumped the RAM of the device, I was pretty
curious to see, what's inside of it. And

one of my suspicions was, that potentially
the emulator, that's hopefully running on

the device, loads the original Super Mario
Brothers ROM into RAM. And so, I was

wondering whether maybe we can find the
ROM that the device uses in the RAM-dump.

And so I opened up the RAM-dump in a hex
editor and I also opened up the original

Super Mario Brothers ROM in a second
window in a hex editor and tried to find

different parts of the original ROM in the
RAM-dump. And it turns out that, yes, the

NES ROM is loaded into RAM and it's always
at the same address. And so it's probably

like during boot up, it gets copied into
RAM or something along those lines. And so

this is pretty cool to know, because it
tells us a couple of things. First off, we

know now that the debug port is enabled
and working, but that it's unfortunately

at RDP level one and so we can only dump
the RAM. And we also know that the NES ROM

is loaded into RAM. And this means that
the device runs a real NES emulator. And

so if we get lucky, we can, for example,
just replace the ROM that is used by

the device and play, for example,
our own NES game.

little pause

Next, it was time to dump the flash chip

of the device. For this, I'm using a
device called Mini Pro and I'm using one

of these really useful SOIC8 clips. And so
these ones you can simply clip onto the

flash chip and then dump it. Now, one
warning though, the flash chip on the device,

is running at 1.8 volts. And so you want to
make sure that your programmer also

supports 1.8 volt operation. If you
accidentally try to read it out at 3.3 volts,

you will break your flash. Trust
me, because it happened to me on one of my

units. Now, with this flash dump from the
device, we can start to analyze it. And

what I always like to do first, is take a
look at the entropy or the randomness of

the flash dump. And so using binwalk with
the -E option, we get a nice entropy

graph. And in this case, you can see we
have a very high entropy over almost the

whole flash contents. And this mostly
indicates, that the flash contents are

encrypted. It could also mean compression,
but if it's compressed, you would often

see more like dips in the entropy. And in
this case, it's one very high entropy

stream. We also noticed, that there are no
repetitions whatsoever, which also tells

us that it's probably not like a simple
XOR based encryption or so and instead

something like AES or something similar.
But, just because the flash is encrypted

doesn't mean we have to give up. On the
contrary, I think now it starts to get

interesting, because you actually have a
challenge and it's not just plug and play,

so to say. One of the biggest questions I
had is, is the flash actually verified?

Like does the device boot, even though the
flash has been modified? Because, if it

does, this would open up a lot of attack
vectors, basically, as you will see. And

so to verify this, I basically try to
put zeros in random places in the flash

image. And so, I put some at adress zero,
some at 0x2000 and so on. And then I

checked whether the device would still
boot-up. And with the most flash

modifications, it would still boot just
fine. This tells us, that even though the

flash contents are encrypted, they are not
validated, they are not checksummed or

anything. And so we can potentially trick
the device into accepting a modified flash

image. And this is really important to
know, as you will see in a couple of

minutes. My next suspicion was, that maybe
the NES ROM we see in RAM, is actually

loaded from the external flash. And so to
find out whether that's the case, I again

took the flash and I inserted zeros at
multiple positions in the flash image.

Flashed that over, booted-up the game,
dumped the RAM and then compared the NES

ROM that I'm now dumping from RAM with the
one that I dumped initially and checked

whether they are equal. Because my
suspicion was that maybe I can overwrite a

couple of bytes in the encrypted flash and
then I will modify the NES room. And after

doing this for, like, I don't know, half
an hour, I got lucky and I modified 4

bytes in the flash image and 4 bytes in the
RAM...sorry...in the ROM that was loaded

into RAM changed. And this tells us quite
a bit. It means that the ROM is loaded

from flash into RAM and that the flash
contents are not validated. And what's

also important is, that we change 4
bytes in the flash and now 4 bytes in

the decrypted image changed. And this is
very important to know, because if we take

a look at what we would expect to happen
when we change the flash contents, there

are multiple outcomes. And so, for
example, here we have the SPI-flash

contents on the left and the RAM contents
on the right. And so the RAM contents are

basically the decrypted version of the
SPI-flash contents. Now let's say we

change 4 bytes in the encrypted flash
image to zeros. How would we expect the

RAM contents to change, for example, if we
would see that now 16 bytes in the RAM are

changing, this means that we are
potentially looking at an encryption

algorithm, such as AES in electronic
codebook mode. Because, it's a block based

encryption and so if we change four bytes
in the input data, a block size, in this

case 16 bytes, in the output data would
change. The next possibility is, that we

change 4 bytes in the SPI-flash and all
data afterwards will be changed. And in

this case, we would look at some kind of
chaining cipher such as AES in the CBC

mode. However, if we change 4 bytes in
the SPI-flash and only 4 bytes in the

RAM changed, we are looking at
something such as AES in counter mode. And

to understand this, let's take a better
look at how AES in CTR works. AES-CTR

works by having your cleartext and xoring
it with an AES encryption stream, that is

generated from a key, a Nonce and the
counter algorithm. Now, the AES stream,

that will be used to xor your your
cleartext will always be the same, if key

and Nonce is the same. This is why it's
super important, that if you use AES-CTR,

you always select a unique Nonce for each
encryption. If you encrypt similar data

with the same Nonce twice, large parts of
the resulting ciphertext will be the same.

And so the cleartext gets xored with the
AES-CTR stream and then we get our

ciphertext. Now, if we know the cleartext,
as we do, because the cleartext is the ROM,

that is loaded into RAM and we know the
ciphertext, which we do, because it's the

contents of the encrypted flash we just
dump. We can basically reverse the

operation and as a result, we get the AES-
CTR stream, that was used to encrypt the

flash. And now this means, that we can
take, for example, a custom ROM, xor it

with the AES-CTR stream we just
calculated and then generate our own

encrypted flash image, for example, with a
modified ROM. And so I wrote a couple of

Python scripts to try this. And after a
while, I was running Hacked Super Mario

Brothers instead of Super Mario Brothers.
So, wohoo, we hacked the Nintendo Game &

Watch one day before the official release.
And we can install modified Super Mario

Brothers ROMs. Now, you can find the
scripts that I used for this on my Github.

So it's in a repository called "Game &
Watch Hacking". And I was super excited,

because it meant, that I succeeded and that
I basically hacked a Nintendo console one

day before the official release.
Unfortunately, I finished the level, but

Toad wasn't as excited. He told me that
unfortunately, our firmware is still in

another castle. And so on the Monday after
the launch of the device, I teamed up with

Konrad Beckman, a hardware hacker from
Sweden who I met at the previous Congress.

And we started chatting and throwing ideas
back and forth and so on. And eventually

we noticed that the device has a special
RAM area called ITCM-RAM, which is a

tightly coupled instruction RAM that is
normally used for very high performance

routines such as interrupt handlers and so
on. And so it's in a very fast RAM area.

And we realized that we never actually
looked at the contents of that ITCM-RAM.

And so we dumped it from the device using
the debugging port. And it turns out that

this ITCM-RAM contains ARM code. And so,
again, the question is, where does this

ARM code come from, does it maybe just
like the NES ROM come from the external

flash? And so basically, I repeated the
whole thing that we also did with the NES

ROM and just put zeros at the very
beginning of the encrypted flash. Rebooted

the device and dumped the ITCM-RAM and I
got super lucky on the first try already

the ITCM contents changed. And because the
ITCM contains code, not just data, so

early we only had the NES-ROM, which is
just data, but this time the RAM contains

code. This means that with the same x or
trick we used before, we could inject

custom ITCM code into the external flash,
which would then be loaded into RAM when

the device boots. And because it's a
persistent method, we can then reboot the

device and let it run without the debugger
connected. And so whatever code we load

into this ITCM area will be able to
actually read the flash. And so we could

potentially write some code that gets
somehow called by the firmware and then

copies the internal flash into RAM from
where we then can retrieve it using the

debugger. Now, the problem is, let's say
we have a custom payload somehow in this

ITCM area. We don't know which address of
this ITCM code gets executed. And so we

don't know whether the firmware will jump
to adress zero or adress 200 or whatever.

But there's a really simple trick to still
build a successful payload. And it's

called a NOP slide. A NOP, or no
operation, is an instruction that simply

does nothing. And if we fill most of the
ITCM-RAM with NOPs and put our payload at

the very end, we build something that is
basically a NOP-slide. And so when the

CPU, indicated by Mario here, jumps to a
random address in that whole NOP-slide, it

will start executing NOPs and slide down
into our payload and execute it. And so

even if Mario jumps right in the middle of
the NOP-slide, he will always slide down

the slide and end up in our payload. And
Konrad wrote this really, really simple

payload, which is only like 10
instructions, which basically just copies

the internal flash into RAM from where we
can then retrieve it using the debugger.

So wohoo, super simple exploit. We have a
full firmware backup and a full flash

backup and now we can really fiddle with
everything on the device. And we've

actually released tools to do this
yourself. And so if you want to back up

your Nintendo Game & Watch, you can just
go onto my GitHub and download the game

and watch backup repository, which
contains a lot of information on how to

back it up. It does check something and
so on to ensure that you don't

accidentally brick your device and you can
easily back up the original firmware,

install homebrew, and then always go back
to the original software. We also have an

awesome support community on Discord. And
so if you ever need help, I think you will

find success there. And so far we haven't
had a single bricked Game & Watch and so

looks to be pretty stable. And so I
was pretty excited because the quest was

over. Or is it? If you ever claim on the
internet that you successfully hacked an

embedded device, there will be exactly one
response and one response only: but does

it run Doom? Literally my Twitter DMs, my
YouTube comments, and even my friends were

spamming me with the challenge to get Doom
running on the device. But to get Doom

running, we first needed to bring up all
the hardware. And so we basically needed

to create a way to develop and load
homebrew onto the device. Now, luckily for

us, most of the components on the board
are very well documented and so there are

no NDA components. And so, for example,
the processor has an open reference manual

and open source library to use it. The
flash is a well-known flash chip. And so

on and so forth. And there are only a
couple of very proprietary or custom

components. And so, for example, the LCD
on the device is proprietary and we had to

basically sniff the SPI-bus that goes to
the display to basically decode the

initialization of the display and so on.
And after a while, we had the full

hardware running, we had LCD support, we
had audio support, deep support, buttons

and even flashing tools that allow you to
simply use an SWD debugger to dump and

rewrite the external flash. And you can
find all of these things on our GitHub.

Now, if you want to mod your own Game &
Watch, all you need is a simple debugging

adapter such as a cheap, three dollar ST-
link, a J-link or a real ST-link device,

and then you can get started. We've also
published a base project for anyone who

wants to get started with building their
own games for the Game & Watch. And so

it's really simple. It's just a frame
buffer you can draw to, input is really

simple and so on. And as said, we have a
really helpful community. Now with all the

hardware up and running, I could finally
start porting Doom. I started by looking

around for other ports of Doom to an
STM32. And I found this project by floppes

called stm32doom. Now the issue is,
stm32doom is designed for a board with

eight megabytes of RAM and also the data
files for Doom were stored on external USB

drive. On our platform, we only have 1.3
MB of RAM, 128 kB of flash and only 1 MB

of external flash and we have to fit all
the level information, all the code and

so on in there. Now, the Doom level
information is stored in so-called WAD -

Where's All my Data files. And these data
files contain the sprites, the textures,

the levels and so on. Now the WAD for Doom
1 is roughly four megabytes in size and

the WAD for Doom 2 is 40 MB in size. But
we only have 1.1 MB of storage. Plus we

have to fit all the code in there. So
obviously we needed to find a very, very

small Doom port. And as it turns out,
there's a file called Mini-WAD, which is a

minimal Doom, I wrote, which is basically
all the bells and whistles are stripped

from the WAD file and everything replaced
by simple outlines and so on. And while

it's not pretty, I was pretty confident
that I could get it working as it's only

250 kB of storage, down from 40 megabytes.
Now, in addition to that, a lot of stuff

on the Chocolate Doom port itself had to
be changed. And so, for example, I had to

rip out all the file handling and add a
custom file handler. I had to add support

for the Game & Watch LCD, button input
support. And I also had to get rid of a

lot of things to get it running somewhat
smoothly. And so, for example, the

infamous Wipe effect had to go and I also
had to remove sound support. Now, the next

issue was that once it was compiling, it
simply would not fit into RAM and crash

all the time. Now on the device, we have
roughly 1.3 MB of RAM in different RAM

areas. And for example just the frame
buffer, that we obviously need, takes up

154 kB off that. Then we have 160 kB of
initialized data, 320 kB of uninitialized

data and a ton of dynamic allocations that
are done by Chocolate Doom. And these

dynamic allocations were a huge issue
because the Chocolate Doom source code

does a lot of small allocations, which are
only used for temporary data. And so they

get freed again and so on, and so your
dynamic memory gets very, very fragmented

very quickly, and so eventually there's
just not enough space to, for example,

initialize the level. And so to fix this,
I took the Chocolate Doom code and I

changed a lot of the dynamic allocations
to static allocations, which also had the

big advantage of making the error messages
by the compiler much more meaningful.

Because it would actually tell you: Hey,
this and this data does not fit into RAM.

And eventually, after a lot of trial and
error and copying as many of the original

assets as possible into the minimal IWAD,
I got it. I had Doom running on the

Nintendo Game & Watch Super Mario Brothers
and I hopefully calmed the internet gods

that forced me to do it. Now,
unfortunately, the USB port is physically

not connected to the processor and so it
will not be possible to hack the device

simply by plugging it into your computer.
However, it's relatively simple to do this

using one of these USB-Debuggers. Now, the
most requested type of homebrew software

was obviously emulators. And I'm proud to
say that by now we actually have kind of a

large collection of emulators running on
the Nintendo Game & Watch. And it all

started with Conrad Beckman discovering
the Retro Go Project, which is an emulator

collection for a device called the Odroid
Go and the Odroid Go is a small handheld

with similar input and size constraints as
the Nintendo Game & Watch. And so it's

kind of cool to port this over because it
basically already did all of the hard

work, so to say. And Retro Go comes with
emulators for the NES, for the Gameboy and

the Gameboy color and even for the Sega
Master System and the Sega Game Gear. And

after a couple of days, Conrad actually
was able to show off his NES emulator

running Zelda and other games such as
Contra and so on, on the Nintendo Game &

Watch. This is super fun and initially we
only had really a basic emulator that

could barely play and we had a lot of
frame drops, we didn't have nice scaling,

VSync and so on. But now after a couple of
weeks, it's really a nice device to use

and to play with. And so we also have a
Gameboy emulator running and so you can

play your favorite Gameboy games such as
Pokémon, Super Mario Land and so on on the

Nintendo Game & Watch if you own the
corresponding ROM Backups. And we also

experimented with different scaling
algorithms to make the most out of the

screen. And so you can basically change
the scaling algorithm that is used for the

display, depending on what you prefer. And
you could even change the palette for the

different games. We also have a nice game
chooser menu which allows you to basically

have multiple ROMs on the device that you
can switch between. We have safe state

support and so if you turn off the device,
it will save wherever you left off and you

can even come back to your save game once
the battery run out. You can find the

source code for all of that on the Retro
Go repository from Conrad. And it's

really, really awesome. Other people build
for example emulators for the CHIP-8

system and so the CHIP-8 emulator comes
with a nice collection of small arcade

games and so on, and it's really fun and
really easy to develop for it. And so

really give this a try if you own a Game &
Watch and want to try homebrew on it. Tim

Schuerwegen is even working on an
emulator for the original Game & Watch

games. And so this is really cool because
it basically turned the Nintendo Game &

Watch into an emulator for all Game &
Watch games that were ever released. And

what was really amazing to me is how the
community came together. And so we were

pretty open about the progress on Twitter.
And also Conrad was Twitch streaming a lot

of the process. And we opened up a discord
where people could join who were

interested in hacking on the device. And
it was amazing to see what came out of the

community. And so, for example, we now
have a working storage upgrade that works

both with homebrew but also with the
original firmware. And so instead of one

megabyte of storage, you can have 60
megabytes of flash and you just need to

replace a single chip, which is pretty
easy to do. Then for understanding the

full hardware. Daniel Cuthbert and Daniel
Padilla provided us with high resolution x

ray images, which allowed us to fully
understand every single connection, even

of the PGA parts, without desoldering
anything. Then Jake Little of Upcycle

Electronics traced on the x rays and also
using a multimeter every last trace on the

PCB, and he even created a schematic of
the device, which gives you all the

details you need when you want to program
something also and it was really, really

fun. Sander van der Wel for example even
created a custom backplate and now there

are even projects that try to replace the
original PCB with a custom PCB with an

FPGA and an ESP 32. And so it's really
exciting to see what people come up with.

Now, I hope you enjoyed this talk and I
hope to see you on our discord if you want

to join the fun. And thank you for coming.

Herald: Hi. Wow, that was a really amazing
talk. Thank you very much Thomas. As

announced in the beginning we do accept
questions from you and we have quite a

few. Let's see if we manage to make it
through all of them. The first one is:

Q: Did you read the articles about
Nintendo observing hackers, like private

investigators, et cetera and are you
somehow worried about this?

Thomas: Oh, what's going on with my
camera? Looks like Luigi messed around

with my video setup here. Yeah, I so I've
read those articles, but so I believe that

in this case, there is no piracy issue,
right? Like, I'm not allowing anyone to

play any new games. If you wanted to to
dump a Super Mario ROM, you would have

done it 30 years ago or on the NES Classic
or on the Switch or on any of the hundred

consoles Nintendo launched in between. And
so I'm really not too worried about it, to

be honest.
Herald: I also think the aspect of the

target audience is to be seen here. So off
to the next question which is: Do you

think that there is a reason why an
external flash chip has been used?

Thomas: Yeah. So the internal flash of the
STM32-H7B0 is relatively small. It's only

128 kB. And so they simply couldn't
fit everything in, like basically even

just the frame buffer. Even just a frame
buffer picture also is larger than the

internal flash. And so I think that's why
they did it and I'm glad they did.

Herald: Sure. And is the decryption done
in software or is it a feature of the

microcontroller?
Thomas: So the microcontroller has an

integrated feature called OTF-DEC and
basically the flash is directly mapped

into memory and they have this chip
prefill called OTF DEC that automatically

provides the decryption and so on. And so
it's done all in hardware and you can even

retrieve the keys from hardware,
basically.

Herald: OK, very nice. And also, the next
question is somehow related to that: Is in

your opinion the encryption Nintendo has
applied even worth the effort for them?

It feels like it's just there to give
shareholders a false sense of security.

What would you think about that?
Thomas: I think from my perspective, they

choose just the right encryption because
it was a ton of fun to reverse engineer

and try to to bypass it and so it was an
awesome challenge and so I think they did

everything right. But I also think in the
end, it's such a simple device and it's

like if you take a look at what people are
building on top of it with like games and

all that kind of stuff. I think they did
everything right, but probably it was just

a tick markup. Yeah, we totally locked
down JTAG and yeah, but I think it's fun

because again, it doesn't open up any
piracy issues.

Herald: Sure. The one thing is related to
the NOP slide, which you very, very well

animated. So wouldn't starts of
subroutines be suitable as well for that,

for that goal. The person asking says that
a big push R4, R5, etc. instructions are

quite recognizable. How would ... Yeah
Thomas: Yeah. So absolutely. The time from

finding the data in the ITCM-RAM and
actually exploiting it was less than an

hour. And so if we would have tried to
reverse engineer it, it would be more

work. Like absolutely possible and also
not difficult, but just filling the RAM

with NOP took a couple of minutes and so
was really the easiest way and the fastest

way without fiddling around in Ghidra or so.
Herald: OK, cool, thanks. And this is more

a remark than a question. The person says
it's strange that an STAN5281 does not

mention a single time that the data is not
verified during encryption. I think it's

more a fault on STs than Nintendos site.
What would you think about that?

Thomas: Yeah, I would somewhat agree
because in this case, even if you don't

have JTAG, like an ARM thum instruction is
2-4 bytes and so you have a relatively small

space to brute force to potentially get an
interesting branch instruction and so on.

So I think it's yeah, I mean, it's
not perfect, but also doing verification

is very expensive, computational wise and
so I think it should just be the firmware

that actually verifies the contents of the
external flash.

Herald: OK, so I think we should ask 2
questions more and then we can go back to

the studio. There is a question about the
AS encryption keys. Have you managed to

recover them?
Thomas: Yes, we did. But so it's an

applicational AST, and they do some crazy
shifting around with the keys but I think

even just today, like an hour before the
talk, a guy, sorry I'm not sure it's a

guy, a person on our discord actually
managed to rebuild the full encryption.

But we, I personally wasn't never
interested in that because after you've

downgraded to RTP 0, the device. You can
just access the memory mapped flash and

get the completely decrypted flash
contents basically.

Herald: Sure. Thanks. And a last question
about the LCD-Controller, whether it's

used by writing pixels over SPI or if it
has some extra features, maybe even

background or sprites or something like
that?

Thomas: So the the LCD itself doesn't have
any special features. It has one SPI bus

to configure it and then a parallel
interface where - so it takes up a lot

of pins. But the chip itself has a
hardware called LTDC, which is an LCD

controller, which provides two layers with
alpha blending and some basic windowing

and so on.
Herald: OK, cool then thank you very, very

much for the great talk and the great
intro. And with that, back to our main

studio in the orbit. Thank you very much.
Back to orbit.

rC3 postroll music

Subtitles created by c3subtitles.de
in the year 2020. Join, and help us!