 For as long as Nintendo has been making video games. They've been building in copy protection and region locking and as long as there's been copy Protection there have been people breaking it today Pluto Derek and never Return to enlighten us on the state of the Nintendo switch. Give them a round of applause Hey guys. Oh Is it working? Oh, yeah, cool. Okay Hey, I'm Pluto. This is Derek and never and Yeah first off We tried to be ethical hackers so We don't really condone piracy and we really just want to do creative things with the hardware that we own so Yeah, and So the Nintendo switch was released about nine months ago and we've been playing around with it since it It's it's been really successful like it's sold a lot of units and so but we want to hack it right so the usual entry point that you do is you go by the web browser and The switch has a web browser, but it doesn't have a generic web browser. So We found a way to launch the browser, but it's not actually intended to be launched this way So there's this Tetris game that you can buy It will take some time. So you go into the main menu You press that right trigger button on your right joy-con and it launches the game manual And then you go to the menu and you go all the way down to the bottom and Then they included a link to their website Take some time spraying the heat Oh, I hope I didn't break it. Oh, sorry, I broke it Okay, so one more time So this was actually the web exploit that we use it's really old one like it was six months old at the time that the switch was released and We didn't even have to find our own. We could just take a public one and Yeah, use that so it's pretty painful doing this over and over but I've gotten used to it like I've done this thousand times six It's the Wi-Fi Yeah, I don't have one. Sorry Oh, this was not the way we intended it to be but Maybe we can try it later. So sorry Maybe you can go into the menu Okay, so we're talking switch security we'll get the demo working for later. So, okay, so The switch is actually quite powerful unit it's a hybrid Handheld and stationary console. So it has a quad core that's clocked at one gigahertz. It's an a 57 arm And it has an NVIDIA GPU max well architecture. It's clocked on either 384 or Double that if depending on if you're docked to a power supply or not So if you're running off battery, they want to reduce the parts of the power consumption It has plenty of memory like four gigabytes of DRAM And then there's the selling point pretty much It's the joy cons and those are detachable So you can either play yourself or you can share one of the joy cons with a friend and you can play two players They have all the nice sensors accelerometer gyro NFC IR and They have this feature called hg rumble, but it's just a vibrator And these ones don't have any security at all So you can just unscrew them look at the part number Google the part number get all the data sheets and dump the flash It's all plain text But when you open the main unit, this is what you see You have the 2d Rams. It's in the orange section And then you have the main CPU which is in red and then the rest is just Power management Wi-Fi boring stuff So oh, yeah, and the flash they actually made a separate daughter board for the flash so we can easily just unplug it and dump it and stuff and Yeah, the code name for the switch is hack I'm not sure what they were thinking, but yeah, when we look at the main CPU It's branded ODN x o2. It's like because Nintendo is the ODM This ship is actually just got from Nvidia and NX is the code name of the Nintendo switch So but it turns out that the part number is just a lie It's just a regular Tegra x1 Nvidia chip like people decapped it and it looks just the same And yeah, we have the reference manual online. It's freely available pretty much. It's 3000 pages So it goes into detail pretty much everything except the security part But they also have provided their own Linux drivers But yeah, we can get the security at least some of the security registers and everything like that The main overview of the SoC is that you have an arm seven boot CPU It does power management and it has a boot ROM. It also has an internal SRAM And then you have the main CPU and it has 64k of SRAM. That's for trust zone. So it's secure only secure bus secure access only And then you have the GPU on the same die and then you have the security engine that does RCA, ES, acceleration it can DMA and stuff and then they have on-dive fuses a lot of them actually like 1000 and then they have the memory controller. They have a tsec, which is Security CPU. It's a really weird architecture. They were really Yeah, creative and so and then they have the DSP Which is kind of boring and then they have a bunch of buses that yeah, you can talk to external devices so The highlights for the fuses they use it for a lot of stuff configuration stuff But they have 32 bits dedicated to downgrade protection So every time they have a vulnerable firmware, they can just burn a fuse and every bootloader reads the fuse to make sure that The number of bits it expects is actually set. So If you try to downgrade just rewrite the flash memory It will not boot because there's a fuse inside of the CPU that Says oh, we're not allowed to boot this anymore. So and then they have the SPK, which is a just normal AS128 AS key and It's the source of all the confidentiality in system. So this is what you want to have if you want to decrypt all the software And it's also in the fuses and you can disable this one later on in boot So you can only access it during early boot time And then they store the hash of the RSA public key, which is the How they verify the firmware binaries, but they don't store the actual key They just store the hash because they want to save space, but it's equally good And then they have this cool feature that they can patch the boot ROM so they can store Patch instructions for how to modify the boot ROM code. So if they have exploitable bugs in the boot ROM and they do They can actually fix them, which is they can fix it at factory time. So They actually filled up all of this space just fixing bugs and it turns out that since this is just an off-the-shelf ship from Nintendo, from NVIDIA, sorry, they actually just provide this dev board you can buy from them It's 700 bucks or half that if you're a student So this gives you access to you can play with all the IO and discover what's undocumented about it and If we look at the software so People just there was this room. It was running free beastie and everyone was asking does it run? No, it doesn't run it and stop asking Instead it runs the custom microkernel called horizon. That's been in development at Nintendo for Pre for the 3ds. So it's it's yeah, like eight nine years old. Maybe All the drivers are running in user space and they call services. So it's a micro micro services architecture And then they have a custom NVIDIA graphics driver. That's kind of similar to the Linux driver, but they modified it a lot and then they have the custom API to talk to it So they have a it kind of is like Vulkan like it's a really thin abstraction on top of the GPU and It's custom. It's undocumented for us. So So if you come from the 3s The hacking scene you can we can do comparison So the main difference is that all use land processes now a slur So all the drivers and all the games are using a slur So since it's randomizing the outer space and that makes it really hard to exploit save games because if you just have a file format bug you really can't do much if you don't know where things are in memory and They rewrote everything pretty much is refactored Renamed everything, but if you just Switch out the abbreviations all the concepts are the same They don't have a security processor like the 3ds had arm 9. It was a big problem 3ds because it was a So they were so 3ds had this arm 9 processor, which did a lot of stuff It was a big attack surface and it didn't have any memory protection. So They remove this now everything is running on the same CPU with memory protection proper. Yeah, so the security model they have is The most privileged part is trust zone and it just is a crypto interface pretty much It's designed in a way that the keys never leave the trust zone. Hopefully. Well, that's there. That's how they wanted it So it kind of works like a hardware secret And then you have the kernel So it it's goal is just to enforce process isolation and communication between processes and it has the IOMMU It controls the IOMMU And then it has what we call base services These are processes with a star and everything and there's the FS module, which is the file system driver and NCM, which is not really interesting and SM, which is a service manager. This one is pretty interesting it It enforces the whitelist of which process is allowed to talk to which process And then this PM loader, which just Loads and creates new processes and then SPL, which is the interface to trust zone And then they have a bunch of microservices like the GPU driver Wi-Fi driver Bluetooth And stuff like that. And then finally we have at lowest privilege level. We have the game or the web browser So the web so the web browser game sandbox We only get access to approximately half of the syscalls And there are 40 user services, which are yeah services that you're supposed to access as a user and It has a concept of per-process file systems. So a game can really only access its own save data and save games And it can't mount SD card, which is when we want to make a homebrew exploit for example we want to Load files of SD card like elves But yeah, we can't do that just from the browser alone And then the service sandbox, which is where all the drivers are at We have like 20 more syscalls. It's mostly just for talking to DMA devices and handling IPC communication It has a service whitelist, but it's vastly reduced, but you get access to a few more And the services don't have any file access at all in general. There are a few exceptions But this is pretty powerful because even if you were to elevate, let's say go into the GPU driver You don't get any extra file access as a result And they sometimes need to talk to external devices. So they have MMIO mapped But even if a malicious driver tries to do a DMA request outside its own process address space The kernel is actually the one who maintains the IOMMU for all the busmasters. So a malicious driver cannot really ask Yeah, the device to do something. It's not supposed to do The base service sandbox, which is those 5.6 processes that are special They are bundled inside the kernel package together with the kernel and they have Approximately the same syscalls as normal services But these ones don't have a service whitelist because these ones are the ones that actually enforce the whitelist. So you can't Like they are they're the ones who enforce it and also fill it in And maintain it so they can't check themselves basically and they'd also because they maintain the file system. They have no White list for files they can access everything basically So yeah, we're going places and we start from the lower like the most unprivileged part and Yeah, so we start with WebKit as we're going to demo later and Yeah, so they've had a bunch of bugs here they fixed them all but it just keeps coming more It's used for eShop Like when you buy games online and manual and other stuff But it's also always over HTTP or yeah when we can't control the data except it with this one game Also firmware 2.0 Implemented a new way of launching the browser. You can just Create a new access point and act like a Wi-Fi and Yeah, you can just render arbitrary HTML because it thinks it's a login page For a protective Wi-Fi network and yeah, we just took this Pegasus exploit and just works So when we get code when we dump the memory of the browser the first thing we find is that It's linking. It's dynamic linking with a file called SDK and when we Run strings on it. It's not an elf, but we convert it to an elf We get pretty much all of their function names, which is really nice when you reverse engineering stuff We get names of all the syscalls and all the fancy crypto some of the crypto stuff. Yeah So yeah, this is what we're gonna demo later So the game application Yeah, they knew we were gonna get this at some point and with WebKit is pretty easy So what we did then is we're trying to black box trying to elevate our privileges from the sandbox so mine my my handle is Pluto and There's a service called flu So I I don't believe in fate, but yeah, I looked into this service and it's a user accessible service That's what the U is for we think PL is for preload There's three commands to take an integer sign integer and If you feed it a big value You notice it's crashes and this is just like an array out of bonds read where we control the index completely So we can just give it a negative index and we can read out the entire binary of service So this way we can dump the code of NS, which is one of the problem. Yeah So we managed to get one of the microservices through just black box poking things and Now we're gonna look into the SM, which is the service manager. It's the one that enforces The white list of which services you're allowed to access So the way you you ask it for you give it a string and it gives back a handle to that service that you asked for and You send it a PID you send it your PID so that it knows which whitelist to enforce But yeah, what if we just don't call the initialized function, so we never actually give it our PID Turns out that the variable that's supposed to store the PID is uninitialized. It will just be zero So SM thinks we're a process with PID zero and then we get access to everything so But we still we can talk to everything but we don't have the code So what we want to do is we want to dump all the code in the system so we can analyze it so if you look out how the binaries are launched it launched this way and All the code it comes from this FSP loader service. It has a function called mount code So we just need to connect to it and read out all the binaries, right? But when we try to connect we get some error message turns out the kernel enforcers you can only have one session at a time But this session is currently held by the loader so the loader has a session to the file system Driver, but if we crash loader the kernel will garbage collect the reference counts will go to zero and It will release the session So we found a command in loader that you just give it a thread handle and it crashes So we get all the code binaries just can read them out. This is really nice now we can really understand the system a lot better and Finally, we look at the kernel and for that We're going to take a little bit of detour. So Derek is gonna talk next about What happens before the system has booted up so? Okay, it seems like we lost some time on the demo. So I'm trying to hurry a little bit So okay, so far and this was all achieved by just using plague box Like box testing and you know like so like box testing is fun except that it's not because well the switch uses a microkernel and that means the attack surface is Pretty low. It seems quite unlikely that you will get some read primitive where you can just dump the entire kernel and Also, there's a cell are in the privilege processes So you might even need two vulnerabilities in the process to get access to like Current system calls that only purge process can use so yeah black box testing on the kernel was kind of a dead end for us and When you think about the chain of trust Webkit is pretty much at the end So maybe it's a new console. So maybe you why not just start at the other end so We gotta have a look at the boot sequence and It's very cool because it's all documented publicly by Nvidia and Yeah, you get a bunch of information just for free and The way how it works is there's a boot room that runs on the arm seven, which is like Super old and crappy CPU that they call the BP MP, which means like a boot and power management processor and This this is actually not the custom boot room. It's written by Nvidia, but as Pluto already mentioned Nintendo has some custom patches on it The boot room will Well as it is as it is explained in the documentation It will just load the BCT, which is the boot configuration table and the second stage loader from emmc So at this point, you don't really need to know what the BCT is But basically it helps the boot room where the next well well the where the second stage loader is located in the emmc and also contains the signatures So when that's the usual boot flow on the switch it will try to boot from emmc But if that fails because for example the emmc is missing it will enter a recovery mode Which allows you to send USB messages to the boot room and if you might think yeah, this is a ultimate backdoor Well, unfortunately, it's not because all messages must be signed by using Nintendo's private RSA key And of course we don't have that But what we can do is we can dump the emmc, which is like super easy and we did that and we got a pretty nice overview of All the boot components that are stored on the emmc. So this is a little bit complicated, but What you can see is the boot room on the left It loads something that is called package one, which is basically the second stage boot loader and next stage in one image and The first part is actually is stored on emmc in plain text. It is not encrypted and the other part is encrypted by using Universal universal encryption keys. It's not there's no console unique encryption there So how does it work? How does the package one loader decrypt the decrypt the next stage? So they have this feature where they lower the key blob from emmc Which is console unique and it basically contains encrypted keys and package one loader Generates a key blob key to decrypt that key blob and then it uses the Decryption keys from that key blob to decrypt the next stage So we would like to get this key because the kernel is also encrypted when it's part of package 2 as you can see on the right and Well This key is only available to this package one loader So that means we need to get code execution in package one loader Okay So how do we add emm keys? Well in the past As you might know We glitched the 3ds and got the keys and we glitched the Wii U and got the keys. So maybe Yeah Maybe you can glitch the switch and get the keys So we wanted to try that and in order to do this you want to get code execution package one loader and Basically you want to glitch the component that loads the package one loader, which is the bootrom but How how is this actually verified? So the bootrom uses that bct which I've already mentioned and this is basically a Plaintext blob stored on the emmc and it contains all the signatures of the bootloaders and Then there's an RSA PSS signature on top. RSA PSS is a really strong signature scheme and It uses the RSA public key, which you can see on the top to verify the signature and This public key is hashed and this hash is stored in the fuse of the device So you cannot you cannot change it Basically what we want to do is When the bootrom verifies this public key using the hash We want to glitch this hash check Because then we can put our own public key and our own bct signatures and with that our own bootloader signatures So we can sign our own bootloaders Okay, but we don't well we didn't have the bootrom then back there and We didn't know when this check like the hashtag when when does it happen? So we have to find the timing for it and for that we can take a look at the emmc bus You can just sniff it So we get a really nice dump of all the commands that are issued by the bootrom to the emmc So you can see the diff It's the time difference between each command that was issued and it's basically the Time that the bootrom needed to do some operation between those reads so when the year when the when the bct is was good it took quite some time to verify it and When you put like an invalid Public key in the bct the bct validation will fail and it will actually start reading the next bct and then you can see the Difference is much smaller. So that means the bootrom will see. Oh the The public key is wrong. I will not I will not try to verify the rest of the bct and with that They basically leaked the time of check When the bootrom checks the public key hash Okay, so this was all in theory Basically it took like one month to develop a glitching setup And this is this just uses power glitching so What I did was I first desoldered all the capacitors on the voltage ray that was that powers the arm seven and then I've used an FPGA to Basically control some MOSFETs and those MOSFETs will pretty much Lower the voltage for a short time. So Hopefully the public key hash check will fail and and Then when you get code execution We are pretty lazy and we just bit bang the emc clock because we actually found some clock divider register so Basically by changing the frequency we could encode The data of all the secret keys Bit by bit sending it to our FPGA and then we got all the keys and With that all the binaries Okay, so I'm so thanks Derek. You got us all the keys, which is really nice So now we can analyze the kernel white box instead of black box, which means we can read the code And the first thing you do when you want to explode something is you find out the memory map because you want to crop memory eventually where should you write So it currents map to the high address somewhere fff fbfc. It's Read execute But this actually this is a virtual address that maps to DRAM and then they have a DRAM mirror. That's read write so We can actually bypass the read only portion by using the other address instead and the three days at the same flaw But I think they're thinking here is that yeah, it makes the code a lot cleaner So they just Always keep this DRAM mirror inside the their outer space all the objects are allocated using a slab heap which is like one heap per object type and all the allocations are of the same size so this makes use after free is really difficult to exploit because You can't overlap two different two objects of different type Which you usually want to do so you can only overlap an object with a different object And that's the same type so some of the fields will be different, but Most of the pointers are still valid for both Objects will still be at the same offsets. So yeah And now the kernel cannot execute use land code because they use the privileged execute never bait pxm Which is a hurdle that you have to get through I'm not sure if anyone paid attention so just explain this the string to write is the permissions The first three are privileged permissions and the lower three are user land permissions And there's something a little bit weird here They accidentally mapped the kernel into user space as executable It's mostly useless, but It means that we can use these we can just jump into kernel from user space and it will execute kernel functions in use User space context, but we can use this as an asr bypass because the kernel is always mapped at the same address So we can use it for gadgets But this really we haven't really owned the kernel yet So the IOMMU is one of the parts of the kernel you can attack. It's Yeah, it's simply the member controller of the SOC The idea is that all of the non CPU bus masters are protected. So Yeah, you assign it an address base identifier acid and then you assign a pitch table to that acid and Every device that goes through the IOMMU can only access what's mapped in the pitch table and the kernel which maintains this pitch table That's why it's secure. So a malicious driver can't Violate the process isolation Yeah, and so this is this forces that you can only access your own heap 3d ma There's a functionality for accessing a another process heap as well. You can lend the memory, but yeah So, how do we bypass the SMMU? So we got the official datasheet to 3,000 pages and we can just search for bypass the SMMU I'll get this So the GMMU is a memory management unit inside the GPU and yeah, it supports bypassing the SMMU so Nvidia back towards themselves So this is a GMMU attack You can set bit 31 in the page table entry and yeah, it's in hardware so you can't fix it Nvidia, thank you This is one way of doing it and they can't fix it but we also had a different way of bypassing the SMMU and it has to do it's a trust issue so The loader loads the permissions that we have from FS and if we own FS or a vulnerability in FS We can just tell it what we're allowed to do So we can tell it we're allowed we should be allowed to access the memory controller and then we can just assign acids So we can assign the acid zero here to our device Just means don't do Any virtual addressing So we can DMA all over DRAM pretty much So the answer is simple we can just the current is in DRAM so we can just DMA it but that doesn't work because there's our security feature in the memory controller you can specify Contiguous memory range that's protected from DMA and they protect this to include all of the kernels so we can't really touch it But we inspected the code a little bit more and when they allocate it handle table They are two different ways of allocation if you have a small Handle table less than 40 capacity You are you just use the internal struct as storage But if you have more than 40 They allocate in the pool and this is the same pool that's used for all the memory of all the user processes and this pool is not protected by the carve out, but the Handle table just is trusted like it contains kernel pointers and everything and Yeah, we can just DMA it So we can create a shared memory object, which is just Primitive that the kernel provides and we can tell it to share the kernel to And then we can inject it into our handle table of our process And then we can use the syscall to map it into our own process so then it will map the kernel into our process thinking it's a shared memory and Then we can just patch it or insert the backdoor or anything. So this is the way we own the kernel And here's some code Yeah, and now we're gonna talk Now we're gonna talk a little bit about trust on so never worked All right, so trust zone is this nice execution environment by arm and We already seen their ex glitching actually gave us a method to the crypt package 1.1 And it just contains the trust on payload and now what I will show you in the next 10 minutes There's always why we can actually ignore this trust zone at all so The RMA it supports trust zone The code running under secure al3 which is this trust zone as we call it is called the secure monitor This is an official name Nintendo calls it the same, but under Nintendo switch. It doesn't monitor anything. All right so That's a cure monitor It's the first code that runs on the rmb 80 main CPU So the arm 7 the crypts package 1.1 It writes the trust zone payload to a TZ RAM that is what we saw It's this small RAM in the rmb 8. That's this trust zone secure memory Boots up the rmb 8 Chumps there and then this is actually the first task of the secure monitor already. It's a booting the horizon kernel All right, so we saw this package 2 at this point package 2 will be in main RAM Then secure monitor will start deriving some keys the crypt package 2 write the kernel to the DRAM and Decrypt the the packaged modules and then just start executing the kernel So this is the most important task probably or one of the most important ones and the second most important task of the secure monitor is actually cryptography, so Cryptography is not directly done in software by the secure monitor But they actually make use of this nice security engine that is provided by Nvidia the Tegra security engine and other some not so important task is Trust zone or the secure monitor is actually used to start stop the additional CPU cores as we've seen We have four CPU cores. We start executing from core 3 initially So we have to have means to start stop the other cores And the last important part is the sleep mode So the Tegra actually supports some deep sleep mode to save some battery This is always a nice feature of Nintendo consoles. You usually live very long through the sleep mode Now Take a good look at this list This is actually not important for homebrew at all that that's why I said we can really just ignore the trust zone completely But let's look at it anyways For completeness sake, so the Tegra is E. I mentioned. It's a hardware crypto engine. It supports AES Shah RSA RNG all the good things And maybe you remember from the 3ds. They had this key slot concept. It's apparently a good concept So they kept it for here as well. So you have 16 key slots for AES to for RSA You can lock them individually. This is for example what the bootrom uses the SPK is written to a key slot It's locked. So you can't just read it out. I mean it gets cleared once we're in this area But then the trust zone code does the same it derives some keys into the upper key slots and locks them so even if you Get code execution in a trust zone. You wouldn't be simply able to just read out these keys so that that's quite secure all right and What's another interesting thing about the Tegra SE is that the crypt operations actually don't just operate on memory You can actually encrypt and decrypt between key slots So this actually enables you to do some secure key derivation So you could imagine having a key in one key slot key slot could be locked And then you could actually decrypt this key slot into another one without ever having any keys Leaving into memory. So this then maybe you could think of some cool things you could do with that So how does the cryptography work? So on your left side, you see this a cure world This would be the sector monitor the right side is the non-secure world or the user mode Mostly this is used in the file system module. So what you have to do at first You have to request a key encryption key Then the secure world will generate this key encryption key you pass some parameters It'll wrap the key encryption key and this is where the important part comes in it'll actually use a random session key So even if you get a key encryption key from one session once you reboot your console your switch The next time it'll be invalid So even if you for example exploit the file system module and grab one key encryption key You won't be able to use it after the reboot. So this is security sign there, but On the other hand, how do you do use these key encryption keys? Well, you pass an encrypted key into secure World along with a key encryption key Then this is unwrapped the keys decrypted and then a plain text final key actually is passed back to use them Oh, so that's quite interesting. So what you actually find is that for example the file system module Doesn't use the hardware crypto engine to decrypt games or binaries or what not at all So this is all done by accelerated the hardware Accelerated arm instruction actually so In theory you could for example exploit the file system module get some permissions and then ask The secure monitor to derive all the keys for you. All right, so this is another reason why it's not really important Now The last task we've seen is to sleep mode. So this is actually a string from the secure monitor to call it Oyazumi apparently it means a good night or something and So on the sock, there's the small thing. It's the power management controller and this controls the sleep and wake transitions and On system sleep the entire system on a chip is powered down Except for the PMC. So there's a small block that's always on and the DRAM is put into some self-refresh mode So that it keeps the contents, right? Now if you enter sleep mode the secure monitor actually has to save some states, right? So it does it spills the secure memory into external DRAM, which is untrusted, but but it's alright. It's encrypted. So don't worry and It also authenticates the DTC RAM to PMC. So it's encrypted and authenticated so you can't just mess with it, right? And it tells the security engine to save its context to DRAM. You also have to retain the keys I mean you have to use them after you wake up, right? And then we signal the arm to put everything into this LP0 mode, which is like the slow power mode And then in wake up you just roll everything up from back to the fourth. So this is the Ohio and The boot ROM will restart as E-state from DRAM Then it'll pass ARM code execution to assigned warm boot bin and this warm boot bin is bit like a bootloader for DRAM So instead from an end boot, a cold boot, we're doing a warm boot. So from DRAM And this warm boot bin is signed. That's all nice. What this does is it will just encrypt the secure monitor from DRAM to trust on RAM, verify it with authentication information that we have left in PMC, and then the main CPU will just resume running. So in theory this all sounds very good, but for completeness sake, you can just remove the trust from trust on. So as we've already seen from Pluto, there are some trust issues. We can just ask the kernel to map the lower DRAM where all these states are stored. We can map in PMC into user mode, the PMC registers, et cetera, et cetera. And we just seen that these are crucial in the wake-up process, right? We've seen that the trust on memory is decrypted from DRAM into TZRAM and whatnot. So if you poke all these areas in just the right way, you get code execution from user mode. Right. But as I said, it's just a fun thing to do. It's not very useful for homebrew anyways. Thank you. All right, so it's pretty green. Okay, so what we've done so far is when we put in the kernel, we made a USB debugger. And it's... Yeah, it works. You can debug user programs. You can put breakpoints and inspect the registers. You don't get the symbols yet, but it's open source. So if anyone wants to add it, it currently requires a kernel exploit, but we don't share it. But hopefully someone will make their own by this after this talk. But what we really care about is homebrew. So we've made LibNX, which is user mode homebrew library. We have... We provide all the kernel primitives like you can create threads, you can have mutex. You can talk to other processes using IPC. We have nice wrappers for everything. We have fully working network file system. We can add as a USB host. We have the controller's input working and it's... Let's see here. Okay. So we have framebuffer working and this took a really long time. I think our friend Yellows8 worked on this for like two weeks full-time. They're running like Android binder IPC interface inside their own IPC interface. It's pretty crazy. But yeah, we have it working and we're pushing the updates. So anyone can just use this now. So, but still there's work to be done, right? We enjoy reversing provider code a lot. It's a lot of fun. Homebrew is fun. I hope you agree. And we still have work to be done, right? So we don't have any GPU acceleration right now in LibNX. So right now everything is software rendering. And audio support, we don't have right now. And then we want people to make games because otherwise the hacking is for nothing. So we couldn't release it today, but we're working on a homebrew launcher. So there will be homebrew soon. It's in collaboration with another team, Team ReSwitch, which actually implemented a lot of the exploit. So we're just like trying to make it a nice stable platform for homebrew. And yeah, get on firmware 3 if you're lower and stay, stay there. Thank you to everyone involved and especially YellowSate who couldn't make it. So yeah, we have the demo working and I'll have it now. So also thanks to... Oh, is it on? Oh, thanks to Nintendo as well. It's a pretty nice system. This is just something I wrote last night, but hopefully it works. Thank you. If we have time for questions, we can have them. We have time for some questions. There are microphones stationed around the auditorium, numbered one through six. If you have a question burning that you would like to ask, then please, I would ask you to line up behind these microphones. And I will call you. Also, there is a signal angel who is taking questions from the internet. And I see that he already has one. So dearest signal angel, please, our first question. Thank you. When glitching to get the keys, how long did it take to get the keys with the, you know, the exact right timing? Have you been able to anyhow automate this task? Sorry, could you repeat the question? The speaker is a bit lousy. When glitching to get the keys, how long did it take? And could you anyhow automate this task? Okay. So the question was how long it took to get the keys and if we could automate it? Yeah, it took about like one month to get some key blob keys. And just recently, like, I think last week, we got some other keys as well. So, yeah, regarding the glitching setup, yes, it was possible to automate it because we found the reset signal. So after each glitching attempt that failed, we could just reset and try again. Microphone number six. Yeah, thank you for your great talk. I would really like to rebuild your glitch attack. Is this stuff somewhere available? So could you repeat? It was something about the glitch attack reproducing it? Yes, I would really like to try it myself. Is this information about the glitch attack somewhere available? So the question is if the more information is available on the glitch attack. Yeah, well, basically, it's just power glitching. There's a lot of information about it, but it's not that difficult. I mean, you saw it was a pretty cheap setup. You just need some MOSFETs that somehow pull the voltage down to ground and it will just work, I guess. Microphone one. The jokes about the switch just being an Android tap, did you guys try to start running Android or Linux on it? No, we didn't try that yet, but I think it would be pretty sweet to have Android running on Switch, yeah. But yeah, I think it would only make sense with some kind of cold boot exploit. And yeah, we are still working on that. So, yeah, signal angel. Thank you. So you told about doing crypto on the key slots. Could you copy an encrypted key from a locked key slot into an unlocked key slot, read it out, and then decrypt it? So there are bits that actually... The question was whether you could copy and encrypt a locked key slot into an unlocked key slot and then read it out. So there are some bits that actually controls whether you can read right from a locked key slot and you could actually set it up such that you wouldn't be able to encrypt from a locked key slot into an unlocked key slot. So you can actually make it secure. This is one attack it would be thought of, but there are mitigations against this attack by the locking mechanism. So unfortunately, that's not possible if you set it up correctly. Thank you. Microphone four. Yeah, thank you very much. You just told us that we should stay on exactly firmware 3.0.0. So what did change from 2.0 to 3.0 that doesn't make Homebrew feasible on that version? And what was patched for 3.0.1 so that it doesn't work anymore? Yeah, so the question is why Homebrew won't work beyond 3.0.0 if I got it right? And the reason is that the bug we talked about where you don't send the PID, so it thinks PID zero. They fixed that bug on 3.0.1. So if you're below that, you're still vulnerable. But if you're above that, you can bypass the whitelist and you can't really get anywhere. Yeah, so that's the answer to that. But something else can say. Yeah, it wasn't anything important, probably. Microphone two. Yeah, so this exploit works on pre-Otatris, but have you been able to test it on other webkits like the captive portal? Yeah, so the question was if the webkit exploit only works with this Tetris game. And no, the answer is that the webkit is not actually bundled with the game. It's more like a system applet. So the game just launches an applet from the system firmware. And so we have the same bug, the Pegasus one that we demoed. It works up to 2.3, I think. And then they fixed it and then it will be fixed for all of the games. But yeah, if you're above 2.0, you don't really have to buy this game, this Tetris game. You can just launch it without it. All right, that was all the time we had for questions. Let's give them another round of applause.