[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:19.78,Default,,0000,0000,0000,,{\i1}36C3 preroll music{\i0}
Dialogue: 0,0:00:22.71,0:00:26.44,Default,,0000,0000,0000,,Herald: The following talk is titled "It's\NNot Safe in the Streets, especially for
Dialogue: 0,0:00:26.44,0:00:31.43,Default,,0000,0000,0000,,your 3DS" and it's about exploring a new\Nattack surface on the 3DS. And the speaker
Dialogue: 0,0:00:31.43,0:00:36.27,Default,,0000,0000,0000,,is nba::yoh. The show is yours.
Dialogue: 0,0:00:36.27,0:00:42.19,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:00:43.30,0:00:49.88,Default,,0000,0000,0000,,nba::yoh: Hi, everyone. I'm nba::yoh and\Ntoday I'm going to talk about 3DS hacking
Dialogue: 0,0:00:49.88,0:01:01.11,Default,,0000,0000,0000,,and especially about a protocol, an\Nundocumented protocol. And we're gonna see
Dialogue: 0,0:01:01.11,0:01:10.58,Default,,0000,0000,0000,,how I attacked the protocol and got remote\Ncode execution on the system. But before
Dialogue: 0,0:01:10.58,0:01:18.23,Default,,0000,0000,0000,,before saying, oh, I did that, I'd like to\Ndo a quick recap of the state of 3DS
Dialogue: 0,0:01:18.23,0:01:27.10,Default,,0000,0000,0000,,hacking in 2019, because there have been a\Nlot of userland exploits, a lot of patched
Dialogue: 0,0:01:27.10,0:01:33.03,Default,,0000,0000,0000,,kernel flaws and there's a lot of\Ndocumentation online about the system. And
Dialogue: 0,0:01:33.03,0:01:41.42,Default,,0000,0000,0000,,during the last few years, people have\Nbeen working on it and broke the hardware
Dialogue: 0,0:01:41.42,0:01:49.51,Default,,0000,0000,0000,,keyscambler. And they managed to dump the\Nbootroms. And as a result, anyone who now
Dialogue: 0,0:01:49.51,0:01:57.90,Default,,0000,0000,0000,,have the bootrom can derive all the secret\Nkeys of the system. And as a bonus, they
Dialogue: 0,0:01:57.90,0:02:03.70,Default,,0000,0000,0000,,were able to find a permanent unpatchable\Nbootrom exploit. So at that point, you
Dialogue: 0,0:02:03.70,0:02:11.04,Default,,0000,0000,0000,,might be wondering what's left to do in\Nthe system. And actually, I wonder if it
Dialogue: 0,0:02:11.04,0:02:16.62,Default,,0000,0000,0000,,would be possible to use those keys to\Nattack features that were protected until
Dialogue: 0,0:02:16.62,0:02:22.48,Default,,0000,0000,0000,,then by encryption. So that's why today\NI'm going to talk about StreetPass.
Dialogue: 0,0:02:25.06,0:02:30.65,Default,,0000,0000,0000,,First, I'm going to do a quick introduction about\Nthe feature and then we'll see how I
Dialogue: 0,0:02:30.65,0:02:39.24,Default,,0000,0000,0000,,expoited it and see what's possible to do\Nonce you get code execution. So what is
Dialogue: 0,0:02:39.24,0:02:45.79,Default,,0000,0000,0000,,StreetPass? This is a local and wireless\Ncommunication feature. The basic idea
Dialogue: 0,0:02:45.79,0:02:51.98,Default,,0000,0000,0000,,behind StreetPass was that users would\Ntake their 3DS with them and go out and it
Dialogue: 0,0:02:51.98,0:02:59.99,Default,,0000,0000,0000,,would automatically communicate with other\Npeople's systems. The point of the feature
Dialogue: 0,0:02:59.99,0:03:07.18,Default,,0000,0000,0000,,was to share data between applications\Nlike custom levels for your games or
Dialogue: 0,0:03:07.18,0:03:14.80,Default,,0000,0000,0000,,messages, avatars, et cetera. So this is\Nquite an interesting feature for players,
Dialogue: 0,0:03:14.80,0:03:21.93,Default,,0000,0000,0000,,but also for hackers. So this is the\Nplayer point of view so you can send your
Dialogue: 0,0:03:21.93,0:03:29.21,Default,,0000,0000,0000,,messages and other people will be able to\Nreceive them. But we'd like to - from an
Dialogue: 0,0:03:29.21,0:03:34.51,Default,,0000,0000,0000,,hacker point of view - we'd like to\Nreplace one of these systems with a PC to
Dialogue: 0,0:03:34.51,0:03:40.63,Default,,0000,0000,0000,,tamper with the protocol, for example. And\Neventually it would be nice if we could
Dialogue: 0,0:03:40.63,0:03:48.02,Default,,0000,0000,0000,,send some corrupted messages and see if we\Ncan get code execution on foreign systems.
Dialogue: 0,0:03:49.62,0:03:54.66,Default,,0000,0000,0000,,But for doing that, you need to know how\Nthe street the StreetPass feature works.
Dialogue: 0,0:03:55.84,0:04:01.32,Default,,0000,0000,0000,,So it's quite simple. It acts like a mailbox.\NSo you have CECD, which is a system
Dialogue: 0,0:04:01.32,0:04:10.83,Default,,0000,0000,0000,,module, and it's the only one that manages\Nall this StreetPass feature. So all your
Dialogue: 0,0:04:10.83,0:04:18.37,Default,,0000,0000,0000,,applications have an inbox and an\Nassociated outbox in the CECD file system
Dialogue: 0,0:04:18.37,0:04:27.32,Default,,0000,0000,0000,,and they can put and get messages from and\Nto these boxes via IPC. Then messages in
Dialogue: 0,0:04:27.32,0:04:32.39,Default,,0000,0000,0000,,these boxes are used to craft packets\Nwhich are then sent using the StreetPass
Dialogue: 0,0:04:32.39,0:04:40.61,Default,,0000,0000,0000,,protocol. And we can already see on this\Ndiagram which path we could try to attack.
Dialogue: 0,0:04:40.61,0:04:47.22,Default,,0000,0000,0000,,The first one you might think about are\Nour application boxes because it's very
Dialogue: 0,0:04:47.22,0:04:53.75,Default,,0000,0000,0000,,likely that you'll be able to find some kind\Nof game or application that have a float
Dialogue: 0,0:04:53.75,0:05:02.89,Default,,0000,0000,0000,,parser. So we might take and get remote\Ncode execution in such an application. But
Dialogue: 0,0:05:02.89,0:05:10.96,Default,,0000,0000,0000,,the most interesting one would be to try\Nto attack CECDs parser. And this would
Dialogue: 0,0:05:10.96,0:05:19.29,Default,,0000,0000,0000,,give us remote code execution in a system\Nmodule, which would be nice. But for doing
Dialogue: 0,0:05:19.29,0:05:25.06,Default,,0000,0000,0000,,that, we need to figure out how the\NStreetPass protocol works and nobody
Dialogue: 0,0:05:25.06,0:05:31.07,Default,,0000,0000,0000,,really knows how it works. There is a bit\Nof documentation online about the
Dialogue: 0,0:05:31.07,0:05:36.42,Default,,0000,0000,0000,,pairings, so "oh both our systems are\Nseeing a hand here. Would like would you
Dialogue: 0,0:05:36.42,0:05:42.41,Default,,0000,0000,0000,,like to communicate with me?" But it has\Nnever been successfully reproduced, at
Dialogue: 0,0:05:42.41,0:05:49.60,Default,,0000,0000,0000,,least publicly. And we know that it's\Nusing an unknown and encrypted protocol
Dialogue: 0,0:05:49.60,0:05:58.90,Default,,0000,0000,0000,,that uses the secret AES key that we can\Nnow get. So let's reverse the protocol.
Dialogue: 0,0:05:58.90,0:06:08.10,Default,,0000,0000,0000,,First, well, let's reverse the pairing and\Nreplicate it. So it's fairly easy to
Dialogue: 0,0:06:08.10,0:06:15.36,Default,,0000,0000,0000,,understand: You have both peers, the\Nclient and the master and before
Dialogue: 0,0:06:15.36,0:06:23.17,Default,,0000,0000,0000,,communicating they randomize their console\NID and their MAC address. Then the client
Dialogue: 0,0:06:23.17,0:06:32.46,Default,,0000,0000,0000,,sends a bunch of probe requests with our\Nbundle specific tag, containing a list of
Dialogue: 0,0:06:32.46,0:06:37.94,Default,,0000,0000,0000,,the applications that have StreetPass\Nactivated. And then eventually the master
Dialogue: 0,0:06:37.94,0:06:45.11,Default,,0000,0000,0000,,received that public list and analyzes it.\NIt's checked if an application from the
Dialogue: 0,0:06:45.11,0:06:50.42,Default,,0000,0000,0000,,client that has StreetPass activated\Nmatches one of it's own applications with
Dialogue: 0,0:06:50.42,0:06:55.68,Default,,0000,0000,0000,,StreetPass activated. If it's the case, it\Nsends the probe response to the client,
Dialogue: 0,0:06:55.68,0:07:02.16,Default,,0000,0000,0000,,which will do the same. And if both peers\Nagree that they can exchange data, they
Dialogue: 0,0:07:02.16,0:07:11.43,Default,,0000,0000,0000,,will start communicating after deriving a\Ncommon key. So replicating the pairing is
Dialogue: 0,0:07:11.43,0:07:20.81,Default,,0000,0000,0000,,not super odd if you know what tool to\Nuse. I tried to reproduce the pairing
Dialogue: 0,0:07:20.81,0:07:28.47,Default,,0000,0000,0000,,using a monitor mode, but it's really hard\Nbecause you have to deal with all the
Dialogue: 0,0:07:28.47,0:07:38.01,Default,,0000,0000,0000,,action item frames et cetera. So I used\Nnl80211 which lets you register some
Dialogue: 0,0:07:38.01,0:07:44.47,Default,,0000,0000,0000,,specific callback for some specific frames\Nand send custom frames and everything is
Dialogue: 0,0:07:44.47,0:07:53.59,Default,,0000,0000,0000,,handled by your wifi adapter driver. So at\Nthat point the 3DS starts sending
Dialogue: 0,0:07:53.59,0:08:00.83,Default,,0000,0000,0000,,encrypted data and we have to decrypt\Nthem. So let's review the encryption. They
Dialogue: 0,0:08:00.83,0:08:09.98,Default,,0000,0000,0000,,do this in two passes, the first one they\Nuse an HMAC-SHA1 over both consoles CIDs
Dialogue: 0,0:08:09.98,0:08:18.27,Default,,0000,0000,0000,,and both MAC addresses and the output of\Nthis pass is used as an input counter for
Dialogue: 0,0:08:18.27,0:08:28.66,Default,,0000,0000,0000,,on AES-CTR using the AES key slot we can\Nnow get. And the output of this encryption
Dialogue: 0,0:08:28.66,0:08:37.57,Default,,0000,0000,0000,,is used as a session key for the\Ncommunication. So nl80211 lets you
Dialogue: 0,0:08:37.57,0:08:45.53,Default,,0000,0000,0000,,register CCMP keys so it's quite easy to\Nsend and receive encrypted packets using
Dialogue: 0,0:08:45.53,0:08:56.47,Default,,0000,0000,0000,,it. So now we can start reversing the\Nprotocol. Let's take a look at the
Dialogue: 0,0:08:56.47,0:09:04.10,Default,,0000,0000,0000,,structure of packets before doing any\Nreverse engineering. So I put some packets
Dialogue: 0,0:09:04.10,0:09:09.54,Default,,0000,0000,0000,,I was able to receive and the first one is\None of the smallest one you can actually
Dialogue: 0,0:09:09.54,0:09:19.45,Default,,0000,0000,0000,,observe. So first you have a header and\Nthen you have some data and you can spot
Dialogue: 0,0:09:19.45,0:09:26.83,Default,,0000,0000,0000,,some magic values here. Actually, it's\Neasy to spot them because CECD is using
Dialogue: 0,0:09:26.83,0:09:35.89,Default,,0000,0000,0000,,really recognizable magic values. It's\Nalways the same byte repeated twice. Once
Dialogue: 0,0:09:35.89,0:09:40.52,Default,,0000,0000,0000,,you know the structure of the packets, you\Ncan view that there are actually
Dialogue: 0,0:09:40.52,0:09:49.34,Default,,0000,0000,0000,,two protocols. The first one is SPTCP.\NIt's an equivalent of TCP, but for local
Dialogue: 0,0:09:49.34,0:09:55.38,Default,,0000,0000,0000,,communication. It's mainly designed to\Nensure reliability and data segmentation.
Dialogue: 0,0:09:55.38,0:10:03.79,Default,,0000,0000,0000,,And then you have SPMTP which is built\Nover SPTCP and handles all the exchange of
Dialogue: 0,0:10:03.79,0:10:11.06,Default,,0000,0000,0000,,stricter data and StreetPass messages. So\Nwe have two protocols and we need to
Dialogue: 0,0:10:11.06,0:10:18.29,Default,,0000,0000,0000,,review both of them. Let's start with\NSPTCP. Actually, there is not much to say
Dialogue: 0,0:10:18.29,0:10:29.09,Default,,0000,0000,0000,,because you only basically have to reverse\Nand understand the header. You have a
Dialogue: 0,0:10:29.09,0:10:33.57,Default,,0000,0000,0000,,magic value and some constants. But the\Nmost important field here is the flag
Dialogue: 0,0:10:33.57,0:10:39.10,Default,,0000,0000,0000,,field because if you can understand what\Nare the flags, you can understand the
Dialogue: 0,0:10:39.10,0:10:45.76,Default,,0000,0000,0000,,meaning of the packets you are sending and\Nreceiving. And so you can basically
Dialogue: 0,0:10:45.76,0:10:53.71,Default,,0000,0000,0000,,understand the protocol. And fortunately,\Nin this case, they're using the same flags
Dialogue: 0,0:10:53.71,0:11:01.95,Default,,0000,0000,0000,,as TCP, so it was really easy to\Nunderstand the protocol and how it worked.
Dialogue: 0,0:11:01.95,0:11:13.59,Default,,0000,0000,0000,,And what about SPTCP security? Actually,\Nit's OK. I did not find any bug. But the
Dialogue: 0,0:11:13.59,0:11:19.14,Default,,0000,0000,0000,,attack surface is really small. We can\Nbasically only tamper with the header and
Dialogue: 0,0:11:19.14,0:11:31.46,Default,,0000,0000,0000,,that's it. So SPMTP should be much more\Ninteresting. Let's take a look at the
Dialogue: 0,0:11:31.46,0:11:40.42,Default,,0000,0000,0000,,structure of SPMTP packets, because there\Nare actually two different packet types.
Dialogue: 0,0:11:40.42,0:11:49.90,Default,,0000,0000,0000,,The first one is an info packet. It's\Nbasically used in the handshake and it's
Dialogue: 0,0:11:49.90,0:11:56.92,Default,,0000,0000,0000,,only here to share information between\Nboth peers. And then you have message box
Dialogue: 0,0:11:56.92,0:12:03.12,Default,,0000,0000,0000,,packets which are much more interesting\Nbecause they contain actual StreetPass
Dialogue: 0,0:12:03.12,0:12:11.36,Default,,0000,0000,0000,,data and you can even spot the CECD\Nmessage via magic value, which means that
Dialogue: 0,0:12:11.36,0:12:17.65,Default,,0000,0000,0000,,we actually reach actual game data and\NSPMTP is the last layer of encapsulation
Dialogue: 0,0:12:17.65,0:12:26.05,Default,,0000,0000,0000,,of the whole protocol. So once you figure\Nout how SPMTP works, you can reimplement
Dialogue: 0,0:12:26.05,0:12:33.66,Default,,0000,0000,0000,,the protocol. So let's first review info\Npackets. There's a bunch of things in
Dialogue: 0,0:12:33.66,0:12:40.44,Default,,0000,0000,0000,,here. Many fixed size data like friend\Ncodes, MAC addresses, et cetera. It's not
Dialogue: 0,0:12:40.44,0:12:46.75,Default,,0000,0000,0000,,much interesting when you're looking for\Nvulnerabilities. There are variable size
Dialogue: 0,0:12:46.75,0:12:51.56,Default,,0000,0000,0000,,data, which are much more interesting.\NThey are sending application lists,
Dialogue: 0,0:12:51.56,0:12:59.45,Default,,0000,0000,0000,,metadata lists, and it's much more\Ninteresting because when you process them,
Dialogue: 0,0:12:59.45,0:13:06.26,Default,,0000,0000,0000,,you can fail your parser. And if there is\Nsome vulnerability here, we might exploit
Dialogue: 0,0:13:06.26,0:13:14.72,Default,,0000,0000,0000,,them to get remote execution. So let's\Ntake a look at one of this parser. This is
Dialogue: 0,0:13:14.72,0:13:23.70,Default,,0000,0000,0000,,a function that parses meta data lists. So\Nlet's focus on the for-loop. They are
Dialogue: 0,0:13:23.70,0:13:33.74,Default,,0000,0000,0000,,actually copying a list of entries to the\Nstack. The destination is on the stack and
Dialogue: 0,0:13:33.74,0:13:41.11,Default,,0000,0000,0000,,they do not check the number of entries in\Nthe list. So this is clearly a buffer
Dialogue: 0,0:13:41.11,0:13:48.42,Default,,0000,0000,0000,,overflow, but is it exploitable? Let's\Nillustrate this with a diagram. So this is
Dialogue: 0,0:13:48.42,0:13:57.13,Default,,0000,0000,0000,,a regular copy. So you have your packet\Nbuffer. And you have memcopy called on
Dialogue: 0,0:13:57.13,0:14:08.77,Default,,0000,0000,0000,,each entry and everything's is all right\Nhere. But if you had more entries, you
Dialogue: 0,0:14:08.77,0:14:15.69,Default,,0000,0000,0000,,have a bunch of entries, compete on the\Nstack, that overwrite a bunch of things.
Dialogue: 0,0:14:15.69,0:14:21.81,Default,,0000,0000,0000,,But there's a problem here, because the\Npacket buffer is not large enough for us
Dialogue: 0,0:14:21.81,0:14:32.68,Default,,0000,0000,0000,,to reach the return address on the stack.\NSo we are probably copying uncontrol data.
Dialogue: 0,0:14:32.68,0:14:39.43,Default,,0000,0000,0000,,So I was like, it's too bad, we can't do\Nanything with this, but let's check the
Dialogue: 0,0:14:39.43,0:14:44.90,Default,,0000,0000,0000,,buffer next to our packet buffer. Maybe\Nthere are some control data in there. And
Dialogue: 0,0:14:44.90,0:14:54.26,Default,,0000,0000,0000,,actually, yes, it's this buffer just\Nnext to the packet buffer, dedicated to a
Dialogue: 0,0:14:54.26,0:15:03.24,Default,,0000,0000,0000,,list that we sent just before. So actually\Nwe can rewrite the return address. So, how
Dialogue: 0,0:15:03.24,0:15:09.94,Default,,0000,0000,0000,,do we exploit it now? On the 3DS, you have\Nthe NX bit, but there is no stack cookies
Dialogue: 0,0:15:09.94,0:15:15.50,Default,,0000,0000,0000,,or no ASLR, so it's pretty\Nstraightforward. You can just embed a ROP-
Dialogue: 0,0:15:15.50,0:15:22.79,Default,,0000,0000,0000,,chain, a small ROP-chain, and then send\Nanother one in some kind of packets and
Dialogue: 0,0:15:22.79,0:15:31.23,Default,,0000,0000,0000,,stack-pivot to it. And then you get remote\Ncode execution in CECD. So this one was
Dialogue: 0,0:15:31.23,0:15:40.35,Default,,0000,0000,0000,,quite easy. Let's move on to message box\Npackets. Message box packets are packets
Dialogue: 0,0:15:40.35,0:15:48.29,Default,,0000,0000,0000,,to send a list of StreetPass messages for\Nsome specific applications. They are
Dialogue: 0,0:15:48.29,0:15:55.01,Default,,0000,0000,0000,,actually stored in some temporary files\Nfor avoiding delays and they are parsed
Dialogue: 0,0:15:55.01,0:16:02.08,Default,,0000,0000,0000,,once the communication is over. So they\Nare parsed. So let's take a look at the
Dialogue: 0,0:16:02.08,0:16:15.37,Default,,0000,0000,0000,,parser. This is the function that actually\Nloads a temp file into an associated
Dialogue: 0,0:16:15.37,0:16:24.29,Default,,0000,0000,0000,,structure on the stack and whoops, they do\Nnot check the number of messages in the
Dialogue: 0,0:16:24.29,0:16:35.01,Default,,0000,0000,0000,,box. So this is another buffer overflow.\NYou are basically overflowing the message
Dialogue: 0,0:16:35.01,0:16:43.05,Default,,0000,0000,0000,,pointers array and the message sizes\Narray. So let's treat this with another
Dialogue: 0,0:16:43.05,0:16:55.43,Default,,0000,0000,0000,,diagram. So you have on the right the temp\Nfile and on the left the stack and you see
Dialogue: 0,0:16:55.43,0:17:02.00,Default,,0000,0000,0000,,that you have this structure on the stack\Nwe can see that there is the message
Dialogue: 0,0:17:02.00,0:17:08.31,Default,,0000,0000,0000,,pointers with pointer pointing to your\Ntemp file buffer and you have the message
Dialogue: 0,0:17:08.31,0:17:17.52,Default,,0000,0000,0000,,sizes. And if you add another message in\Nthe temporary file, you overflow both
Dialogue: 0,0:17:17.52,0:17:26.98,Default,,0000,0000,0000,,arrays and start overwriting some data on\Nthe stack. We are a bit concerned because
Dialogue: 0,0:17:26.98,0:17:31.83,Default,,0000,0000,0000,,we are writing partially or uncontrolled\Ndata on the stack. Obviously you cannot
Dialogue: 0,0:17:31.83,0:17:39.44,Default,,0000,0000,0000,,control the message pointers and you can\Nnot still control message size because you
Dialogue: 0,0:17:39.44,0:17:44.91,Default,,0000,0000,0000,,can not put some arbitrary values in\Nthere. You'd have to send gigabytes of
Dialogue: 0,0:17:44.91,0:17:56.51,Default,,0000,0000,0000,,messages and you can not do that. So what\Ncan we do? What you can see here is that
Dialogue: 0,0:17:56.51,0:18:02.49,Default,,0000,0000,0000,,you can actually set the last message size\Nto an arbitrary value because they are
Dialogue: 0,0:18:02.49,0:18:10.79,Default,,0000,0000,0000,,checking if the current message being\Nparsed is actually inside of the temporary
Dialogue: 0,0:18:10.79,0:18:15.81,Default,,0000,0000,0000,,file, a buffer. And if the current message\Npointer goes out of the buffer,
Dialogue: 0,0:18:15.81,0:18:17.25,Default,,0000,0000,0000,,they break the loop
Dialogue: 0,0:18:17.25,0:18:24.11,Default,,0000,0000,0000,,without returning an error. So what you\Ncan do is set the last message size to an
Dialogue: 0,0:18:24.11,0:18:30.20,Default,,0000,0000,0000,,arbitrary value and then the pointer will\Ngo out of the buffer and you will write
Dialogue: 0,0:18:30.20,0:18:39.92,Default,,0000,0000,0000,,one 32-bit value on the stack. But we\Nneed to know what to write. You cannot,
Dialogue: 0,0:18:39.92,0:18:44.99,Default,,0000,0000,0000,,unfortunately, you cannot directly\Noverwrite the return address because
Dialogue: 0,0:18:44.99,0:18:51.81,Default,,0000,0000,0000,,remember that we are writing mainly\Nuncontrolled data and reaching the return
Dialogue: 0,0:18:51.81,0:18:59.10,Default,,0000,0000,0000,,address would require you to overwrite the\Nwhole stack frame with uncontrolled or
Dialogue: 0,0:18:59.10,0:19:07.89,Default,,0000,0000,0000,,partially uncontrolled data. So the only\Nthing I was able to rewrite without
Dialogue: 0,0:19:07.89,0:19:17.35,Default,,0000,0000,0000,,crashing the system is this particular\Nvariable. It's a pointer to a critical
Dialogue: 0,0:19:17.35,0:19:26.15,Default,,0000,0000,0000,,section and it's used for signed\Nsynchronization and mutual exclusion. And
Dialogue: 0,0:19:26.15,0:19:31.69,Default,,0000,0000,0000,,you can see it's used after the temporary\Nfile has been parsed. So maybe we can do
Dialogue: 0,0:19:31.69,0:19:36.87,Default,,0000,0000,0000,,something with it. This is the leave_critical_section\Ncall at the end of the loop
Dialogue: 0,0:19:36.87,0:19:42.91,Default,,0000,0000,0000,,iteration. And you can see that they're\Nusing the pointer to decrement some kind
Dialogue: 0,0:19:42.91,0:19:49.32,Default,,0000,0000,0000,,of count. So it's basically the number of\Nthreads that are using the critical
Dialogue: 0,0:19:49.32,0:19:55.97,Default,,0000,0000,0000,,section and we can override the lock\Npointer. So by overwriting it, we can
Dialogue: 0,0:19:55.97,0:20:03.00,Default,,0000,0000,0000,,decrement an arbitrary value in memory,\Nbut we need to find what to overwrite,
Dialogue: 0,0:20:03.00,0:20:12.86,Default,,0000,0000,0000,,that would give us more control of the\Nmemory and control the execution flow. So
Dialogue: 0,0:20:12.86,0:20:18.69,Default,,0000,0000,0000,,I've been looking for something like this\Nand I found something interesting in the
Dialogue: 0,0:20:18.69,0:20:26.61,Default,,0000,0000,0000,,function that deinitialized the structure\Nassociated to temporary files. This is the
Dialogue: 0,0:20:26.61,0:20:34.90,Default,,0000,0000,0000,,function for the structure\Ndeinitialization. And you can spot this
Dialogue: 0,0:20:34.90,0:20:42.92,Default,,0000,0000,0000,,variable. They actually implemented\Nsome kind of allocation mode. And if it's
Dialogue: 0,0:20:42.92,0:20:49.82,Default,,0000,0000,0000,,equal to pointer mode, it will not try to\Nfree the pointer. The pointers in the
Dialogue: 0,0:20:49.82,0:20:58.48,Default,,0000,0000,0000,,message pointers array. But if it's not\Npointer mode, they will free all of them.
Dialogue: 0,0:20:58.48,0:21:04.39,Default,,0000,0000,0000,,And while this value should be pointer\Nmode in any case. But we can decrement it
Dialogue: 0,0:21:04.39,0:21:13.85,Default,,0000,0000,0000,,using the the vulnerability we've seen\Nbefore. So we can get some pointer freed.
Dialogue: 0,0:21:13.85,0:21:22.38,Default,,0000,0000,0000,,And since we control everything at the\Nlocation pointed by message pointers, we can
Dialogue: 0,0:21:22.38,0:21:31.03,Default,,0000,0000,0000,,try to make it free some crafted and fake\Nchunks. But there is another problem
Dialogue: 0,0:21:31.03,0:21:38.95,Default,,0000,0000,0000,,because they're actually resetting the\Nallocation mode each time a temporary box
Dialogue: 0,0:21:38.95,0:21:48.29,Default,,0000,0000,0000,,is passed. So we have to find a solution\Nto this. And what you can do is try to
Dialogue: 0,0:21:48.29,0:21:55.41,Default,,0000,0000,0000,,make that function return early before the\Nallocation mode is restored. But this
Dialogue: 0,0:21:55.41,0:22:06.20,Default,,0000,0000,0000,,implies making it return an invalid return\Ncode. But actually, it's not a problem
Dialogue: 0,0:22:06.20,0:22:15.69,Default,,0000,0000,0000,,because they're not checking the return\Ncode. So what can we do so far with
Dialogue: 0,0:22:15.69,0:22:23.51,Default,,0000,0000,0000,,this? So you can send a first temporary\Nbox. This will overwrite the lock variable
Dialogue: 0,0:22:23.51,0:22:29.92,Default,,0000,0000,0000,,in the stack and decrement the\Nallocation mode. Then you can send your
Dialogue: 0,0:22:29.92,0:22:38.46,Default,,0000,0000,0000,,invalid second temorary box and the\Nparser will return early and the
Dialogue: 0,0:22:38.46,0:22:43.09,Default,,0000,0000,0000,,message pointers array will not be\Nupdated. And in the end, all the pointers
Dialogue: 0,0:22:43.09,0:22:51.37,Default,,0000,0000,0000,,in that particular array will be freed.\NBut since the message pointers array is
Dialogue: 0,0:22:51.37,0:22:57.75,Default,,0000,0000,0000,,not updated, the pointer in that\Nparticular array are still pointing to the
Dialogue: 0,0:22:57.75,0:23:05.85,Default,,0000,0000,0000,,first temporary file buffer\Nwhich has been freed. That's not a
Dialogue: 0,0:23:05.85,0:23:11.58,Default,,0000,0000,0000,,problem. If you send a xecond temporary\Nbox with the same size, the buffer will be
Dialogue: 0,0:23:11.58,0:23:15.76,Default,,0000,0000,0000,,re-allocated for that second\Ntemporary file and we eventually free
Dialogue: 0,0:23:15.76,0:23:25.93,Default,,0000,0000,0000,,up pointers to control the buffer. So\Nwhat's next? We can craft some fake heap
Dialogue: 0,0:23:25.93,0:23:32.92,Default,,0000,0000,0000,,chunks. We can have the application free\Nthem. What do we do? The free, yes, it is
Dialogue: 0,0:23:32.92,0:23:39.07,Default,,0000,0000,0000,,actually really insecure. You can exploit\Nthe classic unsafe linker vulnerability,
Dialogue: 0,0:23:39.07,0:23:47.65,Default,,0000,0000,0000,,so you get one arbitrary write for each\Nchunk you can free. And you still need to
Dialogue: 0,0:23:47.65,0:23:56.73,Default,,0000,0000,0000,,know what to overwrite. But you can just\Nrewrite the heap free list head pointer. So the
Dialogue: 0,0:23:56.73,0:24:04.35,Default,,0000,0000,0000,,next malloc call will return a pointer to\Nwherever you want, and you can especially
Dialogue: 0,0:24:04.35,0:24:10.47,Default,,0000,0000,0000,,put a pointer to the stack in there. So\Nthe next malloc call will return a
Dialogue: 0,0:24:10.47,0:24:20.99,Default,,0000,0000,0000,,pointer to the stack and it will be used\Nto store your third temporary file. So
Dialogue: 0,0:24:20.99,0:24:29.46,Default,,0000,0000,0000,,it's a bit hard to understand. So let's\Nagain illustrate this with a diagram. So
Dialogue: 0,0:24:29.46,0:24:35.67,Default,,0000,0000,0000,,first you have your first temporary file\Nloaded in memory. So on the right it's
Dialogue: 0,0:24:35.67,0:24:49.44,Default,,0000,0000,0000,,parsed and the associated structure is\Nwritten in stack and it overwrites the
Dialogue: 0,0:24:49.44,0:24:57.51,Default,,0000,0000,0000,,lock pointer to make it point to the alloc\Nmode in memory. In the end,
Dialogue: 0,0:24:57.51,0:25:05.07,Default,,0000,0000,0000,,leave_critical_section is called. So you have\Nyour temporary buffer freed and your location
Dialogue: 0,0:25:05.07,0:25:13.54,Default,,0000,0000,0000,,mode decremented. Then your second\Ntemporary file is loaded in memory. The
Dialogue: 0,0:25:13.54,0:25:19.16,Default,,0000,0000,0000,,buffer used for the first\Nfile is relocated and the pointers in the
Dialogue: 0,0:25:19.16,0:25:26.18,Default,,0000,0000,0000,,structure still point to our\Ncontrolled data and especially our fake
Dialogue: 0,0:25:26.18,0:25:39.48,Default,,0000,0000,0000,,chunks. So your second temporary file is\Nloaded and parsed. Then all the chunks are
Dialogue: 0,0:25:39.48,0:25:49.10,Default,,0000,0000,0000,,freed and the field it is at is moved to\Npoint on the stack. And finally, you can
Dialogue: 0,0:25:49.10,0:25:54.36,Default,,0000,0000,0000,,see that your last temporary file is\Nread in on the stack so we can overwrite
Dialogue: 0,0:25:54.36,0:26:00.89,Default,,0000,0000,0000,,the return address and put a ROP-chain in\Nthere. So this gives us a second remote
Dialogue: 0,0:26:00.89,0:26:10.07,Default,,0000,0000,0000,,code execution vulnerability in CECD. And\Nthis one this one was quite trickier. So
Dialogue: 0,0:26:10.07,0:26:18.65,Default,,0000,0000,0000,,what's next? Another one. Yeah. Again,\Nthere is another vulnerability in the
Dialogue: 0,0:26:18.65,0:26:29.88,Default,,0000,0000,0000,,message parser. It's actually an SDK\Nfunction. So any application that uses
Dialogue: 0,0:26:29.88,0:26:33.97,Default,,0000,0000,0000,,SteetPass is vulnerable, not only CECD but\Nall application and games that use
Dialogue: 0,0:26:33.97,0:26:36.36,Default,,0000,0000,0000,,StreetPass are vulnerable for this one.
Dialogue: 0,0:26:36.36,0:26:41.01,Default,,0000,0000,0000,,But I'm not going\Nto talk about it and explain everything.
Dialogue: 0,0:26:41.01,0:26:50.59,Default,,0000,0000,0000,,It's up to you to exploit it. So this\Ngives us a third Remote Code Execution in
Dialogue: 0,0:26:50.59,0:26:57.45,Default,,0000,0000,0000,,CECD and you can get Code Execution in any\Napplication using StreetPass. And this
Dialogue: 0,0:26:57.45,0:27:06.26,Default,,0000,0000,0000,,also give us a persistent backdoor in CECD\Nbecause of CECD usually parses all the
Dialogue: 0,0:27:06.26,0:27:15.26,Default,,0000,0000,0000,,messages in the in and out boxes at startup.\NSo you can trigger the vulnerability
Dialogue: 0,0:27:15.26,0:27:25.27,Default,,0000,0000,0000,,once the system boots. So we've got a\NRemote Code Execution in CECD, what can we
Dialogue: 0,0:27:25.27,0:27:34.73,Default,,0000,0000,0000,,do? No, actually, CECD does not have much\Nprivileges. It's only a userspace
Dialogue: 0,0:27:34.73,0:27:41.09,Default,,0000,0000,0000,,application. And it's pretty well\Nsandboxed. You can not access the
Dialogue: 0,0:27:41.09,0:27:49.23,Default,,0000,0000,0000,,internet, for example or not the SD card.\NSo if you want more privileges and we
Dialogue: 0,0:27:49.23,0:27:57.13,Default,,0000,0000,0000,,want more privileges, you need to take\Ncare of something else. And your
Dialogue: 0,0:27:57.13,0:28:04.98,Default,,0000,0000,0000,,best choice would be trying to take over\NARM11 Kernel, which is the kernel for the
Dialogue: 0,0:28:04.98,0:28:13.59,Default,,0000,0000,0000,,userland processor. This this would give\Nyou total control over this processor.
Dialogue: 0,0:28:13.59,0:28:18.49,Default,,0000,0000,0000,,And if you want really full system\Ncontrol, you'd like to also take over the
Dialogue: 0,0:28:18.49,0:28:25.60,Default,,0000,0000,0000,,ARM9 security processor. So this is the\Nprocessor that do all the encryption and
Dialogue: 0,0:28:25.60,0:28:34.59,Default,,0000,0000,0000,,signature stuff. And we will see this\Nlater. So let's first try to take over the
Dialogue: 0,0:28:34.59,0:28:46.47,Default,,0000,0000,0000,,ARM11 kernel. But first, I need to\Ntalk about IPC and especially
Dialogue: 0,0:28:46.47,0:28:55.64,Default,,0000,0000,0000,,what are called static buffers. So when\Nyou are doing IPC, you need to sometimes
Dialogue: 0,0:28:55.64,0:29:03.46,Default,,0000,0000,0000,,send data from a sender process to a\Nreceiver process and on the 3DS, you can
Dialogue: 0,0:29:03.46,0:29:12.17,Default,,0000,0000,0000,,do this in multiple ways. The first one is\Nif you want to send large regular
Dialogue: 0,0:29:12.17,0:29:20.02,Default,,0000,0000,0000,,buffers, you can map parts of the sender's\Nmemory into the receivers, but you can
Dialogue: 0,0:29:20.02,0:29:27.02,Default,,0000,0000,0000,,also use what are called static buffers.\NIf you want to send some small buffers,
Dialogue: 0,0:29:27.02,0:29:34.67,Default,,0000,0000,0000,,the receiver can register static buffers\Nand the ARM11 kernel will do the copy for
Dialogue: 0,0:29:34.67,0:29:42.01,Default,,0000,0000,0000,,you to that particular buffer. And\Nsometimes you need some buffers
Dialogue: 0,0:29:42.01,0:29:51.87,Default,,0000,0000,0000,,to be sent to the ARM9\Nprocessor. So the ARM11 kernel need to
Dialogue: 0,0:29:51.87,0:29:59.00,Default,,0000,0000,0000,,write some pairs of\Nphysical addresses and size to the static
Dialogue: 0,0:29:59.00,0:30:05.56,Default,,0000,0000,0000,,buffers because the ARM9 does not have an\NMMU so it's only using physical addresses
Dialogue: 0,0:30:05.56,0:30:14.97,Default,,0000,0000,0000,,and the copy of data is eventually done by\Nthe Process9, which is the only process
Dialogue: 0,0:30:14.97,0:30:23.76,Default,,0000,0000,0000,,running on the ARM9 side. So let's talk\Nabout a vulnerability now. So it's called
Dialogue: 0,0:30:23.76,0:30:32.100,Default,,0000,0000,0000,,LazyPixie and it has been found by TuxSH.\NSo it's not me. How does the kernel handle the
Dialogue: 0,0:30:32.100,0:30:44.60,Default,,0000,0000,0000,,PXI buffers case because it\Nseems a bit complicated. So first
Dialogue: 0,0:30:44.60,0:30:48.79,Default,,0000,0000,0000,,they check the alignment of the\Ndestination state buffer, they check the
Dialogue: 0,0:30:48.79,0:30:54.25,Default,,0000,0000,0000,,size of the destination static buffer.\NThey check the permissions for the source
Dialogue: 0,0:30:54.25,0:31:01.10,Default,,0000,0000,0000,,buffers. Then they do cache operations, they\Ncopy metadata. So the physical address and
Dialogue: 0,0:31:01.10,0:31:09.48,Default,,0000,0000,0000,,the size of the static buffer\Nto the destination and then the copy is
Dialogue: 0,0:31:09.48,0:31:15.83,Default,,0000,0000,0000,,done by the ARM9 side. But I think\Nthere is something missing here because
Dialogue: 0,0:31:15.83,0:31:23.87,Default,,0000,0000,0000,,they do not check the permissions for the\Ndestination buffer. So what you can do is
Dialogue: 0,0:31:23.87,0:31:30.44,Default,,0000,0000,0000,,use an arbitrary address as a destination.\NAnd so you can just overwrite the MMU
Dialogue: 0,0:31:30.44,0:31:37.86,Default,,0000,0000,0000,,table and make your kernnel read, write and\Nexecute, which is obviously enough to take
Dialogue: 0,0:31:37.86,0:31:48.89,Default,,0000,0000,0000,,it over. So at that point, the ARM11\NKernel has fallen and we have
Dialogue: 0,0:31:48.89,0:31:58.74,Default,,0000,0000,0000,,the full control of that processor. But we\Nwould like a bit more privileges because
Dialogue: 0,0:31:58.74,0:32:07.64,Default,,0000,0000,0000,,why not? We want the full system control.\NSo let's take the road to full system
Dialogue: 0,0:32:07.64,0:32:15.77,Default,,0000,0000,0000,,control and see why taking over CECD was\None of the best ideas ever. So I am going
Dialogue: 0,0:32:15.77,0:32:22.41,Default,,0000,0000,0000,,to talk about SAFEHAX. Maybe some of you\Nknow what SAFEHAX is because it's a really
Dialogue: 0,0:32:22.41,0:32:31.87,Default,,0000,0000,0000,,cool vulnerability. It's actually race a\Ncondition in the firmware header parsing
Dialogue: 0,0:32:31.87,0:32:38.41,Default,,0000,0000,0000,,you can take over the ARM9 side if you\Ncontrol the ARM11 kernel. It has
Dialogue: 0,0:32:38.41,0:32:47.17,Default,,0000,0000,0000,,been fixed in the system version 9.5 for\Nthe regular native firmware
Dialogue: 0,0:32:47.17,0:32:52.02,Default,,0000,0000,0000,,and fixed in the safe mode firmware, which\Nis basically the recovery firmware if
Dialogue: 0,0:32:52.02,0:32:58.33,Default,,0000,0000,0000,,something went wrong for your console. So\Npeople have been exploiting it both on the
Dialogue: 0,0:32:58.33,0:33:04.78,Default,,0000,0000,0000,,native firmware and the\Nsafe mode firmware and it has been
Dialogue: 0,0:33:04.78,0:33:12.96,Default,,0000,0000,0000,,mitigated in version 11.3 and 11.4. So it\Ndoes not work anymore, but it has only
Dialogue: 0,0:33:12.96,0:33:19.80,Default,,0000,0000,0000,,been mitigated and not patched. So let's\Ntake a look at that mitigation because
Dialogue: 0,0:33:19.80,0:33:26.56,Default,,0000,0000,0000,,how do they prevent us to exploit that\Nvulnerability? So this so-called
Dialogue: 0,0:33:26.56,0:33:36.82,Default,,0000,0000,0000,,mitigation is a boolean flag that has been\Nadded on the ARM9 side and when it's set to
Dialogue: 0,0:33:36.82,0:33:48.56,Default,,0000,0000,0000,,1 the system just panics. When you try to\Nlaunch the safe mode firmware. So this
Dialogue: 0,0:33:48.56,0:33:53.14,Default,,0000,0000,0000,,flag is actually set to 1 whenever you try\Nto launch an application, so this was the
Dialogue: 0,0:33:53.14,0:33:59.49,Default,,0000,0000,0000,,usual way to exploit it, you were\Nlaunching the homebrew menu through an
Dialogue: 0,0:33:59.49,0:34:07.07,Default,,0000,0000,0000,,application and then exploiting the ARM11\Nkernel and then running SAFEHAX. So they
Dialogue: 0,0:34:07.07,0:34:13.55,Default,,0000,0000,0000,,set the flag to 1 whenever you try to\Nlaunch a specific application, except some
Dialogue: 0,0:34:13.55,0:34:22.24,Default,,0000,0000,0000,,of them because your reconnection ARMs needs some\Napplications to run. So this is there is
Dialogue: 0,0:34:22.24,0:34:29.27,Default,,0000,0000,0000,,an exception for the home menu and the\Nsystem modules. And guess what? We are
Dialogue: 0,0:34:29.27,0:34:35.27,Default,,0000,0000,0000,,exploiting CCD, which is a system module\Nand we are getting Remote Code Execution
Dialogue: 0,0:34:35.27,0:34:43.09,Default,,0000,0000,0000,,in CCD. So the the flag is never set to 1\Nwhen we are getting code executing on the
Dialogue: 0,0:34:43.09,0:34:52.63,Default,,0000,0000,0000,,CCD. So with that kind of exploit. You can\Neasily replicate the initial SAFEHAX
Dialogue: 0,0:34:52.63,0:35:02.83,Default,,0000,0000,0000,,exploit. So then you get a full control,\Nremote code execution without any user
Dialogue: 0,0:35:02.83,0:35:10.13,Default,,0000,0000,0000,,interaction. And it's StreetPass and it's\Ndoing all of this thing in the background
Dialogue: 0,0:35:10.13,0:35:16.32,Default,,0000,0000,0000,,and on any firmwre version at the time\Nthis was developed because Nintendo
Dialogue: 0,0:35:16.32,0:35:28.52,Default,,0000,0000,0000,,patched it with firmware version 11.12. So\NI guess it's time for a little demo. I'm
Dialogue: 0,0:35:28.52,0:35:37.55,Default,,0000,0000,0000,,not going to do it live because I don't\Nwant to some exploits in the air. So I
Dialogue: 0,0:35:37.55,0:35:46.30,Default,,0000,0000,0000,,have a little video. So I'm running my\Nexploit on my laptop and you can see the
Dialogue: 0,0:35:46.30,0:35:52.85,Default,,0000,0000,0000,,LED is turned on to see that the exploit\Nis running in CCD. And then you once
Dialogue: 0,0:35:52.85,0:35:59.70,Default,,0000,0000,0000,,you're you can exploit and you can launch\Nthe installer for the Boot ROM exploit,
Dialogue: 0,0:35:59.70,0:36:10.46,Default,,0000,0000,0000,,for example.\N{\i1}applause{\i0}
Dialogue: 0,0:36:10.46,0:36:24.14,Default,,0000,0000,0000,,Thanks. So now, some some takeaways. Well,\Nyou'd better check your return value,
Dialogue: 0,0:36:24.14,0:36:28.96,Default,,0000,0000,0000,,really, because there's a second\Nvulnerability would have been really,
Dialogue: 0,0:36:28.96,0:36:41.80,Default,,0000,0000,0000,,really out to exploit without that\Nmistake. And really, you should not hide
Dialogue: 0,0:36:41.80,0:36:47.91,Default,,0000,0000,0000,,behind cryptography because one day your\Nencryption will be broken and this might
Dialogue: 0,0:36:47.91,0:36:59.65,Default,,0000,0000,0000,,come sooner than you think. And for this\Nspecific case, there was a bunch of dumb
Dialogue: 0,0:36:59.65,0:37:09.19,Default,,0000,0000,0000,,mistakes and basically all vulnerabilities\Nwere only buffer overflows. Then,
Dialogue: 0,0:37:09.19,0:37:16.90,Default,,0000,0000,0000,,assessing hard-to-reach features is really\Narduous. I spent a lot of time doing this,
Dialogue: 0,0:37:16.90,0:37:26.48,Default,,0000,0000,0000,,especially figuring out how to replicate\Nall the features, parts and all the
Dialogue: 0,0:37:26.48,0:37:32.83,Default,,0000,0000,0000,,different protocols involved. But\Neventually, you can get some really
Dialogue: 0,0:37:32.83,0:37:41.09,Default,,0000,0000,0000,,interesting results like this. Then, I'd\Nsay please fix your flows, and do not
Dialogue: 0,0:37:41.09,0:37:50.76,Default,,0000,0000,0000,,implement some poor mitigation, like for\NSAFEHAX. And there's things still to do on
Dialogue: 0,0:37:50.76,0:37:57.34,Default,,0000,0000,0000,,the 3DS. I think I was able to show this\Ntoday. There is, this is an amazing system
Dialogue: 0,0:37:57.34,0:38:03.83,Default,,0000,0000,0000,,you can start to work on and do some\Npractical things. And there's still things
Dialogue: 0,0:38:03.83,0:38:13.49,Default,,0000,0000,0000,,to document on the open source wiki, so\Nfeel free to contribute. So, in the end, I
Dialogue: 0,0:38:13.49,0:38:25.22,Default,,0000,0000,0000,,would like to thank @TuxSH for the\NLazyPixie and helping me getting this full
Dialogue: 0,0:38:25.22,0:38:39.27,Default,,0000,0000,0000,,chain exploit done, and @hedgeberg for\Nrecurring support with a lot of things. So
Dialogue: 0,0:38:39.27,0:38:45.23,Default,,0000,0000,0000,,now, if you have some questions, feel free\Nto ask.
Dialogue: 0,0:38:45.23,0:38:50.93,Default,,0000,0000,0000,,Herald: Thank you very much.
Dialogue: 0,0:38:50.93,0:38:54.64,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:38:54.64,0:39:02.08,Default,,0000,0000,0000,,Herald: We are very, very much on time. So\Nask any questions, but please do ask them
Dialogue: 0,0:39:02.08,0:39:13.61,Default,,0000,0000,0000,,at a microphone. Go ahead. No, I thought\Nthere was going to ask a question. No
Dialogue: 0,0:39:13.61,0:39:21.20,Default,,0000,0000,0000,,questions? Oh, the Internet has one.\NGreat.
Dialogue: 0,0:39:21.20,0:39:29.23,Default,,0000,0000,0000,,Signal angel: So, yes, we have two\Nquestions. The first one is what tools and
Dialogue: 0,0:39:29.23,0:39:34.22,Default,,0000,0000,0000,,environments do you use for your research?\NFor example, someone mentioned how do you
Dialogue: 0,0:39:34.22,0:39:40.97,Default,,0000,0000,0000,,get all the source code?\Nnba::yoh: Oh, everything on the 3DS is
Dialogue: 0,0:39:40.97,0:39:50.41,Default,,0000,0000,0000,,closed source. So you have to reverse\Nengineer everything. I used IDA and Ghidra
Dialogue: 0,0:39:50.41,0:39:57.39,Default,,0000,0000,0000,,to reverse the binaries of CCD and, yeah,\Nthat, that's it.
Dialogue: 0,0:39:57.39,0:40:08.32,Default,,0000,0000,0000,,Signal angel: OK. Thank you. We have a\Nsecond question: Is there any procedure
Dialogue: 0,0:40:08.32,0:40:13.20,Default,,0000,0000,0000,,for the Switch that is compatible with all\Nwhat you've done?
Dialogue: 0,0:40:13.20,0:40:16.11,Default,,0000,0000,0000,,nba::yoh: Sorry, could you repeat that\Nquestion?
Dialogue: 0,0:40:16.11,0:40:23.33,Default,,0000,0000,0000,,Signal angel: Well, all the things you\Nhave done, all the code. Is there anything
Dialogue: 0,0:40:23.33,0:40:28.43,Default,,0000,0000,0000,,similar for the Switch?\Nnba::yoh: I don't think there is something
Dialogue: 0,0:40:28.43,0:40:37.42,Default,,0000,0000,0000,,similar on the Switch, at least something\Nthat looks like the StreetPass feature.
Dialogue: 0,0:40:37.42,0:40:44.42,Default,,0000,0000,0000,,But I don't really know how the Switch\Nworks, I've only done things on the 3DS.
Dialogue: 0,0:40:44.42,0:40:51.93,Default,,0000,0000,0000,,Herald: OK, first question for the room.\NMicrophone: Thanks for the talk, great.
Dialogue: 0,0:40:51.93,0:40:57.80,Default,,0000,0000,0000,,Did you really need all the three\Nexploits? And which one did you use in the
Dialogue: 0,0:40:57.80,0:41:03.45,Default,,0000,0000,0000,,end for the full chain? Thanks.\Nnba::yoh: Could you repeat the question?
Dialogue: 0,0:41:03.45,0:41:07.87,Default,,0000,0000,0000,,Microphone: Did you need all the three\Nexploits that you had or could you just
Dialogue: 0,0:41:07.87,0:41:11.99,Default,,0000,0000,0000,,use the easiest one? And which one did you\Nuse in the end?
Dialogue: 0,0:41:11.99,0:41:19.65,Default,,0000,0000,0000,,nba::yoh: Well, no, you do not need all\Nthree exploits, at least in CCD. You only
Dialogue: 0,0:41:19.65,0:41:30.37,Default,,0000,0000,0000,,need one basically to get remote code\Nexecution. But I found it fun to just show
Dialogue: 0,0:41:30.37,0:41:35.57,Default,,0000,0000,0000,,all the exploits for CCD.\NHerald: Next question.
Dialogue: 0,0:41:35.57,0:41:40.08,Default,,0000,0000,0000,,Microphone: Are the StreetPass messages\Npassed to the applications even when those
Dialogue: 0,0:41:40.08,0:41:44.03,Default,,0000,0000,0000,,applications are not running? So, for\Nexample, when you have like Pokémon or
Dialogue: 0,0:41:44.03,0:41:46.67,Default,,0000,0000,0000,,something installed...\Nnba::yoh: Could you speak louder, please?
Dialogue: 0,0:41:46.67,0:41:51.26,Default,,0000,0000,0000,,Microphone: Okay. Are the applications\Nparsing the messages even if they are not
Dialogue: 0,0:41:51.26,0:41:55.45,Default,,0000,0000,0000,,running? Like, is there some sort of a\Nhandler being run by the OS even if you
Dialogue: 0,0:41:55.45,0:41:59.93,Default,,0000,0000,0000,,don't have an application running, just\Ninstalled? So that if you have a
Dialogue: 0,0:41:59.93,0:42:06.15,Default,,0000,0000,0000,,vulnerable application with the old SDK\Nbuilt in there, will it automatically
Dialogue: 0,0:42:06.15,0:42:15.05,Default,,0000,0000,0000,,parse the corrupted message?\Nnba::yoh: Could you reformulate your
Dialogue: 0,0:42:15.05,0:42:19.05,Default,,0000,0000,0000,,question? I don't understand.\NMicrophone: Okay. In your tree
Dialogue: 0,0:42:19.05,0:42:24.93,Default,,0000,0000,0000,,exploitation method, you mentioned the\Nthird method that mentions the SDK being
Dialogue: 0,0:42:24.93,0:42:26.93,Default,,0000,0000,0000,,broken.\Nnba::yoh: Yeah.
Dialogue: 0,0:42:26.93,0:42:31.49,Default,,0000,0000,0000,,Microphone: And if you have an application\Nbuilt with that old SDK, does it
Dialogue: 0,0:42:31.49,0:42:36.28,Default,,0000,0000,0000,,automatically parse the message even if\Nit's not running, so that even if you have
Dialogue: 0,0:42:36.28,0:42:41.39,Default,,0000,0000,0000,,a patched OS, but not patched\Napplications, it will still get exploited?
Dialogue: 0,0:42:41.39,0:42:49.00,Default,,0000,0000,0000,,nba::yoh: Yeah, all the applications using\Nthe SDK should be updated to fix the
Dialogue: 0,0:42:49.00,0:42:59.95,Default,,0000,0000,0000,,vulnerability. So the exploit is triggered\Nwhen the application parsed the messages.
Dialogue: 0,0:42:59.95,0:43:10.54,Default,,0000,0000,0000,,So you have to run the application to\Nexploit it. CCD has been patched, so there
Dialogue: 0,0:43:10.54,0:43:20.93,Default,,0000,0000,0000,,is no more remote code execution in CCD,\Nnor a permanent backdoor in CCD, that
Dialogue: 0,0:43:20.93,0:43:29.16,Default,,0000,0000,0000,,automatically runs, when the system is\Nstarted. But you can probably still
Dialogue: 0,0:43:29.16,0:43:34.43,Default,,0000,0000,0000,,exploit games and applications that use\Nthe old SDK.
Dialogue: 0,0:43:34.43,0:43:39.16,Default,,0000,0000,0000,,Microphone: Okay, thanks.\NHerald: There's a question over there.
Dialogue: 0,0:43:39.16,0:43:44.10,Default,,0000,0000,0000,,Microphone: Yes. Can you go back to the\Nslide where you showed how the encryption
Dialogue: 0,0:43:44.10,0:43:46.61,Default,,0000,0000,0000,,for the packets worked?\Nnba::yoh: The encryption?
Dialogue: 0,0:43:46.61,0:44:12.36,Default,,0000,0000,0000,,Microphone: Yes, the encryption. Yeah.\NYeah. That one. So my question is, if all
Dialogue: 0,0:44:12.36,0:44:18.72,Default,,0000,0000,0000,,you're, if the only thing that you're\Nchanging is the counter, and the data is
Dialogue: 0,0:44:18.72,0:44:24.16,Default,,0000,0000,0000,,constant and the key is constant, and it's\NCTR, then you're basically just XOring a
Dialogue: 0,0:44:24.16,0:44:33.77,Default,,0000,0000,0000,,known block with your HMAC output. So why\Ndo you even need the key here?
Dialogue: 0,0:44:33.77,0:44:42.91,Default,,0000,0000,0000,,nba::yoh: Well, the counter changed every\Ntime you start a new StreetPass
Dialogue: 0,0:44:42.91,0:44:50.44,Default,,0000,0000,0000,,communication, because the CID's are\Nrandomized and the MAC address is, the MAC
Dialogue: 0,0:44:50.44,0:44:55.56,Default,,0000,0000,0000,,address is also randomized before starting\Na new communication.
Dialogue: 0,0:44:55.56,0:45:01.27,Default,,0000,0000,0000,,Microphone: Right. But I guess what I'm\Nasking is, why do you need key slot 2E? In
Dialogue: 0,0:45:01.27,0:45:08.31,Default,,0000,0000,0000,,my mind, having the CCD HMAC key would be\Nenough, because you can just XOR the, you
Dialogue: 0,0:45:08.31,0:45:13.92,Default,,0000,0000,0000,,know, output of that with the final\Noutput, and that removes, you know, the
Dialogue: 0,0:45:13.92,0:45:20.28,Default,,0000,0000,0000,,CTR part, and now you have the raw output\Nof the null block encrypted with key slot
Dialogue: 0,0:45:20.28,0:45:27.11,Default,,0000,0000,0000,,2E, which is always going to be constant,\Nand then you can just XOR whatever output
Dialogue: 0,0:45:27.11,0:45:32.60,Default,,0000,0000,0000,,to get the final result, right?\Nnba::yoh: Yeah, well I'm not super
Dialogue: 0,0:45:32.60,0:45:41.56,Default,,0000,0000,0000,,familiar with all the cryptography, but\Nmaybe we could talk about it. I was just
Dialogue: 0,0:45:41.56,0:45:50.77,Default,,0000,0000,0000,,putting this for, for people to reproduce\Nit if they want.
Dialogue: 0,0:45:50.77,0:46:01.58,Default,,0000,0000,0000,,Herald: Okay. Are there any more\Nquestions? Thank you so much.
Dialogue: 0,0:46:01.58,0:46:03.55,Default,,0000,0000,0000,,nba::yoh: Thanks.
Dialogue: 0,0:46:03.55,0:46:04.55,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:46:04.55,0:46:07.64,Default,,0000,0000,0000,,{\i1}postroll music{\i0}
Dialogue: 0,0:46:07.64,0:46:29.00,Default,,0000,0000,0000,,subtitles created by c3subtitles.de\Nin the year 2020. Join, and help us!