*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!