1 00:00:00,000 --> 00:00:12,710 *rC3 Opening Music* 2 00:00:12,710 --> 00:00:19,340 Herald: So about our next speaker. He's a security researcher focused on embedded 3 00:00:19,340 --> 00:00:26,500 systems, secure communications and mobile security. He was nominated by 4 00:00:26,500 --> 00:00:39,940 Forbes for the 30 under 30 in technology and also has won a OWASP Appsec CTF. 5 00:00:39,940 --> 00:00:46,790 He has also found and disclosed responsibly multiple vulnerabilities. And especially 6 00:00:46,790 --> 00:00:52,280 for you Nintendo aficionados I want you to watch out for the next intro, which is 7 00:00:52,280 --> 00:00:56,270 really amazing and you will all love. Thank you very much. 8 00:00:56,305 --> 00:01:00,825 *shows nintendo cartridge* 9 00:01:00,825 --> 00:01:06,065 *plugs cartridge* 10 00:01:09,532 --> 00:01:10,532 *nintendo start sound plays* 11 00:01:10,532 --> 00:01:14,850 Thomas: Oh, damn it. *retrieves cartridge* 12 00:01:14,850 --> 00:01:19,980 *blows into cartridge* *plugs cartridge again* 13 00:01:22,146 --> 00:01:23,446 *nintendo start sound plays* 14 00:01:26,243 --> 00:01:29,423 *music plays* 15 00:02:52,810 --> 00:02:56,099 Thomas Roth: Uff, what a trip. Welcome to my talk on 16 00:02:56,099 --> 00:03:00,810 hacking the new Nintendo Game & Watch Super Mario Brothers. My name is Thomas 17 00:03:00,810 --> 00:03:05,290 Roth and I'm a security researcher and trainer from Germany. And you can find me 18 00:03:05,290 --> 00:03:10,719 on Twitter at @ghidraninja and also on YouTube at stacksmashing. Now, this year 19 00:03:10,719 --> 00:03:16,439 marks the 35th anniversary of our favorite plumber, Super Mario And to celebrate 20 00:03:16,439 --> 00:03:20,699 that, Nintendo launched a new game console called the Nintendo Game & Watch Super 21 00:03:20,699 --> 00:03:26,669 Mario Brothers. The console is lightweight and looks pretty nice, and it comes 22 00:03:26,669 --> 00:03:31,859 preinstalled with three games and also this nice animated clock. The three games 23 00:03:31,859 --> 00:03:36,920 are Super Mario Brothers, the original NES game, Super Mario Brothers 2 The Lost 24 00:03:36,920 --> 00:03:44,830 Levels and also a reinterpretation of an old Game & Watch game called Ball. Now, as 25 00:03:44,830 --> 00:03:49,939 you probably know, this is not the first retro console that Nintendo released. In 26 00:03:49,939 --> 00:03:57,400 2016, they released the NES Classic and 2017 they released the SNES Classic. Now, 27 00:03:57,400 --> 00:04:01,729 these devices were super popular in the homebrew community, because they make it 28 00:04:01,729 --> 00:04:05,779 really easy to add additional ROMs to it. They make it really easy to modify the 29 00:04:05,779 --> 00:04:10,540 firmware and so on. And you can basically just plug them into your computer, install 30 00:04:10,540 --> 00:04:14,959 a simple software and you can do whatever you want with them. The reason for that is 31 00:04:14,959 --> 00:04:21,140 that they run Linux and have a pretty powerful ARM processor on the inside. And 32 00:04:21,140 --> 00:04:27,360 so it's really a nice device to play with and so on. And so when Nintendo announced 33 00:04:27,360 --> 00:04:31,650 this new console, a lot of people were hoping for a similar experience of having 34 00:04:31,650 --> 00:04:38,810 a nice mobile home brew device. Now, if you were to make a Venn diagram of some of 35 00:04:38,810 --> 00:04:43,099 my biggest interests, you would have reverse engineering, hardware hacking and 36 00:04:43,099 --> 00:04:48,539 retro computing. And this new Game & Watch fits right in the middle of that. And so 37 00:04:48,539 --> 00:04:52,920 when it was announced on the 3rd of September, I knew that I needed to have 38 00:04:52,920 --> 00:04:58,930 one of those. And given how hard the NES and SNES classic were to buy for a while, 39 00:04:58,930 --> 00:05:03,389 I preordered it on like four or five different sites, a couple of which got 40 00:05:03,389 --> 00:05:09,470 canceled. But I was pretty excited, because I had three preorders and was supposed to 41 00:05:09,470 --> 00:05:15,380 ship on the 13th of November. And so I was really looking forward to this. And I was 42 00:05:15,380 --> 00:05:19,909 having breakfast on the 12th of November, when suddenly the doorbell rang and DHL 43 00:05:19,909 --> 00:05:25,730 delivered me the new Game & Watch one day before the official release. Now, at that 44 00:05:25,730 --> 00:05:30,300 point in time, there was no technical information available about the device 45 00:05:30,300 --> 00:05:35,449 whatsoever. Like, if you searched for Game & Watch on Twitter, you would only find 46 00:05:35,449 --> 00:05:40,680 denouncements or maybe a picture of the box of someone who also received it early. 47 00:05:40,680 --> 00:05:44,900 But there were no teardowns, no pictures of the insides and most importantly, 48 00:05:44,900 --> 00:05:50,319 nobody had hacked it yet. And this gave me, as a hardware hacker, the kind of 49 00:05:50,319 --> 00:05:55,669 unique opportunity to potentially be the first one to hack a new Nintendo console. 50 00:05:55,669 --> 00:06:00,199 And so I just literally dropped everything else I was doing and started investigating 51 00:06:00,199 --> 00:06:05,949 the device. Now, I should say that normally I stay pretty far away from any 52 00:06:05,949 --> 00:06:11,460 new console hacking. Mainly, because of the piracy issues. I don't want to enable 53 00:06:11,460 --> 00:06:18,930 piracy. I don't want to deal with piracy. And I don't want to build tools that 54 00:06:18,930 --> 00:06:23,930 enable other people to pirate stuff, basically. But given that on this device, 55 00:06:23,930 --> 00:06:28,900 you cannot buy any more games and that all the games, that are on there, were basically 56 00:06:28,900 --> 00:06:33,840 already released over 30 years ago. I was not really worried about piracy and felt 57 00:06:33,840 --> 00:06:39,449 pretty comfortable in sharing all the results of the investigation and also 58 00:06:39,449 --> 00:06:44,490 the... basically the issues we found that allowed us to customize the device and so 59 00:06:44,490 --> 00:06:49,389 on. And in this talk, I want to walk you through, how we managed to hack the device 60 00:06:49,389 --> 00:06:54,931 and how you can do it at home using relatively cheap hardware. And, yeah, hope 61 00:06:54,931 --> 00:07:03,040 you enjoy it. Now, let's start by looking at the device itself. The device is 62 00:07:03,040 --> 00:07:08,469 pretty lightweight and comes with a nicely sized case. And so it really... for me, it 63 00:07:08,469 --> 00:07:14,889 sits really well in my hand. And it has a nice 320 by 240 LCD display, a d-pad, A 64 00:07:14,889 --> 00:07:19,529 and B buttons and also three buttons to switch between the different game modes. 65 00:07:19,529 --> 00:07:23,940 On the right side we also have the power button and the USB-C port. Now, before you 66 00:07:23,940 --> 00:07:28,640 get excited about the USB port, I can already tell you that unfortunately, 67 00:07:28,640 --> 00:07:33,030 Nintendo decided to not connect the data lines off the USB port. And so you can 68 00:07:33,030 --> 00:07:38,550 really only use it for charging. Also, because we are talking about Nintendo 69 00:07:38,550 --> 00:07:43,979 here, they use their proprietary tri-point screws on the device. And so to open it 70 00:07:43,979 --> 00:07:48,730 up, you need one of those special tri- point bits. Luckily, nowadays, most bit 71 00:07:48,730 --> 00:07:54,120 sets should have them, but it still would suck, if you order your unit and then you 72 00:07:54,120 --> 00:07:59,639 can't open it up, because you're missing a screwdriver. After opening it up, the 73 00:07:59,639 --> 00:08:03,779 first thing you probably notice is the battery. And if you've ever opened up a 74 00:08:03,779 --> 00:08:07,599 Nintendo switch joycon before, you might recognize the battery, because it's the 75 00:08:07,599 --> 00:08:12,729 exact same one that's used in the joycons. This is very cool, because if down the 76 00:08:12,729 --> 00:08:16,529 line, like, let's say in two or three years, your battery of your Game & Watch 77 00:08:16,529 --> 00:08:20,650 dies, you can just go and buy a joycon battery, which you can have really 78 00:08:20,650 --> 00:08:26,520 cheaply, almost anywhere. Next to the battery, on the right side, we have a 79 00:08:26,520 --> 00:08:32,349 small speaker which is not very good. And underneath we have the main PCB with the 80 00:08:32,349 --> 00:08:37,510 processor, all the storage and so on and so forth. Let's take a look at those. Now, 81 00:08:37,510 --> 00:08:44,779 the main processor of the device is an STM32H7B0. This is a Cortex M7 from 82 00:08:44,779 --> 00:08:53,201 STMicroelectronics with 1.3 MB of RAM and 128 kB of flash. It runs at 280 MHz and is 83 00:08:53,201 --> 00:08:59,460 a pretty beefy microcontroller. But it's much less powerful than the processor in 84 00:08:59,460 --> 00:09:03,860 the NES or SNES classic. Like this processor is really just a microcontroller 85 00:09:03,860 --> 00:09:09,260 and so it can't run Linux. It can't run, let's say, super complex software. Instead 86 00:09:09,260 --> 00:09:14,170 it'll be programed in some bare metal way. And so we will have a bare metal 87 00:09:14,170 --> 00:09:20,580 firmware on the device. To the right of it, you can also find a 1 MB SPI flash. 88 00:09:20,580 --> 00:09:26,180 And so overall, we have roughly 1.1 MB of storage on the device. Now, most 89 00:09:26,180 --> 00:09:31,279 microcontrollers or basically all microcontrollers have a debugging port. 90 00:09:31,279 --> 00:09:36,370 And if we take a look at the PCB, you can see that there are five unpopulated 91 00:09:36,370 --> 00:09:40,980 contacts here. And if you see a couple of contacts, that are not populated close to 92 00:09:40,980 --> 00:09:47,510 your CPU, it's very likely, that it's the debugging port. And luckily, the datasheet 93 00:09:47,510 --> 00:09:54,449 for the STM32 is openly available. And so we can check the pinouts in the datasheet 94 00:09:54,449 --> 00:09:59,050 and then use a multimeter to to see whether these pins are actually the 95 00:09:59,050 --> 00:10:04,500 debugging interface. And turns out they actually are. And so we can find the SWD 96 00:10:04,500 --> 00:10:11,630 debugging interface as well as Vcc and ground exposed on these pins. Now this 97 00:10:11,630 --> 00:10:16,779 means that we can use a debugger. So, for example, a J-link or ST-link or whatever 98 00:10:16,779 --> 00:10:21,980 to connect to the device. And because the the contacts are really easy to access, 99 00:10:21,980 --> 00:10:25,870 you don't even have to solder. You can just hook up a couple of test pins and 100 00:10:25,870 --> 00:10:32,600 they will allow you to easily hook-up your debugger. Now, the problem is, on most 101 00:10:32,600 --> 00:10:36,900 devices, the debugging interface will be locked during manufacturing, this is done 102 00:10:36,900 --> 00:10:42,550 to prevent people like us to basically do whatever with the device and to prevent us 103 00:10:42,550 --> 00:10:47,450 from being able to dump the firmware, potentially reflash it and so on. And so I 104 00:10:47,450 --> 00:10:52,190 was very curious to see, whether we can actually connect to the debugging port. 105 00:10:52,190 --> 00:10:56,090 And when starting up J-link and trying to connect, we can see it can actually 106 00:10:56,090 --> 00:11:01,230 successfully connect. But, when you take a closer look, there's also a message that 107 00:11:01,230 --> 00:11:09,269 the device is active read protected. This is because the chip, the STM32 chip, 108 00:11:09,269 --> 00:11:15,650 features something called RDP protection level or readout protection level. This is 109 00:11:15,650 --> 00:11:20,300 basically the security setting for the debugging interface and it has three 110 00:11:20,300 --> 00:11:26,769 levels. Level zero means no protection is active. Level one means that the flash 111 00:11:26,769 --> 00:11:31,839 memory is protected and so we can't dump the internal flash of the device. However, 112 00:11:31,839 --> 00:11:36,939 we can dump the RAM contents and we can also execute code from RAM. And then 113 00:11:36,939 --> 00:11:42,240 there's also level two, which means that all debugging features are disabled. Now, 114 00:11:42,240 --> 00:11:46,630 just because a chip is in level two, doesn't mean that you have to give up. 115 00:11:46,630 --> 00:11:51,589 For example, in our talk wallet.fail a couple of years ago, we showed how to use fault 116 00:11:51,589 --> 00:11:56,000 injection to bypass the level two protection and downgrade a chip to level 117 00:11:56,000 --> 00:12:00,820 one. However, on the Game & Watch, we are lucky and the interface is not fully 118 00:12:00,820 --> 00:12:07,139 disabled. Instead, it's in level one. And so we can still dump the RAM, which is a 119 00:12:07,139 --> 00:12:11,300 pretty good entry point, even though we can't dump the firmware yet. Now, having 120 00:12:11,300 --> 00:12:17,010 dumped the RAM of the device, I was pretty curious to see, what's inside of it. And 121 00:12:17,010 --> 00:12:21,660 one of my suspicions was, that potentially the emulator, that's hopefully running on 122 00:12:21,660 --> 00:12:29,000 the device, loads the original Super Mario Brothers ROM into RAM. And so, I was 123 00:12:29,000 --> 00:12:34,830 wondering whether maybe we can find the ROM that the device uses in the RAM-dump. 124 00:12:34,830 --> 00:12:39,750 And so I opened up the RAM-dump in a hex editor and I also opened up the original 125 00:12:39,750 --> 00:12:44,450 Super Mario Brothers ROM in a second window in a hex editor and tried to find 126 00:12:44,450 --> 00:12:49,411 different parts of the original ROM in the RAM-dump. And it turns out that, yes, the 127 00:12:49,411 --> 00:12:55,380 NES ROM is loaded into RAM and it's always at the same address. And so it's probably 128 00:12:55,380 --> 00:13:00,289 like during boot up, it gets copied into RAM or something along those lines. And so 129 00:13:00,289 --> 00:13:05,420 this is pretty cool to know, because it tells us a couple of things. First off, we 130 00:13:05,420 --> 00:13:09,790 know now that the debug port is enabled and working, but that it's unfortunately 131 00:13:09,790 --> 00:13:16,319 at RDP level one and so we can only dump the RAM. And we also know that the NES ROM 132 00:13:16,319 --> 00:13:21,259 is loaded into RAM. And this means that the device runs a real NES emulator. And 133 00:13:21,259 --> 00:13:25,680 so if we get lucky, we can, for example, just replace the ROM that is used by 134 00:13:25,680 --> 00:13:29,840 the device and play, for example, our own NES game. 135 00:13:30,600 --> 00:13:33,460 *little pause* 136 00:13:33,930 --> 00:13:37,010 Next, it was time to dump the flash chip 137 00:13:37,010 --> 00:13:41,160 of the device. For this, I'm using a device called Mini Pro and I'm using one 138 00:13:41,160 --> 00:13:46,959 of these really useful SOIC8 clips. And so these ones you can simply clip onto the 139 00:13:46,959 --> 00:13:52,240 flash chip and then dump it. Now, one warning though, the flash chip on the device, 140 00:13:52,240 --> 00:13:56,220 is running at 1.8 volts. And so you want to make sure that your programmer also 141 00:13:56,220 --> 00:14:01,839 supports 1.8 volt operation. If you accidentally try to read it out at 3.3 volts, 142 00:14:01,839 --> 00:14:06,770 you will break your flash. Trust me, because it happened to me on one of my 143 00:14:06,770 --> 00:14:12,940 units. Now, with this flash dump from the device, we can start to analyze it. And 144 00:14:12,940 --> 00:14:17,319 what I always like to do first, is take a look at the entropy or the randomness of 145 00:14:17,319 --> 00:14:23,350 the flash dump. And so using binwalk with the -E option, we get a nice entropy 146 00:14:23,350 --> 00:14:27,410 graph. And in this case, you can see we have a very high entropy over almost the 147 00:14:27,410 --> 00:14:32,899 whole flash contents. And this mostly indicates, that the flash contents are 148 00:14:32,899 --> 00:14:37,240 encrypted. It could also mean compression, but if it's compressed, you would often 149 00:14:37,240 --> 00:14:43,529 see more like dips in the entropy. And in this case, it's one very high entropy 150 00:14:43,529 --> 00:14:48,830 stream. We also noticed, that there are no repetitions whatsoever, which also tells 151 00:14:48,830 --> 00:14:53,350 us that it's probably not like a simple XOR based encryption or so and instead 152 00:14:53,350 --> 00:14:58,340 something like AES or something similar. But, just because the flash is encrypted 153 00:14:58,340 --> 00:15:02,199 doesn't mean we have to give up. On the contrary, I think now it starts to get 154 00:15:02,199 --> 00:15:06,829 interesting, because you actually have a challenge and it's not just plug and play, 155 00:15:06,829 --> 00:15:13,020 so to say. One of the biggest questions I had is, is the flash actually verified? 156 00:15:13,020 --> 00:15:18,160 Like does the device boot, even though the flash has been modified? Because, if it 157 00:15:18,160 --> 00:15:24,789 does, this would open up a lot of attack vectors, basically, as you will see. And 158 00:15:24,789 --> 00:15:30,720 so to verify this, I basically try to put zeros in random places in the flash 159 00:15:30,720 --> 00:15:35,760 image. And so, I put some at adress zero, some at 0x2000 and so on. And then I 160 00:15:35,760 --> 00:15:39,910 checked whether the device would still boot-up. And with the most flash 161 00:15:39,910 --> 00:15:44,370 modifications, it would still boot just fine. This tells us, that even though the 162 00:15:44,370 --> 00:15:48,599 flash contents are encrypted, they are not validated, they are not checksummed or 163 00:15:48,599 --> 00:15:54,610 anything. And so we can potentially trick the device into accepting a modified flash 164 00:15:54,610 --> 00:15:58,529 image. And this is really important to know, as you will see in a couple of 165 00:15:58,529 --> 00:16:05,310 minutes. My next suspicion was, that maybe the NES ROM we see in RAM, is actually 166 00:16:05,310 --> 00:16:12,839 loaded from the external flash. And so to find out whether that's the case, I again 167 00:16:12,839 --> 00:16:18,939 took the flash and I inserted zeros at multiple positions in the flash image. 168 00:16:18,939 --> 00:16:24,550 Flashed that over, booted-up the game, dumped the RAM and then compared the NES 169 00:16:24,550 --> 00:16:29,620 ROM that I'm now dumping from RAM with the one that I dumped initially and checked 170 00:16:29,620 --> 00:16:35,399 whether they are equal. Because my suspicion was that maybe I can overwrite a 171 00:16:35,399 --> 00:16:41,519 couple of bytes in the encrypted flash and then I will modify the NES room. And after 172 00:16:41,519 --> 00:16:46,760 doing this for, like, I don't know, half an hour, I got lucky and I modified 4 173 00:16:46,760 --> 00:16:51,399 bytes in the flash image and 4 bytes in the RAM...sorry...in the ROM that was loaded 174 00:16:51,399 --> 00:16:56,790 into RAM changed. And this tells us quite a bit. It means that the ROM is loaded 175 00:16:56,790 --> 00:17:04,450 from flash into RAM and that the flash contents are not validated. And what's 176 00:17:04,450 --> 00:17:10,280 also important is, that we change 4 bytes in the flash and now 4 bytes in 177 00:17:10,280 --> 00:17:15,510 the decrypted image changed. And this is very important to know, because if we take 178 00:17:15,510 --> 00:17:19,740 a look at what we would expect to happen when we change the flash contents, there 179 00:17:19,740 --> 00:17:23,880 are multiple outcomes. And so, for example, here we have the SPI-flash 180 00:17:23,880 --> 00:17:29,310 contents on the left and the RAM contents on the right. And so the RAM contents are 181 00:17:29,310 --> 00:17:35,410 basically the decrypted version of the SPI-flash contents. Now let's say we 182 00:17:35,410 --> 00:17:41,750 change 4 bytes in the encrypted flash image to zeros. How would we expect the 183 00:17:41,750 --> 00:17:47,580 RAM contents to change, for example, if we would see that now 16 bytes in the RAM are 184 00:17:47,580 --> 00:17:52,960 changing, this means that we are potentially looking at an encryption 185 00:17:52,960 --> 00:17:57,650 algorithm, such as AES in electronic codebook mode. Because, it's a block based 186 00:17:57,650 --> 00:18:03,180 encryption and so if we change four bytes in the input data, a block size, in this 187 00:18:03,180 --> 00:18:09,730 case 16 bytes, in the output data would change. The next possibility is, that we 188 00:18:09,730 --> 00:18:16,160 change 4 bytes in the SPI-flash and all data afterwards will be changed. And in 189 00:18:16,160 --> 00:18:21,830 this case, we would look at some kind of chaining cipher such as AES in the CBC 190 00:18:21,830 --> 00:18:27,600 mode. However, if we change 4 bytes in the SPI-flash and only 4 bytes in the 191 00:18:27,600 --> 00:18:33,510 RAM changed, we are looking at something such as AES in counter mode. And 192 00:18:33,510 --> 00:18:40,270 to understand this, let's take a better look at how AES in CTR works. AES-CTR 193 00:18:40,270 --> 00:18:45,930 works by having your cleartext and xoring it with an AES encryption stream, that is 194 00:18:45,930 --> 00:18:53,211 generated from a key, a Nonce and the counter algorithm. Now, the AES stream, 195 00:18:53,211 --> 00:18:57,370 that will be used to xor your your cleartext will always be the same, if key 196 00:18:57,370 --> 00:19:02,840 and Nonce is the same. This is why it's super important, that if you use AES-CTR, 197 00:19:02,840 --> 00:19:08,780 you always select a unique Nonce for each encryption. If you encrypt similar data 198 00:19:08,780 --> 00:19:15,060 with the same Nonce twice, large parts of the resulting ciphertext will be the same. 199 00:19:15,060 --> 00:19:19,960 And so the cleartext gets xored with the AES-CTR stream and then we get our 200 00:19:19,960 --> 00:19:26,570 ciphertext. Now, if we know the cleartext, as we do, because the cleartext is the ROM, 201 00:19:26,570 --> 00:19:32,270 that is loaded into RAM and we know the ciphertext, which we do, because it's the 202 00:19:32,270 --> 00:19:38,010 contents of the encrypted flash we just dump. We can basically reverse the 203 00:19:38,010 --> 00:19:44,580 operation and as a result, we get the AES- CTR stream, that was used to encrypt the 204 00:19:44,580 --> 00:19:52,050 flash. And now this means, that we can take, for example, a custom ROM, xor it 205 00:19:52,050 --> 00:19:57,830 with the AES-CTR stream we just calculated and then generate our own 206 00:19:57,830 --> 00:20:02,010 encrypted flash image, for example, with a modified ROM. And so I wrote a couple of 207 00:20:02,010 --> 00:20:08,340 Python scripts to try this. And after a while, I was running Hacked Super Mario 208 00:20:08,340 --> 00:20:14,290 Brothers instead of Super Mario Brothers. So, wohoo, we hacked the Nintendo Game & 209 00:20:14,290 --> 00:20:18,870 Watch one day before the official release. And we can install modified Super Mario 210 00:20:18,870 --> 00:20:23,990 Brothers ROMs. Now, you can find the scripts that I used for this on my Github. 211 00:20:23,990 --> 00:20:28,260 So it's in a repository called "Game & Watch Hacking". And I was super excited, 212 00:20:28,260 --> 00:20:33,570 because it meant, that I succeeded and that I basically hacked a Nintendo console one 213 00:20:33,570 --> 00:20:37,961 day before the official release. Unfortunately, I finished the level, but 214 00:20:37,961 --> 00:20:43,350 Toad wasn't as excited. He told me that unfortunately, our firmware is still in 215 00:20:43,350 --> 00:20:50,050 another castle. And so on the Monday after the launch of the device, I teamed up with 216 00:20:50,050 --> 00:20:54,790 Konrad Beckman, a hardware hacker from Sweden who I met at the previous Congress. 217 00:20:54,790 --> 00:20:59,850 And we started chatting and throwing ideas back and forth and so on. And eventually 218 00:20:59,850 --> 00:21:05,620 we noticed that the device has a special RAM area called ITCM-RAM, which is a 219 00:21:05,620 --> 00:21:10,570 tightly coupled instruction RAM that is normally used for very high performance 220 00:21:10,570 --> 00:21:15,121 routines such as interrupt handlers and so on. And so it's in a very fast RAM area. 221 00:21:15,121 --> 00:21:22,160 And we realized that we never actually looked at the contents of that ITCM-RAM. 222 00:21:22,160 --> 00:21:26,540 And so we dumped it from the device using the debugging port. And it turns out that 223 00:21:26,540 --> 00:21:33,020 this ITCM-RAM contains ARM code. And so, again, the question is, where does this 224 00:21:33,020 --> 00:21:37,570 ARM code come from, does it maybe just like the NES ROM come from the external 225 00:21:37,570 --> 00:21:45,741 flash? And so basically, I repeated the whole thing that we also did with the NES 226 00:21:45,741 --> 00:21:52,260 ROM and just put zeros at the very beginning of the encrypted flash. Rebooted 227 00:21:52,260 --> 00:21:57,720 the device and dumped the ITCM-RAM and I got super lucky on the first try already 228 00:21:57,720 --> 00:22:03,990 the ITCM contents changed. And because the ITCM contains code, not just data, so 229 00:22:03,990 --> 00:22:09,300 early we only had the NES-ROM, which is just data, but this time the RAM contains 230 00:22:09,300 --> 00:22:14,850 code. This means that with the same x or trick we used before, we could inject 231 00:22:14,850 --> 00:22:21,530 custom ITCM code into the external flash, which would then be loaded into RAM when 232 00:22:21,530 --> 00:22:27,620 the device boots. And because it's a persistent method, we can then reboot the 233 00:22:27,620 --> 00:22:32,520 device and let it run without the debugger connected. And so whatever code we load 234 00:22:32,520 --> 00:22:38,490 into this ITCM area will be able to actually read the flash. And so we could 235 00:22:38,490 --> 00:22:43,280 potentially write some code that gets somehow called by the firmware and then 236 00:22:43,280 --> 00:22:49,540 copies the internal flash into RAM from where we then can retrieve it using the 237 00:22:49,540 --> 00:22:57,560 debugger. Now, the problem is, let's say we have a custom payload somehow in this 238 00:22:57,560 --> 00:23:04,750 ITCM area. We don't know which address of this ITCM code gets executed. And so we 239 00:23:04,750 --> 00:23:09,410 don't know whether the firmware will jump to adress zero or adress 200 or whatever. 240 00:23:09,410 --> 00:23:14,270 But there's a really simple trick to still build a successful payload. And it's 241 00:23:14,270 --> 00:23:19,230 called a NOP slide. A NOP, or no operation, is an instruction that simply 242 00:23:19,230 --> 00:23:25,100 does nothing. And if we fill most of the ITCM-RAM with NOPs and put our payload at 243 00:23:25,100 --> 00:23:31,700 the very end, we build something that is basically a NOP-slide. And so when the 244 00:23:31,700 --> 00:23:37,260 CPU, indicated by Mario here, jumps to a random address in that whole NOP-slide, it 245 00:23:37,260 --> 00:23:43,500 will start executing NOPs and slide down into our payload and execute it. And so 246 00:23:43,500 --> 00:23:49,100 even if Mario jumps right in the middle of the NOP-slide, he will always slide down 247 00:23:49,100 --> 00:23:54,920 the slide and end up in our payload. And Konrad wrote this really, really simple 248 00:23:54,920 --> 00:23:58,330 payload, which is only like 10 instructions, which basically just copies 249 00:23:58,330 --> 00:24:03,980 the internal flash into RAM from where we can then retrieve it using the debugger. 250 00:24:03,980 --> 00:24:08,280 So wohoo, super simple exploit. We have a full firmware backup and a full flash 251 00:24:08,280 --> 00:24:13,590 backup and now we can really fiddle with everything on the device. And we've 252 00:24:13,590 --> 00:24:17,700 actually released tools to do this yourself. And so if you want to back up 253 00:24:17,700 --> 00:24:23,161 your Nintendo Game & Watch, you can just go onto my GitHub and download the game 254 00:24:23,161 --> 00:24:27,670 and watch backup repository, which contains a lot of information on how to 255 00:24:27,670 --> 00:24:33,270 back it up. It does check something and so on to ensure that you don't 256 00:24:33,270 --> 00:24:38,420 accidentally brick your device and you can easily back up the original firmware, 257 00:24:38,420 --> 00:24:43,610 install homebrew, and then always go back to the original software. We also have an 258 00:24:43,610 --> 00:24:50,630 awesome support community on Discord. And so if you ever need help, I think you will 259 00:24:50,630 --> 00:24:55,270 find success there. And so far we haven't had a single bricked Game & Watch and so 260 00:24:55,270 --> 00:25:02,200 looks to be pretty stable. And so I was pretty excited because the quest was 261 00:25:02,200 --> 00:25:11,170 over. Or is it? If you ever claim on the internet that you successfully hacked an 262 00:25:11,170 --> 00:25:18,180 embedded device, there will be exactly one response and one response only: but does 263 00:25:18,180 --> 00:25:23,610 it run Doom? Literally my Twitter DMs, my YouTube comments, and even my friends were 264 00:25:23,610 --> 00:25:28,720 spamming me with the challenge to get Doom running on the device. But to get Doom 265 00:25:28,720 --> 00:25:34,390 running, we first needed to bring up all the hardware. And so we basically needed 266 00:25:34,390 --> 00:25:40,070 to create a way to develop and load homebrew onto the device. Now, luckily for 267 00:25:40,070 --> 00:25:44,880 us, most of the components on the board are very well documented and so there are 268 00:25:44,880 --> 00:25:50,040 no NDA components. And so, for example, the processor has an open reference manual 269 00:25:50,040 --> 00:25:56,890 and open source library to use it. The flash is a well-known flash chip. And so 270 00:25:56,890 --> 00:26:00,440 on and so forth. And there are only a couple of very proprietary or custom 271 00:26:00,440 --> 00:26:06,280 components. And so, for example, the LCD on the device is proprietary and we had to 272 00:26:06,280 --> 00:26:12,690 basically sniff the SPI-bus that goes to the display to basically decode the 273 00:26:12,690 --> 00:26:19,160 initialization of the display and so on. And after a while, we had the full 274 00:26:19,160 --> 00:26:24,540 hardware running, we had LCD support, we had audio support, deep support, buttons 275 00:26:24,540 --> 00:26:29,210 and even flashing tools that allow you to simply use an SWD debugger to dump and 276 00:26:29,210 --> 00:26:33,820 rewrite the external flash. And you can find all of these things on our GitHub. 277 00:26:33,820 --> 00:26:38,520 Now, if you want to mod your own Game & Watch, all you need is a simple debugging 278 00:26:38,520 --> 00:26:46,840 adapter such as a cheap, three dollar ST- link, a J-link or a real ST-link device, 279 00:26:46,840 --> 00:26:51,140 and then you can get started. We've also published a base project for anyone who 280 00:26:51,140 --> 00:26:54,911 wants to get started with building their own games for the Game & Watch. And so 281 00:26:54,911 --> 00:26:58,670 it's really simple. It's just a frame buffer you can draw to, input is really 282 00:26:58,670 --> 00:27:04,470 simple and so on. And as said, we have a really helpful community. Now with all the 283 00:27:04,470 --> 00:27:10,000 hardware up and running, I could finally start porting Doom. I started by looking 284 00:27:10,000 --> 00:27:15,420 around for other ports of Doom to an STM32. And I found this project by floppes 285 00:27:15,420 --> 00:27:22,010 called stm32doom. Now the issue is, stm32doom is designed for a board with 286 00:27:22,010 --> 00:27:28,340 eight megabytes of RAM and also the data files for Doom were stored on external USB 287 00:27:28,340 --> 00:27:37,630 drive. On our platform, we only have 1.3 MB of RAM, 128 kB of flash and only 1 MB 288 00:27:37,630 --> 00:27:42,600 of external flash and we have to fit all the level information, all the code and 289 00:27:42,600 --> 00:27:50,880 so on in there. Now, the Doom level information is stored in so-called WAD - 290 00:27:50,880 --> 00:27:57,240 Where's All my Data files. And these data files contain the sprites, the textures, 291 00:27:57,240 --> 00:28:03,230 the levels and so on. Now the WAD for Doom 1 is roughly four megabytes in size and 292 00:28:03,230 --> 00:28:11,440 the WAD for Doom 2 is 40 MB in size. But we only have 1.1 MB of storage. Plus we 293 00:28:11,440 --> 00:28:16,390 have to fit all the code in there. So obviously we needed to find a very, very 294 00:28:16,390 --> 00:28:22,200 small Doom port. And as it turns out, there's a file called Mini-WAD, which is a 295 00:28:22,200 --> 00:28:27,680 minimal Doom, I wrote, which is basically all the bells and whistles are stripped 296 00:28:27,680 --> 00:28:34,240 from the WAD file and everything replaced by simple outlines and so on. And while 297 00:28:34,240 --> 00:28:38,130 it's not pretty, I was pretty confident that I could get it working as it's only 298 00:28:38,130 --> 00:28:46,320 250 kB of storage, down from 40 megabytes. Now, in addition to that, a lot of stuff 299 00:28:46,320 --> 00:28:51,300 on the Chocolate Doom port itself had to be changed. And so, for example, I had to 300 00:28:51,300 --> 00:28:56,150 rip out all the file handling and add a custom file handler. I had to add support 301 00:28:56,150 --> 00:29:01,230 for the Game & Watch LCD, button input support. And I also had to get rid of a 302 00:29:01,230 --> 00:29:05,350 lot of things to get it running somewhat smoothly. And so, for example, the 303 00:29:05,350 --> 00:29:10,630 infamous Wipe effect had to go and I also had to remove sound support. Now, the next 304 00:29:10,630 --> 00:29:16,270 issue was that once it was compiling, it simply would not fit into RAM and crash 305 00:29:16,270 --> 00:29:22,820 all the time. Now on the device, we have roughly 1.3 MB of RAM in different RAM 306 00:29:22,820 --> 00:29:27,510 areas. And for example just the frame buffer, that we obviously need, takes up 307 00:29:27,510 --> 00:29:36,350 154 kB off that. Then we have 160 kB of initialized data, 320 kB of uninitialized 308 00:29:36,350 --> 00:29:42,000 data and a ton of dynamic allocations that are done by Chocolate Doom. And these 309 00:29:42,000 --> 00:29:46,610 dynamic allocations were a huge issue because the Chocolate Doom source code 310 00:29:46,610 --> 00:29:52,480 does a lot of small allocations, which are only used for temporary data. And so they 311 00:29:52,480 --> 00:29:58,600 get freed again and so on, and so your dynamic memory gets very, very fragmented 312 00:29:58,600 --> 00:30:02,710 very quickly, and so eventually there's just not enough space to, for example, 313 00:30:02,710 --> 00:30:09,791 initialize the level. And so to fix this, I took the Chocolate Doom code and I 314 00:30:09,791 --> 00:30:15,110 changed a lot of the dynamic allocations to static allocations, which also had the 315 00:30:15,110 --> 00:30:22,030 big advantage of making the error messages by the compiler much more meaningful. 316 00:30:22,030 --> 00:30:27,340 Because it would actually tell you: Hey, this and this data does not fit into RAM. 317 00:30:27,340 --> 00:30:31,990 And eventually, after a lot of trial and error and copying as many of the original 318 00:30:31,990 --> 00:30:39,400 assets as possible into the minimal IWAD, I got it. I had Doom running on the 319 00:30:39,400 --> 00:30:45,030 Nintendo Game & Watch Super Mario Brothers and I hopefully calmed the internet gods 320 00:30:45,030 --> 00:30:49,750 that forced me to do it. Now, unfortunately, the USB port is physically 321 00:30:49,750 --> 00:30:55,690 not connected to the processor and so it will not be possible to hack the device 322 00:30:55,690 --> 00:31:00,390 simply by plugging it into your computer. However, it's relatively simple to do this 323 00:31:00,390 --> 00:31:06,790 using one of these USB-Debuggers. Now, the most requested type of homebrew software 324 00:31:06,790 --> 00:31:12,870 was obviously emulators. And I'm proud to say that by now we actually have kind of a 325 00:31:12,870 --> 00:31:19,210 large collection of emulators running on the Nintendo Game & Watch. And it all 326 00:31:19,210 --> 00:31:23,370 started with Conrad Beckman discovering the Retro Go Project, which is an emulator 327 00:31:23,370 --> 00:31:29,970 collection for a device called the Odroid Go and the Odroid Go is a small handheld 328 00:31:29,970 --> 00:31:35,880 with similar input and size constraints as the Nintendo Game & Watch. And so it's 329 00:31:35,880 --> 00:31:40,630 kind of cool to port this over because it basically already did all of the hard 330 00:31:40,630 --> 00:31:47,670 work, so to say. And Retro Go comes with emulators for the NES, for the Gameboy and 331 00:31:47,670 --> 00:31:52,770 the Gameboy color and even for the Sega Master System and the Sega Game Gear. And 332 00:31:52,770 --> 00:31:58,290 after a couple of days, Conrad actually was able to show off his NES emulator 333 00:31:58,290 --> 00:32:02,960 running Zelda and other games such as Contra and so on, on the Nintendo Game & 334 00:32:02,960 --> 00:32:09,230 Watch. This is super fun and initially we only had really a basic emulator that 335 00:32:09,230 --> 00:32:13,170 could barely play and we had a lot of frame drops, we didn't have nice scaling, 336 00:32:13,170 --> 00:32:18,290 VSync and so on. But now after a couple of weeks, it's really a nice device to use 337 00:32:18,290 --> 00:32:24,090 and to play with. And so we also have a Gameboy emulator running and so you can 338 00:32:24,090 --> 00:32:29,440 play your favorite Gameboy games such as Pokémon, Super Mario Land and so on on the 339 00:32:29,440 --> 00:32:35,160 Nintendo Game & Watch if you own the corresponding ROM Backups. And we also 340 00:32:35,160 --> 00:32:38,650 experimented with different scaling algorithms to make the most out of the 341 00:32:38,650 --> 00:32:43,310 screen. And so you can basically change the scaling algorithm that is used for the 342 00:32:43,310 --> 00:32:48,160 display, depending on what you prefer. And you could even change the palette for the 343 00:32:48,160 --> 00:32:54,450 different games. We also have a nice game chooser menu which allows you to basically 344 00:32:54,450 --> 00:32:59,240 have multiple ROMs on the device that you can switch between. We have safe state 345 00:32:59,240 --> 00:33:04,210 support and so if you turn off the device, it will save wherever you left off and you 346 00:33:04,210 --> 00:33:08,870 can even come back to your save game once the battery run out. You can find the 347 00:33:08,870 --> 00:33:14,380 source code for all of that on the Retro Go repository from Conrad. And it's 348 00:33:14,380 --> 00:33:20,710 really, really awesome. Other people build for example emulators for the CHIP-8 349 00:33:20,710 --> 00:33:25,430 system and so the CHIP-8 emulator comes with a nice collection of small arcade 350 00:33:25,430 --> 00:33:31,271 games and so on, and it's really fun and really easy to develop for it. And so 351 00:33:31,271 --> 00:33:37,010 really give this a try if you own a Game & Watch and want to try homebrew on it. Tim 352 00:33:37,010 --> 00:33:41,590 Schuerwegen is even working on an emulator for the original Game & Watch 353 00:33:41,590 --> 00:33:45,920 games. And so this is really cool because it basically turned the Nintendo Game & 354 00:33:45,920 --> 00:33:53,130 Watch into an emulator for all Game & Watch games that were ever released. And 355 00:33:53,130 --> 00:33:57,860 what was really amazing to me is how the community came together. And so we were 356 00:33:57,860 --> 00:34:02,140 pretty open about the progress on Twitter. And also Conrad was Twitch streaming a lot 357 00:34:02,140 --> 00:34:06,480 of the process. And we opened up a discord where people could join who were 358 00:34:06,480 --> 00:34:11,850 interested in hacking on the device. And it was amazing to see what came out of the 359 00:34:11,850 --> 00:34:16,720 community. And so, for example, we now have a working storage upgrade that works 360 00:34:16,720 --> 00:34:21,179 both with homebrew but also with the original firmware. And so instead of one 361 00:34:21,179 --> 00:34:25,320 megabyte of storage, you can have 60 megabytes of flash and you just need to 362 00:34:25,320 --> 00:34:30,549 replace a single chip, which is pretty easy to do. Then for understanding the 363 00:34:30,549 --> 00:34:35,690 full hardware. Daniel Cuthbert and Daniel Padilla provided us with high resolution x 364 00:34:35,690 --> 00:34:41,010 ray images, which allowed us to fully understand every single connection, even 365 00:34:41,010 --> 00:34:46,379 of the PGA parts, without desoldering anything. Then Jake Little of Upcycle 366 00:34:46,379 --> 00:34:52,980 Electronics traced on the x rays and also using a multimeter every last trace on the 367 00:34:52,980 --> 00:34:58,220 PCB, and he even created a schematic of the device, which gives you all the 368 00:34:58,220 --> 00:35:02,260 details you need when you want to program something also and it was really, really 369 00:35:02,260 --> 00:35:07,099 fun. Sander van der Wel for example even created a custom backplate and now there 370 00:35:07,099 --> 00:35:13,220 are even projects that try to replace the original PCB with a custom PCB with an 371 00:35:13,220 --> 00:35:20,019 FPGA and an ESP 32. And so it's really exciting to see what people come up with. 372 00:35:20,019 --> 00:35:24,819 Now, I hope you enjoyed this talk and I hope to see you on our discord if you want 373 00:35:24,819 --> 00:35:35,019 to join the fun. And thank you for coming. 374 00:35:35,019 --> 00:35:41,329 Herald: Hi. Wow, that was a really amazing talk. Thank you very much Thomas. As 375 00:35:41,329 --> 00:35:48,140 announced in the beginning we do accept questions from you and we have quite a 376 00:35:48,140 --> 00:35:54,450 few. Let's see if we manage to make it through all of them. The first one is: 377 00:35:54,450 --> 00:35:59,650 Q: Did you read the articles about Nintendo observing hackers, like private 378 00:35:59,650 --> 00:36:04,799 investigators, et cetera and are you somehow worried about this? 379 00:36:04,799 --> 00:36:08,400 Thomas: Oh, what's going on with my camera? Looks like Luigi messed around 380 00:36:08,400 --> 00:36:17,539 with my video setup here. Yeah, I so I've read those articles, but so I believe that 381 00:36:17,539 --> 00:36:22,210 in this case, there is no piracy issue, right? Like, I'm not allowing anyone to 382 00:36:22,210 --> 00:36:26,940 play any new games. If you wanted to to dump a Super Mario ROM, you would have 383 00:36:26,940 --> 00:36:32,160 done it 30 years ago or on the NES Classic or on the Switch or on any of the hundred 384 00:36:32,160 --> 00:36:37,240 consoles Nintendo launched in between. And so I'm really not too worried about it, to 385 00:36:37,240 --> 00:36:41,480 be honest. Herald: I also think the aspect of the 386 00:36:41,480 --> 00:36:50,270 target audience is to be seen here. So off to the next question which is: Do you 387 00:36:50,270 --> 00:36:55,460 think that there is a reason why an external flash chip has been used? 388 00:36:55,460 --> 00:37:02,849 Thomas: Yeah. So the internal flash of the STM32-H7B0 is relatively small. It's only 389 00:37:02,849 --> 00:37:08,450 128 kB. And so they simply couldn't fit everything in, like basically even 390 00:37:08,450 --> 00:37:13,240 just the frame buffer. Even just a frame buffer picture also is larger than the 391 00:37:13,240 --> 00:37:19,100 internal flash. And so I think that's why they did it and I'm glad they did. 392 00:37:19,100 --> 00:37:26,730 Herald: Sure. And is the decryption done in software or is it a feature of the 393 00:37:26,730 --> 00:37:30,460 microcontroller? Thomas: So the microcontroller has an 394 00:37:30,460 --> 00:37:36,160 integrated feature called OTF-DEC and basically the flash is directly mapped 395 00:37:36,160 --> 00:37:41,109 into memory and they have this chip prefill called OTF DEC that automatically 396 00:37:41,109 --> 00:37:45,430 provides the decryption and so on. And so it's done all in hardware and you can even 397 00:37:45,430 --> 00:37:48,350 retrieve the keys from hardware, basically. 398 00:37:48,350 --> 00:37:57,910 Herald: OK, very nice. And also, the next question is somehow related to that: Is in 399 00:37:57,910 --> 00:38:03,520 your opinion the encryption Nintendo has applied even worth the effort for them? 400 00:38:03,520 --> 00:38:07,430 It feels like it's just there to give shareholders a false sense of security. 401 00:38:07,430 --> 00:38:12,709 What would you think about that? Thomas: I think from my perspective, they 402 00:38:12,709 --> 00:38:16,489 choose just the right encryption because it was a ton of fun to reverse engineer 403 00:38:16,489 --> 00:38:21,910 and try to to bypass it and so it was an awesome challenge and so I think they did 404 00:38:21,910 --> 00:38:26,900 everything right. But I also think in the end, it's such a simple device and it's 405 00:38:26,900 --> 00:38:31,569 like if you take a look at what people are building on top of it with like games and 406 00:38:31,569 --> 00:38:36,680 all that kind of stuff. I think they did everything right, but probably it was just 407 00:38:36,680 --> 00:38:41,569 a tick markup. Yeah, we totally locked down JTAG and yeah, but I think it's fun 408 00:38:41,569 --> 00:38:44,609 because again, it doesn't open up any piracy issues. 409 00:38:44,609 --> 00:38:51,140 Herald: Sure. The one thing is related to the NOP slide, which you very, very well 410 00:38:51,140 --> 00:39:01,189 animated. So wouldn't starts of subroutines be suitable as well for that, 411 00:39:01,189 --> 00:39:11,460 for that goal. The person asking says that a big push R4, R5, etc. instructions are 412 00:39:11,460 --> 00:39:20,640 quite recognizable. How would ... Yeah Thomas: Yeah. So absolutely. The time from 413 00:39:20,640 --> 00:39:25,019 finding the data in the ITCM-RAM and actually exploiting it was less than an 414 00:39:25,019 --> 00:39:29,950 hour. And so if we would have tried to reverse engineer it, it would be more 415 00:39:29,950 --> 00:39:33,660 work. Like absolutely possible and also not difficult, but just filling the RAM 416 00:39:33,660 --> 00:39:38,559 with NOP took a couple of minutes and so was really the easiest way and the fastest 417 00:39:38,559 --> 00:39:45,420 way without fiddling around in Ghidra or so. Herald: OK, cool, thanks. And this is more 418 00:39:45,420 --> 00:39:54,329 a remark than a question. The person says it's strange that an STAN5281 does not 419 00:39:54,329 --> 00:39:59,630 mention a single time that the data is not verified during encryption. I think it's 420 00:39:59,630 --> 00:40:05,759 more a fault on STs than Nintendos site. What would you think about that? 421 00:40:05,759 --> 00:40:10,690 Thomas: Yeah, I would somewhat agree because in this case, even if you don't 422 00:40:10,690 --> 00:40:17,670 have JTAG, like an ARM thum instruction is 2-4 bytes and so you have a relatively small 423 00:40:17,670 --> 00:40:21,859 space to brute force to potentially get an interesting branch instruction and so on. 424 00:40:21,859 --> 00:40:28,009 So I think it's yeah, I mean, it's not perfect, but also doing verification 425 00:40:28,009 --> 00:40:33,410 is very expensive, computational wise and so I think it should just be the firmware 426 00:40:33,410 --> 00:40:37,160 that actually verifies the contents of the external flash. 427 00:40:37,160 --> 00:40:44,109 Herald: OK, so I think we should ask 2 questions more and then we can go back to 428 00:40:44,109 --> 00:40:52,000 the studio. There is a question about the AS encryption keys. Have you managed to 429 00:40:52,000 --> 00:40:57,349 recover them? Thomas: Yes, we did. But so it's an 430 00:40:57,349 --> 00:41:01,700 applicational AST, and they do some crazy shifting around with the keys but I think 431 00:41:01,700 --> 00:41:07,400 even just today, like an hour before the talk, a guy, sorry I'm not sure it's a 432 00:41:07,400 --> 00:41:12,650 guy, a person on our discord actually managed to rebuild the full encryption. 433 00:41:12,650 --> 00:41:16,779 But we, I personally wasn't never interested in that because after you've 434 00:41:16,779 --> 00:41:22,080 downgraded to RTP 0, the device. You can just access the memory mapped flash and 435 00:41:22,080 --> 00:41:24,740 get the completely decrypted flash contents basically. 436 00:41:24,740 --> 00:41:32,009 Herald: Sure. Thanks. And a last question about the LCD-Controller, whether it's 437 00:41:32,009 --> 00:41:38,180 used by writing pixels over SPI or if it has some extra features, maybe even 438 00:41:38,180 --> 00:41:40,930 background or sprites or something like that? 439 00:41:40,930 --> 00:41:46,809 Thomas: So the the LCD itself doesn't have any special features. It has one SPI bus 440 00:41:46,809 --> 00:41:50,930 to configure it and then a parallel interface where - so it takes up a lot 441 00:41:50,930 --> 00:41:56,809 of pins. But the chip itself has a hardware called LTDC, which is an LCD 442 00:41:56,809 --> 00:42:00,769 controller, which provides two layers with alpha blending and some basic windowing 443 00:42:00,769 --> 00:42:06,630 and so on. Herald: OK, cool then thank you very, very 444 00:42:06,630 --> 00:42:11,799 much for the great talk and the great intro. And with that, back to our main 445 00:42:11,799 --> 00:42:14,859 studio in the orbit. Thank you very much. Back to orbit. 446 00:42:14,859 --> 00:42:17,977 *rC3 postroll music* 447 00:42:17,977 --> 00:42:56,000 Subtitles created by c3subtitles.de in the year 2020. Join, and help us!