Hacking the Nintendo Game & Watch
Roth, Thomas
On November 13., Nintendo launched its newest retro console, the Nintendo Game and Watch - but by then it was already hacked! In contrast to the other Nintendo classic consoles (NES & SNES), Nintendo upped their game this time: A locked processor, AES-CTR encrypted flash & co. made it significantly harder to hack it, but in the end it was still hacked - one day before release. This talk walks through the whole process of opening it up, exploiting the firmware up to bringing homebrew to a new console - in a fun, beginner friendly way. The Nintendo Game & Watch was anticipated by a lot of retro-interested folks, and the clear expectation was: We wan't to get more games onto this device! But Nintendo made the life of hackers harder: The CPU is locked, the external flash AES encrypted, and the USB-C connector does not have its data-lines connected. But not so fast! In this talk we learn how to exploit the firmware, get code-execution via a NOP-slide, dump the ROMs & RAMs of the device and achieve what everyone has been asking for: DOOM running on the Nintendo Game & Watch.
 So about the next speaker, he's a security researcher focused on embedded systems, secure communications and mobile security. He was nominated by Forbes for the 30 under 30 in technology and also has won a Oba's AppSex CTF. He has also found and disclosed responsibly multiple vulnerabilities and especially for you Nintendo fiction others, I want you to watch out for the next intro which is really amazing and you will all love. Thank you very much. What a trip. Welcome to my talk on hacking the new Nintendo Game and Watch Super Mario Brothers. My name is Thomas Roth and I'm a security researcher and trainer from Germany and you can find me on Twitter at Gidra Ninja and also on YouTube at Stax Machine. Now this year marks the 35th anniversary of our favorite plumber Super Mario and to celebrate that, Nintendo launched a new game console called the Nintendo Game and Watch Super Mario Brothers. The console is lightweight and looks pretty nice and it comes pre-installed with three games and also this nice animated clock. The three games are Super Mario Brothers, the original NES game, Super Mario Brothers 2, The Lost Levels and also a reinterpretation of an old Game and Watch game called Ball. Now as you probably know, this is not the first retro console that Nintendo released. In 2016 they released the NES Classic and in 2017 they released the SNES Classic. Now these devices were super popular in the homebrew community because they make it really easy to add additional ROMs to it, they make it really easy to modify the firmware and so on and you can basically just plug them into your computer, install a simple software and you can do whatever you want with them. The reason for that is that they run Linux and have a pretty powerful ARM processor on the inside and so it's really a nice device to play with and so on and so when Nintendo announced this new console a lot of people were hoping for a similar experience of having a nice mobile homebrew device. Now if you were to make a Venn diagram of some of my biggest interests you would have reverse engineering, hardware hacking and retro computing and this new Game and Watch fits right in the middle of that and so when it was announced on the 3rd of September I knew that I needed to have one of those and given how hard the NES and the SNES Classic were to buy for a while I pre-ordered it on like four or five different sites, a couple of which got cancelled but I was pretty excited because I had three pre-orders and it was supposed to ship on the 13th of November and so I was really looking forward to this and I was having breakfast on the 12th of November when suddenly the doorbell rang and DHL delivered me the new Game and Watch one day before the official release. Now at that point in time there was no technical information available about the device whatsoever like if you searched for Game and Watch on Twitter you would only find the announcements or maybe a picture of the box of someone who also received it early but there were no tear downs, no pictures of the insides and most importantly nobody hacked had hacked it yet and this gave me as a hardware hacker the kind of unique opportunity to potentially be the first one to hack a new Nintendo console and so I just literally dropped everything else I was doing and started investigating the device. Now I should say that normally I stay pretty far away from any new console hacking mainly because of the piracy issues. I don't want to enable piracy, I don't want to deal with piracy and I don't want to build tools that enable other people to pirate stuff basically but given that on this device you cannot buy any more games and that all the games that are on there were basically already released over 30 years ago I was not really worried about piracy and felt pretty comfortable in sharing all the results of the investigation and also the basically the issues we found that allowed us to customize the device and so on and in this talk I want to walk I want to walk you through how we managed to hack the device and how you can do it at home using relatively cheap hardware and yeah hope you enjoy it. Now let's start by looking at the device itself. The device is pretty lightweight and comes with a nicely sized case and so it really for me it sits really well on my hand and it has a nice 320x240 LCD display, a D-pad, A and B buttons and also three buttons to switch between the different game modes. On the right side we also have the power button and the USB-C port. Now before you get excited about the USB port I can already tell you that unfortunately Nintendo decided to not connect the data lines of the USB port and so you can really only use it for charging. Also because we are talking about Nintendo here they use their proprietary tri-point screws on the device and so to open it up you need one of those special tri-point bits. Luckily nowadays most bit sets should have them but it still would suck if you order your unit and then you can't open it up because you're missing a screwdriver. After opening it up the first thing you probably notice is the battery and if you've ever opened up a Nintendo Switch Joy-Con before you might recognize the battery because it's the exact same one that's used in the Joy-Cons. This is very cool because if down the line like let's say in two or three years your battery of your Game & Watch dies you can just go and buy a Joy-Con battery which you can have really cheaply almost anywhere. Next to the battery on the right side we have a small speaker which is not very good and underneath we have the main PCB with the processor, the storage and so on and so forth. Let's take a look at those. Now the main processor of the device is an STM32 H7B0. This is a Cortex M7 from ST Microelectronics with 1.3 megabytes of RAM and 128 kilobytes of flash. It runs at 280 MHz and is a pretty beefy microcontroller but it's much less powerful than the processor in the NES or SNES Classic. Like this processor is really just a microcontroller and so it can't run Linux, it can't run let's say super complex software instead it will be it will be programmed in some bare metal way and so we will have a bare metal firmware on the device. To the right of it you can also find a 1 megabyte SPI flash and so overall we have roughly 1.1 megabyte of storage on the device. Now most microcontrollers or basically all microcontrollers have a debugging port and if we take a look at the PCB you can see that there are five unpopulated contacts here and if you see a couple of contacts that are not populated close to your CPU it's very likely that it's the debugging port and luckily the datasheet for the STM32 is openly available and so we can check the pinouts in the datasheet and then use a multimeter to to see whether these pins are actually the debugging interface and turns out they actually are and so we can find the SWD debugging interface as well as VCC and ground exposed on these pins. Now this means that we can use a debugger so for example a J-Link or an ST-Link or whatever to connect to the device and because the the contacts are really easy to access you don't even have to solder like you can just hook up a couple of test pins and they will allow you to to easily hook up your debugger. Now the problem is on most devices the debugging interface will be locked during manufacturing this is done to prevent people like us to basically do whatever with the device and to prevent us from being able to dump the firmware potentially reflash it and so on and so I was very curious to see whether we can actually connect to the debugging port and when starting up J-Link and trying to connect we can see it can actually successfully connect but when you take a closer look there's also a message that the device is active-reprotected. This is because the chip the STM32 chip features something called RDP protection level or read out protection level. This is basically the the security setting for the debugging interface and it has three levels. Level zero means no protection is active. Level one means that the flash memory is protected and so we can't dump the internal flash of the device however we can dump the RAM contents and we can also execute code from RAM and then there's also level two which means that all debugging features are disabled. Now just because a chip is in level two doesn't mean that you have to give up for example in our talk wallet.fail a couple of years ago we showed how to use fault injection to bypass the level two protection and downgrade a chip to level one however on the game and watch we are lucky and the interface is not fully disabled instead it's in level one and so we can still dump the RAM which is a pretty good entry point even though we can't dump the firmware yet. Now having dumped the RAM of the device I was pretty curious to see what's inside of it and one of my suspicions was that potentially the emulator that's hopefully running on the device loads the original Super Mario Brothers ROM into RAM and so I was wondering whether maybe we can find the ROM that the device uses in the RAM dump and so I opened up the RAM dump in a in a hex editor and I also opened up the original Super Mario Brothers ROM in a second window in a hex editor and tried to find different parts of the original ROM in the RAM dump and it turns out that yes the NES ROM is loaded into RAM and it's always at the same address and so it's probably like during boot up it gets copied into RAM or something along those lines and so this is pretty cool to know because it tells us a couple of things. First off we know now that the debug port is enabled and working but that it's unfortunately at RDP level one and so we can only dump the the RAM and we also know that the NES ROM is loaded into RAM and this means that the device runs a real NES emulator and so if we get okay we can for example just replace the ROM that is used by the by the device and play for example our own NES game. Next was time to dump the flash chip of the device. For this I'm using a device called Mini Pro and I'm using one of these really useful SOIC8 clips and so these ones you can simply clip onto the flash chip and then dump it. Now one warning though the flash chip on the device is running at 1.8 volts and so you want to make sure that your programmer also supports 1.8 volt operation. If you accidentally try to read it out at 3.3 volts you will break your flash trust me because it happened to me on one of my units. Now with this flash dump from the device we can start to analyze it and what I always like to do first is take a look at the entropy or the randomness of the flash dump and so using binwalk with the dash uppercase e-option we get a nice entropy graph and in this case you can see we have a very high entropy over almost the whole flash contents and this mostly indicates that the flash contents are encrypted. It could also mean compression but if it's compressed you would often see more like dips in the entropy and in this case it's one very high entropy stream. We also notice that there are no repetitions whatsoever which also tells us that it's probably not like a simple XOR based encryption or so and instead something like AES or something similar but just because the flash is encrypted doesn't mean we have to give up. On the contrary I think now it starts to get interesting because you actually have a challenge and it's not just plug and place so to say. One of the biggest questions I had is is the flash actually verified like does the device boot even though the flash has been modified because if it does this would open up a lot of attack vectors basically as you will see and so to verify this I basically try to put zeros in random places in the flash image and so I put some at address zero some at hex 2000 and so on and then I checked whether the device would still boot up and with the most flash modifications it would still boot just fine. This tells us that even though the flash contents are encrypted they are not validated they are not checked something or anything and so the device and so we can potentially trick the device into accepting a modified flash image and this is really important to know as you will see in a couple of minutes. My next suspicion was that maybe the NES ROM we see in RAM is actually loaded from the external flash and so to to find out whether that's the case I again took the flash and I inserted zeros at multiple positions in the flash image, flashed that over, booted up the game, dumped the RAM and then compared the NES ROM that I'm now dumping from RAM with the one that I dumped initially and checked whether they are equal because my suspicion was that maybe I can overwrite a couple of bytes in the encrypted flash and then I will modify the NES ROM and after doing this for like I don't know half an hour I got lucky and I modified four bytes in the flash image and four bytes in the RAM sorry in the ROM that was loaded into RAM changed and this tells us quite a bit it means that the ROM is loaded from flash into RAM and that the flash contents are not validated and what's also important is that we we change four bytes in the flash and now four bytes in the decrypted image changed and this is very important to know because if we take a look at what we would expect to happen when we when we change the flash contents there are multiple outcomes and so for example here we have the spy flash contents on the left and the RAM contents on the right and so the RAM contents are basically the decrypted version of the spy flash contents now let's say we change four bytes in the encrypted flash image to zeros how would we expect the RAM contents to change for example if we would see that now 16 bytes in the RAM are changing this means that we are potentially looking at an encryption algorithm such as AES in electronic codebook mode because it's a block based encryption and so if we change four bytes in the input data a block size in this case 16 bytes in the output data would change the next possibility is that we change four bytes in the spy flash and all data afterwards will be changed and in this case we would look at some kind of chaining cipher such as AES in cbc mode however if we change four bytes in the spy flash and only four bytes in the RAM changed we are looking at at something such as AES in counter mode and to understand this let's take a better look at how AES in CTR works AES CTR works by having your clear text and X oring it with an AES encryption stream that is generated from a key and nonce and a counter algorithm now the AES stream that will be used to X or your clear text will always be the same if key and nonce is the same this is why it's super important that if you use AES CTR you always select a unique nonce for each encryption if you encrypt similar data with the same nonce twice large parts of the resulting cipher text will be the same and so the clear text gets X ored with the AES CTR stream and then we get our cipher text now if we know the clear text as we do because the clear text is the ROM that is loaded into RAM and we know the cipher text which we do because it's the contents of the encrypted flash we just dump we can basically reverse the operation and as a result we get the AES CTR stream that was used to encrypt the flash and now this means that we can take for example a custom ROM X or it with the AES CTR stream we just calculated and then generate our own encrypted flash image for example with a modified ROM and so I wrote a couple of Python scripts to try this and after a while I was running hacked Super Mario Brothers instead of Super Mario Brothers so woohoo we hacked the Nintendo Game & Watch one day before the official release and we can install modified Super Mario Brothers ROMs now you can find the scripts that are used for this on my github so it's in a repository called Game & Watch Hacking and I was super excited because it meant that I succeeded and that I basically hacked a Nintendo console one day before the official release unfortunately I finished the level but Toad wasn't as excited he told me that unfortunately our firmware is still in another castle and so on the Monday after the launch of the device I teamed up with Conrad Beckman a hardware hacker from Sweden who I met at the previous congress and we started chatting and throwing ideas back and forth and so on and eventually we noticed that the device has a special RAM area called ITCM RAM which is a tightly coupled instruction RAM that is normally used for very high performance routines such as interrupt handlers and so on and so it's in a very fast RAM area and we realized that we never actually looked at the contents of that ITCM RAM and so we dumped it from the device using the debugging port and it turns out that this ITCM RAM contains ARM code and so again the question is where does this ARM code come from does it maybe just like the NES ROM come from the external flash and so basically I repeated the whole the whole thing that we also did with the NES ROM and it just put zeros at the very beginning of the encrypted flash rebooted the device and dumped the ITCM ROM and I got super lucky on the first try already the ITCM contents changed and because the ITCM contains code not just data so earlier we only had the the NES ROM which is just data but this time the RAM contains code this means that with the same XOR trick we used before we could inject custom ITCM code into the external flash which would then be loaded into RAM when the device boots and because it's a persistent method we can then reboot the device and let it run without the debugger connected and so whatever code we load into this ITCM area will be able to actually read the flash and so we could potentially write some code that gets somehow called by the firmware and then copies the internal flash into RAM from where we then can retrieve it using the debugger now the problem is let's say we have a custom payload in somehow in this ITCM area we don't know which address of this ITCM code gets executed and so we don't know whether the firmware will jump to address zero or address 200 or whatever but there's a really simple trick to still build a successful payload and it's called a knob slide a knob or a no operation is an instruction that simply does nothing and if we fill most of the ITCM RAM with knobs and put our payload at the very end we build something that is basically a knob slide and so when the CPU indicated by Mario here jumps to a random address in that whole knob slide it will start executing knobs, knobs, knobs, knobs and slide down into our payload and execute it and so even if Mario jumps right in the middle of the knob slide he will always slide down the slide and end up in our payload and Conrad wrote this really really simple payload which is only like 10 instructions which basically just copies the internal flash into RAM from where we can then retrieve it using the debugger so woohoo super simple exploit we have a full firmware backup and a full flash backup and now we can really fiddle with everything on the device and we've actually released tools to do this yourself and so if you want to backup your Nintendo Game and Watch you can just go onto my github and download the Game and Watch backup repository which contains a lot of information on how to back it up it does it does check something and so on to ensure that you don't accidentally brick your device and you can easily backup the original firmware, install homebrew and then always go back to the original software we also have an awesome support community on discord and so if you ever need help you will I think you will find success there and so far we haven't had a single brick game and watch and so it looks to be pretty stable and so I was pretty excited because the quest was over or is it if you ever claim on the internet that you successfully hacked an embedded device there will be exactly one response and one response only but does it run do literally my twitter DMs my youtube comments and even my friends were spamming me with the challenge to get doom running on the device but to get doom running we first needed to bring up all the hardware and so we basically needed to create a way to develop and load homebrew onto the device now luckily for us most of the components on the board are very well documented and so there are no nda components and so for example the processor has an open reference manual and open source library to use it the flash is a well-known flash chip and so on and so forth and there are only a couple of very proprietary or custom components and so for example the lcd on the device is proprietary and we had to basically sniff the spi bus that goes to the display to basically decode the the initialization of the of the display and so on and after a while we had the full hardware running we had lcd support we had audio support sleep support buttons and even flashing tools that allow you to simply use an swd debugger to dump and rewrite the external flash and you can find all of these things on our github now if you want to mod your own game and watch all you need is a simple debugging adapter such as a cheap three dollar st link a jlink one s or a real st link device and then you can get started we've also published a base project for anyone who wants to get started with building their own games for the game and watch and so it's really simple it's just a frame buffer you can draw to input is really simple and so on and as said we have a really helpful community now with all the hardware up and running i could finally start porting doom now i started by looking around for other ports of doom 2 and stm32 and i found this project by floppy called stm32 doom now the issue is stm32 doom is designed for a board with eight megabytes of ram and also the data files for doom were stored on an external usb drive on our platform we only have 1.3 megabytes of ram 128 kilobytes of flash and only one megabyte of external flash and we have to fit all the level information all the code and so on in there now the doom level information is stored in so called wad what where's all my data files and these data files contain the sprites the textures the levels and so on now the wad for doom 1 is roughly four megabytes in size and the wad for doom 2 is 14 megabytes in size but we only have 1.1 megabyte of storage plus we have to fit all the code in there so obviously we needed to find a very very small doom what and as it turns out there's a thing called mini what which is a minimal doom i what which is basically all the bells and whistles stripped from the wad file and everything replaced by simple outlines and so on and while it's not pretty i was pretty confident that i could get it working as it's only 250 kilobytes of storage down from 14 megabytes now in addition to that a lot of stuff on the chocolate doom port itself had to be changed and so for example i had to rip out all the file handling and add a custom file handler i had to add support for the gamut watch lcd button import support and i also had to get rid of a lot of things to get it running somewhat smoothly and so for example the infamous wipe effect had to go and i also had to remove sound support now the next issue was that once it was compiling it simply would not fit into ram and crash all the time now on the device we have roughly 1.3 megabytes of ram in different ram areas and for example just the frame buffer that we obviously need takes up 154 kilobytes of that then we have 160 kilobytes of initialized data 320 kilobytes of uninitialized data and a ton of dynamic allocations that are done by chocolate doom and these dynamic allocations were a huge issue because the chocolate doom source code does a lot of small allocations which are only used for temporary data and so they get freed again and so on and so your dynamic memory gets very very fragmented very quickly and so eventually there's just not enough space to for example initialize the level and so to fix this i took the chocolate doom code and i changed a lot of the dynamic allocations to static allocations which also had the big advantage of making the error messages by the compiler much more meaningful because it would actually tell you hey this and this data does not fit into ram and eventually after a lot of trial and error and copying as many of the original assets as possible into the minimal iWatt i got it i had doom running on the nintendo game and watch super mario brothers and i hopefully calmed the internet gods that forced me to do it now unfortunately the usb port is physically not connected to the processor and so it will not be possible to hack the device simply by plugging it into your computer however it's relatively simple to do this using one of these usb debuggers now the most requested type of home brew software was obviously emulators and i'm proud to say that by now we actually have kind of a large collection of emulators running on the nintendo game and watch and it all started with konrad backman discovering the retro go project which is an emulator collection for a device called the odroid go and the odroid go is a small handheld with similar input and size constraints as the nintendo game and watch and so it's kind of cool to port this over because it it basically already did all of the hard work so to say and retro go comes with emulators for the nes for the gameboy and the gameboy color and even for the sega master system and the sega game gear and after a couple of days konrad actually was able to show off his nes emulator running zelda and other games such as contra and so on on the nintendo game and watch this is super fun and initially we only had really a basic emulator that you know could barely play and we had a lot of frame drops we didn't have nice scaling v-sync and so on but now after a couple of weeks it's really a nice device to use and to play with and so we also have a gameboy emulator running and so you can play your favorite gameboy games such as pokemon super mario land and so on on the nintendo game and watch if you own the corresponding rom backups and we also experimented with different scaling algorithms to make the most out of the screen and so you can basically change the scaling algorithm that is used for the display depending on what you prefer and you could even change the palette for the different games we also have a nice game chooser menu where which allows you to basically have multiple roms on the device that you can switch between we have safe state support and so if you turn off the device it will save wherever you left off and you can even come back to your save game once the battery run out you can find the source code for all of that on the retro go repository from konrad and it's really really awesome other people build for example emulators for the chip 8 system and so the chip 8 emulator comes with a nice collection of small arcade games and so on and it's really fun and really easy to develop for and so you really give this a try if you own a game and watch and want to try homebrew on it team sure being is even working on an emulator for the original game and watch games and so this is really cool because it basically turns the nintendo game and watch into an emulator for all game and watch games that were ever released and what was really amazing to me is how the community came together and so we were pretty open about the progress on twitter and also konrad was twitch streaming a lot of the process and we open up a discord where people could join who are interested in hacking on the device and it was amazing to see what came out of the community and so for example we now have a working storage upgrade that works both with homebrew but also with the original firmware and so instead of one megabyte of storage you can have 60 megabytes of flash and you just need to to replace a single chip which is pretty as easy to do then for understanding the full hardware daniel kathbert and daniel padilla provided us with high resolution x-ray images which allowed us to fully understand every single connection even of the bga parts without desoldering anything then jake little of upcycle electronics traced on the x-rays and also using a multimeter every last trace on the pcb and he even created a schematic of the device which gives you all the details you need when you want to program something or so and was really really fun sender vanderville for example even created a custom backplate and now there are even projects that try to replace the original pcb with a custom pcb with an fpga and an esp32 and so it's really exciting to see what people come up with now i hope you enjoyed this talk and i hope to see you on our discord if you want to join the fun and thanks you for coming hi um wow that was a really amazing talk thank you very much uh thomas um as announced in the beginning uh we do accept questions from you and uh we have quite quite a few um let's see if we manage to make it through all of them um the first one is um did you read the articles about nintendo observing hackers like private investigators etc and are you somehow worried about this oh what's going on with my camera looks like luigi messed around with my video setup here um aha yeah i've so i've read those articles but um so i believe that in this case the there is no piracy issue right like i'm not allowing anyone to play any new games if you wanted to to dump a super mario rom you would have done it 30 years ago or on the nes classic or on the switch on any of the 100 consoles nintendo launched in between and so i'm really not too worried about it to be honest um i know something the the aspect of of the target audience is is to be seen here so off to the next question which is um is there do you think that there is a reason why an external flash chip has been used yeah so the internal flash of the s3 2 h7 b0 is relatively small it's only 128 kilobytes and so they simply couldn't fit everything in like basically even just the frame buffer um even just a frame buffer picture also is larger than the internal flash and so um i think that's why they did it and i'm glad they did yeah sure um and um is the decryption done in software or is it a feature of the microcontroller so the microcontroller has an integrated feature called otf dc otf deck and basically the flash is directly mapped into memory and they have this chip peripheral called otf deck that automatically provides the decryption and so on and so it's done all in hardware um you can even retrieve the keys from hardware basically oh okay very nice and also um and the next question is somehow related to that uh is uh in your opinion the encryption Nintendo has applied uh even worth the effort for them it feels like it's just there to give shareholders a false sense of security how what would you think about that i think from my perspective they choose just the right encryption because it was a ton of fun to reverse engineer and try to to bypass it and so uh it was an awesome challenge and so i think they did everything right but um i also think in the end it's it's such a simple device and it's like if you take a look at what people are building on top of it with like games and and all the kind of stuff um i think they did everything right but probably it was just a tick mark of yeah we totally locked down jtech and yeah but i think it's fun because again like it doesn't open up any piracy issues sure and the one thing is related to the nopslite which you very very well animated um so um wouldn't wouldn't start of sub-routines be suitable as well for that uh for that uh goal um uh the the person asking uh says that a big push our far our four our five etc instructions are quite recognizable um how would yeah yeah so um absolutely so um the the time from finding the data in the itcm ram and actually exploiting it was less than an hour and so um if we would have tried to reverse engineer it would be more work like absolutely possible and also not difficult but just filling the ram with nop took a couple of minutes and so um it was really the easiest way in the fastest way um without fiddling around in gdra also okay cool thanks and uh this is more a remark than a question um the person says it's strange that an sts an 52 81 does not mention a single time that the data is not verified during encryption i think it's more a fault on sts than nintendo's side what would you uh think about that yeah i would i would somewhat agree because in this case even if you don't have jtag like an arm thump instruction is two to four bytes and so you you you have a relatively small space to brute force to potentially get an interesting branch instruction and so on so i think it's yeah i mean it's it's not perfect but also um doing verification is very expensive computational wise and so i think it should just be the the firmware that actually verifies the contents of the external flash okay um so we i think we should two questions more and then we can go back to the studio um the there's a question about the is encryption key um have you managed to recover them yes we did um but so there is an application of by st and they do some crazy shifting around with the keys but i think even just today like an hour before the talk or so a guy who's also or sorry i'm not sure this guy uh a person on our discord actually managed to to rebuild the full encryption but we i personally was never interested in that because um after you've downgraded to rdp0 the device you can just access the memory map flash and get the completely decrypted flash contents basically sure thanks and last question about the lcd controller um whether it's used by writing pixels over spi or if it has some extra features maybe even backgrounds or sprites or something like that so um the the lcd itself doesn't have any special features it has a one spi bus to configure it and then a parallel interface where you uh so it takes up a lot of pins but the chip itself has a hardware called lcdc which is an lcd controller which provides two layers with alpha blending and some basic windowing and so on okay cool then thank you very very much for the great talk and the great intro and with that back to our main studio in the orbit thank you very much back to orbit so You
 So about the next speaker, he's a security researcher focused on embedded systems, secure  communications and mobile security. He was nominated by Forbes for the 30 under 30 in technology  and also has won a Oba's AppSex CTF. He has also found and disclosed responsibly multiple  vulnerabilities and especially for you Nintendo fiction others, I want you to watch out for  the next intro which is really amazing and you will all love. Thank you very much.  What a trip. Welcome to my talk on hacking the new Nintendo Game and Watch Super Mario  Brothers. My name is Thomas Roth and I'm a security researcher and trainer from Germany  and you can find me on Twitter at Gidra Ninja and also on YouTube at Stax Machine. Now this year  marks the 35th anniversary of our favorite plumber Super Mario and to celebrate that,  Nintendo launched a new game console called the Nintendo Game and Watch Super Mario Brothers.  The console is lightweight and looks pretty nice and it comes pre-installed with three games and  also this nice animated clock. The three games are Super Mario Brothers, the original NES game,  Super Mario Brothers 2, The Lost Levels and also a reinterpretation of an old Game and Watch game  called Ball. Now as you probably know, this is not the first retro console that Nintendo released.  In 2016 they released the NES Classic and in 2017 they released the SNES Classic. Now these devices  were super popular in the homebrew community because they make it really easy to add additional  ROMs to it, they make it really easy to modify the firmware and so on and you can basically just  plug them into your computer, install a simple software and you can do whatever you want with them.  The reason for that is that they run Linux and have a pretty powerful ARM processor on the inside  and so it's really a nice device to play with and so on and so when Nintendo announced this new  console a lot of people were hoping for a similar experience of having a nice mobile homebrew device.  Now if you were to make a Venn diagram of some of my biggest interests you would have reverse  engineering, hardware hacking and retro computing and this new Game and Watch fits right in the  middle of that and so when it was announced on the 3rd of September I knew that I needed to have one  of those and given how hard the NES and the SNES Classic were to buy for a while I pre-ordered  it on like four or five different sites, a couple of which got cancelled but I was pretty excited  because I had three pre-orders and it was supposed to ship on the 13th of November and so I was really  looking forward to this and I was having breakfast on the 12th of November when suddenly the doorbell  rang and DHL delivered me the new Game and Watch one day before the official release.  Now at that point in time there was no technical information available about the device whatsoever  like if you searched for Game and Watch on Twitter you would only find the announcements  or maybe a picture of the box of someone who also received it early but there were no tear downs,  no pictures of the insides and most importantly nobody hacked had hacked it yet and this gave me  as a hardware hacker the kind of unique opportunity to potentially be the first one to hack a new  Nintendo console and so I just literally dropped everything else I was doing and started investigating  the device. Now I should say that normally I stay pretty far away from any new console hacking  mainly because of the piracy issues. I don't want to enable piracy, I don't want to deal with  piracy and I don't want to build tools that enable other people to pirate stuff basically  but given that on this device you cannot buy any more games and that all the games that are on there  were basically already released over 30 years ago I was not really worried about piracy and felt  pretty comfortable in sharing all the results of the investigation and also the basically the  issues we found that allowed us to customize the device and so on and in this talk I want to walk  I want to walk you through how we managed to hack the device and how you can do it at home using  relatively cheap hardware and yeah hope you enjoy it. Now let's start by looking at the  device itself. The device is pretty lightweight and comes with a nicely sized case and so it really  for me it sits really well on my hand and it has a nice 320x240 LCD display, a D-pad,  A and B buttons and also three buttons to switch between the different game modes. On the right  side we also have the power button and the USB-C port. Now before you get excited about the USB port  I can already tell you that unfortunately Nintendo decided to not connect the data lines of the USB  port and so you can really only use it for charging. Also because we are talking about Nintendo here  they use their proprietary tri-point screws on the device and so to open it up you need one of those  special tri-point bits. Luckily nowadays most bit sets should have them but it still would suck if  you order your unit and then you can't open it up because you're missing a screwdriver.  After opening it up the first thing you probably notice is the battery and if you've ever opened  up a Nintendo Switch Joy-Con before you might recognize the battery because it's the exact  same one that's used in the Joy-Cons. This is very cool because if down the line like let's say in  two or three years your battery of your Game & Watch dies you can just go and buy a Joy-Con battery  which you can have really cheaply almost anywhere. Next to the battery on the right side we have a  small speaker which is not very good and underneath we have the main PCB with the processor, the storage  and so on and so forth. Let's take a look at those. Now the main processor of the device is an  STM32 H7B0. This is a Cortex M7 from ST Microelectronics with 1.3 megabytes of RAM and 128 kilobytes  of flash. It runs at 280 MHz and is a pretty beefy microcontroller but it's much less powerful than  the processor in the NES or SNES Classic. Like this processor is really just a microcontroller  and so it can't run Linux, it can't run let's say super complex software instead it will be  it will be programmed in some bare metal way and so we will have a bare metal firmware on the device.  To the right of it you can also find a 1 megabyte SPI flash and so overall we have roughly 1.1 megabyte  of storage on the device. Now most microcontrollers or basically all microcontrollers have a debugging  port and if we take a look at the PCB you can see that there are five unpopulated contacts here  and if you see a couple of contacts that are not populated close to your CPU it's very likely that  it's the debugging port and luckily the datasheet for the STM32 is openly available and so we can  check the pinouts in the datasheet and then use a multimeter to to see whether these pins are  actually the debugging interface and turns out they actually are and so we can find the SWD  debugging interface as well as VCC and ground exposed on these pins. Now this means that we  can use a debugger so for example a J-Link or an ST-Link or whatever to connect to the device  and because the the contacts are really easy to access you don't even have to solder like you can  just hook up a couple of test pins and they will allow you to to easily hook up your debugger.  Now the problem is on most devices the debugging interface will be locked during manufacturing  this is done to prevent people like us to basically do whatever with the device  and to prevent us from being able to dump the firmware potentially reflash it and so on and  so I was very curious to see whether we can actually connect to the debugging port and when  starting up J-Link and trying to connect we can see it can actually successfully connect  but when you take a closer look there's also a message that the device is active-reprotected.  This is because the chip the STM32 chip features something called RDP protection level or read  out protection level. This is basically the the security setting for the debugging interface  and it has three levels. Level zero means no protection is active. Level one means that the  flash memory is protected and so we can't dump the internal flash of the device however we can  dump the RAM contents and we can also execute code from RAM and then there's also level two  which means that all debugging features are disabled. Now just because a chip is in level two  doesn't mean that you have to give up for example in our talk wallet.fail a couple of years ago  we showed how to use fault injection to bypass the level two protection and downgrade a chip to  level one however on the game and watch we are lucky and the interface is not fully disabled  instead it's in level one and so we can still dump the RAM which is a pretty good entry point  even though we can't dump the firmware yet. Now having dumped the RAM of the device I was pretty  curious to see what's inside of it and one of my suspicions was that potentially the emulator  that's hopefully running on the device loads the original Super Mario Brothers ROM into RAM  and so I was wondering whether maybe we can find the ROM that the device uses in the RAM dump  and so I opened up the RAM dump in a in a hex editor and I also opened up the original Super  Mario Brothers ROM in a second window in a hex editor and tried to find different parts of the  original ROM in the RAM dump and it turns out that yes the NES ROM is loaded into RAM and it's  always at the same address and so it's probably like during boot up it gets copied into RAM  or something along those lines and so this is pretty cool to know because it tells us a couple  of things. First off we know now that the debug port is enabled and working but that it's unfortunately  at RDP level one and so we can only dump the the RAM and we also know that the NES ROM is loaded  into RAM and this means that the device runs a real NES emulator and so if we get okay we can  for example just replace the ROM that is used by the by the device and play for example our own NES game.  Next was time to dump the flash chip of the device. For this I'm using a device called Mini Pro  and I'm using one of these really useful SOIC8 clips and so these ones you can simply clip onto  the flash chip and then dump it. Now one warning though the flash chip on the device is running at  1.8 volts and so you want to make sure that your programmer also supports 1.8 volt operation.  If you accidentally try to read it out at 3.3 volts you will break your flash trust me because  it happened to me on one of my units. Now with this flash dump from the device we can start to  analyze it and what I always like to do first is take a look at the entropy or the randomness of  the flash dump and so using binwalk with the dash uppercase e-option we get a nice entropy graph  and in this case you can see we have a very high entropy over almost the whole flash contents  and this mostly indicates that the flash contents are encrypted. It could also mean compression but  if it's compressed you would often see more like dips in the entropy and in this case it's one very  high entropy stream. We also notice that there are no repetitions whatsoever which also tells us  that it's probably not like a simple XOR based encryption or so and instead something like AES  or something similar but just because the flash is encrypted doesn't mean we have to give up.  On the contrary I think now it starts to get interesting because you actually have a challenge  and it's not just plug and place so to say. One of the biggest questions I had is is the flash  actually verified like does the device boot even though the flash has been modified because if it  does this would open up a lot of attack vectors basically as you will see and so to verify this  I basically try to put zeros in random places in the flash image and so I put some at address zero  some at hex 2000 and so on and then I checked whether the device would still boot up and with  the most flash modifications it would still boot just fine. This tells us that even though the  flash contents are encrypted they are not validated they are not checked something or anything and so  the device and so we can potentially trick the device into accepting a modified flash image  and this is really important to know as you will see in a couple of minutes.  My next suspicion was that maybe the NES ROM we see in RAM is actually loaded from the external  flash and so to to find out whether that's the case I again took the flash and I inserted zeros at  multiple positions in the flash image, flashed that over, booted up the game, dumped the RAM and  then compared the NES ROM that I'm now dumping from RAM with the one that I dumped initially  and checked whether they are equal because my suspicion was that maybe I can overwrite a couple  of bytes in the encrypted flash and then I will modify the NES ROM and after doing this for like  I don't know half an hour I got lucky and I modified four bytes in the flash image and four bytes in  the RAM sorry in the ROM that was loaded into RAM changed and this tells us quite a bit it means  that the ROM is loaded from flash into RAM and that the flash contents are not validated  and what's also important is that we we change four bytes in the flash and now four bytes in  the decrypted image changed and this is very important to know because if we take a look at  what we would expect to happen when we when we change the flash contents there are multiple  outcomes and so for example here we have the spy flash contents on the left and the RAM contents  on the right and so the RAM contents are basically the decrypted version of the spy flash contents  now let's say we change four bytes in the encrypted flash image to zeros  how would we expect the RAM contents to change for example if we would see that now 16 bytes in  the RAM are changing this means that we are potentially looking at an encryption algorithm  such as AES in electronic codebook mode because it's a block based encryption and so if we change  four bytes in the input data a block size in this case 16 bytes in the output data would change  the next possibility is that we change four bytes in the spy flash and all data afterwards  will be changed and in this case we would look at some kind of chaining cipher such as AES in  cbc mode however if we change four bytes in the spy flash and only four bytes in the RAM changed  we are looking at at something such as AES in counter mode and to understand this let's take  a better look at how AES in CTR works AES CTR works by having your clear text and X oring it  with an AES encryption stream that is generated from a key and nonce and a counter algorithm  now the AES stream that will be used to X or your clear text will always be the same if key  and nonce is the same this is why it's super important that if you use AES CTR you always  select a unique nonce for each encryption if you encrypt similar data with the same nonce twice  large parts of the resulting cipher text will be the same and so the clear text gets X ored with  the AES CTR stream and then we get our cipher text now if we know the clear text as we do because  the clear text is the ROM that is loaded into RAM and we know the cipher text which we do because  it's the contents of the encrypted flash we just dump we can basically reverse the operation  and as a result we get the AES CTR stream that was used to encrypt the flash and now this means  that we can take for example a custom ROM X or it with the AES CTR stream we just calculated  and then generate our own encrypted flash image for example with a modified ROM and so I wrote  a couple of Python scripts to try this and after a while I was running hacked Super Mario Brothers  instead of Super Mario Brothers so woohoo we hacked the Nintendo Game & Watch one day before the  official release and we can install modified Super Mario Brothers ROMs now you can find the  scripts that are used for this on my github so it's in a repository called Game & Watch Hacking  and I was super excited because it meant that I succeeded and that I basically hacked a Nintendo  console one day before the official release unfortunately I finished the level but Toad  wasn't as excited he told me that unfortunately our firmware is still in another castle and so on  the Monday after the launch of the device I teamed up with Conrad Beckman a hardware hacker from  Sweden who I met at the previous congress and we started chatting and throwing ideas back and  forth and so on and eventually we noticed that the device has a special RAM area called ITCM RAM  which is a tightly coupled instruction RAM that is normally used for very high performance  routines such as interrupt handlers and so on and so it's in a very fast RAM area and we realized  that we never actually looked at the contents of that ITCM RAM and so we dumped it from the device  using the debugging port and it turns out that this ITCM RAM contains ARM code and so again the  question is where does this ARM code come from does it maybe just like the NES ROM come from the  external flash and so basically I repeated the whole the whole thing that we also did with the  NES ROM and it just put zeros at the very beginning of the encrypted flash rebooted the device and  dumped the ITCM ROM and I got super lucky on the first try already the ITCM contents changed  and because the ITCM contains code not just data so earlier we only had the the NES ROM which is  just data but this time the RAM contains code this means that with the same XOR trick we used before  we could inject custom ITCM code into the external flash which would then be loaded into RAM when  the device boots and because it's a persistent method we can then reboot the device and let it  run without the debugger connected and so whatever code we load into this ITCM area will be able  to actually read the flash and so we could potentially write some code that gets somehow called  by the firmware and then copies the internal flash into RAM from where we then can retrieve it using  the debugger now the problem is let's say we have a custom payload in somehow in this ITCM area we  don't know which address of this ITCM code gets executed and so we don't know whether the firmware  will jump to address zero or address 200 or whatever but there's a really simple trick to  still build a successful payload and it's called a knob slide a knob or a no operation is an instruction  that simply does nothing and if we fill most of the ITCM RAM with knobs and put our payload at the  very end we build something that is basically a knob slide and so when the CPU indicated by Mario  here jumps to a random address in that whole knob slide it will start executing knobs, knobs,  knobs, knobs and slide down into our payload and execute it and so even if Mario jumps right in the  middle of the knob slide he will always slide down the slide and end up in our payload and Conrad  wrote this really really simple payload which is only like 10 instructions which basically just copies  the internal flash into RAM from where we can then retrieve it using the debugger so woohoo super  simple exploit we have a full firmware backup and a full flash backup and now we can really fiddle  with everything on the device and we've actually released tools to do this yourself and so if you  want to backup your Nintendo Game and Watch you can just go onto my github and download the Game  and Watch backup repository which contains a lot of information on how to back it up it does  it does check something and so on to ensure that you don't accidentally brick your device and you  can easily backup the original firmware, install homebrew and then always go back to the original  software we also have an awesome support community on discord and so if you ever need help you will  I think you will find success there and so far we haven't had a single brick game and watch and so  it looks to be pretty stable and so I was pretty excited because the quest was over or is it  if you ever claim on the internet that you successfully hacked an embedded device there  will be exactly one response and one response only but does it run do literally my twitter DMs  my youtube comments and even my friends were spamming me with the challenge to get doom running  on the device but to get doom running we first needed to bring up all the hardware and so we  basically needed to create a way to develop and load homebrew onto the device now luckily for us  most of the components on the board are very well documented and so there are no nda components and  so for example the processor has an open reference manual and open source library to use it the flash  is a well-known flash chip and so on and so forth and there are only a couple of very proprietary  or custom components and so for example the lcd on the device is proprietary and we had to basically  sniff the spi bus that goes to the display to basically decode the the initialization  of the of the display and so on and after a while we had the full hardware running we had lcd support  we had audio support sleep support buttons and even flashing tools that allow you to simply use an swd  debugger to dump and rewrite the external flash and you can find all of these things on our github  now if you want to mod your own game and watch all you need is a simple debugging adapter such as a  cheap three dollar st link a jlink one s or a real st link device and then you can get started  we've also published a base project for anyone who wants to get started with building their own games  for the game and watch and so it's really simple it's just a frame buffer you can draw to input is  really simple and so on and as said we have a really helpful community now with all the hardware  up and running i could finally start porting doom now i started by looking around for other ports of  doom 2 and stm32 and i found this project by floppy called stm32 doom now the issue is stm32 doom  is designed for a board with eight megabytes of ram and also the data files for doom were stored on  an external usb drive on our platform we only have 1.3 megabytes of ram 128 kilobytes of flash  and only one megabyte of external flash and we have to fit all the level information all the code  and so on in there now the doom level information is stored in so called wad what where's all my data  files and these data files contain the sprites the textures the levels and so on now the wad for  doom 1 is roughly four megabytes in size and the wad for doom 2 is 14 megabytes in size but we only  have 1.1 megabyte of storage plus we have to fit all the code in there so obviously we needed to  find a very very small doom what and as it turns out there's a thing called mini what which is a  minimal doom i what which is basically all the bells and whistles stripped from the wad file  and everything replaced by simple outlines and so on and while it's not pretty i was pretty confident  that i could get it working as it's only 250 kilobytes of storage down from 14 megabytes  now in addition to that a lot of stuff on the chocolate doom port itself had to be changed and so  for example i had to rip out all the file handling and add a custom file handler i had to add support  for the gamut watch lcd button import support and i also had to get rid of a lot of things  to get it running somewhat smoothly and so for example the infamous wipe effect had to go and  i also had to remove sound support now the next issue was that once it was compiling it simply  would not fit into ram and crash all the time now on the device we have roughly 1.3 megabytes of  ram in different ram areas and for example just the frame buffer that we obviously need takes up  154 kilobytes of that then we have 160 kilobytes of initialized data 320 kilobytes of uninitialized  data and a ton of dynamic allocations that are done by chocolate doom and these dynamic allocations  were a huge issue because the chocolate doom source code does a lot of small allocations  which are only used for temporary data and so they get freed again and so on and so your dynamic  memory gets very very fragmented very quickly and so eventually there's just not enough space to for  example initialize the level and so to fix this i took the chocolate doom code and i changed a lot  of the dynamic allocations to static allocations which also had the big advantage of making the  error messages by the compiler much more meaningful because it would actually tell you hey this and  this data does not fit into ram and eventually after a lot of trial and error and copying as  many of the original assets as possible into the minimal iWatt i got it i had doom running on the  nintendo game and watch super mario brothers and i hopefully calmed the internet gods that forced  me to do it now unfortunately the usb port is physically not connected to the processor and so  it will not be possible to hack the device simply by plugging it into your computer however it's  relatively simple to do this using one of these usb debuggers now the most requested type of home  brew software was obviously emulators and i'm proud to say that by now we actually have kind of a  large collection of emulators running on the nintendo game and watch and it all started with  konrad backman discovering the retro go project which is an emulator collection for a device  called the odroid go and the odroid go is a small handheld with similar input and size constraints  as the nintendo game and watch and so it's kind of cool to port this over because it it basically  already did all of the hard work so to say and retro go comes with emulators for the nes for the  gameboy and the gameboy color and even for the sega master system and the sega game gear and  after a couple of days konrad actually was able to show off his nes emulator running zelda and  other games such as contra and so on on the nintendo game and watch this is super fun and  initially we only had really a basic emulator that you know could barely play and we had a lot of  frame drops we didn't have nice scaling v-sync and so on but now after a couple of weeks it's really  a nice device to use and to play with and so we also have a gameboy emulator running and so you  can play your favorite gameboy games such as pokemon super mario land and so on on the nintendo  game and watch if you own the corresponding rom backups and we also experimented with different  scaling algorithms to make the most out of the screen and so you can basically change the scaling  algorithm that is used for the display depending on what you prefer and you could even change the  palette for the different games we also have a nice game chooser menu where which allows you to  basically have multiple roms on the device that you can switch between we have safe state support  and so if you turn off the device it will save wherever you left off and you can even come back  to your save game once the battery run out you can find the source code for all of that on the  retro go repository from konrad and it's really really awesome other people build for example  emulators for the chip 8 system and so the chip 8 emulator comes with a nice collection of small  arcade games and so on and it's really fun and really easy to develop for and so you really give  this a try if you own a game and watch and want to try homebrew on it team sure being is even working  on an emulator for the original game and watch games and so this is really cool because it basically  turns the nintendo game and watch into an emulator for all game and watch games that were ever released  and what was really amazing to me is how the community came together and so we were pretty open  about the progress on twitter and also konrad was twitch streaming a lot of the process and we open  up a discord where people could join who are interested in hacking on the device and it was  amazing to see what came out of the community and so for example we now have a working storage  upgrade that works both with homebrew but also with the original firmware and so instead of one  megabyte of storage you can have 60 megabytes of flash and you just need to to replace a single chip  which is pretty as easy to do then for understanding the full hardware daniel kathbert and daniel padilla  provided us with high resolution x-ray images which allowed us to fully understand every  single connection even of the bga parts without desoldering anything then jake little of upcycle  electronics traced on the x-rays and also using a multimeter every last trace on the pcb and he  even created a schematic of the device which gives you all the details you need when you want to  program something or so and was really really fun sender vanderville for example even created a  custom backplate and now there are even projects that try to replace the original pcb with a custom  pcb with an fpga and an esp32 and so it's really exciting to see what people come up with now i hope  you enjoyed this talk and i hope to see you on our discord if you want to join the fun and thanks  you for coming  hi um wow that was a really amazing talk thank you very much uh thomas um as announced in the  beginning uh we do accept questions from you and uh we have quite quite a few um let's see if we  manage to make it through all of them um the first one is um did you read the articles about  nintendo observing hackers like private investigators etc and are you somehow worried about this  oh what's going on with my camera looks like luigi messed around with my video setup here  um aha yeah i've so i've read those articles but um so i believe that in this case the there is no  piracy issue right like i'm not allowing anyone to play any new games if you wanted to to dump a  super mario rom you would have done it 30 years ago or on the nes classic or on the switch on any  of the 100 consoles nintendo launched in between and so i'm really not too worried about it to be  honest um i know something the the aspect of of the target audience is is to be seen here  so off to the next question which is um is there do you think that there is a reason why an external  flash chip has been used yeah so the internal flash of the s3 2 h7 b0 is relatively small it's  only 128 kilobytes and so they simply couldn't fit everything in like basically even just the frame  buffer um even just a frame buffer picture also is larger than the internal flash and so um i think  that's why they did it and i'm glad they did yeah sure um and um is the decryption done in software  or is it a feature of the microcontroller so the microcontroller has an integrated feature  called otf dc otf deck and basically the flash is directly mapped into memory and they have this  chip peripheral called otf deck that automatically provides the decryption and so on and so it's  done all in hardware um you can even retrieve the keys from hardware basically oh okay very nice and  also um and the next question is somehow related to that uh is uh in your opinion the encryption  Nintendo has applied uh even worth the effort for them it feels like it's just there to give shareholders  a false sense of security how what would you think about that i think from my perspective they choose  just the right encryption because it was a ton of fun to reverse engineer and try to to bypass it  and so uh it was an awesome challenge and so i think they did everything right but um i also think  in the end it's it's such a simple device and it's like if you take a look at what people are building  on top of it with like games and and all the kind of stuff um i think they did everything right but  probably it was just a tick mark of yeah we totally locked down jtech and yeah but i think  it's fun because again like it doesn't open up any piracy issues sure and the one thing  is related to the nopslite which you very very well animated um so um wouldn't wouldn't start  of sub-routines be suitable as well for that uh for that uh goal um uh the the person asking uh  says that a big push our far our four our five etc instructions are quite recognizable um how would  yeah yeah so um absolutely so um the the time from finding the data in the itcm ram and actually  exploiting it was less than an hour and so um if we would have tried to reverse engineer it would  be more work like absolutely possible and also not difficult but just filling the ram with nop  took a couple of minutes and so um it was really the easiest way in the fastest way um without  fiddling around in gdra also okay cool thanks and uh this is more a remark than a question um  the person says it's strange that an sts an 52 81 does not mention a single time  that the data is not verified during encryption i think it's more a fault on sts than nintendo's side  what would you uh think about that yeah i would i would somewhat agree because in this case even  if you don't have jtag like an arm thump instruction is two to four bytes and so you you  you have a relatively small space to brute force to potentially get an interesting branch  instruction and so on so i think it's yeah i mean it's it's not perfect but also um doing  verification is very expensive computational wise and so i think it should just be the the firmware  that actually verifies the contents of the external flash okay um so we i think we should  two questions more and then we can go back to the studio um the there's a question about the  is encryption key um have you managed to recover them yes we did um but so there is an application  of by st and they do some crazy shifting around with the keys but i think even just today like  an hour before the talk or so a guy who's also or sorry i'm not sure this guy uh a person on our  discord actually managed to to rebuild the full encryption but we i personally was never interested  in that because um after you've downgraded to rdp0 the device you can just access the memory map  flash and get the completely decrypted flash contents basically sure thanks and last question  about the lcd controller um whether it's used by writing pixels over spi or if it has some extra  features maybe even backgrounds or sprites or something like that so um the the lcd itself  doesn't have any special features it has a one spi bus to configure it and then a parallel interface  where you uh so it takes up a lot of pins but the chip itself has a hardware called lcdc which is  an lcd controller which provides two layers with alpha blending and some basic windowing and so on  okay cool then thank you very very much for the great talk and the great intro and with that  back to our main studio in the orbit thank you very much back to orbit  so  You
rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_0_1727.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_1728_1799.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_1800_2435.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_2436_2807.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_2808_3179.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_3180_3275.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_3276_3587.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_3588_3755.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_3756_4739.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_4740_6911.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_6912_10355.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_10356_18155.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_18156_18275.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_18276_20423.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_20424_21203.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_21204_21371.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_21372_21575.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_21576_22691.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_22692_22799.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_22800_25103.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_25104_27971.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_27972_29723.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_29724_31511.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_31512_35999.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_36000_38819.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_38820_39047.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_39048_40583.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_40584_41111.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_41112_43751.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_43752_44459.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_44460_46163.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_46164_46979.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_46980_47843.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_47844_55967.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_55968_60083.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_60084_63107.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_63108_63443.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_63444_63623.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_63624_63887.png rc3-mcr-11527-eng-deu-Hacking_the_Nintendo_Game_Watch_hd_63888_64387.png
So about the next speaker, he's a security researcher focused on embedded systems, secure communications and mobile security. He was nominated by Forbes for the 30 under 30 in technology and also has won a Oba's AppSex CTF. He has also found and disclosed responsibly multiple vulnerabilities and especially for you Nintendo fiction others, I want you to watch out for the next intro which is really amazing and you will all love. Thank you very much. What a trip. Welcome to my talk on hacking the new Nintendo Game and Watch Super Mario Brothers. My name is Thomas Roth and I'm a security researcher and trainer from Germany and you can find me on Twitter at Gidra Ninja and also on YouTube at Stax Machine. Now this year marks the 35th anniversary of our favorite plumber Super Mario and to celebrate that, Nintendo launched a new game console called the Nintendo Game and Watch Super Mario Brothers. The console is lightweight and looks pretty nice and it comes pre-installed with three games and also this nice animated clock. The three games are Super Mario Brothers, the original NES game, Super Mario Brothers 2, The Lost Levels and also a reinterpretation of an old Game and Watch game called Ball. Now as you probably know, this is not the first retro console that Nintendo released. In 2016 they released the NES Classic and in 2017 they released the SNES Classic. Now these devices were super popular in the homebrew community because they make it really easy to add additional ROMs to it, they make it really easy to modify the firmware and so on and you can basically just plug them into your computer, install a simple software and you can do whatever you want with them. The reason for that is that they run Linux and have a pretty powerful ARM processor on the inside and so it's really a nice device to play with and so on and so when Nintendo announced this new console a lot of people were hoping for a similar experience of having a nice mobile homebrew device. Now if you were to make a Venn diagram of some of my biggest interests you would have reverse engineering, hardware hacking and retro computing and this new Game and Watch fits right in the middle of that and so when it was announced on the 3rd of September I knew that I needed to have one of those and given how hard the NES and the SNES Classic were to buy for a while I pre-ordered it on like four or five different sites, a couple of which got cancelled but I was pretty excited because I had three pre-orders and it was supposed to ship on the 13th of November and so I was really looking forward to this and I was having breakfast on the 12th of November when suddenly the doorbell rang and DHL delivered me the new Game and Watch one day before the official release. Now at that point in time there was no technical information available about the device whatsoever like if you searched for Game and Watch on Twitter you would only find the announcements or maybe a picture of the box of someone who also received it early but there were no tear downs, no pictures of the insides and most importantly nobody hacked had hacked it yet and this gave me as a hardware hacker the kind of unique opportunity to potentially be the first one to hack a new Nintendo console and so I just literally dropped everything else I was doing and started investigating the device. Now I should say that normally I stay pretty far away from any new console hacking mainly because of the piracy issues. I don't want to enable piracy, I don't want to deal with piracy and I don't want to build tools that enable other people to pirate stuff basically but given that on this device you cannot buy any more games and that all the games that are on there were basically already released over 30 years ago I was not really worried about piracy and felt pretty comfortable in sharing all the results of the investigation and also the basically the issues we found that allowed us to customize the device and so on and in this talk I want to walk I want to walk you through how we managed to hack the device and how you can do it at home using relatively cheap hardware and yeah hope you enjoy it. Now let's start by looking at the device itself. The device is pretty lightweight and comes with a nicely sized case and so it really for me it sits really well on my hand and it has a nice 320x240 LCD display, a D-pad, A and B buttons and also three buttons to switch between the different game modes. On the right side we also have the power button and the USB-C port. Now before you get excited about the USB port I can already tell you that unfortunately Nintendo decided to not connect the data lines of the USB port and so you can really only use it for charging. Also because we are talking about Nintendo here they use their proprietary tri-point screws on the device and so to open it up you need one of those special tri-point bits. Luckily nowadays most bit sets should have them but it still would suck if you order your unit and then you can't open it up because you're missing a screwdriver. After opening it up the first thing you probably notice is the battery and if you've ever opened up a Nintendo Switch Joy-Con before you might recognize the battery because it's the exact same one that's used in the Joy-Cons. This is very cool because if down the line like let's say in two or three years your battery of your Game & Watch dies you can just go and buy a Joy-Con battery which you can have really cheaply almost anywhere. Next to the battery on the right side we have a small speaker which is not very good and underneath we have the main PCB with the processor, the storage and so on and so forth. Let's take a look at those. Now the main processor of the device is an STM32 H7B0. This is a Cortex M7 from ST Microelectronics with 1.3 megabytes of RAM and 128 kilobytes of flash. It runs at 280 MHz and is a pretty beefy microcontroller but it's much less powerful than the processor in the NES or SNES Classic. Like this processor is really just a microcontroller and so it can't run Linux, it can't run let's say super complex software instead it will be it will be programmed in some bare metal way and so we will have a bare metal firmware on the device. To the right of it you can also find a 1 megabyte SPI flash and so overall we have roughly 1.1 megabyte of storage on the device. Now most microcontrollers or basically all microcontrollers have a debugging port and if we take a look at the PCB you can see that there are five unpopulated contacts here and if you see a couple of contacts that are not populated close to your CPU it's very likely that it's the debugging port and luckily the datasheet for the STM32 is openly available and so we can check the pinouts in the datasheet and then use a multimeter to to see whether these pins are actually the debugging interface and turns out they actually are and so we can find the SWD debugging interface as well as VCC and ground exposed on these pins. Now this means that we can use a debugger so for example a J-Link or an ST-Link or whatever to connect to the device and because the the contacts are really easy to access you don't even have to solder like you can just hook up a couple of test pins and they will allow you to to easily hook up your debugger. Now the problem is on most devices the debugging interface will be locked during manufacturing this is done to prevent people like us to basically do whatever with the device and to prevent us from being able to dump the firmware potentially reflash it and so on and so I was very curious to see whether we can actually connect to the debugging port and when starting up J-Link and trying to connect we can see it can actually successfully connect but when you take a closer look there's also a message that the device is active-reprotected. This is because the chip the STM32 chip features something called RDP protection level or read out protection level. This is basically the the security setting for the debugging interface and it has three levels. Level zero means no protection is active. Level one means that the flash memory is protected and so we can't dump the internal flash of the device however we can dump the RAM contents and we can also execute code from RAM and then there's also level two which means that all debugging features are disabled. Now just because a chip is in level two doesn't mean that you have to give up for example in our talk wallet.fail a couple of years ago we showed how to use fault injection to bypass the level two protection and downgrade a chip to level one however on the game and watch we are lucky and the interface is not fully disabled instead it's in level one and so we can still dump the RAM which is a pretty good entry point even though we can't dump the firmware yet. Now having dumped the RAM of the device I was pretty curious to see what's inside of it and one of my suspicions was that potentially the emulator that's hopefully running on the device loads the original Super Mario Brothers ROM into RAM and so I was wondering whether maybe we can find the ROM that the device uses in the RAM dump and so I opened up the RAM dump in a in a hex editor and I also opened up the original Super Mario Brothers ROM in a second window in a hex editor and tried to find different parts of the original ROM in the RAM dump and it turns out that yes the NES ROM is loaded into RAM and it's always at the same address and so it's probably like during boot up it gets copied into RAM or something along those lines and so this is pretty cool to know because it tells us a couple of things. First off we know now that the debug port is enabled and working but that it's unfortunately at RDP level one and so we can only dump the the RAM and we also know that the NES ROM is loaded into RAM and this means that the device runs a real NES emulator and so if we get okay we can for example just replace the ROM that is used by the by the device and play for example our own NES game. Next was time to dump the flash chip of the device. For this I'm using a device called Mini Pro and I'm using one of these really useful SOIC8 clips and so these ones you can simply clip onto the flash chip and then dump it. Now one warning though the flash chip on the device is running at 1.8 volts and so you want to make sure that your programmer also supports 1.8 volt operation. If you accidentally try to read it out at 3.3 volts you will break your flash trust me because it happened to me on one of my units. Now with this flash dump from the device we can start to analyze it and what I always like to do first is take a look at the entropy or the randomness of the flash dump and so using binwalk with the dash uppercase e-option we get a nice entropy graph and in this case you can see we have a very high entropy over almost the whole flash contents and this mostly indicates that the flash contents are encrypted. It could also mean compression but if it's compressed you would often see more like dips in the entropy and in this case it's one very high entropy stream. We also notice that there are no repetitions whatsoever which also tells us that it's probably not like a simple XOR based encryption or so and instead something like AES or something similar but just because the flash is encrypted doesn't mean we have to give up. On the contrary I think now it starts to get interesting because you actually have a challenge and it's not just plug and place so to say. One of the biggest questions I had is is the flash actually verified like does the device boot even though the flash has been modified because if it does this would open up a lot of attack vectors basically as you will see and so to verify this I basically try to put zeros in random places in the flash image and so I put some at address zero some at hex 2000 and so on and then I checked whether the device would still boot up and with the most flash modifications it would still boot just fine. This tells us that even though the flash contents are encrypted they are not validated they are not checked something or anything and so the device and so we can potentially trick the device into accepting a modified flash image and this is really important to know as you will see in a couple of minutes. My next suspicion was that maybe the NES ROM we see in RAM is actually loaded from the external flash and so to to find out whether that's the case I again took the flash and I inserted zeros at multiple positions in the flash image, flashed that over, booted up the game, dumped the RAM and then compared the NES ROM that I'm now dumping from RAM with the one that I dumped initially and checked whether they are equal because my suspicion was that maybe I can overwrite a couple of bytes in the encrypted flash and then I will modify the NES ROM and after doing this for like I don't know half an hour I got lucky and I modified four bytes in the flash image and four bytes in the RAM sorry in the ROM that was loaded into RAM changed and this tells us quite a bit it means that the ROM is loaded from flash into RAM and that the flash contents are not validated and what's also important is that we we change four bytes in the flash and now four bytes in the decrypted image changed and this is very important to know because if we take a look at what we would expect to happen when we when we change the flash contents there are multiple outcomes and so for example here we have the spy flash contents on the left and the RAM contents on the right and so the RAM contents are basically the decrypted version of the spy flash contents now let's say we change four bytes in the encrypted flash image to zeros how would we expect the RAM contents to change for example if we would see that now 16 bytes in the RAM are changing this means that we are potentially looking at an encryption algorithm such as AES in electronic codebook mode because it's a block based encryption and so if we change four bytes in the input data a block size in this case 16 bytes in the output data would change the next possibility is that we change four bytes in the spy flash and all data afterwards will be changed and in this case we would look at some kind of chaining cipher such as AES in cbc mode however if we change four bytes in the spy flash and only four bytes in the RAM changed we are looking at at something such as AES in counter mode and to understand this let's take a better look at how AES in CTR works AES CTR works by having your clear text and X oring it with an AES encryption stream that is generated from a key and nonce and a counter algorithm now the AES stream that will be used to X or your clear text will always be the same if key and nonce is the same this is why it's super important that if you use AES CTR you always select a unique nonce for each encryption if you encrypt similar data with the same nonce twice large parts of the resulting cipher text will be the same and so the clear text gets X ored with the AES CTR stream and then we get our cipher text now if we know the clear text as we do because the clear text is the ROM that is loaded into RAM and we know the cipher text which we do because it's the contents of the encrypted flash we just dump we can basically reverse the operation and as a result we get the AES CTR stream that was used to encrypt the flash and now this means that we can take for example a custom ROM X or it with the AES CTR stream we just calculated and then generate our own encrypted flash image for example with a modified ROM and so I wrote a couple of Python scripts to try this and after a while I was running hacked Super Mario Brothers instead of Super Mario Brothers so woohoo we hacked the Nintendo Game & Watch one day before the official release and we can install modified Super Mario Brothers ROMs now you can find the scripts that are used for this on my github so it's in a repository called Game & Watch Hacking and I was super excited because it meant that I succeeded and that I basically hacked a Nintendo console one day before the official release unfortunately I finished the level but Toad wasn't as excited he told me that unfortunately our firmware is still in another castle and so on the Monday after the launch of the device I teamed up with Conrad Beckman a hardware hacker from Sweden who I met at the previous congress and we started chatting and throwing ideas back and forth and so on and eventually we noticed that the device has a special RAM area called ITCM RAM which is a tightly coupled instruction RAM that is normally used for very high performance routines such as interrupt handlers and so on and so it's in a very fast RAM area and we realized that we never actually looked at the contents of that ITCM RAM and so we dumped it from the device using the debugging port and it turns out that this ITCM RAM contains ARM code and so again the question is where does this ARM code come from does it maybe just like the NES ROM come from the external flash and so basically I repeated the whole the whole thing that we also did with the NES ROM and it just put zeros at the very beginning of the encrypted flash rebooted the device and dumped the ITCM ROM and I got super lucky on the first try already the ITCM contents changed and because the ITCM contains code not just data so earlier we only had the the NES ROM which is just data but this time the RAM contains code this means that with the same XOR trick we used before we could inject custom ITCM code into the external flash which would then be loaded into RAM when the device boots and because it's a persistent method we can then reboot the device and let it run without the debugger connected and so whatever code we load into this ITCM area will be able to actually read the flash and so we could potentially write some code that gets somehow called by the firmware and then copies the internal flash into RAM from where we then can retrieve it using the debugger now the problem is let's say we have a custom payload in somehow in this ITCM area we don't know which address of this ITCM code gets executed and so we don't know whether the firmware will jump to address zero or address 200 or whatever but there's a really simple trick to still build a successful payload and it's called a knob slide a knob or a no operation is an instruction that simply does nothing and if we fill most of the ITCM RAM with knobs and put our payload at the very end we build something that is basically a knob slide and so when the CPU indicated by Mario here jumps to a random address in that whole knob slide it will start executing knobs, knobs, knobs, knobs and slide down into our payload and execute it and so even if Mario jumps right in the middle of the knob slide he will always slide down the slide and end up in our payload and Conrad wrote this really really simple payload which is only like 10 instructions which basically just copies the internal flash into RAM from where we can then retrieve it using the debugger so woohoo super simple exploit we have a full firmware backup and a full flash backup and now we can really fiddle with everything on the device and we've actually released tools to do this yourself and so if you want to backup your Nintendo Game and Watch you can just go onto my github and download the Game and Watch backup repository which contains a lot of information on how to back it up it does it does check something and so on to ensure that you don't accidentally brick your device and you can easily backup the original firmware, install homebrew and then always go back to the original software we also have an awesome support community on discord and so if you ever need help you will I think you will find success there and so far we haven't had a single brick game and watch and so it looks to be pretty stable and so I was pretty excited because the quest was over or is it if you ever claim on the internet that you successfully hacked an embedded device there will be exactly one response and one response only but does it run do literally my twitter DMs my youtube comments and even my friends were spamming me with the challenge to get doom running on the device but to get doom running we first needed to bring up all the hardware and so we basically needed to create a way to develop and load homebrew onto the device now luckily for us most of the components on the board are very well documented and so there are no nda components and so for example the processor has an open reference manual and open source library to use it the flash is a well-known flash chip and so on and so forth and there are only a couple of very proprietary or custom components and so for example the lcd on the device is proprietary and we had to basically sniff the spi bus that goes to the display to basically decode the the initialization of the of the display and so on and after a while we had the full hardware running we had lcd support we had audio support sleep support buttons and even flashing tools that allow you to simply use an swd debugger to dump and rewrite the external flash and you can find all of these things on our github now if you want to mod your own game and watch all you need is a simple debugging adapter such as a cheap three dollar st link a jlink one s or a real st link device and then you can get started we've also published a base project for anyone who wants to get started with building their own games for the game and watch and so it's really simple it's just a frame buffer you can draw to input is really simple and so on and as said we have a really helpful community now with all the hardware up and running i could finally start porting doom now i started by looking around for other ports of doom 2 and stm32 and i found this project by floppy called stm32 doom now the issue is stm32 doom is designed for a board with eight megabytes of ram and also the data files for doom were stored on an external usb drive on our platform we only have 1.3 megabytes of ram 128 kilobytes of flash and only one megabyte of external flash and we have to fit all the level information all the code and so on in there now the doom level information is stored in so called wad what where's all my data files and these data files contain the sprites the textures the levels and so on now the wad for doom 1 is roughly four megabytes in size and the wad for doom 2 is 14 megabytes in size but we only have 1.1 megabyte of storage plus we have to fit all the code in there so obviously we needed to find a very very small doom what and as it turns out there's a thing called mini what which is a minimal doom i what which is basically all the bells and whistles stripped from the wad file and everything replaced by simple outlines and so on and while it's not pretty i was pretty confident that i could get it working as it's only 250 kilobytes of storage down from 14 megabytes now in addition to that a lot of stuff on the chocolate doom port itself had to be changed and so for example i had to rip out all the file handling and add a custom file handler i had to add support for the gamut watch lcd button import support and i also had to get rid of a lot of things to get it running somewhat smoothly and so for example the infamous wipe effect had to go and i also had to remove sound support now the next issue was that once it was compiling it simply would not fit into ram and crash all the time now on the device we have roughly 1.3 megabytes of ram in different ram areas and for example just the frame buffer that we obviously need takes up 154 kilobytes of that then we have 160 kilobytes of initialized data 320 kilobytes of uninitialized data and a ton of dynamic allocations that are done by chocolate doom and these dynamic allocations were a huge issue because the chocolate doom source code does a lot of small allocations which are only used for temporary data and so they get freed again and so on and so your dynamic memory gets very very fragmented very quickly and so eventually there's just not enough space to for example initialize the level and so to fix this i took the chocolate doom code and i changed a lot of the dynamic allocations to static allocations which also had the big advantage of making the error messages by the compiler much more meaningful because it would actually tell you hey this and this data does not fit into ram and eventually after a lot of trial and error and copying as many of the original assets as possible into the minimal iWatt i got it i had doom running on the nintendo game and watch super mario brothers and i hopefully calmed the internet gods that forced me to do it now unfortunately the usb port is physically not connected to the processor and so it will not be possible to hack the device simply by plugging it into your computer however it's relatively simple to do this using one of these usb debuggers now the most requested type of home brew software was obviously emulators and i'm proud to say that by now we actually have kind of a large collection of emulators running on the nintendo game and watch and it all started with konrad backman discovering the retro go project which is an emulator collection for a device called the odroid go and the odroid go is a small handheld with similar input and size constraints as the nintendo game and watch and so it's kind of cool to port this over because it it basically already did all of the hard work so to say and retro go comes with emulators for the nes for the gameboy and the gameboy color and even for the sega master system and the sega game gear and after a couple of days konrad actually was able to show off his nes emulator running zelda and other games such as contra and so on on the nintendo game and watch this is super fun and initially we only had really a basic emulator that you know could barely play and we had a lot of frame drops we didn't have nice scaling v-sync and so on but now after a couple of weeks it's really a nice device to use and to play with and so we also have a gameboy emulator running and so you can play your favorite gameboy games such as pokemon super mario land and so on on the nintendo game and watch if you own the corresponding rom backups and we also experimented with different scaling algorithms to make the most out of the screen and so you can basically change the scaling algorithm that is used for the display depending on what you prefer and you could even change the palette for the different games we also have a nice game chooser menu where which allows you to basically have multiple roms on the device that you can switch between we have safe state support and so if you turn off the device it will save wherever you left off and you can even come back to your save game once the battery run out you can find the source code for all of that on the retro go repository from konrad and it's really really awesome other people build for example emulators for the chip 8 system and so the chip 8 emulator comes with a nice collection of small arcade games and so on and it's really fun and really easy to develop for and so you really give this a try if you own a game and watch and want to try homebrew on it team sure being is even working on an emulator for the original game and watch games and so this is really cool because it basically turns the nintendo game and watch into an emulator for all game and watch games that were ever released and what was really amazing to me is how the community came together and so we were pretty open about the progress on twitter and also konrad was twitch streaming a lot of the process and we open up a discord where people could join who are interested in hacking on the device and it was amazing to see what came out of the community and so for example we now have a working storage upgrade that works both with homebrew but also with the original firmware and so instead of one megabyte of storage you can have 60 megabytes of flash and you just need to to replace a single chip which is pretty as easy to do then for understanding the full hardware daniel kathbert and daniel padilla provided us with high resolution x-ray images which allowed us to fully understand every single connection even of the bga parts without desoldering anything then jake little of upcycle electronics traced on the x-rays and also using a multimeter every last trace on the pcb and he even created a schematic of the device which gives you all the details you need when you want to program something or so and was really really fun sender vanderville for example even created a custom backplate and now there are even projects that try to replace the original pcb with a custom pcb with an fpga and an esp32 and so it's really exciting to see what people come up with now i hope you enjoyed this talk and i hope to see you on our discord if you want to join the fun and thanks you for coming hi um wow that was a really amazing talk thank you very much uh thomas um as announced in the beginning uh we do accept questions from you and uh we have quite quite a few um let's see if we manage to make it through all of them um the first one is um did you read the articles about nintendo observing hackers like private investigators etc and are you somehow worried about this oh what's going on with my camera looks like luigi messed around with my video setup here um aha yeah i've so i've read those articles but um so i believe that in this case the there is no piracy issue right like i'm not allowing anyone to play any new games if you wanted to to dump a super mario rom you would have done it 30 years ago or on the nes classic or on the switch on any of the 100 consoles nintendo launched in between and so i'm really not too worried about it to be honest um i know something the the aspect of of the target audience is is to be seen here so off to the next question which is um is there do you think that there is a reason why an external flash chip has been used yeah so the internal flash of the s3 2 h7 b0 is relatively small it's only 128 kilobytes and so they simply couldn't fit everything in like basically even just the frame buffer um even just a frame buffer picture also is larger than the internal flash and so um i think that's why they did it and i'm glad they did yeah sure um and um is the decryption done in software or is it a feature of the microcontroller so the microcontroller has an integrated feature called otf dc otf deck and basically the flash is directly mapped into memory and they have this chip peripheral called otf deck that automatically provides the decryption and so on and so it's done all in hardware um you can even retrieve the keys from hardware basically oh okay very nice and also um and the next question is somehow related to that uh is uh in your opinion the encryption Nintendo has applied uh even worth the effort for them it feels like it's just there to give shareholders a false sense of security how what would you think about that i think from my perspective they choose just the right encryption because it was a ton of fun to reverse engineer and try to to bypass it and so uh it was an awesome challenge and so i think they did everything right but um i also think in the end it's it's such a simple device and it's like if you take a look at what people are building on top of it with like games and and all the kind of stuff um i think they did everything right but probably it was just a tick mark of yeah we totally locked down jtech and yeah but i think it's fun because again like it doesn't open up any piracy issues sure and the one thing is related to the nopslite which you very very well animated um so um wouldn't wouldn't start of sub-routines be suitable as well for that uh for that uh goal um uh the the person asking uh says that a big push our far our four our five etc instructions are quite recognizable um how would yeah yeah so um absolutely so um the the time from finding the data in the itcm ram and actually exploiting it was less than an hour and so um if we would have tried to reverse engineer it would be more work like absolutely possible and also not difficult but just filling the ram with nop took a couple of minutes and so um it was really the easiest way in the fastest way um without fiddling around in gdra also okay cool thanks and uh this is more a remark than a question um the person says it's strange that an sts an 52 81 does not mention a single time that the data is not verified during encryption i think it's more a fault on sts than nintendo's side what would you uh think about that yeah i would i would somewhat agree because in this case even if you don't have jtag like an arm thump instruction is two to four bytes and so you you you have a relatively small space to brute force to potentially get an interesting branch instruction and so on so i think it's yeah i mean it's it's not perfect but also um doing verification is very expensive computational wise and so i think it should just be the the firmware that actually verifies the contents of the external flash okay um so we i think we should two questions more and then we can go back to the studio um the there's a question about the is encryption key um have you managed to recover them yes we did um but so there is an application of by st and they do some crazy shifting around with the keys but i think even just today like an hour before the talk or so a guy who's also or sorry i'm not sure this guy uh a person on our discord actually managed to to rebuild the full encryption but we i personally was never interested in that because um after you've downgraded to rdp0 the device you can just access the memory map flash and get the completely decrypted flash contents basically sure thanks and last question about the lcd controller um whether it's used by writing pixels over spi or if it has some extra features maybe even backgrounds or sprites or something like that so um the the lcd itself doesn't have any special features it has a one spi bus to configure it and then a parallel interface where you uh so it takes up a lot of pins but the chip itself has a hardware called lcdc which is an lcd controller which provides two layers with alpha blending and some basic windowing and so on okay cool then thank you very very much for the great talk and the great intro and with that back to our main studio in the orbit thank you very much back to orbit so You
and to celebrate that, Nintendo launched a new game console called the Nintendo Game and Watch this new console a lot of people were hoping for the NES and the SNES Classic were to buy for a customize the device and so on and in this talk I want to walk I want to walk you through how we managed to hack the device and how you can do it device is active-reprotected. This is because the the device boot even though the flash has been do because the clear text is the ROM that is day before the official release and we can hacked a Nintendo console one day before the whole the whole thing that we also did with the beginning of the encrypted flash rebooted the somehow called by the firmware and then copies how to back it up it does it does check something with the challenge to get doom running on the dump and rewrite the external flash and you can time now on the device we have roughly 1.3 physically not connected to the processor and so games and so on and it's really fun and really homebrew but also with the original firmware and was really the easiest way in the fastest way um