0:00:00.320,0:00:09.500
32C3 preroll music
0:00:09.500,0:00:16.240
Herald: Okay, welcome to our[br]last talk in this hall today!
0:00:16.240,0:00:20.420
It’s about Console Hacking and I guess[br]that’s the reason why you are here.
0:00:20.420,0:00:23.509
Console hacking has a long[br]tradition at our great conference
0:00:23.509,0:00:30.109
and we have seen lots of funny things.[br]People doing stuff with Xboxes,
0:00:30.109,0:00:33.900
Playstations and everything.
0:00:33.900,0:00:39.010
Okay. Today we got a team which[br]deals with the Nintendo DS,
0:00:39.010,0:00:44.260
so give a warm applause[br]for plutoo, derrek and smea!
0:00:44.260,0:00:53.770
applause
0:00:53.770,0:00:58.910
smea: Hi! I’m smea,[br]this is plutoo, this is derrek,
0:00:58.910,0:01:02.930
and today we are going to talk to you[br]about our work on the Nintendo 3DS.
0:01:02.930,0:01:05.390
So, the way this talk is going to be[br]structured, is we are just going to
0:01:05.390,0:01:08.850
go over all the hardware,[br]organisation, software, like…
0:01:08.850,0:01:12.240
Just give you a basic overview[br]about how the system works.
0:01:12.240,0:01:15.040
And after that we are going to go into
0:01:15.040,0:01:18.330
basically every layer of[br]security the system has,
0:01:18.330,0:01:21.269
and break every one of them.
0:01:21.269,0:01:23.219
laughter
0:01:23.219,0:01:27.550
applause
0:01:27.550,0:01:31.860
Okay. So, as you probably know,[br]the 3DS, the original Nintendo 3DS
0:01:31.860,0:01:36.500
was released in 2011. It’s a system[br]that is kind of underpowered.
0:01:36.500,0:01:41.479
It’s got, like… It’s got an[br]ARM11 dual core CPU,
0:01:41.479,0:01:46.399
268Mhz, it’s got a nice[br]proprietary GPU, a bit of RAM,
0:01:46.399,0:01:49.920
you know, the usual. It’s also backwards[br]compatible with the DS games,
0:01:49.920,0:01:55.299
which is nice. Then the new 3DS[br]was released in 2014 and 2015,
0:01:55.299,0:02:01.060
there was like different regions. And it[br]was basically just the same console,
0:02:01.060,0:02:04.239
just some improvements in the[br]hardware. You’ve got a better CPU,
0:02:04.239,0:02:09.410
it has got more cores. It’s faster, it has[br]got more RAM. Basically everywhere.
0:02:09.410,0:02:12.240
So, it is just the same thing,[br]it runs the same software, exactly.
0:02:12.240,0:02:15.800
It has got some exclusive[br]software, but not much.
0:02:15.800,0:02:19.460
So, in terms of a hardware overview, this[br]is what what we are going to talk about
0:02:19.460,0:02:24.050
looks like; in general. So you[br]got the top part right here,
0:02:24.050,0:02:27.490
which is what we are[br]going to go into first.
0:02:27.490,0:02:31.470
This is like the ARM11 part.
0:02:31.470,0:02:35.110
Basically, you’ve got the ARM11,[br]which is the main CPU. It runs
0:02:35.110,0:02:40.740
the main operating system. It has[br]2 cores as I just said, or 4 cores.
0:02:40.740,0:02:42.790
So, it runs the main operating[br]system, it runs the games,
0:02:42.790,0:02:45.340
it runs all the applications.[br]Basically, it’s just –
0:02:45.340,0:02:48.380
if you’re doing something on the 3DS[br]that you can… you can see it happening,
0:02:48.380,0:02:52.220
it’s happening on that CPU. It has got[br]access to all of the main memory.
0:02:52.220,0:02:56.090
So that includes FCRAM,
0:02:56.090,0:03:01.040
which is 128MB or 256MB,
0:03:01.040,0:03:04.730
depending on which model it is.[br]And FCRAM is actually divided
0:03:04.730,0:03:09.130
into 3 separate regions. So you[br]first got the Application Region,
0:03:09.130,0:03:12.520
which contains the currently[br]running game or application.
0:03:12.520,0:03:17.200
The System Region, which contains applets,[br]which are basically tiny applications,
0:03:17.200,0:03:20.050
which run in the background.[br]So, that includes the home menu,
0:03:20.050,0:03:23.390
which is actually always running[br]in background, and the web browser,
0:03:23.390,0:03:25.890
which you can actually run at[br]the same time as your game, so
0:03:25.890,0:03:28.860
it has to run there. And then you got the[br]Base Region, which is more interesting.
0:03:28.860,0:03:31.050
It contains all the system modules[br]of the operating system,
0:03:31.050,0:03:35.260
as well as some kernel data,[br]such as handle tables
0:03:35.260,0:03:39.840
and MMU tables. So it is kind of sensitive[br]stuff. And then we got a WRAM,
0:03:39.840,0:03:44.330
which is tiny and contains all[br]the kernel code, and, well,
0:03:44.330,0:03:49.550
most of the kernel structures as well.[br]So it’s also an interesting target.
0:03:49.550,0:03:55.160
Then we’ve got the lower part, which[br]is the ARM9 part of the hardware.
0:03:55.160,0:03:58.270
So the ARM9 is basically a separate, well…
0:03:58.270,0:04:02.790
it’s an entirely separate CPU,[br]which has access to…
0:04:02.790,0:04:06.760
well… So it runs basically the[br]same microkernel as the ARM11.
0:04:06.760,0:04:11.600
It’s mostly the same code,[br]it has just got some pure features.
0:04:11.600,0:04:14.630
Mostly it runs a single process,[br]which is called ‘Process9’,
0:04:14.630,0:04:19.399
which does everything the ARM9 does.[br]Beyond that the role of the ARM9 is
0:04:19.399,0:04:24.260
to broker access to hardware that[br]might be sensitive in terms of security.
0:04:24.260,0:04:29.320
So one of the things it does is it[br]brokers access to all storage media,
0:04:29.320,0:04:33.590
so that includes the permanent[br]storage as well as the SD card.
0:04:33.590,0:04:38.450
And then it does all sorts of crypto[br]stuff, which is really important,
0:04:38.450,0:04:43.930
and does that by using hardware, actually.[br]So there is this hardware key scrambler,
0:04:43.930,0:04:48.260
which is used to.. to store[br]secrets in hardware basically.
0:04:48.260,0:04:51.100
The idea is, you feed[br]it two separate keys,
0:04:51.100,0:04:54.980
and it is going to generate a[br]normal key and feed that directly
0:04:54.980,0:04:59.260
into the hardware implementation[br]of the AES algorithm.
0:04:59.260,0:05:02.340
So that way, we never[br]actually see the final keys.
0:05:02.340,0:05:06.430
So that’s something that[br]is kind of annoying.
0:05:06.430,0:05:10.100
And then beyond that what you can see is:[br]the ARM9 has access to all of main memory
0:05:10.100,0:05:13.890
without much of, well, without any[br]restrictions. But it has also got
0:05:13.890,0:05:17.790
its own internal memory which the[br]ARM11 does not have access to.
0:05:17.790,0:05:21.350
So the ARM9 internal memory is[br]where the ARM9 stores all its code,
0:05:21.350,0:05:26.600
all of its data; and this way we[br]can’t actually take over the ARM9
0:05:26.600,0:05:33.340
just from the ARM11 without some kind of[br]exploit. So it’s basically a security CPU.
0:05:33.340,0:05:36.730
So this leads us to having[br]4 layers of security.
0:05:36.730,0:05:39.940
Basically, you’re first going to have[br]the ARM11 userland, which is what…
0:05:39.940,0:05:43.550
well, like your games, your applications,[br]whatever. On top of that,
0:05:43.550,0:05:48.630
you’re going to have, well, below[br]that, I guess, the ARM11 kernel.
0:05:48.630,0:05:51.810
So that is going to have[br]full privileges on the ARM11.
0:05:51.810,0:05:55.300
And then you’re going to have[br]ARM9 userland, which is ‘Process9’.
0:05:55.300,0:05:59.560
Beyond that you’ll have ARM9[br]kernel mode. So that’s in theory.
0:05:59.560,0:06:04.380
In practice, the microkernel[br]has a system call,
0:06:04.380,0:06:09.280
which we call… syscall…[br]we call it ‘svc backdoor’.
0:06:09.280,0:06:13.510
Because essentially you feed it a[br]function pointer and it just executes
0:06:13.510,0:06:16.970
that function in kernel mode.[br]So you don’t even need an exploit
0:06:16.970,0:06:20.889
if you have access to that syscall.[br]Of course, on the ARM11
0:06:20.889,0:06:25.300
no application or title or anything[br]ever has access to that,
0:06:25.300,0:06:29.560
but on the ARM9 ‘Process9’ actually[br]has access to it. Which means,
0:06:29.560,0:06:34.050
that from here we actually…[br]well, userland and kernel mode
0:06:34.050,0:06:37.770
are basically the same thing.[br]When you got userland on the ARM9,
0:06:37.770,0:06:41.020
you got kernel mode.[br]So that’s nice.
0:06:41.020,0:06:44.950
Beyond that, in terms of[br]cryptography on the system,
0:06:44.950,0:06:49.030
basically, they went out loud (?). So, anything[br]that can be signed, is signed.
0:06:49.030,0:06:51.570
So, that includes the firmware,[br]that includes every application.
0:06:51.570,0:06:55.480
Signatures are checked not only[br]at install time but also at runtime,
0:06:55.480,0:06:58.750
so that’s something to keep in mind.
0:06:58.750,0:07:02.889
Same thing: anything that can[br]be encrypted is encrypted.
0:07:02.889,0:07:07.650
And anything that can be made, well,[br]console-specific through cryptography
0:07:07.650,0:07:13.270
or authentication, such as[br]internal permanent storage
0:07:13.270,0:07:17.510
or the data that is stored on[br]the SD card, or savegames,
0:07:17.510,0:07:22.740
or extra data for games, this[br]is all made console-specific.
0:07:22.740,0:07:26.510
And gamecard-specific in[br]regards of savegames.
0:07:26.510,0:07:31.470
So, that’s kind of annoying as well. And,[br]of course, all this is handled by the ARM9
0:07:31.470,0:07:35.590
using the hardware… the crypto[br]hardware, so we got to get through that
0:07:35.590,0:07:38.190
if we want to do interesting things.
0:07:38.190,0:07:43.860
So, first we are going to go through the[br]first layer, which is the ARM11 userland.
0:07:43.860,0:07:47.320
Basically, getting a full[br]hold onto the system.
0:07:47.320,0:07:51.370
So, we first need to find[br]some kind of entry point.
0:07:51.370,0:07:55.780
There are problems… well,[br]there are challenges there.
0:07:55.780,0:07:59.760
One of the challenges is[br]that the system implements
0:07:59.760,0:08:05.080
strict Data Execution Prevention. So,[br]existing pages will never be read…
0:08:05.080,0:08:09.290
well, will never be read-write-executable.[br]It’s all only going to be read-only,
0:08:09.290,0:08:13.480
or read-writable or read-executable.[br]There’s no way from a standard application
0:08:13.480,0:08:18.079
to reprotect or map new pages[br]that are read-write-executable.
0:08:18.079,0:08:22.180
Because all of the system[br]calls are locked out, except for
0:08:22.180,0:08:26.400
higher privileged system[br]modules. Another thing is
0:08:26.400,0:08:29.840
that there is no ASLR, so that is not[br]a challenge, that’s actually kind of nice.
0:08:29.840,0:08:34.020
The nice thing here is that we… well,[br]that makes savegame vulnerabilities
0:08:34.020,0:08:37.010
totally fair game because, well, we don’t[br]need an actual scripting environment
0:08:37.010,0:08:40.640
or any kind of exotic[br]vulnerability to exploit this.
0:08:40.640,0:08:44.930
As long as we can get past[br]DEP somehow. And then,
0:08:44.930,0:08:48.990
of course, the fact that all[br]savegames are both encrypted
0:08:48.990,0:08:52.960
and made specific either to the[br]gamecard or the game console,
0:08:52.960,0:08:57.630
in the case of eShop games, is really[br]annoying for savegame vulnerabilities
0:08:57.630,0:09:01.450
because basically you can’t use those[br]as an initial entry point in most cases,
0:09:01.450,0:09:05.460
because, well, you can’t generate[br]the right, well, ES MAC,
0:09:05.460,0:09:12.160
or just… you don’t know the right[br]cryptography. So, that’s annoying.
0:09:12.160,0:09:15.300
Thankfully, the 3DS runs Webkit…
0:09:15.300,0:09:18.470
laughter
0:09:18.470,0:09:21.780
So, that’s nice.[br]Can always use that.
0:09:21.780,0:09:26.400
applause
0:09:26.400,0:09:29.690
So, Webkit is used in a number of places,[br]obviously it’s using the main web browser,
0:09:29.690,0:09:32.810
which you can access from the home menu.[br]It’s also used in the Youtube application,
0:09:32.810,0:09:37.210
which is available free on the eShop[br]and doesn’t use any kind of
0:09:37.210,0:09:41.180
client side authentication for the server,[br]so you can just redirect traffic through,
0:09:41.180,0:09:46.589
like a DNS server for example. Miiverse[br]applet, other stuff, that also uses it.
0:09:46.589,0:09:50.870
Slightly more secure, but might be[br]usable at some point, I don’t know.
0:09:50.870,0:09:54.900
Anywho, the important part here,[br]is that it’s not only using webkit,
0:09:54.900,0:09:59.310
it is using a very old version of webkit.[br]Basically, they do cherrypick
0:09:59.310,0:10:03.290
some patches into the version[br]of webkit they use, but only
0:10:03.290,0:10:10.040
after we exploit those on release, so it[br]comes a little too late, most of the time.
0:10:10.040,0:10:15.690
So yeah, this has been used by multiple[br]people, most notably yellows8,
0:10:15.690,0:10:21.580
but it has proven to be a very[br]efficient, reliable entry point.
0:10:21.580,0:10:25.690
Beyond that, we got Cubic Ninja as initial[br]entry point. Cubic Ninja is a game
0:10:25.690,0:10:30.020
that was released in 2011 on Nintendo[br]3DS. It is nice, because it actually
0:10:30.020,0:10:34.350
allows users to share levels[br]that they make themselves
0:10:34.350,0:10:40.850
through QR codes; and also it is[br]really bad at parsing those levels.
0:10:40.850,0:10:44.910
So what you can do, is just, well,[br]manufacture your own QR code
0:10:44.910,0:10:47.740
that is going to crash the game[br]and give you access. So these are
0:10:47.740,0:10:52.529
nice initial entry points. So, once we’ve[br]got this, what we have to remember is
0:10:52.529,0:10:56.020
that we might be able to crash the game[br]and may be able to control registers,
0:10:56.020,0:11:00.550
but we don’t actually have our code[br]running because of that. So,
0:11:00.550,0:11:04.200
the obvious solution to[br]hit this, is to use ROP.
0:11:04.200,0:11:07.770
For those of you, who are[br]not familiar with ROP:
0:11:07.770,0:11:11.730
You build your own fake stack[br]that lets you return into
0:11:11.730,0:11:15.899
code snippets that are located right[br]before return instructions. That way…
0:11:15.899,0:11:20.750
so this is an example. You can just
0:11:20.750,0:11:24.779
jump to this kind of instruction,[br]so ‘pop {r0, pc}’ and then
0:11:24.779,0:11:29.220
this is going to let you load your own[br]register value and then it is going to
0:11:29.220,0:11:33.870
jump to the next instruction that you give[br]it. So, this is a way of executing code
0:11:33.870,0:11:37.580
without actually executing code,[br]which is widely used; so this is like
0:11:37.580,0:11:42.080
the obvious thing to do. Of course,[br]ROP is annoying. It is very limiting.
0:11:42.080,0:11:47.560
It can be enough to actually execute[br]an exploit to get higher privileges,
0:11:47.560,0:11:53.149
but overall it is just annoying and very[br]limiting for homebrew, for example.
0:11:53.149,0:11:56.000
And of course, as I mentioned earlier, we[br]don’t have access to any of the system calls
0:11:56.000,0:12:01.010
that would let us map[br]read-writable-executable pages.
0:12:01.010,0:12:04.850
Also, the system does support dynamically[br]linked libraries, so that might be a way,
0:12:04.850,0:12:09.560
but these are signed and checked in[br]places that we can’t access at this point.
0:12:09.560,0:12:13.959
So, what we’re going to look[br]at next is the GPU to see
0:12:13.959,0:12:19.070
if we use that to bypass that.[br]What you can see here is that
0:12:19.070,0:12:23.220
the GPU has access not only to[br]video RAM, but also to FCRAM,
0:12:23.220,0:12:26.420
which is, if you recall it, main[br]memory. So, if you look at this,
0:12:26.420,0:12:30.540
with all the different memory regions,
0:12:30.540,0:12:33.480
we have got the Application Region[br]here, which is entirely contained within
0:12:33.480,0:12:38.700
what the GPU can access within FCRAM.[br]Of course, the GPU can not actually access
0:12:38.700,0:12:42.790
all of that FCRAM, so that is kind[br]of limiting. What we can see here,
0:12:42.790,0:12:49.279
is that, of course, application code is[br]within range of the GPU’s level of access.
0:12:49.279,0:12:53.250
The reason the GPU has access to[br]FCRAM and Video RAM, through DMA,
0:12:53.250,0:12:58.209
by the way, is, so that it can access[br]information such as textures,
0:12:58.209,0:13:01.030
vertex buffers, this sort of thing.
0:13:01.030,0:13:04.240
So, it’s actually kind of important. And[br]the reason it can write to it is because
0:13:04.240,0:13:08.730
it has to render its data somewhere.[br]The point is, that we can use this
0:13:08.730,0:13:12.050
to render data into main memory.
0:13:12.050,0:13:16.490
And main memory contains application[br]code. And since the physical layout is
0:13:16.490,0:13:20.200
actually completely deterministic, and[br]even if it wasn’t, we could just use the
0:13:20.200,0:13:23.580
read capabilities of the GPU to[br]search for what we are looking for.
0:13:23.580,0:13:27.970
Well, we can use this to overwrite our[br]current application’s text section
0:13:27.970,0:13:32.610
and we get code execution[br]that way, in spite of DEP.
0:13:32.610,0:13:34.440
Yeah, so this is where[br]we get code execution…
0:13:34.440,0:13:35.280
applause
0:13:35.280,0:13:37.779
We execute our own,[br]unsigned code, which is very…
0:13:37.779,0:13:39.830
applause
0:13:39.830,0:13:44.520
It’s great, but we are still confined[br]within the application sandbox.
0:13:44.520,0:13:47.450
So, we bypassed DEP,[br]we are inside the sandbox.
0:13:47.450,0:13:53.140
This means we can only access[br]our current application’s savedata,
0:13:53.140,0:13:58.120
so if we want to install some kind of[br]secondary exploit, this is too limiting.
0:13:58.120,0:14:02.190
We can only access certain services and[br]system calls, which is also limiting
0:14:02.190,0:14:06.200
and frustrating. And we can’t alter[br]memory layout, so we can’t allocate
0:14:06.200,0:14:08.769
more executable pages[br]than I mentioned earlier.
0:14:08.769,0:14:10.779
So, we are still kind[br]of limited at this point.
0:14:10.779,0:14:14.680
So, what we are going to do, is look at[br]what else the GPU can access.
0:14:14.680,0:14:18.630
And you can see, is that, of course, there[br]is this entirely separate memory region
0:14:18.630,0:14:21.780
the GPU can modify.
0:14:21.780,0:14:24.860
So it can access most of the System[br]Region. And the System Region contains
0:14:24.860,0:14:27.510
a few things. It contains the home menu, as[br]I mentioned, because that is an applet.
0:14:27.510,0:14:31.500
It contains the internet browser, and it[br]contains actually a single system module,
0:14:31.500,0:14:38.020
which is called ‘NS’, which we think stands[br]for ‘Nintendo Shell’, we don’t really know.
0:14:38.020,0:14:42.810
So, let’s look at this. First we got[br]NS code well beyond the GPU cutoff.
0:14:42.810,0:14:46.110
We got menu code, which is[br]also well beyond GPU cutoff.
0:14:46.110,0:14:51.310
But we got the menu’s heap, right here,[br]well, actually there is separate heaps,
0:14:51.310,0:14:55.089
these are well within the[br]GPU’s range, so that’s good.
0:14:55.089,0:14:59.830
NS unfortunately is still well beyond the[br]cutoff. All of its data, all of its code.
0:14:59.830,0:15:03.059
So we apparently can’t get to that.
0:15:03.059,0:15:07.830
So, then the idea is, to just,[br]well, okay, so actually…
0:15:07.830,0:15:11.029
What’s interesting here, is that[br]the cutoff is right before the end of
0:15:11.029,0:15:14.200
the System Region, which as we just[br]saw, has some interesting things, but
0:15:14.200,0:15:18.680
also excludes all of Base Region,[br]which also has very interesting things.
0:15:18.680,0:15:23.670
So, it seems likely that Nintendo knew[br]about the capabilities of GPU DMA,
0:15:23.670,0:15:27.480
like the theoretical capabilities, but[br]they didn’t do anything about it.
0:15:27.480,0:15:30.899
So, it seems that they probably didn’t[br]realize what we could do with it,
0:15:30.899,0:15:33.220
which is a lot.
0:15:33.220,0:15:37.630
So, basically, we got menu heaps. So[br]what we do, is… we have a heap, and
0:15:37.630,0:15:42.399
this is all C++ code. We are just[br]going to find objects inside the heap
0:15:42.399,0:15:46.790
and overwrite it. So it’s pretty simple.[br]Just find an object, that is going to be
0:15:46.790,0:15:50.300
triggered to some kind of synchronisation[br]mechanism. In this case, it’s gonna be
0:15:50.300,0:15:55.010
just ‘Return to Menu’. And we[br]create some kind of vague vtable
0:15:55.010,0:15:59.560
and get it to run our own[br]stack pivot. And then we get…
0:15:59.560,0:16:03.300
we get ROP execution under[br]Home menu, which is cool.
0:16:03.300,0:16:07.060
We still don’t have code execution[br]in the Home menu, but that’s okay.
0:16:07.060,0:16:10.630
So, we can do a bunch of stuff from ROP.
0:16:10.630,0:16:16.180
We can access a new system[br]service, which is called ‘ns:s’,
0:16:16.180,0:16:19.890
which is very helpful, because it can[br]kill any arbitrary process, as well as
0:16:19.890,0:16:24.930
create new ones. Also it gives us access[br]to SD card, which most applications
0:16:24.930,0:16:29.690
actually don’t have. And it lets us[br]decrypt/dump any title on the system.
0:16:29.690,0:16:34.300
So any game, even if it uses new[br]cryptography that Nintendo introduced,
0:16:34.300,0:16:38.230
we can actually dump that, because[br]for some reason, well, Home menu
0:16:38.230,0:16:41.890
apparently needs access to[br]that. And then we can also
0:16:41.890,0:16:47.490
access and overwrite all that extra data[br]used by any application, which is great.
0:16:47.490,0:16:50.380
So we use this as a base[br]for running homebrew.
0:16:50.380,0:16:54.920
Our homebrew launcher is[br]essentially just a service
0:16:54.920,0:16:58.810
that runs in the background under Home[br]menu process. It is written in ROP,
0:16:58.810,0:17:02.370
which is kind of disgusting, but it works.[br]laughter
0:17:02.370,0:17:05.999
The ‘Service’ handles running homebrew,[br]so the process is very simple. You just
0:17:05.999,0:17:09.358
kill off the current application, you[br]spawn a new one, and then you take it over
0:17:09.358,0:17:15.019
using the GPU DMA access.[br]And then, what we do is
0:17:15.019,0:17:19.489
we send all of these new capabilities that[br]we got through handles to the new process
0:17:19.489,0:17:23.558
and that gives us some[br]higher privilege homebrew.
0:17:23.558,0:17:30.190
It also handles events, such as Home[br]button, Power button, all that good stuff.
0:17:30.190,0:17:33.749
Which is nice, because we can actually[br]run code under any arbitrary application
0:17:33.749,0:17:37.929
or game, so we can actually modify[br]these games. We can run ROM hacks.
0:17:37.929,0:17:41.179
So there has been a bunch of translations[br]that can be run through this, for games
0:17:41.179,0:17:44.469
that haven’t come out outside[br]of Japan, so that’s pretty nice.
0:17:44.469,0:17:46.889
It’s the same principle, you just[br]launch the app, you take it over,
0:17:46.889,0:17:50.769
you pass the code, and then[br]you jump to it, essentially.
0:17:50.769,0:17:53.959
All within the confines of[br]userland, which is nice.
0:17:53.959,0:17:59.600
So, the other thing is, we can actually[br]access any game or application’s data
0:17:59.600,0:18:03.460
because we can run code under[br]it. So, these things include
0:18:03.460,0:18:07.970
savegame data for any game. So we[br]can actually install more convenient
0:18:07.970,0:18:11.980
secondary entry points, which do not[br]rely on the browser, which can be
0:18:11.980,0:18:15.749
patched any moment, or on some old game.
0:18:15.749,0:18:21.019
So, some examples include ‘Menuhax’[br]by yellows8, which exploits
0:18:21.019,0:18:27.539
faulty theme handling code, which[br]was introduced in firmware 9.0.
0:18:27.539,0:18:30.519
Which is really nice, because this way,[br]you can actually just run homebrew
0:18:30.519,0:18:35.359
right as Home menu is opened,[br]so right on boot time,
0:18:35.359,0:18:38.929
which is great. Then you got other games.[br]Of course you got a Zelda game
0:18:38.929,0:18:41.619
that’s vulnerable.[br]audience chuckles
0:18:41.619,0:18:44.549
This time it wasn’t the[br]horse’s name, but pretty similar.
0:18:44.549,0:18:48.389
And then you got other games. We[br]got tons of entry points at this point.
0:18:48.389,0:18:54.999
We’re really, literally drowning[br]in them. So, this is nice.
0:18:54.999,0:18:58.749
But we forgot about ‘Nintendo Shell’,[br]right? It’s a very attractive target,
0:18:58.749,0:19:03.090
for a couple of reasons. For one thing,[br]it has access the ‘am:u’ service,
0:19:03.090,0:19:05.929
which can be used to[br]downgrade any system title.
0:19:05.929,0:19:09.600
It’s not actually designed to downgrade[br]titles, the thing is, you can both
0:19:09.600,0:19:13.200
install and uninstall titles.[br]So, what happens is,
0:19:13.200,0:19:16.639
if you uninstall a title, and[br]then install an older version
0:19:16.639,0:19:19.210
of that title, you actually[br]bypass the version check.
0:19:19.210,0:19:22.210
So, you can just do that to[br]downgrade any system title
0:19:22.210,0:19:27.699
and bring back old exploits,[br]if that is necessary.
0:19:27.699,0:19:30.320
Assuming you have[br]access to the service.
0:19:30.320,0:19:32.679
And of course it’s in a region[br]that we can partially modify,
0:19:32.679,0:19:35.989
so it’s an interesting target.
0:19:35.989,0:19:38.769
Unfortunately, we can’t actually[br]access its data right now.
0:19:38.769,0:19:42.489
But maybe we can actually move[br]it to somewhere, where we can.
0:19:42.489,0:19:47.830
The idea is, if you were to kill NS, and[br]then allocate something in it’s place,
0:19:47.830,0:19:52.129
then run NS again, you can[br]move it below the cutoff.
0:19:52.129,0:19:54.519
laughter
0:19:54.519,0:20:01.809
applause
0:20:01.809,0:20:06.369
Thanks. But unfortunately[br]it’s not that simple. That can’t work.
0:20:06.369,0:20:10.790
The reason being, that we actually need[br]NS to be running to launch NS again.
0:20:10.790,0:20:13.369
So that kind of sucks.
0:20:13.369,0:20:15.820
But… well, no.[br]Actually we also can’t run
0:20:15.820,0:20:17.960
a second instance of NS at the same time,
0:20:17.960,0:20:20.369
so we can’t do that either.
0:20:20.369,0:20:23.559
But interestingly…[br]Well, the 3DS has an interesting feature,
0:20:23.559,0:20:28.200
which is called ‘Safe Mode’. Basically[br]it’s a second firmware, which is
0:20:28.200,0:20:32.649
an old version of the[br]regular one, and that
0:20:32.649,0:20:37.070
creates a bunch of[br]copies of system titles.
0:20:37.070,0:20:41.499
Most of them, anyways. So that gives[br]it a different ID. So, the idea is,
0:20:41.499,0:20:44.249
that if it has got a different ID, we[br]might be able to run it at the same time,
0:20:44.249,0:20:48.129
because, well, PM might fail[br]to notice that. Of course it doesn’t.
0:20:48.129,0:20:51.889
It actually does notice that. So we can’t[br]run the Safe Mode version of a title
0:20:51.889,0:20:54.830
at the sime time as the regular[br]version of the title. But,
0:20:54.830,0:20:59.960
for some reason, in the case of NS – you[br]might not be able to see this very well,
0:20:59.960,0:21:04.669
but we’ve got NS’s regular title right[br]here, and then we got Safe Mode NS
0:21:04.669,0:21:07.100
right here. And for some reason[br]they created a new 3DS version
0:21:07.100,0:21:12.070
of the Safe Mode version of NS,[br]though there is no new 3DS version
0:21:12.070,0:21:16.440
of the original NS. So that[br]creates a separate title ID
0:21:16.440,0:21:20.340
which we can run at the same time[br]as regular NS. So then, the exploit
0:21:20.340,0:21:25.059
becomes very simple. You keep NS running,[br]just allocate enough data, that it will be
0:21:25.059,0:21:29.440
below the cutoff; and then you[br]just run new 3DS Safe Mode NS.
0:21:29.440,0:21:33.239
And then it’s within range of the GPU[br]and you can take it over and have
0:21:33.239,0:21:36.979
access to everything. So, this is nice.
0:21:36.979,0:21:43.509
It’s more of an oversight than[br]a proper exploit, but whatever.
0:21:43.509,0:21:46.399
So this gives us access to a[br]bunch of system calls. Mostly
0:21:46.399,0:21:50.909
service handling system calls,[br]so we can post our own service,
0:21:50.909,0:21:54.639
which can be useful for other[br]exploits that I won’t get into, for
0:21:54.639,0:21:59.190
impersonating other services[br]to other system modules.
0:21:59.190,0:22:02.570
And then we got access to all of[br]these services, which is great.
0:22:02.570,0:22:06.559
So we can downgrade[br]system titles arbitrarily.
0:22:06.559,0:22:10.529
And this runs in background, which[br]can always be helpful for homebrew.
0:22:10.529,0:22:14.210
The only problem is at this point,[br]it’s still new 3DS only, because
0:22:14.210,0:22:20.519
it relies on this new 3DS title. But[br]there are actually ways around that.
0:22:20.519,0:22:24.269
This was just to show that we can actually[br]get fairly high levels of privilege,
0:22:24.269,0:22:28.759
even still just always staying[br]in userland on the ARM11.
0:22:28.759,0:22:32.199
And there are other, similar attacks to[br]that. If you’re interested you can look up
0:22:32.199,0:22:36.489
‘rohax’, which is a similar[br]attack in the system module.
0:22:36.489,0:22:41.229
So, now derrek is going to talk to you[br]about exploiting the ARM11 kernel.
0:22:41.229,0:22:52.279
derrek?[br]applause
0:22:52.279,0:22:55.319
derrek: So, hi everyone!
0:22:55.319,0:22:59.530
First, I will give you some[br]very short inside view
0:22:59.530,0:23:05.059
of the kernel, and then I will[br]explain how you can exploit
0:23:05.059,0:23:09.269
the latest version of the ARM11 kernel.
0:23:09.269,0:23:12.190
So,
0:23:12.190,0:23:16.199
this is actually Nintendo’s very[br]first gaming console kernel.
0:23:16.199,0:23:20.679
Like on any other older console,
0:23:20.679,0:23:26.200
there was no kernel. All games[br]were just running on bare metal.
0:23:26.200,0:23:31.499
Like there was a kernel for the Wii,
0:23:31.499,0:23:36.209
like a very small microkernel[br]running on the security processor,
0:23:36.209,0:23:41.039
but that wasn’t written by Nintendo.
0:23:41.039,0:23:44.830
So it’s their very first[br]gaming console kernel.
0:23:44.830,0:23:50.789
That kernel is made to be thread safe,
0:23:50.789,0:23:54.830
so it can run on multiple cores
0:23:54.830,0:23:58.679
at the same time and there are like
0:23:58.679,0:24:02.659
130 system calls available.
0:24:02.659,0:24:07.349
So that’s quite a lot, in my opinion.
0:24:07.349,0:24:12.309
But usually, if you have gained execution
0:24:12.309,0:24:16.999
in ARM11 userland, you[br]only have access to, like,
0:24:16.999,0:24:22.049
around 50 system calls.
0:24:22.049,0:24:27.019
And there’s a reason for that, but I’m[br]going to explain that in a second.
0:24:27.019,0:24:34.210
So, internally, the kernel[br]works with C++ objects.
0:24:34.210,0:24:38.029
So here are some examples[br]for system calls. So, we have
0:24:38.029,0:24:43.539
‘CreateSemaphore’, for[br]example. That will just create
0:24:43.539,0:24:47.259
a semaphore object in the kernel
0:24:47.259,0:24:52.109
and it will return a[br]handle to the userland.
0:24:52.109,0:24:55.940
And when you want to do any operations
0:24:55.940,0:24:59.879
on that semaphore, you[br]have to pass that handle
0:24:59.879,0:25:04.720
to the kernel, and it will look up[br]this handle in a handle table
0:25:04.720,0:25:10.919
to find the original C++ object.
0:25:10.919,0:25:15.710
Also there are 2 different[br]kinds of memory allocators.
0:25:15.710,0:25:19.299
So, we have a memory allocator[br]for the main memory, which is
0:25:19.299,0:25:25.039
the FCRAM. And there is also a Slab Heap,
0:25:25.039,0:25:29.869
where all the C++ objects are stored in.
0:25:29.869,0:25:35.239
And this Slab Heap is located in FCRAM,
0:25:35.239,0:25:39.339
which is the ARM11 memory,
0:25:39.339,0:25:43.659
where all the kernel code and data is in.
0:25:43.659,0:25:50.450
Also, there’s an IPC system.
0:25:50.450,0:25:53.680
IPC is ‘inter process communication’.
0:25:53.680,0:26:05.149
And it basically allows you[br]to talk to other processes
0:26:05.149,0:26:08.269
like services,
0:26:08.269,0:26:17.270
e.g. the GSP service or FS.
0:26:17.270,0:26:21.939
So, let’s look at the security.
0:26:21.939,0:26:28.779
So, the kernel is really small.[br]There are only like 200KB of code,
0:26:28.779,0:26:34.649
which is pure ARM code. And[br]there are only like 1000 functions.
0:26:34.649,0:26:39.659
So, they try to keep[br]the code size very low
0:26:39.659,0:26:46.720
and that makes it harder to find bugs.
0:26:46.720,0:26:51.999
The code size is really small, and
0:26:51.999,0:26:57.349
you don’t have really much to choose from
0:26:57.349,0:27:03.690
what to exploit. Also there are no[br]symbols included in the kernel.
0:27:03.690,0:27:11.629
Like when you run strings on it, it will[br]just give you some names of C++ objects,
0:27:11.629,0:27:16.389
but there are no function[br]names or something like that.
0:27:16.389,0:27:21.039
As we have seen earlier[br]it’s physically isolated
0:27:21.039,0:27:26.599
in its own memory. Which turned out[br]- of course - to be a good idea.
0:27:26.599,0:27:33.679
Otherwise it would have been[br]overwritable by the CPU eventually.
0:27:33.679,0:27:38.299
And all objects have a reference counting.
0:27:38.299,0:27:43.450
So that’s similar to the[br]C++ shared pointer
0:27:43.450,0:27:49.809
where every object has a small field
0:27:49.809,0:27:54.450
like a counter field and everytime[br]the kernel wants to use an object
0:27:54.450,0:27:59.899
this counter gets increased.[br]And everytime the…
0:27:59.899,0:28:04.239
like when the reference is no longer[br]needed it will decrease the counter
0:28:04.239,0:28:11.080
and when the counter reaches Zero it[br]will automatically delete that object
0:28:11.080,0:28:19.010
from the Slab Heap. So they are basically[br]trying to prevent use after freeze.
0:28:19.010,0:28:24.009
Also I’m not sure if that’s[br]a security measurement
0:28:24.009,0:28:29.690
but there are more than 100[br]panic calls in the kernel
0:28:29.690,0:28:35.689
and that’s every 10th function
0:28:35.689,0:28:44.019
- per average. And they have[br]the syscall access restriction.
0:28:44.019,0:28:51.909
So you - as I said - you only have[br]access to like 50 system calls.
0:28:51.909,0:28:55.189
All the interesting ones are disabled.
0:28:55.189,0:29:01.729
E.g. you can’t map executable pages.
0:29:01.729,0:29:06.039
On the other hand there[br]is no ASLR. But at least
0:29:06.039,0:29:11.809
they’re trying to change the[br]memory mapping every time
0:29:11.809,0:29:17.069
during a larger kernel update.
0:29:17.069,0:29:22.549
Also there’s no stack protection. And[br]the Userland is always mapped.
0:29:22.549,0:29:29.059
So once you’ve got control[br]over the program counter
0:29:29.059,0:29:33.090
you can just jump to
0:29:33.090,0:29:36.769
Userland pages that are[br]marked as executable.
0:29:36.769,0:29:40.899
So you don’t have to do ROP in the kernel.
0:29:40.899,0:29:44.659
It’s pretty nice.
0:29:44.659,0:29:50.599
But they tried to have[br]an execution prevention
0:29:50.599,0:29:57.810
in the kernel that is: they’re[br]marking executable kernel pages
0:29:57.810,0:30:01.899
– that is the code – they’re[br]marking them as executable
0:30:01.899,0:30:08.710
in their Page Table. So let’s take a look.
0:30:08.710,0:30:14.819
The highlighted parts in orange[br]are the kernel code sections.
0:30:14.819,0:30:20.629
And as you can see like when[br]looking at the first highlighted line
0:30:20.629,0:30:24.909
it says ‘virtual address #FFF00’ etc.
0:30:24.909,0:30:32.489
is mapped to the physical[br]address 1FF80000.
0:30:32.489,0:30:40.320
And it is marked as executable[br]and you only have access to it
0:30:40.320,0:30:45.219
in Kernel Mode, of course,[br]and only Read access. Right?
0:30:45.219,0:30:49.979
So this is correct.
0:30:49.979,0:30:56.019
But when you look at the second[br]line of that Page Table dump
0:30:56.019,0:31:00.799
you will notice that[br]there is another section
0:31:00.799,0:31:05.960
which covers the entire AXI WRAM
0:31:05.960,0:31:09.779
and it’s mapped as Read-Write.
0:31:09.779,0:31:15.609
So it doesn’t really make sense. Yeah.
0:31:15.609,0:31:23.939
So basically it’s completely useless.[br]We have Read-Write access to it.
0:31:23.939,0:31:28.430
So, to summarize everything,
0:31:28.430,0:31:32.849
there’s actually no exploitation[br]protection. Once we found
0:31:32.849,0:31:38.700
an exploitable bug it’s[br]pretty likely that we gain
0:31:38.700,0:31:43.219
code execution in kernel mode.
0:31:43.219,0:31:47.779
So, let’s find that bug.
0:31:47.779,0:31:53.509
And I started at looking at the SVC table.
0:31:53.509,0:31:59.809
So this is kind of the interface[br]between kernel land and userland.
0:31:59.809,0:32:05.889
And this shows all system calls
0:32:05.889,0:32:11.369
that are available in the kernel. So[br]you have like normal system calls.
0:32:11.369,0:32:18.049
For memory management you can[br]map read- and writable pages;
0:32:18.049,0:32:25.119
you can mirror pages and do[br]other memory management stuff.
0:32:25.119,0:32:30.869
And there’s also some[br]configuration for threads like
0:32:30.869,0:32:37.589
you can choose which[br]core should be used for
0:32:37.589,0:32:41.450
executing the thread and all that stuff.
0:32:41.450,0:32:47.219
You have a really large range[br]of synchronization objects
0:32:47.219,0:32:51.119
like kernel mute tags and[br]all that stuff. And of course
0:32:51.119,0:32:56.299
you have IPC requesting, so you can
0:32:56.299,0:33:03.099
send messages to services. And[br]there’s a more advanced section
0:33:03.099,0:33:09.270
like this is used by services mostly,
0:33:09.270,0:33:14.629
because they have to[br]respond to your IPC requests.
0:33:14.629,0:33:20.769
And there’s also Kernel DMA,[br]cache control, some things.
0:33:20.769,0:33:26.710
And they have a set of debug system calls.
0:33:26.710,0:33:31.099
It’s just basic debugging.[br]You can set breakpoints,
0:33:31.099,0:33:36.429
read and write process memory.[br]But you don’t have access to them.
0:33:36.429,0:33:39.919
Like on retail it’s not actually used.
0:33:39.919,0:33:47.099
And so one last section[br]is the Privileged section.
0:33:47.099,0:33:53.719
And here are all the[br]interesting system calls
0:33:53.719,0:34:00.260
that allow you to create processes and
0:34:00.260,0:34:07.249
map executable memory and all that stuff.
0:34:07.249,0:34:13.870
Unfortunately, we can’t use the Advanced,[br]Debug and Privileged system calls.
0:34:13.870,0:34:19.810
I mean that would require[br]exploiting some service.
0:34:19.810,0:34:24.020
And that’s just more work for us.
0:34:24.020,0:34:29.130
So this leaves us with[br]the normal system calls.
0:34:29.130,0:34:33.760
But IPC sounds really interesting.
0:34:33.760,0:34:41.239
But unfortunately it’s full of panics.
0:34:41.239,0:34:49.570
Also there’s not much to attack at[br]synchronization object system calls.
0:34:49.570,0:34:59.470
So you only have like this[br]more interesting system call
0:34:59.470,0:35:06.520
for local memory management. And in[br]theory there’s a lot that you can mess up.
0:35:06.520,0:35:12.290
Right? There’s a lot that can possibly[br]go wrong. And also we have
0:35:12.290,0:35:17.030
unchecked DMA access![br]Like through the GPU.
0:35:17.030,0:35:22.180
So maybe we can do[br]something useful with that.
0:35:22.180,0:35:26.430
Okay, so let’s have a look[br]at the memory allocator.
0:35:26.430,0:35:30.440
There are 2 types of memory allocators.
0:35:30.440,0:35:37.080
First is the regular one. And it’s[br]just for mapping normal heap
0:35:37.080,0:35:43.700
like for malloc in C, e.g. And you[br]have the linear memory allocator
0:35:43.700,0:35:49.250
that is used for GPU textures, like
0:35:49.250,0:35:55.080
when memory has to be[br]physically continuous
0:35:55.080,0:35:58.740
you use the linear memory allocator.
0:35:58.740,0:36:03.910
And there’s the FCRAM memory[br]layout that we saw earlier.
0:36:03.910,0:36:09.920
You have these 3 regions[br]and every region has
0:36:09.920,0:36:14.930
its own set of free pages.
0:36:14.930,0:36:21.740
So how are they keeping track of them?
0:36:21.740,0:36:27.430
So you have a region descriptor[br]which tells us the dimensions like:
0:36:27.430,0:36:32.020
where does it start, the region,[br]and its size. And you get also
0:36:32.020,0:36:39.410
a pointer to the first[br]free piece of memory
0:36:39.410,0:36:47.230
in that region. And each[br]free piece of memory
0:36:47.230,0:36:53.650
which we call a Memchunk[br]has a Memchunk header
0:36:53.650,0:36:58.450
right at the beginning. And[br]it basically tells the kernel
0:36:58.450,0:37:03.850
how large that Memchunk[br]is. And it’s also linked
0:37:03.850,0:37:08.410
in a Doubly Linked List. So you[br]have a next and previous pointer
0:37:08.410,0:37:15.030
pointing to the next and[br]previous Memchunk headers.
0:37:15.030,0:37:20.970
It kind of looks like that.[br]So you have the red parts
0:37:20.970,0:37:29.170
which are the free Memchunks[br]and the green parts are memory
0:37:29.170,0:37:34.760
that is already allocated. So
0:37:34.760,0:37:40.240
allocation is pretty straightforward.[br]It’s not really complicated.
0:37:40.240,0:37:45.900
So the first thing that the[br]allocator function does:
0:37:45.900,0:37:52.170
it loads the next free pointer[br]from the region descriptor.
0:37:52.170,0:37:59.230
And for regular memory it[br]just goes through the list
0:37:59.230,0:38:05.380
following the pointers[br]and it sums up their size
0:38:05.380,0:38:10.670
until the requested size is reached.[br]For linear memory it would just
0:38:10.670,0:38:17.120
look for a suitable memory chunk to make[br]sure that the memory is really continuous.
0:38:17.120,0:38:22.490
So when it found enough memory[br]it sets the next pointer
0:38:22.490,0:38:28.230
of the very last Memchunk[br]to Zero. It will then
0:38:28.230,0:38:33.690
update the list and also[br]the next free pointer
0:38:33.690,0:38:38.550
for the region descriptor[br]and finally it will return
0:38:38.550,0:38:44.780
a pointer to the first[br]Memchunk. So,
0:38:44.780,0:38:48.930
let’s look at this from[br]a security perspective.
0:38:48.930,0:38:53.410
And there’s a problem. They[br]basically have kernel structures
0:38:53.410,0:38:59.500
inside the FCRAM![br]And that is a problem
0:38:59.500,0:39:03.930
because we have DMA access[br]to it through the GPU.
0:39:03.930,0:39:08.740
And there was an attack by yellows8
0:39:08.740,0:39:13.180
that is called ‘memchunkhax’.[br]And what he did
0:39:13.180,0:39:17.060
is basically: he overwrote[br]memchunk headers
0:39:17.060,0:39:21.540
with the GPU DMA[br]flaw. And then
0:39:21.540,0:39:27.330
he gained an arbitrary kernel write
0:39:27.330,0:39:31.710
when it’s deallocating memory. So because
0:39:31.710,0:39:36.790
next/prev pointers have been modified.
0:39:36.790,0:39:42.140
So, unfortunately, this[br]was fixed by Nintendo
0:39:42.140,0:39:47.600
in system update 9.3 last year,
0:39:47.600,0:39:54.100
like 1 year ago. And the new kernel will[br]now verify every memchunk header
0:39:54.100,0:40:00.280
during allocation. Like its size[br]and also next/prev pointers.
0:40:00.280,0:40:08.160
So, in theory, everything has been fixed.[br]Invalid pointers or invalid sizes
0:40:08.160,0:40:16.870
will just result in a[br]kernel panic. In theory.
0:40:16.870,0:40:22.260
So when you look at the system[br]call for Controlmemory…
0:40:22.260,0:40:29.140
we have access to it. It’s one[br]of the normal system calls.
0:40:29.140,0:40:33.520
It does basic stuff. You[br]can map/free RW pages,
0:40:33.520,0:40:41.040
but not executable of course. And it[br]takes an address and size as argument.
0:40:41.040,0:40:46.530
And also an operation code[br]which tells the kernel what to do:
0:40:46.530,0:40:50.670
to map or free pages, whatever.
0:40:50.670,0:40:55.590
So first it does some basic[br]checks on the address
0:40:55.590,0:41:01.710
and eventually it will[br]call a very large function.
0:41:01.710,0:41:08.640
And I just call that function[br]kern::controlmemory.
0:41:08.640,0:41:14.980
So what can kern::controlmemory:[br]it calls the allocator function
0:41:14.980,0:41:20.550
and it will just return a[br]memchunk header pointer
0:41:20.550,0:41:28.460
– as we have seen earlier. Then it goes[br]through all of the allocated memchunks
0:41:28.460,0:41:33.100
and it’s mapping them to user space.
0:41:33.100,0:41:40.330
And it’s also updating some block[br]information for KProcess object.
0:41:40.330,0:41:47.490
So there’s a problem. There’s[br]obviously a race condition.
0:41:47.490,0:41:57.070
Like we can overwrite memchunk[br]headers after they have been allocated.
0:41:57.070,0:42:03.570
So we could try using the GPU[br]but it’s really slow, actually,
0:42:03.570,0:42:11.020
because we would have to ask[br]the GSP service to read memory
0:42:11.020,0:42:19.570
and we have to go to this[br]very large IPC kernel code.
0:42:19.570,0:42:26.730
And that would be probably too[br]slow. Allocation is really fast.
0:42:26.730,0:42:30.930
Let’s dig a little bit deeper.
0:42:30.930,0:42:38.060
I tried to reconstruct[br]the source code in C.
0:42:38.060,0:42:44.040
So this is the first step.[br]It tries to allocate memory.
0:42:44.040,0:42:54.070
For this example, it will just[br]allocate regular memory.
0:42:54.070,0:42:58.510
So when it found a memchunk
0:42:58.510,0:43:04.700
which means that it’s not[br]enough memory is available.
0:43:04.700,0:43:11.890
It will then execute this[br]really interesting do-while loop.
0:43:11.890,0:43:15.520
I know, it’s a lot of code. I’m not[br]sure that you can actually read it.
0:43:15.520,0:43:21.900
So let’s go quickly through this code.
0:43:21.900,0:43:27.990
The pages read from the Memchunk header.[br]It gets converted to a physical address.
0:43:27.990,0:43:31.700
And that physical address[br]gets mapped to userland
0:43:31.700,0:43:38.980
by mem_map function. And then[br]it will go to the next memchunk.
0:43:38.980,0:43:45.410
Here. And it will also update[br]the userland virtual address.
0:43:45.410,0:43:49.500
And then it will clear that memory. So
0:43:49.500,0:43:53.880
what’s wrong here?
0:43:53.880,0:44:00.020
The problem is they’re mapping[br]the Memorychunk into userland.
0:44:00.020,0:44:05.770
And after it has been mapped[br]they’re accessing it again.
0:44:05.770,0:44:10.040
And what they access is the next pointer.
0:44:10.040,0:44:13.250
So we can just overwrite it.
0:44:13.250,0:44:19.509
When we have 2 threads running we can
0:44:19.509,0:44:25.410
– from another CPU core –[br]try to overwrite that pointer.
0:44:25.410,0:44:32.320
So our goal would be to map[br]kernel pages to userspace.
0:44:32.320,0:44:37.510
But there are some problems. It[br]requires really, really perfect timing.
0:44:37.510,0:44:45.040
There’s only a very small[br]time frame to do the overwrite.
0:44:45.040,0:44:53.500
Also, we need a Memchunk header[br]structure at the next pointer address…
0:44:53.500,0:45:00.710
…to do this. To make sure[br]we get a perfect timing
0:45:00.710,0:45:06.810
I came up with a kernel[br]address arbiter oracle.
0:45:06.810,0:45:11.650
It is actually used for thread[br]synchronization, we don’t care about it.
0:45:11.650,0:45:15.430
But it tries to read from address and[br]returns an error when the address is
0:45:15.430,0:45:23.860
not accessible by userland. So[br]we can use that system call
0:45:23.860,0:45:28.600
to make sure that the memory[br]has been mapped to userland.
0:45:28.600,0:45:32.260
And once it has been mapped[br]we’re trying to overwrite it.
0:45:32.260,0:45:38.080
So one last problem: we have to[br]inject a memory chunk error
0:45:38.080,0:45:44.720
in kernel. I did this[br]by using the Slab Heap.
0:45:44.720,0:45:50.720
We can just create some KObject[br]and set their member variables
0:45:50.720,0:45:56.170
to create a faked memchunk header.
0:45:56.170,0:46:00.430
So this is the Slab Heap.[br]We’ve got C++ objects,
0:46:00.430,0:46:04.680
vtable pointer and some attributes.
0:46:04.680,0:46:11.200
So the Slab Heap is basically just[br]a really large area of C++ objects.
0:46:11.200,0:46:17.030
And what I did was[br]I changed the attributes
0:46:17.030,0:46:22.170
and used them as Memchunk[br]header. And I am redirecting
0:46:22.170,0:46:29.950
the next-pointer to that[br]object and it will map
0:46:29.950,0:46:34.410
multiple C++ objects to userland.[br]And that’s really nice because
0:46:34.410,0:46:40.180
we have vtable pointers, so[br]we can just overwrite them.
0:46:40.180,0:46:44.440
And that means that[br]we gain code execution.
0:46:44.440,0:46:49.570
So, as a summary, we set[br]up some kernel objects,
0:46:49.570,0:46:52.840
change their attributes, request[br]memory from the kernel;
0:46:52.840,0:46:57.290
and once it becomes available[br]we patch the next-pointer,
0:46:57.290,0:47:02.100
overwrite that mapped[br]SlabHeap pages and
0:47:02.100,0:47:08.060
then we call a system call[br]which closes the handle
0:47:08.060,0:47:11.940
for the kernel objects that[br]we created in step one.
0:47:11.940,0:47:17.470
So it will eventually call[br]some vtable function
0:47:17.470,0:47:23.560
and it will just jump to our[br]modified vtable function.
0:47:23.560,0:47:29.380
And we got ARM11[br]Level0 Code Execution!!
0:47:29.380,0:47:38.750
applause, motivated by smea
0:47:38.750,0:47:43.880
So, now plutoo will tell us[br]what nice things you can do
0:47:43.880,0:47:47.310
once you gained ARM11[br]Code execution.
0:47:47.310,0:47:55.060
plutoo: Hey guys! Okay, so… the ARM9.
0:47:55.060,0:47:58.990
Let’s go.
0:47:58.990,0:48:05.500
The ARM9 is actually also used[br]for executing old DS games.
0:48:05.500,0:48:10.390
So what they do is, they actually,[br]you could say, reused the ARM9
0:48:10.390,0:48:14.210
which is their backwards compatibility[br]processor. They use it
0:48:14.210,0:48:21.130
as a security processor[br]when executing 3DS code.
0:48:21.130,0:48:24.890
And like smea said it’s running[br]a stripped-down version
0:48:24.890,0:48:30.700
of the ARM11 kernel. It basically[br]only does threading sequencation,
0:48:30.700,0:48:35.460
things like that. And there’s[br]no MMU. There’s an MPU,
0:48:35.460,0:48:39.560
8 regions you can configure.
0:48:39.560,0:48:46.210
You could do no-execute[br]within those regions etc. but
0:48:46.210,0:48:50.280
the granularity is not very[br]nice. And they only have 8.
0:48:50.280,0:48:55.390
So they basically ran out of space.[br]And .data+stack is executable
0:48:55.390,0:49:00.020
as long as you can jump to[br]it. And .text is writable
0:49:00.020,0:49:06.240
so that’s bad. Basically whenever you can
0:49:06.240,0:49:11.940
write code into arbitrary memory[br]you can just overwrite code.
0:49:11.940,0:49:16.250
These features – you don’t want[br]them on a security processor.
0:49:16.250,0:49:18.430
laughter
0:49:18.430,0:49:23.740
So let’s go. So it turns out that
0:49:23.740,0:49:28.040
there have been lots of exploits over[br]the years and most of them are fixed.
0:49:28.040,0:49:33.330
And most of them used the[br]normal command interface.
0:49:33.330,0:49:37.940
But in this case we’re taking[br]a different approach. So
0:49:37.940,0:49:42.730
on the 3DS the memory-mapped[br]I/O is split up into 3 regions.
0:49:42.730,0:49:46.420
There’s the ARM9-only I/O: it does crypto,
0:49:46.420,0:49:50.980
it does DMA engine,
0:49:50.980,0:49:54.760
things like that. Then there’s[br]the Shared I/O region.
0:49:54.760,0:49:58.030
And then, finally, there’s the[br]ARM11 I/O region which contains
0:49:58.030,0:50:02.760
the GPU video decoder.
0:50:02.760,0:50:06.310
Thanks to derrek and smea[br]we have full ARM11 control.
0:50:06.310,0:50:09.680
We execute kernel mode.
0:50:09.680,0:50:13.280
So the question is: can we use[br]the shared I/O region, somehow,
0:50:13.280,0:50:17.750
to own the ARM9? So it turns out
0:50:17.750,0:50:21.550
the interface for reading old[br]DS cartridges is actually
0:50:21.550,0:50:24.940
in the shared I/O region.
0:50:24.940,0:50:30.260
We’re not sure why this is, but
0:50:30.260,0:50:33.970
they have it there for some[br]reason. And it’s only the ARM9
0:50:33.970,0:50:38.120
which is actually using this region.[br]But ARM11 still has access to it.
0:50:38.120,0:50:43.780
So when you insert the cartridge[br]it starts by reading the banner.
0:50:43.780,0:50:49.100
And it does this by writing this[br]magic value to CTRL register.
0:50:49.100,0:50:53.940
And basically it just asks[br]for 0x200 [hex] bytes.
0:50:53.940,0:50:56.490
And then there’s this loop.
0:50:56.490,0:50:59.770
And this Assembler code[br]is on the right side.
0:50:59.770,0:51:04.640
You can see it basically waits[br]for some bits to clear / to set
0:51:04.640,0:51:11.170
and then they read 4 bytes and[br]then they wait for another bit.
0:51:11.170,0:51:15.520
And there’s no range check on the[br]buffer. But it’s always 200 bytes,
0:51:15.520,0:51:20.540
so it should be fine.
0:51:20.540,0:51:24.510
What if we overwrite the[br]CTRL register from ARM11
0:51:24.510,0:51:27.880
asking for 0x4000 bytes?
0:51:27.880,0:51:32.080
Boom!
0:51:32.080,0:51:36.490
We have a nice buffer overrun.[br]It’s in the DSS segment but…
0:51:36.490,0:51:40.690
it’s still nice. And can control the data.
0:51:40.690,0:51:48.110
So the data actually comes[br]from the cartridge.
0:51:48.110,0:51:51.720
We need to make our[br]own DS cartridge. So,
0:51:51.720,0:51:56.030
there’s this old device, called the[br]PassMe. It’s for the original DS,
0:51:56.030,0:51:59.850
where you basically plug[br]old DS cartridge in
0:51:59.850,0:52:03.960
and it basically modifies[br]the header as its read. So,
0:52:03.960,0:52:08.620
these are available online for 5 bucks.
0:52:08.620,0:52:15.480
And then you add an FPGA.
0:52:15.480,0:52:21.150
I implemented this and it[br]works, but it’s very gimmicky.
0:52:21.150,0:52:26.290
I don’t recommend it.
0:52:26.290,0:52:30.790
And here’s my soldering,[br]it’s not very nice.
0:52:30.790,0:52:35.730
This gives us ARM9 code execution[br]and this works on latest firmware.
0:52:35.730,0:52:41.370
But we want something better.[br]Let’s look at the chain of trust.
0:52:41.370,0:52:46.620
The chain of trust: the idea is of course,[br]you verify all the code that is running.
0:52:46.620,0:52:51.560
But you’re basically verifying[br]everything at load time.
0:52:51.560,0:52:55.230
The 3DS has the simplest[br]chain of trust you can have.
0:52:55.230,0:52:58.560
There’s the Boot ROM at[br]the start. And then it loads
0:52:58.560,0:53:04.490
the firmware binary from[br]NAND and it jumps to it.
0:53:04.490,0:53:07.900
On the new 3DS they were a bit clever.
0:53:07.900,0:53:12.760
They added an extra crypto[br]layer on the ARM9 portion.
0:53:12.760,0:53:17.520
But it’s actually part[br]of the firmware binary.
0:53:17.520,0:53:20.380
We call this ‘ARM9 loader’.
0:53:20.380,0:53:23.530
So the theory that Nintendo had was:
0:53:23.530,0:53:27.460
“Let’s add another layer of[br]crypto, so we change the keys,
0:53:27.460,0:53:32.470
we introduce new keys,[br]and they can’t break it”.
0:53:32.470,0:53:35.560
And they don’t have any worked-out[br]place to put those keys.
0:53:35.560,0:53:39.200
So they placed them in NAND!
0:53:39.200,0:53:42.760
But they’re encrypted with[br]the per-Console key that’s
0:53:42.760,0:53:48.030
based on a hash of the OTP[br]that’s unique for each Console.
0:53:48.030,0:53:52.120
And then OTP access is[br]disabled early in the Boot.
0:53:52.120,0:53:59.410
So later on you can’t dump the OTP[br]and you can’t figure out the keys.
0:53:59.410,0:54:03.580
This looks safe, in theory.[br]So here’s the implementation.
0:54:03.580,0:54:08.620
So they calculate some hash of the OTP.[br]They read the key-sector from NAND.
0:54:08.620,0:54:12.430
And they decrypt the key.[br]And they put it in a keyslot.
0:54:12.430,0:54:17.180
It’s basically an isolated memory area.
0:54:17.180,0:54:21.170
And then they generate[br]a bunch of sub keys and
0:54:21.170,0:54:24.620
they verify that the key they loaded[br]from NAND is the correct one.
0:54:24.620,0:54:30.810
So even if we were to switch the key[br]they would detect that and just panic.
0:54:30.810,0:54:35.300
And then they decrypt the ARM9 binary[br]and they jump to the entry point.
0:54:35.300,0:54:40.420
But… they forgot to clear the 0x11 key!
0:54:40.420,0:54:44.190
So we can just get code execution[br]later on. And we can just regenerate
0:54:44.190,0:54:51.460
all those keys! So this[br]implementation is useless.
0:54:51.460,0:54:52.760
Okay.[br]laughs
0:54:52.760,0:54:58.960
applause
0:54:58.960,0:55:03.760
And they fixed this because they have[br]more than 1 key hidden in the NAND.
0:55:03.760,0:55:07.780
So they took their next key.
0:55:07.780,0:55:10.680
It’s basically the same idea: you[br]calculate the same hash, you read
0:55:10.680,0:55:14.920
the key sector from NAND, you generate[br]all the previous keys for compatibility,
0:55:14.920,0:55:19.900
and then you decrypt a[br]new key, we call it Key#2.
0:55:19.900,0:55:23.920
And then you decrypt ARM9[br]binary using the second key.
0:55:23.920,0:55:27.780
You clear the keyslot, and[br]you jump to entry point.
0:55:27.780,0:55:32.010
But they forgot to verify the second key![br]audience laughs
0:55:32.010,0:55:40.000
This is epic fail![br]applause
0:55:40.000,0:55:44.520
So let’s exploit this. ‘ARM9LOADERHAX’.
0:55:44.520,0:55:49.510
We can change the second key. ARM9[br]loader will just decrypt the binary
0:55:49.510,0:55:54.820
to garbage and jump to it.
0:55:54.820,0:56:00.110
If you look at the encoding[br]of a ARM Branch instruction:
0:56:00.110,0:56:04.310
the probability is pretty high that[br]there will just be a Branch instruction.
0:56:04.310,0:56:08.590
And just any random data will eventually…[br]like if you try enough keys,
0:56:08.590,0:56:14.810
it will eventually become a Branch[br]instruction to some memory.
0:56:14.810,0:56:19.490
So if we try a lot of keys, eventually[br]we will find some garbage
0:56:19.490,0:56:23.990
that is useful.
0:56:23.990,0:56:29.680
This is the NAND of the Flash[br]memory of an unmodified 3DS
0:56:29.680,0:56:37.349
– a new 3DS. So there’s a small key[br]section, marked in teal, like, blue.
0:56:37.349,0:56:41.660
And it contains those keys[br]that we’re talking about.
0:56:41.660,0:56:44.550
And then there are 2 firmware partitions.
0:56:44.550,0:56:47.960
One is used for backup, in[br]case one gets corrupted;
0:56:47.960,0:56:52.119
so it doesn’t brick the device, whatever.
0:56:52.119,0:56:57.190
We installed our custom key.
0:56:57.190,0:57:00.920
And we installed the largest[br]firm binary we have
0:57:00.920,0:57:06.100
in the firm0 partition. And we keep[br]the one with the vulnerability
0:57:06.100,0:57:11.760
in the firm1 partition. And[br]then we put our code payload
0:57:11.760,0:57:17.250
on top of the firmware0 binary.
0:57:17.250,0:57:21.340
And then we reboot.[br]And so what will happen?
0:57:21.340,0:57:24.070
The Bootrom is executed.
0:57:24.070,0:57:29.660
It will load the first firmware partition.
0:57:29.660,0:57:34.510
And it has our code in the end,[br]but it doesn’t know about it.
0:57:34.510,0:57:38.880
And then it decrypts it.[br]And, you see, it looks okay.
0:57:38.880,0:57:43.800
There’s the ARM9 loader stub in the front;[br]and then comes the encrypted binary.
0:57:43.800,0:57:48.170
And then, finally,[br]there’s our payload.
0:57:48.170,0:57:52.960
But Bootrom checks the[br]hash, right? And it fails.
0:57:52.960,0:57:58.280
So it thinks the partition got corrupted.
0:57:58.280,0:58:03.000
So it will load the smaller one on top.[br]You see we have our payload in memory,
0:58:03.000,0:58:09.380
at Boot. And then it decrypts firmware1
0:58:09.380,0:58:14.810
which is smaller and it still has ARM9[br]loader and another encrypted ARM9 binary.
0:58:14.810,0:58:18.910
And then it jumps to ARM9 loader[br]because the hash checks out.
0:58:18.910,0:58:24.230
And then the ARM9 loader will[br]decrypt our corrupted key
0:58:24.230,0:58:28.940
from NAND and it will[br]decrypt this one to garbage
0:58:28.940,0:58:37.100
and it will jump to it. And[br]hopefully it jumps to our code.
0:58:37.100,0:58:41.770
So this gives us ARM9 code[br]execution from cold Boot.
0:58:41.770,0:58:46.230
Early, very early. So it turns out we[br]can actually use this to get some keys
0:58:46.230,0:58:52.000
that are later not available[br]because they clear those…
0:58:52.000,0:58:56.869
they use a certain memory area for seeding[br]encryption engine to generate keys
0:58:56.869,0:59:04.440
and the memory is later cleared.[br]So you can’t regenerate the keys.
0:59:04.440,0:59:08.400
But with this we can actually[br]get those 2 keys.
0:59:08.400,0:59:11.850
They’re called the firmware 6.x save-key
0:59:11.850,0:59:15.780
and firmware 7.x NCCH-key.
0:59:15.780,0:59:20.400
That’s a bonus.
0:59:20.400,0:59:25.220
We talked a bit about the AES engine.[br]It’s used everywhere for the crypto
0:59:25.220,0:59:30.200
and it’s used for everything, basically.
0:59:30.200,0:59:35.990
It supports all the usual[br]block cipher modes.
0:59:35.990,0:59:40.940
It has 2 security features: it has[br]write-only keys. Which is really useful.
0:59:40.940,0:59:44.750
Like you write a key and then[br]you can never ever read it back.
0:59:44.750,0:59:49.770
This means that they can[br]fill in the keys by the Bootrom
0:59:49.770,0:59:56.150
and we can’t dump them later.
0:59:56.150,1:00:01.300
So they can keep the keys secret.
1:00:01.300,1:00:08.280
Even if we hacked the ARM9, even if we get[br]code execution we’ll never get the keys.
1:00:08.280,1:00:12.250
And then there’s the key scrambler.[br]Which is that the key is actually
1:00:12.250,1:00:16.320
– it’s an optional thing –[br]where the actual key is hidden,
1:00:16.320,1:00:21.090
calculated by a hardware[br]function, that is never…
1:00:21.090,1:00:26.359
that we don’t know about. So the key[br]is actually never exposed to the CPU
1:00:26.359,1:00:30.580
– the actual key. So we just feed it 2[br]values, 2 keys and then it generates
1:00:30.580,1:00:35.000
a new key based on that. And[br]we don’t know what that key is.
1:00:35.000,1:00:40.500
So this creates a situation similar to[br]the isolated SPUs on the PS3
1:00:40.500,1:00:44.000
where you can ask it to decrypt[br]stuff, but you don’t get the keys.
1:00:44.000,1:00:49.640
And if you don’t get the keys,[br]then… we want the keys!!
1:00:49.640,1:00:53.300
We want to decrypt things on[br]our PC because we’re lazy.
1:00:53.300,1:00:57.720
So there’re 2 keys –[br]KeyX, KeyY we call them.
1:00:57.720,1:01:01.970
They’re 128bits and the[br]normal key is derived
1:01:01.970,1:01:06.250
as a function of those 2;[br]and that function is unknown.
1:01:06.250,1:01:12.040
It’s implemented in hardware, in silicon.
1:01:12.040,1:01:15.760
So even if we know X and Y we[br]can’t figure out the normal key
1:01:15.760,1:01:21.960
and we can’t decrypt things[br]without asking the 3DS first.
1:01:21.960,1:01:26.550
But we can poke this hardware engine.
1:01:26.550,1:01:30.050
The first thing you notice when you[br]do this is that if you set the N-th bit
1:01:30.050,1:01:37.140
of the X key and the N+2 bit in[br]the Y key you get the same result.
1:01:37.140,1:01:41.080
And in general, you find that[br]the function that we’re looking for
1:01:41.080,1:01:45.280
is actually just a function[br]of one variable where it’s
1:01:45.280,1:01:50.690
the XOR between the X rotated by 2…
1:01:50.690,1:01:56.100
so this is rotation, not shift,[br]and XOR-ed with Y.
1:01:56.100,1:01:59.430
But we still don’t know the key.[br]But we want to know keys. So…
1:01:59.430,1:02:08.140
So step back a little bit.
1:02:08.140,1:02:12.070
The keyscrambler is used for Mii QR-codes.
1:02:12.070,1:02:18.740
It’s used for everything, right? So it’s[br]used for network protocol, called UDS,
1:02:18.740,1:02:23.930
and it’s used for Download Play – which[br]is when you download games over WiFi,
1:02:23.930,1:02:28.000
temporary games. But the[br]Wii U also supports all of this.
1:02:28.000,1:02:31.180
But it doesn’t have the[br]key scrambler in hardware.
1:02:31.180,1:02:33.090
So the Wii U must be using normal keys.
1:02:33.090,1:02:36.520
applause[br]screamed from audience: WHAT?
1:02:36.520,1:02:46.360
applause
1:02:46.360,1:02:51.210
So we make a table of the shared keys and
1:02:51.210,1:02:54.619
these are the 3 keys that[br]are shared with the Wii U.
1:02:54.619,1:03:00.240
Who is where the KeyX[br]and KeyY on the 3DS…
1:03:00.240,1:03:05.920
where they are set. And 2 of them[br]have KeyY set by firmware.
1:03:05.920,1:03:11.510
So we can’t read the keys set by the[br]Bootrom because it’s locked away
1:03:11.510,1:03:17.310
and we don’t have it. But can[br]we still figure out G? Let’s see.
1:03:17.310,1:03:23.390
So I gave shoutout to shuffle2 and[br]to fail0verflow who hacked the WiiU
1:03:23.390,1:03:27.540
and they helped us… or shuffle[br]helped us extract the Wii U keys.
1:03:27.540,1:03:36.670
So thank you! Now we have KeyY and[br]we know the normal key from the Wii U.
1:03:36.670,1:03:39.740
However, KeyX is still unknown.
1:03:39.740,1:03:44.560
And if G(t) is ‘bad’ then a[br]small change in the KeyY
1:03:44.560,1:03:48.970
will only lead to a small[br]change in the normal key.
1:03:48.970,1:03:53.369
It’s bad! So let’s look at the data.
1:03:53.369,1:03:56.670
So when we flip one bit in the[br]KeyY we can brute-force all keys
1:03:56.670,1:04:01.390
similar to the normal key which[br]is just within a couple of bit flips
1:04:01.390,1:04:06.540
and we find that it always[br]results in the normal key
1:04:06.540,1:04:12.980
with bits flipped at[br]position either 87 or 88,
1:04:12.980,1:04:16.340
sometimes 89, but never 86.
1:04:16.340,1:04:22.359
So this reminds me of an adder[br]where you had a carry bit
1:04:22.359,1:04:26.160
being propagated to upper[br]bits, but never to lower ones.
1:04:26.160,1:04:30.980
So let’s guess that this is[br]an adder and let’s try:
1:04:30.980,1:04:37.599
it’s an adder with a rotation so[br]we guess that G(t) = (t+C)
1:04:37.599,1:04:45.140
– some constant C, we don’t know it –[br]and rotated to the left by 87.
1:04:45.140,1:04:50.680
And then we plug it in to our original[br]formula and we don’t know KeyX, remember,
1:04:50.680,1:04:53.640
because it’s set by Bootrom,[br]we don’t have it.
1:04:53.640,1:04:59.440
We don’t know the constant C because[br]it’s in silicon, it’s in hardware.
1:04:59.440,1:05:04.630
But if we look at the formula,[br]and we consider the inequality,
1:05:04.630,1:05:09.440
where we basically rotate right by 87
1:05:09.440,1:05:13.500
– we’re basically undoing[br]the outer rotation.
1:05:13.500,1:05:18.810
And then we plug in our formula[br]our guess. And then we get this.
1:05:18.810,1:05:23.300
And then we subtract C from[br]both sides. We end up with this.
1:05:23.300,1:05:28.510
And this is basically… we’re XOR-ing[br]2 different keys with the same X value
1:05:28.510,1:05:34.810
rotated to the left by 2.
1:05:34.810,1:05:38.150
Well if you stare for[br]this bit you’ll see that
1:05:38.150,1:05:45.950
if y0 and y1 – which are 2 different[br]KeyY’s – are equal except for
1:05:45.950,1:05:52.240
at one bit position then[br]the XOR is smallest
1:05:52.240,1:05:58.100
for the one which shares[br]the same bit value
1:05:58.100,1:06:03.070
at the position that the[br]2 Y’s are differing at.
1:06:03.070,1:06:07.740
It’s actually pretty simple[br]but it sounds difficult.
1:06:07.740,1:06:12.720
XOR is Zero if they’re the same[br]input and One if they’re different.
1:06:12.720,1:06:16.080
If they’re the same it’s[br]Zero and it’s smaller.
1:06:16.080,1:06:20.550
So we actually look[br]bit-by-bit on this. And
1:06:20.550,1:06:27.910
we repeat this 128 times. And we[br]recover all 128 bits of the KeyX.
1:06:27.910,1:06:32.740
And when we have the KeyX we can[br]calculate the silicon constant C.
1:06:32.740,1:06:38.250
So the end result is: the key[br]scrambler is figured out
1:06:38.250,1:06:45.290
and we have also the secret Bootrom[br]KeyX for a couple of keyslots, as a bonus.
1:06:45.290,1:07:00.780
applause, motivated by smea
1:07:00.780,1:07:04.530
I didn’t think trough the constants in[br]the slides because I want this to be
1:07:04.530,1:07:11.840
an exercise for the listener.
1:07:11.840,1:07:16.400
When the new 3DS was released[br]they rushed it, we think,
1:07:16.400,1:07:22.440
because they left some interesting[br]commands in the PsPs service. And
1:07:22.440,1:07:31.150
it included an early version of the NFC[br]crypto used for the Amiibo figurines.
1:07:31.150,1:07:36.609
This implementation, the first[br]one, uses a normal key. And the…
1:07:36.609,1:07:40.060
the newer one changed it to KeyY.
1:07:40.060,1:07:44.290
So they accidently gave us one of[br]these pairs in the firmware images.
1:07:44.290,1:07:47.260
We don’t need to use the Wii U at all.
1:07:47.260,1:07:52.210
So anyone who can decrypt[br]3DS firmware binaries
1:07:52.210,1:07:58.400
can perform this attack[br]to get the constants.
1:07:58.400,1:08:03.290
So anyone out there: Good luck!
1:08:03.290,1:08:06.750
And now: back to smea, for a summary.
1:08:06.750,1:08:13.720
applause
1:08:13.720,1:08:16.880
smea: Right, I’m just gonna conclude[br]really quickly. So, some take-aways of
1:08:16.880,1:08:20.839
what we talked about[br]today: first thing is:
1:08:20.839,1:08:23.988
it’s all pretty obvious lessons,[br]but – you know – bare with me
1:08:23.988,1:08:29.049
Giving access to physical memory to[br]any application, through GPU or whatever,
1:08:29.049,1:08:31.849
is dangerous. You should always be[br]careful about that. Even if you think
1:08:31.849,1:08:36.059
you’ve protected stuff, there’s probably[br]gonna be stuff that you forgot. So just,
1:08:36.059,1:08:39.538
like “you don’t do it or do it right”.
1:08:39.538,1:08:42.408
Other thing is: Shared I/O is[br]dangerous if you don’t know
1:08:42.408,1:08:47.908
what can actually control the I/O, then,[br]well, again, you should be very careful.
1:08:47.908,1:08:52.319
Also, only checking your data[br]before decryption is dangerous,
1:08:52.319,1:08:56.429
and - both that and not checking the key[br]when you know that it could possibly
1:08:56.429,1:09:00.609
be modified by an attacker[br]is a bad idea. And finally,
1:09:00.609,1:09:05.099
secrets in hardware are great[br]unless you give them away, so…
1:09:05.099,1:09:07.569
don’t do that! laughs[br]audience laughs*
1:09:07.569,1:09:11.309
Beyond that we just wanted to talk about[br]the state of Homebrew really quickly.
1:09:11.309,1:09:15.488
You might recall, on the - during the[br]Wii U talk around here
1:09:15.488,1:09:19.828
2 years ago. And fail0verflow said[br]that they didn’t think necessarily
1:09:19.828,1:09:23.599
there was much of a future for console[br]Homebrew. And there’s definitely
1:09:23.599,1:09:28.629
an argument for that with[br]the rise of phones, mostly.
1:09:28.629,1:09:31.908
Anyone can make an app, can make[br]a game for any number of devices
1:09:31.908,1:09:37.189
and sell it to millions of people.[br]But you know, we disagree.
1:09:37.189,1:09:39.059
cheers and applause
1:09:39.059,1:09:43.920
It’s been a year since we started[br]releasing 3DS homebrew. And
1:09:43.920,1:09:47.788
– this is supposed to be moving,[br]but… let’s imagine it’s moving.
1:09:47.788,1:09:52.489
Well, there in there - like a bunch of[br]3DS Homebrew. It’s been awesome!
1:09:52.489,1:09:56.200
We’ve been working on this really hard.[br]A lot of people had been joining us.
1:09:56.200,1:10:01.570
It’s a great community effort. And[br]basically what I want to say is
1:10:01.570,1:10:05.860
we want more developers.[br]So if you’d like to join us
1:10:05.860,1:10:10.530
there is a very… well it’s not[br]very mature, but it’s maturing,
1:10:10.530,1:10:15.130
our SDK. And you know what:[br]reverse-engineering hardware is fun.
1:10:15.130,1:10:18.210
When we don’t have any documentation,[br]reverse-engineering software is fun.
1:10:18.210,1:10:22.770
We can always use more reverse-engineers[br]and just people who want to make cool shit,
1:10:22.770,1:10:28.999
so… Yeah, oh… right! Just one more thing.
1:10:28.999,1:10:32.769
Lately there has been a wave[br]of patches by Nintendo,
1:10:32.769,1:10:36.170
of known exploits, which[br]has been really annoying.
1:10:36.170,1:10:40.479
So for our Browser Hacks, well,[br]yellows8’s Browser Hacks,
1:10:40.479,1:10:45.150
menu hacks, stuff like that…[br]Yellows8’s been working pretty hard,
1:10:45.150,1:10:49.199
so he actually brought back browser[br]hacks, it should have been released
1:10:49.199,1:11:02.720
about 10 minutes ago.[br]laughter, applause
1:11:02.720,1:11:07.849
But we also had ironhax for an[br]eShop game, a free eShop game,
1:11:07.849,1:11:12.479
so you could just download it. That was[br]patched. The thing is, there’s actually
1:11:12.479,1:11:16.650
a way to download the old version from[br]the eShop application with some patches.
1:11:16.650,1:11:20.269
So we’re also releasing that right now![br]So basically if you can get Homebrew
1:11:20.269,1:11:23.889
and get on to the eShop[br]with a modified patch.
1:11:23.889,1:11:27.539
That should also be released in about…[br]well, whenever this is done.
1:11:27.539,1:11:31.239
So get it as soon as possible,[br]this is a free game, it will get you
1:11:31.239,1:11:36.590
Homebrew forever. So just do that.[br]And also, yellows8 just released
1:11:36.590,1:11:39.800
a new version of menuhax which[br]works on latest firmware version.
1:11:39.800,1:11:43.499
This was also patched like a couple of[br]weeks or months ago. So, this is all out
1:11:43.499,1:11:48.099
right now. If you have a 3DS, get it.[br]If you have friends who have 3DS’s,
1:11:48.099,1:11:53.749
well, tell them and tell them to get it.[br]Because it might not last super long.
1:11:53.749,1:11:57.950
Yeah, so we would like to thank yellows8[br]who unfortunately can not be here tonight
1:11:57.950,1:12:01.800
but has been super helpful, has been[br]doing a ton of work on the 3DS.
1:12:01.800,1:12:05.479
And honestly, a ton of this could[br]not have been done without him.
1:12:05.479,1:12:08.639
And thanks to everyone on the[br]#3DSDEV Homebrew channel,
1:12:08.639,1:12:11.909
everyone who is attending tonight.[br]Thanks for this.
1:12:11.909,1:12:14.999
And if you have any questions,[br]I don’t think we have a lot of time,
1:12:14.999,1:12:28.429
but we’ll accommodate. Thanks![br]applause
1:12:28.429,1:12:31.740
Herald: Thank you for your patience, if[br]you got questions, please come upfront
1:12:31.740,1:12:36.469
to these guys, because we have no more[br]time for structured Q&A. Thank you!
1:12:36.469,1:12:41.400
postroll music
1:12:41.400,1:12:47.499
Subtitles created by c3subtitles.de[br]in the year 2016. Join and help us!