0:00:00.000,0:00:12.710
rC3 Opening Music
0:00:12.710,0:00:19.340
Herald: So about our next speaker. He's a[br]security researcher focused on embedded
0:00:19.340,0:00:26.500
systems, secure communications and mobile[br]security. He was nominated by
0:00:26.500,0:00:39.940
Forbes for the 30 under 30 in technology[br]and also has won a OWASP Appsec CTF.
0:00:39.940,0:00:46.790
He has also found and disclosed responsibly[br]multiple vulnerabilities. And especially
0:00:46.790,0:00:52.280
for you Nintendo aficionados I want you to[br]watch out for the next intro, which is
0:00:52.280,0:00:56.270
really amazing and you will all love.[br]Thank you very much.
0:00:56.305,0:01:00.825
shows nintendo cartridge
0:01:00.825,0:01:06.065
plugs cartridge
0:01:09.532,0:01:10.532
nintendo start sound plays
0:01:10.532,0:01:14.850
Thomas: Oh, damn it.[br]retrieves cartridge
0:01:14.850,0:01:19.980
blows into cartridge[br]plugs cartridge again
0:01:22.146,0:01:23.446
nintendo start sound plays
0:01:26.243,0:01:29.423
music plays
0:02:52.810,0:02:56.099
Thomas Roth: Uff, what a trip.[br]Welcome to my talk on
0:02:56.099,0:03:00.810
hacking the new Nintendo Game & Watch[br]Super Mario Brothers. My name is Thomas
0:03:00.810,0:03:05.290
Roth and I'm a security researcher and[br]trainer from Germany. And you can find me
0:03:05.290,0:03:10.719
on Twitter at @ghidraninja and also on[br]YouTube at stacksmashing. Now, this year
0:03:10.719,0:03:16.439
marks the 35th anniversary of our favorite[br]plumber, Super Mario And to celebrate
0:03:16.439,0:03:20.699
that, Nintendo launched a new game console[br]called the Nintendo Game & Watch Super
0:03:20.699,0:03:26.669
Mario Brothers. The console is lightweight[br]and looks pretty nice, and it comes
0:03:26.669,0:03:31.859
preinstalled with three games and also[br]this nice animated clock. The three games
0:03:31.859,0:03:36.920
are Super Mario Brothers, the original NES[br]game, Super Mario Brothers 2 The Lost
0:03:36.920,0:03:44.830
Levels and also a reinterpretation of an[br]old Game & Watch game called Ball. Now, as
0:03:44.830,0:03:49.939
you probably know, this is not the first[br]retro console that Nintendo released. In
0:03:49.939,0:03:57.400
2016, they released the NES Classic and[br]2017 they released the SNES Classic. Now,
0:03:57.400,0:04:01.729
these devices were super popular in the[br]homebrew community, because they make it
0:04:01.729,0:04:05.779
really easy to add additional ROMs to it.[br]They make it really easy to modify the
0:04:05.779,0:04:10.540
firmware and so on. And you can basically[br]just plug them into your computer, install
0:04:10.540,0:04:14.959
a simple software and you can do whatever[br]you want with them. The reason for that is
0:04:14.959,0:04:21.140
that they run Linux and have a pretty[br]powerful ARM processor on the inside. And
0:04:21.140,0:04:27.360
so it's really a nice device to play with[br]and so on. And so when Nintendo announced
0:04:27.360,0:04:31.650
this new console, a lot of people were[br]hoping for a similar experience of having
0:04:31.650,0:04:38.810
a nice mobile home brew device. Now, if[br]you were to make a Venn diagram of some of
0:04:38.810,0:04:43.099
my biggest interests, you would have[br]reverse engineering, hardware hacking and
0:04:43.099,0:04:48.539
retro computing. And this new Game & Watch[br]fits right in the middle of that. And so
0:04:48.539,0:04:52.920
when it was announced on the 3rd of[br]September, I knew that I needed to have
0:04:52.920,0:04:58.930
one of those. And given how hard the NES[br]and SNES classic were to buy for a while,
0:04:58.930,0:05:03.389
I preordered it on like four or five[br]different sites, a couple of which got
0:05:03.389,0:05:09.470
canceled. But I was pretty excited, because[br]I had three preorders and was supposed to
0:05:09.470,0:05:15.380
ship on the 13th of November. And so I was[br]really looking forward to this. And I was
0:05:15.380,0:05:19.909
having breakfast on the 12th of November,[br]when suddenly the doorbell rang and DHL
0:05:19.909,0:05:25.730
delivered me the new Game & Watch one day[br]before the official release. Now, at that
0:05:25.730,0:05:30.300
point in time, there was no technical[br]information available about the device
0:05:30.300,0:05:35.449
whatsoever. Like, if you searched for Game[br]& Watch on Twitter, you would only find
0:05:35.449,0:05:40.680
denouncements or maybe a picture of the[br]box of someone who also received it early.
0:05:40.680,0:05:44.900
But there were no teardowns, no pictures[br]of the insides and most importantly,
0:05:44.900,0:05:50.319
nobody had hacked it yet. And this gave[br]me, as a hardware hacker, the kind of
0:05:50.319,0:05:55.669
unique opportunity to potentially be the[br]first one to hack a new Nintendo console.
0:05:55.669,0:06:00.199
And so I just literally dropped everything[br]else I was doing and started investigating
0:06:00.199,0:06:05.949
the device. Now, I should say that[br]normally I stay pretty far away from any
0:06:05.949,0:06:11.460
new console hacking. Mainly, because of the[br]piracy issues. I don't want to enable
0:06:11.460,0:06:18.930
piracy. I don't want to deal with piracy.[br]And I don't want to build tools that
0:06:18.930,0:06:23.930
enable other people to pirate stuff,[br]basically. But given that on this device,
0:06:23.930,0:06:28.900
you cannot buy any more games and that all[br]the games, that are on there, were basically
0:06:28.900,0:06:33.840
already released over 30 years ago. I was[br]not really worried about piracy and felt
0:06:33.840,0:06:39.449
pretty comfortable in sharing all the[br]results of the investigation and also
0:06:39.449,0:06:44.490
the... basically the issues we found that[br]allowed us to customize the device and so
0:06:44.490,0:06:49.389
on. And in this talk, I want to walk you[br]through, how we managed to hack the device
0:06:49.389,0:06:54.931
and how you can do it at home using[br]relatively cheap hardware. And, yeah, hope
0:06:54.931,0:07:03.040
you enjoy it. Now, let's start by looking[br]at the device itself. The device is
0:07:03.040,0:07:08.469
pretty lightweight and comes with a nicely[br]sized case. And so it really... for me, it
0:07:08.469,0:07:14.889
sits really well in my hand. And it has a[br]nice 320 by 240 LCD display, a d-pad, A
0:07:14.889,0:07:19.529
and B buttons and also three buttons to[br]switch between the different game modes.
0:07:19.529,0:07:23.940
On the right side we also have the power[br]button and the USB-C port. Now, before you
0:07:23.940,0:07:28.640
get excited about the USB port, I can[br]already tell you that unfortunately,
0:07:28.640,0:07:33.030
Nintendo decided to not connect the data[br]lines off the USB port. And so you can
0:07:33.030,0:07:38.550
really only use it for charging. Also,[br]because we are talking about Nintendo
0:07:38.550,0:07:43.979
here, they use their proprietary tri-point[br]screws on the device. And so to open it
0:07:43.979,0:07:48.730
up, you need one of those special tri-[br]point bits. Luckily, nowadays, most bit
0:07:48.730,0:07:54.120
sets should have them, but it still would[br]suck, if you order your unit and then you
0:07:54.120,0:07:59.639
can't open it up, because you're missing a[br]screwdriver. After opening it up, the
0:07:59.639,0:08:03.779
first thing you probably notice is the[br]battery. And if you've ever opened up a
0:08:03.779,0:08:07.599
Nintendo switch joycon before, you might[br]recognize the battery, because it's the
0:08:07.599,0:08:12.729
exact same one that's used in the joycons.[br]This is very cool, because if down the
0:08:12.729,0:08:16.529
line, like, let's say in two or three[br]years, your battery of your Game & Watch
0:08:16.529,0:08:20.650
dies, you can just go and buy a joycon[br]battery, which you can have really
0:08:20.650,0:08:26.520
cheaply, almost anywhere. Next to the[br]battery, on the right side, we have a
0:08:26.520,0:08:32.349
small speaker which is not very good. And[br]underneath we have the main PCB with the
0:08:32.349,0:08:37.510
processor, all the storage and so on and[br]so forth. Let's take a look at those. Now,
0:08:37.510,0:08:44.779
the main processor of the device is an[br]STM32H7B0. This is a Cortex M7 from
0:08:44.779,0:08:53.201
STMicroelectronics with 1.3 MB of RAM and[br]128 kB of flash. It runs at 280 MHz and is
0:08:53.201,0:08:59.460
a pretty beefy microcontroller. But it's[br]much less powerful than the processor in
0:08:59.460,0:09:03.860
the NES or SNES classic. Like this[br]processor is really just a microcontroller
0:09:03.860,0:09:09.260
and so it can't run Linux. It can't run,[br]let's say, super complex software. Instead
0:09:09.260,0:09:14.170
it'll be programed in some bare metal[br]way. And so we will have a bare metal
0:09:14.170,0:09:20.580
firmware on the device. To the right of[br]it, you can also find a 1 MB SPI flash.
0:09:20.580,0:09:26.180
And so overall, we have roughly 1.1 MB of[br]storage on the device. Now, most
0:09:26.180,0:09:31.279
microcontrollers or basically all[br]microcontrollers have a debugging port.
0:09:31.279,0:09:36.370
And if we take a look at the PCB, you can[br]see that there are five unpopulated
0:09:36.370,0:09:40.980
contacts here. And if you see a couple of[br]contacts, that are not populated close to
0:09:40.980,0:09:47.510
your CPU, it's very likely, that it's the[br]debugging port. And luckily, the datasheet
0:09:47.510,0:09:54.449
for the STM32 is openly available. And so[br]we can check the pinouts in the datasheet
0:09:54.449,0:09:59.050
and then use a multimeter to to see[br]whether these pins are actually the
0:09:59.050,0:10:04.500
debugging interface. And turns out they[br]actually are. And so we can find the SWD
0:10:04.500,0:10:11.630
debugging interface as well as Vcc and[br]ground exposed on these pins. Now this
0:10:11.630,0:10:16.779
means that we can use a debugger. So, for[br]example, a J-link or ST-link or whatever
0:10:16.779,0:10:21.980
to connect to the device. And because the[br]the contacts are really easy to access,
0:10:21.980,0:10:25.870
you don't even have to solder. You can[br]just hook up a couple of test pins and
0:10:25.870,0:10:32.600
they will allow you to easily hook-up[br]your debugger. Now, the problem is, on most
0:10:32.600,0:10:36.900
devices, the debugging interface will be[br]locked during manufacturing, this is done
0:10:36.900,0:10:42.550
to prevent people like us to basically do[br]whatever with the device and to prevent us
0:10:42.550,0:10:47.450
from being able to dump the firmware,[br]potentially reflash it and so on. And so I
0:10:47.450,0:10:52.190
was very curious to see, whether we can[br]actually connect to the debugging port.
0:10:52.190,0:10:56.090
And when starting up J-link and trying to[br]connect, we can see it can actually
0:10:56.090,0:11:01.230
successfully connect. But, when you take a[br]closer look, there's also a message that
0:11:01.230,0:11:09.269
the device is active read protected. This[br]is because the chip, the STM32 chip,
0:11:09.269,0:11:15.650
features something called RDP protection[br]level or readout protection level. This is
0:11:15.650,0:11:20.300
basically the security setting for the[br]debugging interface and it has three
0:11:20.300,0:11:26.769
levels. Level zero means no protection is[br]active. Level one means that the flash
0:11:26.769,0:11:31.839
memory is protected and so we can't dump[br]the internal flash of the device. However,
0:11:31.839,0:11:36.939
we can dump the RAM contents and we can[br]also execute code from RAM. And then
0:11:36.939,0:11:42.240
there's also level two, which means that[br]all debugging features are disabled. Now,
0:11:42.240,0:11:46.630
just because a chip is in level two,[br]doesn't mean that you have to give up.
0:11:46.630,0:11:51.589
For example, in our talk wallet.fail a couple[br]of years ago, we showed how to use fault
0:11:51.589,0:11:56.000
injection to bypass the level two[br]protection and downgrade a chip to level
0:11:56.000,0:12:00.820
one. However, on the Game & Watch, we are[br]lucky and the interface is not fully
0:12:00.820,0:12:07.139
disabled. Instead, it's in level one. And[br]so we can still dump the RAM, which is a
0:12:07.139,0:12:11.300
pretty good entry point, even though we[br]can't dump the firmware yet. Now, having
0:12:11.300,0:12:17.010
dumped the RAM of the device, I was pretty[br]curious to see, what's inside of it. And
0:12:17.010,0:12:21.660
one of my suspicions was, that potentially[br]the emulator, that's hopefully running on
0:12:21.660,0:12:29.000
the device, loads the original Super Mario[br]Brothers ROM into RAM. And so, I was
0:12:29.000,0:12:34.830
wondering whether maybe we can find the[br]ROM that the device uses in the RAM-dump.
0:12:34.830,0:12:39.750
And so I opened up the RAM-dump in a hex[br]editor and I also opened up the original
0:12:39.750,0:12:44.450
Super Mario Brothers ROM in a second[br]window in a hex editor and tried to find
0:12:44.450,0:12:49.411
different parts of the original ROM in the[br]RAM-dump. And it turns out that, yes, the
0:12:49.411,0:12:55.380
NES ROM is loaded into RAM and it's always[br]at the same address. And so it's probably
0:12:55.380,0:13:00.289
like during boot up, it gets copied into[br]RAM or something along those lines. And so
0:13:00.289,0:13:05.420
this is pretty cool to know, because it[br]tells us a couple of things. First off, we
0:13:05.420,0:13:09.790
know now that the debug port is enabled[br]and working, but that it's unfortunately
0:13:09.790,0:13:16.319
at RDP level one and so we can only dump[br]the RAM. And we also know that the NES ROM
0:13:16.319,0:13:21.259
is loaded into RAM. And this means that[br]the device runs a real NES emulator. And
0:13:21.259,0:13:25.680
so if we get lucky, we can, for example,[br]just replace the ROM that is used by
0:13:25.680,0:13:29.840
the device and play, for example, [br]our own NES game.
0:13:30.600,0:13:33.460
little pause
0:13:33.930,0:13:37.010
Next, it was time to dump the flash chip
0:13:37.010,0:13:41.160
of the device. For this, I'm using a[br]device called Mini Pro and I'm using one
0:13:41.160,0:13:46.959
of these really useful SOIC8 clips. And so[br]these ones you can simply clip onto the
0:13:46.959,0:13:52.240
flash chip and then dump it. Now, one[br]warning though, the flash chip on the device,
0:13:52.240,0:13:56.220
is running at 1.8 volts. And so you want to[br]make sure that your programmer also
0:13:56.220,0:14:01.839
supports 1.8 volt operation. If you[br]accidentally try to read it out at 3.3 volts,
0:14:01.839,0:14:06.770
you will break your flash. Trust[br]me, because it happened to me on one of my
0:14:06.770,0:14:12.940
units. Now, with this flash dump from the[br]device, we can start to analyze it. And
0:14:12.940,0:14:17.319
what I always like to do first, is take a[br]look at the entropy or the randomness of
0:14:17.319,0:14:23.350
the flash dump. And so using binwalk with[br]the -E option, we get a nice entropy
0:14:23.350,0:14:27.410
graph. And in this case, you can see we[br]have a very high entropy over almost the
0:14:27.410,0:14:32.899
whole flash contents. And this mostly[br]indicates, that the flash contents are
0:14:32.899,0:14:37.240
encrypted. It could also mean compression,[br]but if it's compressed, you would often
0:14:37.240,0:14:43.529
see more like dips in the entropy. And in[br]this case, it's one very high entropy
0:14:43.529,0:14:48.830
stream. We also noticed, that there are no[br]repetitions whatsoever, which also tells
0:14:48.830,0:14:53.350
us that it's probably not like a simple[br]XOR based encryption or so and instead
0:14:53.350,0:14:58.340
something like AES or something similar.[br]But, just because the flash is encrypted
0:14:58.340,0:15:02.199
doesn't mean we have to give up. On the[br]contrary, I think now it starts to get
0:15:02.199,0:15:06.829
interesting, because you actually have a[br]challenge and it's not just plug and play,
0:15:06.829,0:15:13.020
so to say. One of the biggest questions I[br]had is, is the flash actually verified?
0:15:13.020,0:15:18.160
Like does the device boot, even though the[br]flash has been modified? Because, if it
0:15:18.160,0:15:24.789
does, this would open up a lot of attack[br]vectors, basically, as you will see. And
0:15:24.789,0:15:30.720
so to verify this, I basically try to[br]put zeros in random places in the flash
0:15:30.720,0:15:35.760
image. And so, I put some at adress zero,[br]some at 0x2000 and so on. And then I
0:15:35.760,0:15:39.910
checked whether the device would still[br]boot-up. And with the most flash
0:15:39.910,0:15:44.370
modifications, it would still boot just[br]fine. This tells us, that even though the
0:15:44.370,0:15:48.599
flash contents are encrypted, they are not[br]validated, they are not checksummed or
0:15:48.599,0:15:54.610
anything. And so we can potentially trick[br]the device into accepting a modified flash
0:15:54.610,0:15:58.529
image. And this is really important to[br]know, as you will see in a couple of
0:15:58.529,0:16:05.310
minutes. My next suspicion was, that maybe[br]the NES ROM we see in RAM, is actually
0:16:05.310,0:16:12.839
loaded from the external flash. And so to[br]find out whether that's the case, I again
0:16:12.839,0:16:18.939
took the flash and I inserted zeros at[br]multiple positions in the flash image.
0:16:18.939,0:16:24.550
Flashed that over, booted-up the game,[br]dumped the RAM and then compared the NES
0:16:24.550,0:16:29.620
ROM that I'm now dumping from RAM with the[br]one that I dumped initially and checked
0:16:29.620,0:16:35.399
whether they are equal. Because my[br]suspicion was that maybe I can overwrite a
0:16:35.399,0:16:41.519
couple of bytes in the encrypted flash and[br]then I will modify the NES room. And after
0:16:41.519,0:16:46.760
doing this for, like, I don't know, half[br]an hour, I got lucky and I modified 4
0:16:46.760,0:16:51.399
bytes in the flash image and 4 bytes in the[br]RAM...sorry...in the ROM that was loaded
0:16:51.399,0:16:56.790
into RAM changed. And this tells us quite[br]a bit. It means that the ROM is loaded
0:16:56.790,0:17:04.450
from flash into RAM and that the flash[br]contents are not validated. And what's
0:17:04.450,0:17:10.280
also important is, that we change 4[br]bytes in the flash and now 4 bytes in
0:17:10.280,0:17:15.510
the decrypted image changed. And this is[br]very important to know, because if we take
0:17:15.510,0:17:19.740
a look at what we would expect to happen[br]when we change the flash contents, there
0:17:19.740,0:17:23.880
are multiple outcomes. And so, for[br]example, here we have the SPI-flash
0:17:23.880,0:17:29.310
contents on the left and the RAM contents[br]on the right. And so the RAM contents are
0:17:29.310,0:17:35.410
basically the decrypted version of the[br]SPI-flash contents. Now let's say we
0:17:35.410,0:17:41.750
change 4 bytes in the encrypted flash[br]image to zeros. How would we expect the
0:17:41.750,0:17:47.580
RAM contents to change, for example, if we[br]would see that now 16 bytes in the RAM are
0:17:47.580,0:17:52.960
changing, this means that we are[br]potentially looking at an encryption
0:17:52.960,0:17:57.650
algorithm, such as AES in electronic[br]codebook mode. Because, it's a block based
0:17:57.650,0:18:03.180
encryption and so if we change four bytes[br]in the input data, a block size, in this
0:18:03.180,0:18:09.730
case 16 bytes, in the output data would[br]change. The next possibility is, that we
0:18:09.730,0:18:16.160
change 4 bytes in the SPI-flash and all[br]data afterwards will be changed. And in
0:18:16.160,0:18:21.830
this case, we would look at some kind of[br]chaining cipher such as AES in the CBC
0:18:21.830,0:18:27.600
mode. However, if we change 4 bytes in[br]the SPI-flash and only 4 bytes in the
0:18:27.600,0:18:33.510
RAM changed, we are looking at[br]something such as AES in counter mode. And
0:18:33.510,0:18:40.270
to understand this, let's take a better[br]look at how AES in CTR works. AES-CTR
0:18:40.270,0:18:45.930
works by having your cleartext and xoring[br]it with an AES encryption stream, that is
0:18:45.930,0:18:53.211
generated from a key, a Nonce and the[br]counter algorithm. Now, the AES stream,
0:18:53.211,0:18:57.370
that will be used to xor your your[br]cleartext will always be the same, if key
0:18:57.370,0:19:02.840
and Nonce is the same. This is why it's[br]super important, that if you use AES-CTR,
0:19:02.840,0:19:08.780
you always select a unique Nonce for each[br]encryption. If you encrypt similar data
0:19:08.780,0:19:15.060
with the same Nonce twice, large parts of[br]the resulting ciphertext will be the same.
0:19:15.060,0:19:19.960
And so the cleartext gets xored with the[br]AES-CTR stream and then we get our
0:19:19.960,0:19:26.570
ciphertext. Now, if we know the cleartext,[br]as we do, because the cleartext is the ROM,
0:19:26.570,0:19:32.270
that is loaded into RAM and we know the[br]ciphertext, which we do, because it's the
0:19:32.270,0:19:38.010
contents of the encrypted flash we just[br]dump. We can basically reverse the
0:19:38.010,0:19:44.580
operation and as a result, we get the AES-[br]CTR stream, that was used to encrypt the
0:19:44.580,0:19:52.050
flash. And now this means, that we can[br]take, for example, a custom ROM, xor it
0:19:52.050,0:19:57.830
with the AES-CTR stream we just[br]calculated and then generate our own
0:19:57.830,0:20:02.010
encrypted flash image, for example, with a[br]modified ROM. And so I wrote a couple of
0:20:02.010,0:20:08.340
Python scripts to try this. And after a[br]while, I was running Hacked Super Mario
0:20:08.340,0:20:14.290
Brothers instead of Super Mario Brothers.[br]So, wohoo, we hacked the Nintendo Game &
0:20:14.290,0:20:18.870
Watch one day before the official release.[br]And we can install modified Super Mario
0:20:18.870,0:20:23.990
Brothers ROMs. Now, you can find the[br]scripts that I used for this on my Github.
0:20:23.990,0:20:28.260
So it's in a repository called "Game &[br]Watch Hacking". And I was super excited,
0:20:28.260,0:20:33.570
because it meant, that I succeeded and that[br]I basically hacked a Nintendo console one
0:20:33.570,0:20:37.961
day before the official release.[br]Unfortunately, I finished the level, but
0:20:37.961,0:20:43.350
Toad wasn't as excited. He told me that[br]unfortunately, our firmware is still in
0:20:43.350,0:20:50.050
another castle. And so on the Monday after[br]the launch of the device, I teamed up with
0:20:50.050,0:20:54.790
Konrad Beckman, a hardware hacker from[br]Sweden who I met at the previous Congress.
0:20:54.790,0:20:59.850
And we started chatting and throwing ideas[br]back and forth and so on. And eventually
0:20:59.850,0:21:05.620
we noticed that the device has a special[br]RAM area called ITCM-RAM, which is a
0:21:05.620,0:21:10.570
tightly coupled instruction RAM that is[br]normally used for very high performance
0:21:10.570,0:21:15.121
routines such as interrupt handlers and so[br]on. And so it's in a very fast RAM area.
0:21:15.121,0:21:22.160
And we realized that we never actually[br]looked at the contents of that ITCM-RAM.
0:21:22.160,0:21:26.540
And so we dumped it from the device using[br]the debugging port. And it turns out that
0:21:26.540,0:21:33.020
this ITCM-RAM contains ARM code. And so,[br]again, the question is, where does this
0:21:33.020,0:21:37.570
ARM code come from, does it maybe just[br]like the NES ROM come from the external
0:21:37.570,0:21:45.741
flash? And so basically, I repeated the[br]whole thing that we also did with the NES
0:21:45.741,0:21:52.260
ROM and just put zeros at the very[br]beginning of the encrypted flash. Rebooted
0:21:52.260,0:21:57.720
the device and dumped the ITCM-RAM and I[br]got super lucky on the first try already
0:21:57.720,0:22:03.990
the ITCM contents changed. And because the[br]ITCM contains code, not just data, so
0:22:03.990,0:22:09.300
early we only had the NES-ROM, which is[br]just data, but this time the RAM contains
0:22:09.300,0:22:14.850
code. This means that with the same x or[br]trick we used before, we could inject
0:22:14.850,0:22:21.530
custom ITCM code into the external flash,[br]which would then be loaded into RAM when
0:22:21.530,0:22:27.620
the device boots. And because it's a[br]persistent method, we can then reboot the
0:22:27.620,0:22:32.520
device and let it run without the debugger[br]connected. And so whatever code we load
0:22:32.520,0:22:38.490
into this ITCM area will be able to[br]actually read the flash. And so we could
0:22:38.490,0:22:43.280
potentially write some code that gets[br]somehow called by the firmware and then
0:22:43.280,0:22:49.540
copies the internal flash into RAM from[br]where we then can retrieve it using the
0:22:49.540,0:22:57.560
debugger. Now, the problem is, let's say[br]we have a custom payload somehow in this
0:22:57.560,0:23:04.750
ITCM area. We don't know which address of[br]this ITCM code gets executed. And so we
0:23:04.750,0:23:09.410
don't know whether the firmware will jump[br]to adress zero or adress 200 or whatever.
0:23:09.410,0:23:14.270
But there's a really simple trick to still[br]build a successful payload. And it's
0:23:14.270,0:23:19.230
called a NOP slide. A NOP, or no[br]operation, is an instruction that simply
0:23:19.230,0:23:25.100
does nothing. And if we fill most of the[br]ITCM-RAM with NOPs and put our payload at
0:23:25.100,0:23:31.700
the very end, we build something that is[br]basically a NOP-slide. And so when the
0:23:31.700,0:23:37.260
CPU, indicated by Mario here, jumps to a[br]random address in that whole NOP-slide, it
0:23:37.260,0:23:43.500
will start executing NOPs and slide down[br]into our payload and execute it. And so
0:23:43.500,0:23:49.100
even if Mario jumps right in the middle of[br]the NOP-slide, he will always slide down
0:23:49.100,0:23:54.920
the slide and end up in our payload. And[br]Konrad wrote this really, really simple
0:23:54.920,0:23:58.330
payload, which is only like 10[br]instructions, which basically just copies
0:23:58.330,0:24:03.980
the internal flash into RAM from where we[br]can then retrieve it using the debugger.
0:24:03.980,0:24:08.280
So wohoo, super simple exploit. We have a[br]full firmware backup and a full flash
0:24:08.280,0:24:13.590
backup and now we can really fiddle with[br]everything on the device. And we've
0:24:13.590,0:24:17.700
actually released tools to do this[br]yourself. And so if you want to back up
0:24:17.700,0:24:23.161
your Nintendo Game & Watch, you can just[br]go onto my GitHub and download the game
0:24:23.161,0:24:27.670
and watch backup repository, which[br]contains a lot of information on how to
0:24:27.670,0:24:33.270
back it up. It does check something and[br]so on to ensure that you don't
0:24:33.270,0:24:38.420
accidentally brick your device and you can[br]easily back up the original firmware,
0:24:38.420,0:24:43.610
install homebrew, and then always go back[br]to the original software. We also have an
0:24:43.610,0:24:50.630
awesome support community on Discord. And[br]so if you ever need help, I think you will
0:24:50.630,0:24:55.270
find success there. And so far we haven't[br]had a single bricked Game & Watch and so
0:24:55.270,0:25:02.200
looks to be pretty stable. And so I[br]was pretty excited because the quest was
0:25:02.200,0:25:11.170
over. Or is it? If you ever claim on the[br]internet that you successfully hacked an
0:25:11.170,0:25:18.180
embedded device, there will be exactly one[br]response and one response only: but does
0:25:18.180,0:25:23.610
it run Doom? Literally my Twitter DMs, my[br]YouTube comments, and even my friends were
0:25:23.610,0:25:28.720
spamming me with the challenge to get Doom[br]running on the device. But to get Doom
0:25:28.720,0:25:34.390
running, we first needed to bring up all[br]the hardware. And so we basically needed
0:25:34.390,0:25:40.070
to create a way to develop and load[br]homebrew onto the device. Now, luckily for
0:25:40.070,0:25:44.880
us, most of the components on the board[br]are very well documented and so there are
0:25:44.880,0:25:50.040
no NDA components. And so, for example,[br]the processor has an open reference manual
0:25:50.040,0:25:56.890
and open source library to use it. The[br]flash is a well-known flash chip. And so
0:25:56.890,0:26:00.440
on and so forth. And there are only a[br]couple of very proprietary or custom
0:26:00.440,0:26:06.280
components. And so, for example, the LCD[br]on the device is proprietary and we had to
0:26:06.280,0:26:12.690
basically sniff the SPI-bus that goes to[br]the display to basically decode the
0:26:12.690,0:26:19.160
initialization of the display and so on.[br]And after a while, we had the full
0:26:19.160,0:26:24.540
hardware running, we had LCD support, we[br]had audio support, deep support, buttons
0:26:24.540,0:26:29.210
and even flashing tools that allow you to[br]simply use an SWD debugger to dump and
0:26:29.210,0:26:33.820
rewrite the external flash. And you can[br]find all of these things on our GitHub.
0:26:33.820,0:26:38.520
Now, if you want to mod your own Game &[br]Watch, all you need is a simple debugging
0:26:38.520,0:26:46.840
adapter such as a cheap, three dollar ST-[br]link, a J-link or a real ST-link device,
0:26:46.840,0:26:51.140
and then you can get started. We've also[br]published a base project for anyone who
0:26:51.140,0:26:54.911
wants to get started with building their[br]own games for the Game & Watch. And so
0:26:54.911,0:26:58.670
it's really simple. It's just a frame[br]buffer you can draw to, input is really
0:26:58.670,0:27:04.470
simple and so on. And as said, we have a[br]really helpful community. Now with all the
0:27:04.470,0:27:10.000
hardware up and running, I could finally[br]start porting Doom. I started by looking
0:27:10.000,0:27:15.420
around for other ports of Doom to an[br]STM32. And I found this project by floppes
0:27:15.420,0:27:22.010
called stm32doom. Now the issue is,[br]stm32doom is designed for a board with
0:27:22.010,0:27:28.340
eight megabytes of RAM and also the data[br]files for Doom were stored on external USB
0:27:28.340,0:27:37.630
drive. On our platform, we only have 1.3[br]MB of RAM, 128 kB of flash and only 1 MB
0:27:37.630,0:27:42.600
of external flash and we have to fit all[br]the level information, all the code and
0:27:42.600,0:27:50.880
so on in there. Now, the Doom level[br]information is stored in so-called WAD -
0:27:50.880,0:27:57.240
Where's All my Data files. And these data[br]files contain the sprites, the textures,
0:27:57.240,0:28:03.230
the levels and so on. Now the WAD for Doom[br]1 is roughly four megabytes in size and
0:28:03.230,0:28:11.440
the WAD for Doom 2 is 40 MB in size. But[br]we only have 1.1 MB of storage. Plus we
0:28:11.440,0:28:16.390
have to fit all the code in there. So[br]obviously we needed to find a very, very
0:28:16.390,0:28:22.200
small Doom port. And as it turns out,[br]there's a file called Mini-WAD, which is a
0:28:22.200,0:28:27.680
minimal Doom, I wrote, which is basically[br]all the bells and whistles are stripped
0:28:27.680,0:28:34.240
from the WAD file and everything replaced[br]by simple outlines and so on. And while
0:28:34.240,0:28:38.130
it's not pretty, I was pretty confident[br]that I could get it working as it's only
0:28:38.130,0:28:46.320
250 kB of storage, down from 40 megabytes.[br]Now, in addition to that, a lot of stuff
0:28:46.320,0:28:51.300
on the Chocolate Doom port itself had to[br]be changed. And so, for example, I had to
0:28:51.300,0:28:56.150
rip out all the file handling and add a[br]custom file handler. I had to add support
0:28:56.150,0:29:01.230
for the Game & Watch LCD, button input[br]support. And I also had to get rid of a
0:29:01.230,0:29:05.350
lot of things to get it running somewhat[br]smoothly. And so, for example, the
0:29:05.350,0:29:10.630
infamous Wipe effect had to go and I also[br]had to remove sound support. Now, the next
0:29:10.630,0:29:16.270
issue was that once it was compiling, it[br]simply would not fit into RAM and crash
0:29:16.270,0:29:22.820
all the time. Now on the device, we have[br]roughly 1.3 MB of RAM in different RAM
0:29:22.820,0:29:27.510
areas. And for example just the frame[br]buffer, that we obviously need, takes up
0:29:27.510,0:29:36.350
154 kB off that. Then we have 160 kB of[br]initialized data, 320 kB of uninitialized
0:29:36.350,0:29:42.000
data and a ton of dynamic allocations that[br]are done by Chocolate Doom. And these
0:29:42.000,0:29:46.610
dynamic allocations were a huge issue[br]because the Chocolate Doom source code
0:29:46.610,0:29:52.480
does a lot of small allocations, which are[br]only used for temporary data. And so they
0:29:52.480,0:29:58.600
get freed again and so on, and so your[br]dynamic memory gets very, very fragmented
0:29:58.600,0:30:02.710
very quickly, and so eventually there's[br]just not enough space to, for example,
0:30:02.710,0:30:09.791
initialize the level. And so to fix this,[br]I took the Chocolate Doom code and I
0:30:09.791,0:30:15.110
changed a lot of the dynamic allocations[br]to static allocations, which also had the
0:30:15.110,0:30:22.030
big advantage of making the error messages[br]by the compiler much more meaningful.
0:30:22.030,0:30:27.340
Because it would actually tell you: Hey,[br]this and this data does not fit into RAM.
0:30:27.340,0:30:31.990
And eventually, after a lot of trial and[br]error and copying as many of the original
0:30:31.990,0:30:39.400
assets as possible into the minimal IWAD,[br]I got it. I had Doom running on the
0:30:39.400,0:30:45.030
Nintendo Game & Watch Super Mario Brothers[br]and I hopefully calmed the internet gods
0:30:45.030,0:30:49.750
that forced me to do it. Now,[br]unfortunately, the USB port is physically
0:30:49.750,0:30:55.690
not connected to the processor and so it[br]will not be possible to hack the device
0:30:55.690,0:31:00.390
simply by plugging it into your computer.[br]However, it's relatively simple to do this
0:31:00.390,0:31:06.790
using one of these USB-Debuggers. Now, the[br]most requested type of homebrew software
0:31:06.790,0:31:12.870
was obviously emulators. And I'm proud to[br]say that by now we actually have kind of a
0:31:12.870,0:31:19.210
large collection of emulators running on[br]the Nintendo Game & Watch. And it all
0:31:19.210,0:31:23.370
started with Conrad Beckman discovering[br]the Retro Go Project, which is an emulator
0:31:23.370,0:31:29.970
collection for a device called the Odroid[br]Go and the Odroid Go is a small handheld
0:31:29.970,0:31:35.880
with similar input and size constraints as[br]the Nintendo Game & Watch. And so it's
0:31:35.880,0:31:40.630
kind of cool to port this over because it[br]basically already did all of the hard
0:31:40.630,0:31:47.670
work, so to say. And Retro Go comes with[br]emulators for the NES, for the Gameboy and
0:31:47.670,0:31:52.770
the Gameboy color and even for the Sega[br]Master System and the Sega Game Gear. And
0:31:52.770,0:31:58.290
after a couple of days, Conrad actually[br]was able to show off his NES emulator
0:31:58.290,0:32:02.960
running Zelda and other games such as[br]Contra and so on, on the Nintendo Game &
0:32:02.960,0:32:09.230
Watch. This is super fun and initially we[br]only had really a basic emulator that
0:32:09.230,0:32:13.170
could barely play and we had a lot of[br]frame drops, we didn't have nice scaling,
0:32:13.170,0:32:18.290
VSync and so on. But now after a couple of[br]weeks, it's really a nice device to use
0:32:18.290,0:32:24.090
and to play with. And so we also have a[br]Gameboy emulator running and so you can
0:32:24.090,0:32:29.440
play your favorite Gameboy games such as[br]Pokémon, Super Mario Land and so on on the
0:32:29.440,0:32:35.160
Nintendo Game & Watch if you own the[br]corresponding ROM Backups. And we also
0:32:35.160,0:32:38.650
experimented with different scaling[br]algorithms to make the most out of the
0:32:38.650,0:32:43.310
screen. And so you can basically change[br]the scaling algorithm that is used for the
0:32:43.310,0:32:48.160
display, depending on what you prefer. And[br]you could even change the palette for the
0:32:48.160,0:32:54.450
different games. We also have a nice game[br]chooser menu which allows you to basically
0:32:54.450,0:32:59.240
have multiple ROMs on the device that you[br]can switch between. We have safe state
0:32:59.240,0:33:04.210
support and so if you turn off the device,[br]it will save wherever you left off and you
0:33:04.210,0:33:08.870
can even come back to your save game once[br]the battery run out. You can find the
0:33:08.870,0:33:14.380
source code for all of that on the Retro[br]Go repository from Conrad. And it's
0:33:14.380,0:33:20.710
really, really awesome. Other people build[br]for example emulators for the CHIP-8
0:33:20.710,0:33:25.430
system and so the CHIP-8 emulator comes[br]with a nice collection of small arcade
0:33:25.430,0:33:31.271
games and so on, and it's really fun and[br]really easy to develop for it. And so
0:33:31.271,0:33:37.010
really give this a try if you own a Game &[br]Watch and want to try homebrew on it. Tim
0:33:37.010,0:33:41.590
Schuerwegen is even working on an[br]emulator for the original Game & Watch
0:33:41.590,0:33:45.920
games. And so this is really cool because[br]it basically turned the Nintendo Game &
0:33:45.920,0:33:53.130
Watch into an emulator for all Game &[br]Watch games that were ever released. And
0:33:53.130,0:33:57.860
what was really amazing to me is how the[br]community came together. And so we were
0:33:57.860,0:34:02.140
pretty open about the progress on Twitter.[br]And also Conrad was Twitch streaming a lot
0:34:02.140,0:34:06.480
of the process. And we opened up a discord[br]where people could join who were
0:34:06.480,0:34:11.850
interested in hacking on the device. And[br]it was amazing to see what came out of the
0:34:11.850,0:34:16.720
community. And so, for example, we now[br]have a working storage upgrade that works
0:34:16.720,0:34:21.179
both with homebrew but also with the[br]original firmware. And so instead of one
0:34:21.179,0:34:25.320
megabyte of storage, you can have 60[br]megabytes of flash and you just need to
0:34:25.320,0:34:30.549
replace a single chip, which is pretty[br]easy to do. Then for understanding the
0:34:30.549,0:34:35.690
full hardware. Daniel Cuthbert and Daniel[br]Padilla provided us with high resolution x
0:34:35.690,0:34:41.010
ray images, which allowed us to fully[br]understand every single connection, even
0:34:41.010,0:34:46.379
of the PGA parts, without desoldering[br]anything. Then Jake Little of Upcycle
0:34:46.379,0:34:52.980
Electronics traced on the x rays and also[br]using a multimeter every last trace on the
0:34:52.980,0:34:58.220
PCB, and he even created a schematic of[br]the device, which gives you all the
0:34:58.220,0:35:02.260
details you need when you want to program[br]something also and it was really, really
0:35:02.260,0:35:07.099
fun. Sander van der Wel for example even[br]created a custom backplate and now there
0:35:07.099,0:35:13.220
are even projects that try to replace the[br]original PCB with a custom PCB with an
0:35:13.220,0:35:20.019
FPGA and an ESP 32. And so it's really[br]exciting to see what people come up with.
0:35:20.019,0:35:24.819
Now, I hope you enjoyed this talk and I[br]hope to see you on our discord if you want
0:35:24.819,0:35:35.019
to join the fun. And thank you for coming.
0:35:35.019,0:35:41.329
Herald: Hi. Wow, that was a really amazing[br]talk. Thank you very much Thomas. As
0:35:41.329,0:35:48.140
announced in the beginning we do accept[br]questions from you and we have quite a
0:35:48.140,0:35:54.450
few. Let's see if we manage to make it[br]through all of them. The first one is:
0:35:54.450,0:35:59.650
Q: Did you read the articles about[br]Nintendo observing hackers, like private
0:35:59.650,0:36:04.799
investigators, et cetera and are you[br]somehow worried about this?
0:36:04.799,0:36:08.400
Thomas: Oh, what's going on with my[br]camera? Looks like Luigi messed around
0:36:08.400,0:36:17.539
with my video setup here. Yeah, I so I've[br]read those articles, but so I believe that
0:36:17.539,0:36:22.210
in this case, there is no piracy issue,[br]right? Like, I'm not allowing anyone to
0:36:22.210,0:36:26.940
play any new games. If you wanted to to[br]dump a Super Mario ROM, you would have
0:36:26.940,0:36:32.160
done it 30 years ago or on the NES Classic[br]or on the Switch or on any of the hundred
0:36:32.160,0:36:37.240
consoles Nintendo launched in between. And[br]so I'm really not too worried about it, to
0:36:37.240,0:36:41.480
be honest.[br]Herald: I also think the aspect of the
0:36:41.480,0:36:50.270
target audience is to be seen here. So off[br]to the next question which is: Do you
0:36:50.270,0:36:55.460
think that there is a reason why an[br]external flash chip has been used?
0:36:55.460,0:37:02.849
Thomas: Yeah. So the internal flash of the[br]STM32-H7B0 is relatively small. It's only
0:37:02.849,0:37:08.450
128 kB. And so they simply couldn't[br]fit everything in, like basically even
0:37:08.450,0:37:13.240
just the frame buffer. Even just a frame[br]buffer picture also is larger than the
0:37:13.240,0:37:19.100
internal flash. And so I think that's why[br]they did it and I'm glad they did.
0:37:19.100,0:37:26.730
Herald: Sure. And is the decryption done[br]in software or is it a feature of the
0:37:26.730,0:37:30.460
microcontroller?[br]Thomas: So the microcontroller has an
0:37:30.460,0:37:36.160
integrated feature called OTF-DEC and[br]basically the flash is directly mapped
0:37:36.160,0:37:41.109
into memory and they have this chip[br]prefill called OTF DEC that automatically
0:37:41.109,0:37:45.430
provides the decryption and so on. And so[br]it's done all in hardware and you can even
0:37:45.430,0:37:48.350
retrieve the keys from hardware,[br]basically.
0:37:48.350,0:37:57.910
Herald: OK, very nice. And also, the next[br]question is somehow related to that: Is in
0:37:57.910,0:38:03.520
your opinion the encryption Nintendo has[br]applied even worth the effort for them?
0:38:03.520,0:38:07.430
It feels like it's just there to give[br]shareholders a false sense of security.
0:38:07.430,0:38:12.709
What would you think about that?[br]Thomas: I think from my perspective, they
0:38:12.709,0:38:16.489
choose just the right encryption because[br]it was a ton of fun to reverse engineer
0:38:16.489,0:38:21.910
and try to to bypass it and so it was an[br]awesome challenge and so I think they did
0:38:21.910,0:38:26.900
everything right. But I also think in the[br]end, it's such a simple device and it's
0:38:26.900,0:38:31.569
like if you take a look at what people are[br]building on top of it with like games and
0:38:31.569,0:38:36.680
all that kind of stuff. I think they did[br]everything right, but probably it was just
0:38:36.680,0:38:41.569
a tick markup. Yeah, we totally locked[br]down JTAG and yeah, but I think it's fun
0:38:41.569,0:38:44.609
because again, it doesn't open up any[br]piracy issues.
0:38:44.609,0:38:51.140
Herald: Sure. The one thing is related to[br]the NOP slide, which you very, very well
0:38:51.140,0:39:01.189
animated. So wouldn't starts of[br]subroutines be suitable as well for that,
0:39:01.189,0:39:11.460
for that goal. The person asking says that[br]a big push R4, R5, etc. instructions are
0:39:11.460,0:39:20.640
quite recognizable. How would ... Yeah[br]Thomas: Yeah. So absolutely. The time from
0:39:20.640,0:39:25.019
finding the data in the ITCM-RAM and[br]actually exploiting it was less than an
0:39:25.019,0:39:29.950
hour. And so if we would have tried to[br]reverse engineer it, it would be more
0:39:29.950,0:39:33.660
work. Like absolutely possible and also[br]not difficult, but just filling the RAM
0:39:33.660,0:39:38.559
with NOP took a couple of minutes and so[br]was really the easiest way and the fastest
0:39:38.559,0:39:45.420
way without fiddling around in Ghidra or so.[br]Herald: OK, cool, thanks. And this is more
0:39:45.420,0:39:54.329
a remark than a question. The person says[br]it's strange that an STAN5281 does not
0:39:54.329,0:39:59.630
mention a single time that the data is not[br]verified during encryption. I think it's
0:39:59.630,0:40:05.759
more a fault on STs than Nintendos site.[br]What would you think about that?
0:40:05.759,0:40:10.690
Thomas: Yeah, I would somewhat agree[br]because in this case, even if you don't
0:40:10.690,0:40:17.670
have JTAG, like an ARM thum instruction is[br]2-4 bytes and so you have a relatively small
0:40:17.670,0:40:21.859
space to brute force to potentially get an[br]interesting branch instruction and so on.
0:40:21.859,0:40:28.009
So I think it's yeah, I mean, it's[br]not perfect, but also doing verification
0:40:28.009,0:40:33.410
is very expensive, computational wise and[br]so I think it should just be the firmware
0:40:33.410,0:40:37.160
that actually verifies the contents of the[br]external flash.
0:40:37.160,0:40:44.109
Herald: OK, so I think we should ask 2[br]questions more and then we can go back to
0:40:44.109,0:40:52.000
the studio. There is a question about the[br]AS encryption keys. Have you managed to
0:40:52.000,0:40:57.349
recover them?[br]Thomas: Yes, we did. But so it's an
0:40:57.349,0:41:01.700
applicational AST, and they do some crazy[br]shifting around with the keys but I think
0:41:01.700,0:41:07.400
even just today, like an hour before the[br]talk, a guy, sorry I'm not sure it's a
0:41:07.400,0:41:12.650
guy, a person on our discord actually[br]managed to rebuild the full encryption.
0:41:12.650,0:41:16.779
But we, I personally wasn't never[br]interested in that because after you've
0:41:16.779,0:41:22.080
downgraded to RTP 0, the device. You can[br]just access the memory mapped flash and
0:41:22.080,0:41:24.740
get the completely decrypted flash[br]contents basically.
0:41:24.740,0:41:32.009
Herald: Sure. Thanks. And a last question[br]about the LCD-Controller, whether it's
0:41:32.009,0:41:38.180
used by writing pixels over SPI or if it[br]has some extra features, maybe even
0:41:38.180,0:41:40.930
background or sprites or something like[br]that?
0:41:40.930,0:41:46.809
Thomas: So the the LCD itself doesn't have[br]any special features. It has one SPI bus
0:41:46.809,0:41:50.930
to configure it and then a parallel[br]interface where - so it takes up a lot
0:41:50.930,0:41:56.809
of pins. But the chip itself has a[br]hardware called LTDC, which is an LCD
0:41:56.809,0:42:00.769
controller, which provides two layers with[br]alpha blending and some basic windowing
0:42:00.769,0:42:06.630
and so on.[br]Herald: OK, cool then thank you very, very
0:42:06.630,0:42:11.799
much for the great talk and the great[br]intro. And with that, back to our main
0:42:11.799,0:42:14.859
studio in the orbit. Thank you very much.[br]Back to orbit.
0:42:14.859,0:42:17.977
rC3 postroll music
0:42:17.977,0:42:56.000
Subtitles created by c3subtitles.de[br]in the year 2020. Join, and help us!