1 00:00:00,000 --> 00:00:17,760 *33C3 preroll music* 2 00:00:17,760 --> 00:00:23,730 Herald: Good evening, everyone. In a few minutes, the Nintendo Hacking 2016 talk 3 00:00:23,730 --> 00:00:28,470 will start. This talk will will be translated into German, and there are 4 00:00:28,470 --> 00:00:34,300 English subtitles available. Anyway, without much further ado. These are 5 00:00:34,300 --> 00:00:38,100 derrek, naehrwert and nedwill. They are three students that have been working on 6 00:00:38,100 --> 00:00:42,499 hacking Nintendo platforms for a while now, and please give them a warm applause. 7 00:00:42,499 --> 00:00:54,490 *applause* 8 00:00:54,490 --> 00:01:00,890 naehrwert: Hi guys. So, welcome to our talk about Nintendo Hacking 2016. Let me 9 00:01:00,890 --> 00:01:06,280 quickly introduce the other guys. This is derek, and that's ned, and I think I can 10 00:01:06,280 --> 00:01:11,210 speak for the three of us to say that I am really happy that you guys are here today 11 00:01:11,210 --> 00:01:15,250 and we are happy that we can be here today to tell you everything about what we did 12 00:01:15,250 --> 00:01:22,920 in the past one and a half years. I will start with the state of the Wii U. I hope 13 00:01:22,920 --> 00:01:29,270 a lot of you guys have seen failOverflow's talk in 2013 about hacking the Wii U. Not 14 00:01:29,270 --> 00:01:38,530 much happened afterwards, until 2015 there is a public webkit exploit released and 15 00:01:38,530 --> 00:01:43,640 this time we started looking into the Wii U. And, we wanted more access, right? Than 16 00:01:43,640 --> 00:01:48,430 just user mode and because there is also the kernel running on a PowerPC and then 17 00:01:48,430 --> 00:01:54,320 there is this other ARM processor that runs IOSU. Also user mode and kernel mode. 18 00:01:54,320 --> 00:01:58,470 I am not going to consider the user mode today. Because I think there are currently 19 00:01:58,470 --> 00:02:05,970 exploits that are way more fun. So, let's start with PowerPC kernel very quick. It 20 00:02:05,970 --> 00:02:10,139 has all standard basic security measures, though it doesn't have any ASLR which 21 00:02:10,139 --> 00:02:20,110 makes our lives easier. It has about 140 syscalls. And we don't really.. We can't 22 00:02:20,110 --> 00:02:24,840 really name them from start, right? Kinda need to reverse them. But there's a nice 23 00:02:24,840 --> 00:02:29,210 thing. So, the Wii U uses this RPL mechanism for dynamic libraries. And 24 00:02:29,210 --> 00:02:33,500 there's this really nice library. It's called coreinit.rpl and it contains a lot 25 00:02:33,500 --> 00:02:38,390 of syscalls, shims and symbol names. So we can name all syscalls straight away 26 00:02:38,390 --> 00:02:44,420 without much hassle and, it is important to know that all the syscalls use the safe 27 00:02:44,420 --> 00:02:50,120 copy in/copy out mechanism to get data from the user space into the kernel space. 28 00:02:50,120 --> 00:02:56,330 So we start reversing each syscall and we start looking for bugs And what we came 29 00:02:56,330 --> 00:03:01,750 out with, at first, this is what we call I/O controlled VHAX Or, why indirections 30 00:03:01,750 --> 00:03:07,960 are hard. It's actually a bug in the IPCKDriver_SubmitRequest syscall so what 31 00:03:07,960 --> 00:03:13,950 this syscall is used for is: you want to submit requests from user mode to this 32 00:03:13,950 --> 00:03:20,220 other processor running which I'm going to talk about later. And, so you submit this 33 00:03:20,220 --> 00:03:24,930 kind of request structures and the kernel uses copy in to fetch the request 34 00:03:24,930 --> 00:03:29,260 structure from user mode into kernel mode but there's a certain type of request 35 00:03:29,260 --> 00:03:35,380 structure which contains an indirection like a second layer, right? And, well, 36 00:03:35,380 --> 00:03:41,060 they just ignore that for the second level and hope for the best. So, let's look at 37 00:03:41,060 --> 00:03:45,220 the relevant part. I'm really sorry I'm showing you this code here, but it's not 38 00:03:45,220 --> 00:03:49,430 much more than that. So, there is something that is called ios packet in the 39 00:03:49,430 --> 00:03:53,599 second line which is kind of this request that we submit from user mode into kernel 40 00:03:53,599 --> 00:03:58,351 mode And in the top line there's this special request entry, so it contains a 41 00:03:58,351 --> 00:04:03,069 physical address, a buffer size and a virtual address. And what we do from user 42 00:04:03,069 --> 00:04:07,510 mode is we submit it filled out with the virtual address and the size. and the 43 00:04:07,510 --> 00:04:15,520 kernel does this convenient thing for us. It kind of.. changes the virtual address 44 00:04:15,520 --> 00:04:21,019 to the physical address. So we can see, it copies in these packets from user mode 45 00:04:21,019 --> 00:04:25,530 into kernel mode using the safe mechanism and then it goes through all the entries 46 00:04:25,530 --> 00:04:29,840 and fixes up the physical addresses for us but we can see in this line that it 47 00:04:29,840 --> 00:04:33,500 doesn't use to the safe mechanism at all it doesn't care about whatever address we 48 00:04:33,500 --> 00:04:38,620 put in there so this gives us some kind of right primitive to wherever we want 49 00:04:38,620 --> 00:04:45,780 basically and this looks hard to exploit, right? Because the right kind of going 50 00:04:45,780 --> 00:04:54,630 through this conversation but we actually only need one byte to exploit the kernel 51 00:04:54,630 --> 00:05:01,639 and we do this by noting that this KIEffectiveToPhysical conversion function 52 00:05:01,639 --> 00:05:08,350 actually returns 0 for any garbage input we get and there's a pretty high chance of 53 00:05:08,350 --> 00:05:14,320 the input to the function to being garbage if we point to any part inside kernel data 54 00:05:14,320 --> 00:05:19,940 so the strategy here is that we go into syscall handler address table and we 55 00:05:19,940 --> 00:05:25,020 overwrite the last byte for one particular syscall handler and we hope that the new 56 00:05:25,020 --> 00:05:29,590 address actually points to some usable gadget so we hope for the best basically 57 00:05:29,590 --> 00:05:33,910 and the other important thing to note here is that our user mode code is running from 58 00:05:33,910 --> 00:05:38,230 what we call the JIT area and what's really stupid is that the JIT area is 59 00:05:38,230 --> 00:05:44,050 actually executable from kernel mode for some reason so that's nice too. Okay, 60 00:05:44,050 --> 00:05:49,720 let's look at the relevant structures so this is the kernel and we should read this 61 00:05:49,720 --> 00:05:56,020 from the bottom to the top. Ok, like in the last line the button we see this entry 62 00:05:56,020 --> 00:06:03,040 to KeLoaderCall and then we can look at the last byte there it's hex F0. And what 63 00:06:03,040 --> 00:06:11,080 we will do now is overwrite this last byte with 0 and what happens is that now this 64 00:06:11,080 --> 00:06:16,000 syscall will actually point to this very usable gadget up there where it loads 65 00:06:16,000 --> 00:06:20,880 this register r28 into the link register and just branches there the nice thing is 66 00:06:20,880 --> 00:06:28,120 that we control our 28 from user mode so this gives us a way to just jump anywhere 67 00:06:28,120 --> 00:06:35,800 basically so how do we exploit this. Well, we have our k-mode function there then we 68 00:06:35,800 --> 00:06:42,430 just call ioctlv to this shifted address and from this point on we have this nice 69 00:06:42,430 --> 00:06:46,360 syscall that just comes to anywhere we want and then we call it basically and 70 00:06:46,360 --> 00:06:53,310 this calls our k-mode function. So, the Wii U starts out with full four hearts and 71 00:06:53,310 --> 00:06:59,710 this gives us PowerPC kernel mode code execution so we subtract one hard and it's 72 00:06:59,710 --> 00:07:05,570 quite nice but we can and need to go deeper and for that let's look at the IOSU 73 00:07:05,570 --> 00:07:12,430 architecture. So IOSU is present as one big ELF file and this includes the kernel 74 00:07:12,430 --> 00:07:18,110 and all the services and it's running on the Starbuck it, has a hardware way to 75 00:07:18,110 --> 00:07:24,479 enforce no execute and again no ASLR, making our lives easier and it's a 76 00:07:24,479 --> 00:07:30,590 microkernel design that has about a 140 syscalls so another thing to notice that 77 00:07:30,590 --> 00:07:35,790 the kernel spawns all these services as user mode processes so before we can 78 00:07:35,790 --> 00:07:40,139 exploit the kernel we actually have to exploit one of these user mode processes 79 00:07:40,139 --> 00:07:46,280 which we did but i'm not going to talk about and to look into the kernel, we 80 00:07:46,280 --> 00:07:51,639 began by reversing all of the syscalls and search for bugs and what we came up with 81 00:07:51,639 --> 00:07:56,400 is called MQHAX or message queue hax it contains another nice bug class that 82 00:07:56,400 --> 00:08:05,249 apparently never dies. Integer overflows. And let's look at the code again so 83 00:08:05,249 --> 00:08:09,610 there's this syscall, it's called create message queue you pass it a buffer and a 84 00:08:09,610 --> 00:08:14,050 number of buffer entries and what they assumed was that each buffer entry is four 85 00:08:14,050 --> 00:08:18,410 bytes so when they check the address range to just multiply the number of entries 86 00:08:18,410 --> 00:08:24,361 with four bytes so does anyone see the integer overflow here and then a nice 87 00:08:24,361 --> 00:08:28,110 thing is that it just to use the number of entries for the maximum number of entries 88 00:08:28,110 --> 00:08:33,718 for the message queue and our right primitive again is the send message 89 00:08:33,718 --> 00:08:40,669 syscall. So, I told you about this hardware NX right? So IOSU should be 90 00:08:40,669 --> 00:08:47,759 enforcing that no executable memory is writeable and if you look at the kernel 91 00:08:47,759 --> 00:08:52,180 section flags we actually see that KERNEL_TEXT is read execute and 92 00:08:52,180 --> 00:08:58,789 KERNEL_DATA is read-write but these permissions are all lies. Ok so our 93 00:08:58,789 --> 00:09:05,199 exploit strategy: well, let's look at the relevant part of the IOSU kernel so we see 94 00:09:05,199 --> 00:09:10,230 that KERNEL_TEXT starts at this lower address, at hex 0x08120000 and 95 00:09:10,230 --> 00:09:15,170 conveniently for us there is a syscall there and the addresses before that are 96 00:09:15,170 --> 00:09:21,089 all valid so we create a message queue, I'm starting at minus eight bytes and this 97 00:09:21,089 --> 00:09:27,629 magic hex 0x400- whatever-2 number and from this point on we just push two 98 00:09:27,629 --> 00:09:32,529 messages and then ARM instruction to branch out three and what this does is it 99 00:09:32,529 --> 00:09:38,499 actually causes the start of text section to be overwritten with branch R3 and let's 100 00:09:38,499 --> 00:09:43,619 just look at the integer overflow right four times this value truncated to 4 bytes 101 00:09:43,619 --> 00:09:48,200 gives 8 bytes so what kind of things is that the message queues is only bytes but 102 00:09:48,200 --> 00:09:54,509 we can just push any messages we want ok so this gives us IOSU kernel-mode 103 00:09:54,509 --> 00:09:59,560 execution and the nice thing about this is that we actually have full control over 104 00:09:59,560 --> 00:10:03,871 the console unit now right so we can dump the console's OTP which contains all the 105 00:10:03,871 --> 00:10:10,209 keys except for boot1 which we will come back to later because unfortunately the 106 00:10:10,209 --> 00:10:15,869 pieces for boot1 are locked out as we have already seen. And now we want to make 107 00:10:15,869 --> 00:10:22,199 everything persistent so how do we do that? We find that title content is only 108 00:10:22,199 --> 00:10:27,179 verified at title install time but never at boot time because at boot time they 109 00:10:27,179 --> 00:10:31,790 only verify the title binary so what you can do is you can actually start to mess 110 00:10:31,790 --> 00:10:39,499 with the metadata of titles and overwrite it and what we did was to overwrite the 111 00:10:39,499 --> 00:10:44,769 ROM for a DS game, exploited the emulator and got user mode code 112 00:10:44,769 --> 00:10:50,170 execution again and another thing is that the console contains this config file 113 00:10:50,170 --> 00:10:55,100 which tells it to boot into which title to boot so what you can do is you 114 00:10:55,100 --> 00:11:00,869 overwrite the title ID with your modified DS emulator title and the next time you 115 00:11:00,869 --> 00:11:06,970 start up the console it actually boots into the exploited game and yeah so just 116 00:11:06,970 --> 00:11:11,060 gives us persistent code execution and cold boot with full control over to 117 00:11:11,060 --> 00:11:17,570 console whatsoever so game over 118 00:11:17,570 --> 00:11:26,339 *applause* 119 00:11:26,339 --> 00:11:33,959 derrek: So, as we just saw, the kernel it's like pretty broken, right? So, what 120 00:11:33,959 --> 00:11:41,420 is missing and I just copied this slide from failoverflow's talk as you can see we are 121 00:11:41,420 --> 00:11:49,309 using the same d14 thing for our slides and basically the boot1 key which is the 122 00:11:49,309 --> 00:11:57,060 second stage bootloader on Wii U and this key is still unknown and they tried to get 123 00:11:57,060 --> 00:12:05,129 it somehow with some side-channel attacks thing but I think it never worked 124 00:12:05,129 --> 00:12:12,889 so it would be nice to get this key and the first thing we did was to make a NAND 125 00:12:12,889 --> 00:12:22,139 tracer so we can basically sniff all the traffic between NAND and boot1 to see what 126 00:12:22,139 --> 00:12:33,069 boot1 reads from flash and so we get some nice addresses and we could compare this 127 00:12:33,069 --> 00:12:40,319 with the file system on the / to see what file it is reading and we also kind of 128 00:12:40,319 --> 00:12:46,740 mess around with some files on this file system and we found out that boot1 129 00:12:46,740 --> 00:12:53,360 actually parses a file that is called system.xml and I don't know, it doesn't 130 00:12:53,360 --> 00:13:03,290 really feel safe to parse an XML file in such a really early boot process I mean 131 00:13:03,290 --> 00:13:11,860 there's a lot of stuff that could go wrong. So, we tried to attack this and we 132 00:13:11,860 --> 00:13:18,350 tried some blind exploitation stuff but yeah unfortunately it didn't really work 133 00:13:18,350 --> 00:13:28,899 so let's try something else. So, there's boot1, which of course boots this.. Sorry 134 00:13:28,899 --> 00:13:37,290 we've got boot0 and this boots boot1 and failoverflow found out that this boot0 135 00:13:37,290 --> 00:13:42,629 which is a bootrom of the security processor can be re-enabled again in 136 00:13:42,629 --> 00:13:49,339 virtual Wii mode and you can just dump it so let's look at boot1... boot0 I'm sorry 137 00:13:49,339 --> 00:13:59,029 and we can see that it reads boot1 key from OTP and then it locks out boot1 key 138 00:13:59,029 --> 00:14:05,769 forever and this happens really early but it's basically kept in memory all the time 139 00:14:05,769 --> 00:14:14,790 until it's done until it has launched boot1 or just panicked. So, this means 140 00:14:14,790 --> 00:14:22,740 that we have to exploit boot0 to get the boot1 key and unfortunately, boot0 is 141 00:14:22,740 --> 00:14:30,389 pretty safe it's kind of surprising because this is Wii U and basically this 142 00:14:30,389 --> 00:14:37,649 gives us this question: How can you exploit something that has no bugs? So, 143 00:14:37,649 --> 00:14:43,860 the answer is we have to introduce our own bugs - *laughter* - and we're doing this 144 00:14:43,860 --> 00:14:50,230 by using fault injection and maybe you have heard of it already it's basically 145 00:14:50,230 --> 00:14:58,410 you introduce an error into device by a glitching the clock, voltage, the reset 146 00:14:58,410 --> 00:15:04,790 line you can also do electromagnetic injections. There are many ways. But 147 00:15:04,790 --> 00:15:12,049 basically what you want to get is a mutated instruction, or instruction skip 148 00:15:12,049 --> 00:15:18,579 or some corrupted registers and what you don't want is just a stupid lock up where 149 00:15:18,579 --> 00:15:27,790 it just crashes and yeah that's all really useful so we want to glitch boot0 and to 150 00:15:27,790 --> 00:15:37,069 do this we have to find a nice target like the weak spot of boot0 so let's take a 151 00:15:37,069 --> 00:15:44,829 look what boot0 does first thing it does is it copies itself to ram for some 152 00:15:44,829 --> 00:15:49,129 unknown reason I mean there's no good reason to do this but it's nice for us 153 00:15:49,129 --> 00:15:58,029 because it copies itself to RAM and just executes from there and then it copies the 154 00:15:58,029 --> 00:16:04,519 boot1 key to memory it locks out the auto key slot initializes some other stuff and 155 00:16:04,519 --> 00:16:11,579 flash controller and then it starts reading the boot1 image and it does that 156 00:16:11,579 --> 00:16:22,559 by just reading its header to this address and then they read the size from the 157 00:16:22,559 --> 00:16:30,639 header field and they also do some max size check on this and please note that 158 00:16:30,639 --> 00:16:37,990 the header itself is not encrypted and they also don't do any signature 159 00:16:37,990 --> 00:16:49,869 verification here at this step so they use the size and reads the whole boot1 image 160 00:16:49,869 --> 00:16:54,939 using size and then they do a real signature verification to make sure that 161 00:16:54,939 --> 00:17:00,230 the image is not corrupted it then decrypts the boot1 code using the key from 162 00:17:00,230 --> 00:17:09,010 RAM and then it clears the key and jumps to boot1entry point ok so what is the weak 163 00:17:09,010 --> 00:17:14,680 spot here and I mean if you look at this you can pretty much already tell what it 164 00:17:14,680 --> 00:17:24,940 is and of course it's this size check so what we can do is we can write our own 165 00:17:24,940 --> 00:17:31,500 modified version of boot1 into flash with some really really large size in the 166 00:17:31,500 --> 00:17:43,660 header so it reads the header and then it's supposed to do a size check and this 167 00:17:43,660 --> 00:17:50,830 is exactly where we wanted to glitch it and eventually it will just skip the 168 00:17:50,830 --> 00:17:57,560 instruction or something else happens and then basically the size check is bypassed 169 00:17:57,560 --> 00:18:03,300 so when it's reading the boot1 image using this size it will actually overflow the 170 00:18:03,300 --> 00:18:09,180 buffer and we have some jump instructions at the end so when it returns from the 171 00:18:09,180 --> 00:18:16,730 flash read function it will eventually jump to our code and this is actually 172 00:18:16,730 --> 00:18:19,820 boot0 code execution 173 00:18:19,820 --> 00:18:29,680 *applause* 174 00:18:29,680 --> 00:18:35,450 ok so we have boot0 code execution and you know we can just dump the boot1 key from 175 00:18:35,450 --> 00:18:43,430 RAM and we didn't even need an exploit for this right so it's just boot0 is actually 176 00:18:43,430 --> 00:18:49,600 pretty safe right but when it comes to pitching it's kind of fragile 177 00:18:49,600 --> 00:18:58,350 because boot0 code is writeable and also the boot1 image buffer is in front of boot0 178 00:18:58,350 --> 00:19:04,810 buffer so we can just overflow it and also the setup that I had was also surprisingly 179 00:19:04,810 --> 00:19:11,600 stable so it works like fifty percent of the entire time so let's finally look at 180 00:19:11,600 --> 00:19:19,490 boot1 and boot1 is able to understand the Wii U file system it uses real file path 181 00:19:19,490 --> 00:19:24,670 strings to load the firmware image and of course the first 182 00:19:24,670 --> 00:19:33,370 thing we did was to look at the xml parser and well unfortunately it seems pretty 183 00:19:33,370 --> 00:19:44,160 safe and yeah but maybe we found a bug we're not really sure and we haven't 184 00:19:44,160 --> 00:19:49,750 really tried to exploit it. Interest kind of faded out because you know it's after 185 00:19:49,750 --> 00:20:00,290 all it's just the Wii U so that's it for Wii U and now I will hand over to nedwill. 186 00:20:00,290 --> 00:20:03,250 He's talking about 3DS 187 00:20:03,250 --> 00:20:12,020 *applause* 188 00:20:12,020 --> 00:20:17,820 nedwill: Hi, everyone, I'm ned. I started 3DS this year and I'm basically a software 189 00:20:17,820 --> 00:20:22,860 person so I'm going to be showing some of the homebrew side of 3DS where that's at 190 00:20:22,860 --> 00:20:29,701 right now so just to reiterate from last year these guys broke userland, kernel and 191 00:20:29,701 --> 00:20:37,060 the security processor they also broke the secret hardware key scrambler and since 192 00:20:37,060 --> 00:20:44,130 then Nintendo has been kind of mad about this they released a lot of system updates 193 00:20:44,130 --> 00:20:50,940 and they started a bug bounty program so there's a lot of bugs getting patched but 194 00:20:50,940 --> 00:20:56,360 because of the amount of the level of exploitation we got last year it's 195 00:20:56,360 --> 00:21:01,740 actually really easy to find new bugs and exploits so what I want to emphasize here 196 00:21:01,740 --> 00:21:05,860 is that even though it's like a cat-and-mouse game because we have so much 197 00:21:05,860 --> 00:21:13,310 control we can exploit more difficult books on the latest firmware so starting 198 00:21:13,310 --> 00:21:19,480 with user space. This is where all homebrew comes from so already it's pretty 199 00:21:19,480 --> 00:21:25,040 good like this has always been a huge focus for the homebrew community because 200 00:21:25,040 --> 00:21:29,190 it's kind of where you know user space is where you want to be running your own 201 00:21:29,190 --> 00:21:37,380 custom games you know modifying stuff so we have a bunch of game entry points and a 202 00:21:37,380 --> 00:21:41,930 bunch of browser exploits but there's a couple limitations to leads and that's 203 00:21:41,930 --> 00:21:50,800 that game carts cost money and they frequently are.. like the games that are 204 00:21:50,800 --> 00:21:56,600 exploited are usually somewhat rare and unusual and so the price goes way up as 205 00:21:56,600 --> 00:22:03,870 demand soars and for the browser every time we release a new browser exploit, 206 00:22:03,870 --> 00:22:10,280 Nintendo can actually enforce that you're on the latest firmware, because before we 207 00:22:10,280 --> 00:22:16,490 fetch any web page it will check that the system is on the latest version. So, they 208 00:22:16,490 --> 00:22:23,731 can kind of remotely cut off web browser exploits. So looking at this I thought it 209 00:22:23,731 --> 00:22:27,570 might be fun to look at if any of the system titles can be exploitable as 210 00:22:27,570 --> 00:22:36,960 primary entry points and I found something called SOUNDHAX so just the basic like the 211 00:22:36,960 --> 00:22:42,370 two probably most obvious things to look at are the image loader because it's got 212 00:22:42,370 --> 00:22:48,020 JPEG parsing and also the music player. But, when I looked at the music player I 213 00:22:48,020 --> 00:22:52,330 saw that they're parsing actually a lot of formats and maybe even have their own 214 00:22:52,330 --> 00:23:00,200 custom playlists format and if they make a single mistake anywhere it's it's over so 215 00:23:00,200 --> 00:23:03,450 then I was trying to compare with like open source implementations I didn't find 216 00:23:03,450 --> 00:23:10,610 any overlap. It seemed like everything was custom. So that was pretty promising. So, 217 00:23:10,610 --> 00:23:14,980 over the course of about a month, I found a bunch of bugs and I was trying to like 218 00:23:14,980 --> 00:23:20,070 chain together little like logical bugs and it wasn't really working and then I 219 00:23:20,070 --> 00:23:25,860 just found one that was really critical. So, I'm going to demonstrate that here. 220 00:23:25,860 --> 00:23:29,240 So, actually studied mp3 for the whole month MPEG was like the 221 00:23:29,240 --> 00:23:36,260 last day so I looked at it and they actually malloc 256 byte buffer for the 222 00:23:36,260 --> 00:23:43,000 song name and then when they go to load it if they see a unicode BOM marker they just 223 00:23:43,000 --> 00:23:49,750 memcpy the thing and that tag size is totally controlled so you know that's 224 00:23:49,750 --> 00:23:56,060 that's it so this is like it was pretty great but it's a few pics place that's a 225 00:23:56,060 --> 00:24:01,910 little tricky but this is what it looks like so we have our name chunk that we're 226 00:24:01,910 --> 00:24:08,900 about to overflow and then like I'm a CTF player, so I put A's there and then the 227 00:24:08,900 --> 00:24:15,210 next thing that happens is this gets freed and so this victim chunk that we have 228 00:24:15,210 --> 00:24:21,720 overridden it's actually the way the 3DS heap works they actually track they have a 229 00:24:21,720 --> 00:24:25,880 linked list of what things are currently allocated so this gives us the classical 230 00:24:25,880 --> 00:24:32,611 heap unlink arbitrary write and so at this point we have a 4-byte write and we want 231 00:24:32,611 --> 00:24:40,120 to get ROP out of it so we'll probably do a stack pivot so I looked at the binary 232 00:24:40,120 --> 00:24:47,230 and there's only one pivot gadget and then i looked at the the thumb pivots, there 233 00:24:47,230 --> 00:24:51,410 are actually a lot but because this CPU was too old didn't support the wide 234 00:24:51,410 --> 00:24:58,710 instructions where all the pivots come up so unfortunately that one pivot 235 00:24:58,710 --> 00:25:07,750 instruction has some arithmetic conditions on it specifically it was that in order to 236 00:25:07,750 --> 00:25:12,170 you know load all your registers from memory the condition flags had to satisfy 237 00:25:12,170 --> 00:25:18,800 less than and everywhere where we return from the function it had just checked that 238 00:25:18,800 --> 00:25:23,240 like if this pointer is not null free it and so the comparisons wouldn't ever be 239 00:25:23,240 --> 00:25:29,980 satisfied because nothing is mapped up in the negative area so of course CTF 240 00:25:29,980 --> 00:25:38,230 workarounds. We can still do this so I overwrite the heap freelist head with the 241 00:25:38,230 --> 00:25:43,420 stack address and so on the next malloc we just return that stack address and read 242 00:25:43,420 --> 00:25:50,820 into it so there's a couple of constraints on this and the first one is really normal 243 00:25:50,820 --> 00:25:56,151 like this is every pivot to stack heap thing you have to make sure that you have 244 00:25:56,151 --> 00:26:01,670 a heap chunk on the stack and luckily this is actually pretty easy because all you 245 00:26:01,670 --> 00:26:07,450 need is a size followed by two null pointers representing next and previous so 246 00:26:07,450 --> 00:26:11,640 when malloc goes to look there it seems like the size is big enough and then 247 00:26:11,640 --> 00:26:18,610 nothing else is in the queue so just return this and then this worked so we 248 00:26:18,610 --> 00:26:24,080 memcpy the next tag to the stack and like we just specify that size and malloc some 249 00:26:24,080 --> 00:26:31,320 *unintelligible* for us and then from there we're done because we can just do a 250 00:26:31,320 --> 00:26:35,430 little little ROP chain, we memcpy the shellcode to the heap and then use an 251 00:26:35,430 --> 00:26:41,900 existing exploit gspwn which has been around for a long time to override the 252 00:26:41,900 --> 00:26:52,410 text section and jump there so there's the first heart so you can't really talk about 253 00:26:52,410 --> 00:26:58,430 homebrew without also talking about kernel because we want to get access to more 254 00:26:58,430 --> 00:27:03,060 syscalls like the 3DS actually sandboxes a lot of the syscalls away from you and so 255 00:27:03,060 --> 00:27:09,170 as an attacker, your goal is to call some syscalls that are restricted a really nice 256 00:27:09,170 --> 00:27:14,060 example would be you want to map some executable memory for like a JIT emulator 257 00:27:14,060 --> 00:27:20,590 so it's kind of a tricky situation because you're inside the sandbox you want to 258 00:27:20,590 --> 00:27:26,380 break out you have to find bugs in like pretty restricted syscalls so I looked at 259 00:27:26,380 --> 00:27:32,240 last year's talk here and like what had been done so far and it seemed like there 260 00:27:32,240 --> 00:27:36,740 are a lot of attacks on that memory mapping but I didn't see much about the 261 00:27:36,740 --> 00:27:42,750 sync primitives or anything related to use after free and i had just got a pretty bad 262 00:27:42,750 --> 00:27:46,640 grade on my OS project because i had a lot of those so I knew this is a good place to 263 00:27:46,640 --> 00:27:56,090 look so I noticed the design flaw when I was reversing the ref counting so it's not 264 00:27:56,090 --> 00:28:00,920 so much that they couldn't possibly get this right but generally when you're 265 00:28:00,920 --> 00:28:05,740 designing an API you want to make it really hard to abuse and this is just not 266 00:28:05,740 --> 00:28:10,800 really true for how they do ref counting so I'll go ahead and bring these up yeah 267 00:28:10,800 --> 00:28:18,910 so basically they whenever the user fetches a kernel object to perform some 268 00:28:18,910 --> 00:28:23,310 operation on it meaning you call this syscall that does something using the 269 00:28:23,310 --> 00:28:30,150 current object it does the correct inc ref and then dec ref for you but I was looking 270 00:28:30,150 --> 00:28:33,059 at it and thinking well like a lot of times the kernel actually is using these 271 00:28:33,059 --> 00:28:38,090 objects internally to do stuff so I mean I spelled it but like I mean I was like a 272 00:28:38,090 --> 00:28:42,380 week I found like 3 use after frees and they're all following the same pattern. 273 00:28:42,380 --> 00:28:47,640 The kernel's using an object internally without maintaining the reference count 274 00:28:47,640 --> 00:28:53,510 correctly and then some people ask me like advice on kernel hacking maybe like at 275 00:28:53,510 --> 00:28:58,630 home I definitely recommend looking here I'm sure that there's plenty more so the 276 00:28:58,630 --> 00:29:06,360 one going to talk about today is the the timer object so this is a pretty simple 277 00:29:06,360 --> 00:29:11,950 API with the kernel you can have it create a timer for you you can set the timer you 278 00:29:11,950 --> 00:29:18,300 can wait on it it's like a normal synchronization primitive so like I said I 279 00:29:18,300 --> 00:29:21,020 was looking for these use after frees I saw this I thought it's kind of 280 00:29:21,020 --> 00:29:27,470 interesting that this one called pulse is here because what's happening with this 281 00:29:27,470 --> 00:29:35,390 one is when you set the timer to pulse like every period it's signaling 282 00:29:35,390 --> 00:29:38,660 everything that's waiting on it and then it like resets itself and then if you wait 283 00:29:38,660 --> 00:29:42,559 on it the next period comes around you get a signal again and so was thinking like 284 00:29:42,559 --> 00:29:47,990 it's definitely doing some stuff with this object internally that's like a bit more 285 00:29:47,990 --> 00:29:53,890 complicated than some of the other modes and the other kernel objects so i looked 286 00:29:53,890 --> 00:29:59,810 at how they did the pulse like you know every every second whatever, when it 287 00:29:59,810 --> 00:30:06,610 pulses like what's actually getting executed and if you look here they do some 288 00:30:06,610 --> 00:30:11,370 pretty good locking and then they signal and then what happens here is basically 289 00:30:11,370 --> 00:30:16,299 when they signal they go through and everyone that was waiting gets rescheduled 290 00:30:16,299 --> 00:30:22,420 - made runnable - and then at the end they reset the timer state and just say like 291 00:30:22,420 --> 00:30:28,470 okay everyone that waits on this again has to wait for the next cycle so and then 292 00:30:28,470 --> 00:30:32,790 this also looks pretty good like they they're locking the scheduler here this 293 00:30:32,790 --> 00:30:38,670 would work but nothing is preventing you from just closing this from another call 294 00:30:38,670 --> 00:30:46,809 so I have FASTHAX which is just 3 syscalls and that's it. That's the entire exploit 295 00:30:46,809 --> 00:30:51,440 there's a lot of setup which we will get to but you just create the timer set it to 296 00:30:51,440 --> 00:30:57,760 run really fast and then close the handle and then if it was pulsing and you closed 297 00:30:57,760 --> 00:31:03,950 it it will use after free so what's nice about this is if you lose the race it's 298 00:31:03,950 --> 00:31:09,510 just the timer is just on schedule you're fine and then it actually happens quite 299 00:31:09,510 --> 00:31:14,340 often and I didn't even really specifically try to win this to like I 300 00:31:14,340 --> 00:31:18,740 just.. Once it was within a second I don't worry about those parameters are probably 301 00:31:18,740 --> 00:31:28,610 not optimal so we should look at how do we exploit this basically this is a little 302 00:31:28,610 --> 00:31:32,450 bit of a more complicated view of it. I'll show a diagram in a second but this is 303 00:31:32,450 --> 00:31:37,559 like where the use after free actually happens so like r7 is pointing to my timer 304 00:31:37,559 --> 00:31:42,760 object and then it was freed before we reach this chunk here and then it's 305 00:31:42,760 --> 00:31:48,510 loading r7 to r0, loading something from that and then branching to it so that's 306 00:31:48,510 --> 00:31:54,730 like calling a use after free object. So, this is pretty exploitable on the 3DS 307 00:31:54,730 --> 00:32:03,970 kernel because they use a slab heap to deal with allocating objects so this is the 308 00:32:03,970 --> 00:32:09,050 normal situation when that first timer is allocated the vtable is pointing to the 309 00:32:09,050 --> 00:32:12,930 you know the real KTimer vtable and then it wants to call that timer reset 310 00:32:12,930 --> 00:32:21,460 function. It's totally fine but when we free it actually, that vtable pointer goes 311 00:32:21,460 --> 00:32:25,320 to the next free timer object in the kernel so it's actually interpreting that 312 00:32:25,320 --> 00:32:31,730 struct as a vtable and what's nice is it actually overlaps with the initial timer 313 00:32:31,730 --> 00:32:38,970 value that we totally control and so it looks like okay we can just set the 314 00:32:38,970 --> 00:32:44,590 initial timer value you know do this use after free, we're just calling user space 315 00:32:44,590 --> 00:32:52,580 that's what I thought and then realized it wasn't that easy so because the race like 316 00:32:52,580 --> 00:32:56,820 it because I was actually calling this is in a kernel thread we actually can't 317 00:32:56,820 --> 00:33:01,420 guarantee that our user process is actually mapped in memory and in fact it's 318 00:33:01,420 --> 00:33:07,380 on a different core so even if you open a process in the other core like ran a 319 00:33:07,380 --> 00:33:12,980 thread there you can't get more than twenty-five percent of the time I think so 320 00:33:12,980 --> 00:33:17,840 that's just super unstable also because it's a kernel thread we don't necessarily 321 00:33:17,840 --> 00:33:21,900 want to crash it and we don't like crashes in general but this will just totally 322 00:33:21,900 --> 00:33:27,760 break everything if the timer like sync thread dies so as long as we return to a 323 00:33:27,760 --> 00:33:33,860 function do something cleanly, return it will be fine so it sounds like okay all we 324 00:33:33,860 --> 00:33:38,290 have to do is find some kernel function we can call and we're done but there's 325 00:33:38,290 --> 00:33:44,070 actually another issue and that's that kernel code is mapped at high addresses 326 00:33:44,070 --> 00:33:49,370 and these are actually negative and that the set timer syscall actually checks if 327 00:33:49,370 --> 00:33:57,250 your timer is negative so there's a pretty funny trick I found and that's that when 328 00:33:57,250 --> 00:34:00,510 you set the timer you're saying like you know start I like one second from now 329 00:34:00,510 --> 00:34:06,730 start pulsing obviously it's adding like the current time to the one second to know 330 00:34:06,730 --> 00:34:11,730 like when do i trigger this timer so so SetTimer is the one that does that add for 331 00:34:11,730 --> 00:34:18,359 you they don't check for overflow when installing it and timer schedule values 332 00:34:18,359 --> 00:34:26,210 are signed which is also a bit weird so we can overflow and schedule into the past so 333 00:34:26,210 --> 00:34:32,739 how this looks is that's my like disgusting set up call so what's happening 334 00:34:32,739 --> 00:34:38,789 is like in the middle that's the start of the 3DS boot and then that range on the 335 00:34:38,789 --> 00:34:46,129 right is what the 3DS will allow you to pass for your values for the initial and 336 00:34:46,129 --> 00:34:54,329 like pulse period time and so what I do is I just put it right there at the end and 337 00:34:54,329 --> 00:35:00,230 then it overflows and then on the next pulse I also control that and that's also 338 00:35:00,230 --> 00:35:05,509 less than that range so then we can get it to line up on the kernel address we want 339 00:35:05,509 --> 00:35:13,130 and so that's pretty good. Unfortunately, we're at the end like at this point is 340 00:35:13,130 --> 00:35:19,309 pretty solid but there isn't like an obvious single thing we can call and it 341 00:35:19,309 --> 00:35:22,269 seems like maybe you could race a bunch of times and call a bunch of different things 342 00:35:22,269 --> 00:35:26,359 in the kernel and like you know that's a decent amount of control but because of 343 00:35:26,359 --> 00:35:32,739 all this weird negative scheduling stuff it's actually pretty hard to do multiple 344 00:35:32,739 --> 00:35:37,150 calls so I was trying to look for one thing that I can call that will give me 345 00:35:37,150 --> 00:35:47,049 control and this is where it gets really tricky so if we look at how the memory 346 00:35:47,049 --> 00:35:54,489 mapping on 3DS works in userspace you can access the FCRAM which is that first range 347 00:35:54,489 --> 00:36:00,599 up there that's just where you know your heap goes there and then the kernel also 348 00:36:00,599 --> 00:36:09,039 has a view of this heap it's you know a shared mapping so if we can write one of 349 00:36:09,039 --> 00:36:13,190 those something in that range into the free pointer and allocate it, it actually 350 00:36:13,190 --> 00:36:20,160 ends up in something we can see as the user so then I noticed this.. This is 351 00:36:20,160 --> 00:36:30,099 actually a common instruction prefix in ARM so I jumped here and at this point 352 00:36:30,099 --> 00:36:35,559 like we just did in C++, a vtable call on the use after free thing with one argument 353 00:36:35,559 --> 00:36:41,009 so this means that r0 contains the address of the object and r1 contains the address 354 00:36:41,009 --> 00:36:49,519 of where we just jumped to so that uh like B65C [0xFFF1B65C] is where r1 is pointing 355 00:36:49,519 --> 00:36:53,290 so this is actually like some random linked lists lookup function but it's 356 00:36:53,290 --> 00:36:57,829 actually looking down to the add instruction and loading it to r1 and then 357 00:36:57,829 --> 00:37:05,720 we write that to the object and so at this point it looks like this it's pointing to 358 00:37:05,720 --> 00:37:11,190 something in user space and then we just alloc two times we can look in user space 359 00:37:11,190 --> 00:37:16,579 so they put the object there you control the vtable and from there it's pretty much 360 00:37:16,579 --> 00:37:25,970 standard straightforward thing. So, there we go *unintelligible* userspace in kernel 361 00:37:25,970 --> 00:37:31,210 and this is almost game over one more time 362 00:37:31,210 --> 00:37:39,450 *applause* 363 00:37:39,450 --> 00:37:42,000 derrek: So we've broken several parts of 364 00:37:42,000 --> 00:37:48,920 the 3DS firmware including 3DS kernel and all software that's running on the 365 00:37:48,920 --> 00:37:55,390 security processor what we haven't looked at yet are the 3DS bootroms and I'm 366 00:37:55,390 --> 00:38:04,470 basically there's one bootrom for each processor for the ARM 11 and for the ARM 9 367 00:38:04,470 --> 00:38:10,869 and I think there's probably, there are more bootroms in 3DS system-on-a-chip used 368 00:38:10,869 --> 00:38:18,220 to for old Nintendo DS mode but we will focus on the 3DS bootroms here and what we 369 00:38:18,220 --> 00:38:27,670 know is 3DS is somehow loading the firmware image from NAND flash and we also 370 00:38:27,670 --> 00:38:34,640 know that the ARM9 bootrom does all the interesting stuff because only the ARM9 371 00:38:34,640 --> 00:38:43,549 has access to the whole crypto hardware like the AES engine, RSA engine we also 372 00:38:43,549 --> 00:38:53,279 know that the bootrom will initialize the secret keys for the AES key slots and yes 373 00:38:53,279 --> 00:39:00,769 we would like to get those keys but um unfortunately the bootrom is disabled, it 374 00:39:00,769 --> 00:39:08,789 disables itself before its launching of the firmware and 3DS bootroms also print 375 00:39:08,789 --> 00:39:16,330 nice error screens like when the NAND is corrupted or something, it shows an error 376 00:39:16,330 --> 00:39:23,580 screen so let's look how the bootroms are protected in detail and basically there 377 00:39:23,580 --> 00:39:30,730 are two registers that we call CFG_SYSPROT9 and CFG_SYSPROT11 and the 378 00:39:30,730 --> 00:39:37,089 bootrom writes to those registers and of course they are one shot you cannot 379 00:39:37,089 --> 00:39:44,490 re-enable bootroms again because this is not the Wii U and basically when it's 380 00:39:44,490 --> 00:39:53,029 disables the bootrom it only disables one half of it so what you get are two parts 381 00:39:53,029 --> 00:40:01,190 of bootrom there's the unprotected part and protected part you can just dump the 382 00:40:01,190 --> 00:40:07,739 unprotected part by taking over ARM9 from firmware but you can never see the 383 00:40:07,739 --> 00:40:14,030 protected part and they were really clever and basically they put all the interesting 384 00:40:14,030 --> 00:40:20,249 code in the protected part and if you look at the reset vector it just jumps directly 385 00:40:20,249 --> 00:40:25,680 to protected part of the boot room so as you can't really figure out what is going 386 00:40:25,680 --> 00:40:32,499 on when the 3DS is starting up but what you can do is you can look at the code 387 00:40:32,499 --> 00:40:40,989 from the unprotected bootrom and who knows maybe we can find a bug so let's do this. 388 00:40:40,989 --> 00:40:47,190 First of all of course there are no keys in in the unprotected bootrom, they put 389 00:40:47,190 --> 00:40:53,989 all the keys in the protected part it's also mainly it's a lot of driver code. 390 00:40:53,989 --> 00:41:00,059 Talks to some hardware like NAND flash, MMC, AES engine and also to SPI flash 391 00:41:00,059 --> 00:41:07,539 which is kind of interesting because the SPI flash is some really tiny chip that is 392 00:41:07,539 --> 00:41:14,509 soldered on the Wi-Fi socket and it's actually used for some Wi-Fi settings and 393 00:41:14,509 --> 00:41:21,430 other user settings us by old Nintendo DS mode and yeah that's kind of interesting 394 00:41:21,430 --> 00:41:28,170 uses the SPI flash and it also includes the ARM exception vector table and this is 395 00:41:28,170 --> 00:41:32,769 actually just design that they have adopted from previous generations of the 396 00:41:32,769 --> 00:41:41,299 Nintendo DS such as the DSi if you don't know ARM basically, you have something 397 00:41:41,299 --> 00:41:48,089 that is called an exception vector table and this is located at this hardcoded 398 00:41:48,089 --> 00:41:55,769 address in bootrom and basically every time when something weird happens or 399 00:41:55,769 --> 00:42:03,249 something special on the CPU it will jump to those exception vectors like the reset 400 00:42:03,249 --> 00:42:09,000 vector as we just so or when you're trying to read from an invalid address, it 401 00:42:09,000 --> 00:42:16,160 returns to the prefetch abort or data abort vector and also when you receive an 402 00:42:16,160 --> 00:42:25,160 interrupt it will jump to interrupt request vector so those are the exception 403 00:42:25,160 --> 00:42:29,580 vectors and they're hardcoded in the bootrom and there's kind of a problem with 404 00:42:29,580 --> 00:42:37,700 that because as a developer you don't want to put the exception in the routines in 405 00:42:37,700 --> 00:42:45,480 the boot rom, you want to it'd be able to change the code right? So, what they do is 406 00:42:45,480 --> 00:42:53,839 they just redirect all the exception execution flow from bootrom to another 407 00:42:53,839 --> 00:43:01,699 jumptable that is located in ARM9 memory so it looks like this. What you can see 408 00:43:01,699 --> 00:43:06,539 here are the bootrom vectors and it's basically just a jump instruction to the 409 00:43:06,539 --> 00:43:12,239 RAM vectors and the RAM vectors are also just another jump instruction to the 410 00:43:12,239 --> 00:43:16,980 actual firmware handler and this is so things look like when the firmware is 411 00:43:16,980 --> 00:43:26,200 running but what about cold boot well on cold boot you get this and this looks 412 00:43:26,200 --> 00:43:33,339 kinda interesting because you have the bootrom vectors that still point to ARM9 413 00:43:33,339 --> 00:43:39,930 memory but since this is cold boot, the RAM is not initialized so this is 414 00:43:39,930 --> 00:43:45,050 interesting but it is it's not really a bug because at some point the bootrom will 415 00:43:45,050 --> 00:43:53,700 initialize those RAM vectors so but let's cheat a little bit here and say let's just 416 00:43:53,700 --> 00:43:59,130 assume we could somehow trigger a really early exception even before the bootrom is 417 00:43:59,130 --> 00:44:08,729 able to initialize the RAM vectors well probably it was just crash because on 418 00:44:08,729 --> 00:44:13,519 exception it will just jump to uninitialized memory and there's probably 419 00:44:13,519 --> 00:44:22,190 no valid instruction there so this is not very useful but there's a really nice 420 00:44:22,190 --> 00:44:27,960 hardware flaw and we found this by just writing to some memory reboot, and see 421 00:44:27,960 --> 00:44:35,010 what what happened basically we found out that some RAM is actually not cleared on 422 00:44:35,010 --> 00:44:42,410 reboot and this also includes ARM9 so the basic idea is we can set up some custom 423 00:44:42,410 --> 00:44:49,650 exception vectors in RAM that regenerate execution flow to some dumper code so when 424 00:44:49,650 --> 00:44:55,579 we reboot we get this and this is really interesting because if you look at this 425 00:44:55,579 --> 00:45:01,469 this means all we need to do now is trigger a really early exception and then 426 00:45:01,469 --> 00:45:10,039 the bootrom will jump to our dumper code so, how can we trigger an exception? Well 427 00:45:10,039 --> 00:45:14,489 if you look at here, the exception vector table again there are some exceptions that 428 00:45:14,489 --> 00:45:20,261 we can trigger like because they are hardcoded like reset and they won't jump 429 00:45:20,261 --> 00:45:29,200 to ARM9 memory and you also can't use the interrupt vector because interrupts are 430 00:45:29,200 --> 00:45:39,190 disabled on reset and yeah this won't work so what's left is these 3 here interesting 431 00:45:39,190 --> 00:45:45,150 exceptions and if you look at those and they normally don't happen right undefined 432 00:45:45,150 --> 00:45:50,970 instruction is pretty rare and it shouldn't happen so I don't know about 433 00:45:50,970 --> 00:45:57,839 this reminds me kind of like it's a really nice use case for doing for injection 434 00:45:57,839 --> 00:46:04,759 again because you can corrupt registers and getting mutated instruction so it's 435 00:46:04,759 --> 00:46:10,950 really likely that it will trigger an exception so this is the vector glitch 436 00:46:10,950 --> 00:46:17,200 hack and basically we set up some vectors in RAM, trigger reboot then do some 437 00:46:17,200 --> 00:46:24,930 glitching magic and then we reset again and let it boot up normally and hopefully 438 00:46:24,930 --> 00:46:32,170 our dumper code got executed and just wrote a copy of the bootrom in memory so 439 00:46:32,170 --> 00:46:38,299 we can just dump it. All this stuff is not very stable but it works for me. 440 00:46:38,299 --> 00:46:48,549 *applause* 441 00:46:48,549 --> 00:46:57,990 Wo okay we got the bootrom and Nintendo is losing a life there so before we look at 442 00:46:57,990 --> 00:47:08,889 the bootrom I have a little problem for you and basically in early 2014 an FCC 443 00:47:08,889 --> 00:47:15,629 document became public. There it is, and basically it says that Nintendo has changed 444 00:47:15,629 --> 00:47:21,400 the CPU of the Nintendo 2DS and there's one really interesting sentence that 445 00:47:21,400 --> 00:47:26,819 basically says, they have changed security function of the initial program loader 446 00:47:26,819 --> 00:47:33,300 that is installed in each model so the initial program loader is probably bootrom 447 00:47:33,300 --> 00:47:42,180 so obviously there must be some really huge bug in the bootrom, right? So so 448 00:47:42,180 --> 00:47:48,680 that's it let's look at the bootrom. Basically there are some boot methods and 449 00:47:48,680 --> 00:47:52,721 you can boot from NAND, that's what it normally does but alternatively you can 450 00:47:52,721 --> 00:48:00,839 also boot from SPI flash which is the Wi-Fi flash and it will only boot firmware 451 00:48:00,839 --> 00:48:08,050 images that are signed and encrypted there's no freaky development backdoor 452 00:48:08,050 --> 00:48:15,420 that we can exploit it also uses two different sets of keys for NAND and non 453 00:48:15,420 --> 00:48:21,390 NAND boot methods and also for our retail and dev mode so even when stuff gets 454 00:48:21,390 --> 00:48:28,150 leaked you cannot use it on your retail console so let's do a small boot walk 455 00:48:28,150 --> 00:48:34,469 through and it's pretty straightforward actually so the first thing it does is it 456 00:48:34,469 --> 00:48:41,869 selects a boot device then it loads the firmware header and RSA signature from it 457 00:48:41,869 --> 00:48:50,959 it's just one block and then it hashes the header and extract the hash from the 458 00:48:50,959 --> 00:48:58,170 signature and compares it, so basically a basic signature verification header 459 00:48:58,170 --> 00:49:04,859 verification and then assumes yeah the header is safe and then it starts loading 460 00:49:04,859 --> 00:49:12,789 the firmware sections and the firmware images are pretty simple format and like 461 00:49:12,789 --> 00:49:19,930 you have some entries in the header that tells you okay take the data from this 462 00:49:19,930 --> 00:49:26,849 offset and there there's a section with the size load it to that address. It's 463 00:49:26,849 --> 00:49:32,729 pretty simple so we know from Nintendos past that they like to mess up RSA 464 00:49:32,729 --> 00:49:42,220 signature checks so let's look as how RSA is done on 3DS so for the 3DS firmware 465 00:49:42,220 --> 00:49:51,630 they're using RSA signatures in the PKCS standard PKCS is basically a bunch of 466 00:49:51,630 --> 00:49:57,500 standards that tell you how your signatures have to look like and they are 467 00:49:57,500 --> 00:50:11,269 using the 2048-bit version of RSA which is safe and in the signature you have a SHA-2 468 00:50:11,269 --> 00:50:19,870 hash and this is encoded using ASN.1 and ASN.1 it's some really complex structure 469 00:50:19,870 --> 00:50:26,009 it's basically it's similar to the mp3 structure so you have little chunks of 470 00:50:26,009 --> 00:50:31,490 data and those chunks have little headers and the headers have tag bytes and length 471 00:50:31,490 --> 00:50:40,900 bytes and basically this ASN.1 stuff is used to tell the parser which hashing 472 00:50:40,900 --> 00:50:51,311 algorithm is used and well since the SHA-2 hash is only 20 hex [0x20] bytes in size 473 00:50:51,311 --> 00:50:57,050 you have some remaining space in the signature that you have to fill and PKCS 474 00:50:57,050 --> 00:51:01,959 says you need a padding and this padding should be deterministic it should only 475 00:51:01,959 --> 00:51:07,950 contain FF bytes so when you're trying to forge signatures it's it's really 476 00:51:07,950 --> 00:51:14,489 difficult because of this padding that really long and when you compare the 477 00:51:14,489 --> 00:51:22,019 signatures of different firmware images you'll actually notice that only the hash 478 00:51:22,019 --> 00:51:28,269 will change and the rest of the data is always the same for all signatures but 479 00:51:28,269 --> 00:51:34,729 well for some reason they decided to write a signature parser for this stuff so what 480 00:51:34,729 --> 00:51:45,860 you get now is RSA the Nintendo way again so the first thing it does is it tries to 481 00:51:45,860 --> 00:51:53,129 parse the padding and this part is totally messed up like there is a flag byte that 482 00:51:53,129 --> 00:51:59,129 tells you if the padding should be checked and if it's one then it is checked it 483 00:51:59,129 --> 00:52:06,910 should be all FF but but if it's two then it will just skip the padding and it also 484 00:52:06,910 --> 00:52:12,809 has some really weak bounds checking it make sure that it will not when it's 485 00:52:12,809 --> 00:52:18,859 passing the padding it make sure that it will not go out of bounds but they forget 486 00:52:18,859 --> 00:52:28,489 to verify that the hash will actually fit in there as well so next thing they do is 487 00:52:28,489 --> 00:52:35,000 parsing this really complicated ASN.1 structure and this process is also really 488 00:52:35,000 --> 00:52:42,770 simplified so we know ASN.1 has some length fields and there's no bounds 489 00:52:42,770 --> 00:52:52,800 checking so eventually it will add the length to the current pointer in the 490 00:52:52,800 --> 00:53:02,300 signature and then they stop parsing and say okay we parsed all the data and now 491 00:53:02,300 --> 00:53:08,950 there should be the hash and yet they are not checking this length and this pointer 492 00:53:08,950 --> 00:53:18,430 is used to do the hash comparison so all in all you can say it only checks a few 493 00:53:18,430 --> 00:53:23,410 bytes in the signature because the padding parser is messed up and also the ASN.1 494 00:53:23,410 --> 00:53:29,249 parser is really simplified so what we can do is we can bruteforce the perfect 495 00:53:29,249 --> 00:53:36,909 signature where the final pointer when it's done parsing the padding and the 496 00:53:36,909 --> 00:53:45,779 ASN.1 data that this final pointer matches the pointer of the calculated hash of 497 00:53:45,779 --> 00:53:57,359 bootrom so what it does then this it does a mem compare [memory compare] with the 498 00:53:57,359 --> 00:54:05,481 calculated hash and the calculated hash like and this never fails, right? So it 499 00:54:05,481 --> 00:54:10,009 will always succeed and this is SIGHAX. 500 00:54:10,009 --> 00:54:18,210 *applause* 501 00:54:18,210 --> 00:54:24,450 So the SIGHAX is a bootrom exploit for 3DS and basically we can sign our own 502 00:54:24,450 --> 00:54:31,279 firmwares and there are over 60 million vulnerable devices and basically in new 503 00:54:31,279 --> 00:54:37,259 3DS and 2DS basically all models are affected and of course since this is the 504 00:54:37,259 --> 00:54:45,709 bootrom, Nintendo can't fix it so that's very nice but that's one heart remaining 505 00:54:45,709 --> 00:54:54,960 so something is missing what we haven't done yet is we haven't dumped the ARM11 506 00:54:54,960 --> 00:55:00,019 bootrom. It's probably not really interesting but for sake of completeness 507 00:55:00,019 --> 00:55:07,759 you would like to get it and in theory we can just do a vector glitch hack again 508 00:55:07,759 --> 00:55:13,369 because it has the same flaw but know that we can sign our own firmwares let's try 509 00:55:13,369 --> 00:55:21,450 something else so if you look at the unprotected part of the ARM11 bootrom you 510 00:55:21,450 --> 00:55:29,059 can see there are a lot of references to ARM11 memory so maybe now that we can sign 511 00:55:29,059 --> 00:55:33,880 our own firmwares and we can set up our own firmware sections maybe we can 512 00:55:33,880 --> 00:55:41,979 overwrite some bootrom data so but they're the bootrom developers were kind of clever 513 00:55:41,979 --> 00:55:49,059 and the ARM9 bootrom checks the firmware sections and they have some kind of 514 00:55:49,059 --> 00:55:58,359 blacklist and unfortunately you can't just overwrite boot9 data sections sections but 515 00:55:58,359 --> 00:56:03,709 for some reason they forgot to blacklist all the boot11 data regions so we can just 516 00:56:03,709 --> 00:56:11,770 overwrite boot11 stack or the exception vectors and well you can dump the ARM11 517 00:56:11,770 --> 00:56:12,990 bootrom. 518 00:56:12,990 --> 00:56:21,989 *applause* 519 00:56:21,989 --> 00:56:29,520 yeah that was pretty easy and now I get to tell you something, all this stuff about 520 00:56:29,520 --> 00:56:38,829 the bootrom we did this in summer 2015 so we could have talked about this already 521 00:56:38,829 --> 00:56:45,880 last year but since we are kind of friendly hackers we held this bug so long 522 00:56:45,880 --> 00:56:56,660 so yeah Nintendo should be thankful and ok so that's it 3DS is pretty game over and 523 00:56:56,660 --> 00:57:02,209 here's a picture of Nintendo Switch and our body is ready *laughter* 524 00:57:02,209 --> 00:57:16,429 *applause* 525 00:57:16,429 --> 00:57:21,499 Herald: Thank you very much there's about five minutes left for questions and are 526 00:57:21,499 --> 00:57:26,749 there any questions from the internet? No no no okay? 527 00:57:26,749 --> 00:57:32,069 Signal Angel: Yes there's actually one question from the internet and that is the 528 00:57:32,069 --> 00:57:41,519 internet wants to know if we can get DSP code execution maybe sometime soon 529 00:57:41,519 --> 00:57:43,000 Herald: Can you repeat the question? 530 00:57:43,000 --> 00:57:44,780 yeah very hard to understand here 531 00:57:44,780 --> 00:57:51,049 Signal Angel: Ok I'm the internet wants to know if we can get a DSP code execution? 532 00:57:51,049 --> 00:58:02,259 derrek: Yes well the DSP of the 3DS runs its own firmware and that is included in 533 00:58:02,259 --> 00:58:10,440 some kernel module and basically when you can sign your own firmware you can also 534 00:58:10,440 --> 00:58:21,519 make it load another DSP firmware so yes you can do this 535 00:58:21,519 --> 00:58:25,369 Herald: Ok people who are leaving please do so quietly and people entering please 536 00:58:25,369 --> 00:58:35,369 do so quietly. There was a question on microphone 3 I think but no longer okay. 537 00:58:35,369 --> 00:58:38,260 Does the internet have more questions? 538 00:58:38,260 --> 00:58:44,009 Signal Angel: Yes it does. The internet wants to know if you or how you glitch the 539 00:58:44,009 --> 00:58:48,599 Wii U to get execution 540 00:58:48,599 --> 00:58:56,729 derrek: Well I don't want to worry how I did it in detail but there are some basic 541 00:58:56,729 --> 00:59:04,660 fault injection attacks and my setup was I think kind of complicated you had to 542 00:59:04,660 --> 00:59:11,490 modify a lot of stuff on the Wii U mainboard to get it to work so I guess you 543 00:59:11,490 --> 00:59:17,260 have to figure out yourself, sorry. 544 00:59:17,260 --> 00:59:21,109 Herald: Ok there's a question upstairs microphone five I think? 545 00:59:21,109 --> 00:59:29,920 Mic 7: Seven but it's okay. Yeah well you said that you broke all the 2DS but 546 00:59:29,920 --> 00:59:36,880 actually you showed that the 2DS changed in the boot process so did you verify that 547 00:59:36,880 --> 00:59:40,500 that work for the first version as well 548 00:59:40,500 --> 00:59:47,160 derrek: Yes so the new 3DS was released after the 2DS and the new 3DS is also 549 00:59:47,160 --> 00:59:54,900 vulnerable and basically all the Nintendo 2DS consoles are also also vulnerable as 550 00:59:54,900 --> 01:00:01,140 well. Yes we did verify this and we don't really know what this FCC document is 551 01:00:01,140 --> 01:00:12,019 about we got some really new 2DS from store and and basically yes, no difference 552 01:00:12,019 --> 01:00:16,179 for the bootrom at all, so yes everything is vulnerable. 553 01:00:16,179 --> 01:00:18,169 Mic 7: Nice to know, thanks. 554 01:00:18,169 --> 01:00:23,470 derrek: ok *applause* 555 01:00:23,470 --> 01:00:25,650 Herald: Final question from microphone 3? 556 01:00:25,650 --> 01:00:29,390 Mic 3: Yeah just a fun question out of interest when you're going to buy such a 557 01:00:29,390 --> 01:00:33,880 device do you also plan to play games on it? Or is it just going to check if the 558 01:00:33,880 --> 01:00:38,730 other kernel works? 559 01:00:38,730 --> 01:00:42,549 naehrwert: Personally for the Wii U, I own 0 games so 560 01:00:42,549 --> 01:00:44,199 Mic 3: Great, thanks. 561 01:00:44,199 --> 01:00:49,519 *applause* 562 01:00:49,519 --> 01:00:55,979 I also didn't pirate any so i never played a game on my Wii U. 563 01:00:55,979 --> 01:01:19,701 *33c3 postroll music*