WEBVTT 00:10.060 --> 00:12.240 Alright, we're still getting that challenge ready. 00:12.240 --> 00:14.560 I want to go ahead and give everybody an update of just kind of where we're at. 00:14.560 --> 00:16.420 Again, this is the final round. 00:16.620 --> 00:19.440 We've got MMM and we've got Hypeboy. 00:19.440 --> 00:21.200 We had just the closest match. 00:21.200 --> 00:25.820 They were both running locally, but the payloads weren't working remotely. 00:25.820 --> 00:28.280 We're not sure why exactly that, we're going to have to go back and look at it. 00:28.280 --> 00:31.960 We did have one, our test solver script, we were running at the same time. 00:31.960 --> 00:37.080 We were running that remotely on the same server at the same time, just to verify it was still solvable. 00:37.220 --> 00:42.100 That was still working, so we're pretty confident that the challenge wasn't broken, but we're hitting our time limit. 00:42.100 --> 00:49.840 And unfortunately, because we have a hard stop that we have to attend to and we want to have consistent rules, we had to pull that challenge back at the 50-minute mark. 00:49.840 --> 00:52.940 Every challenge in live CTF this year only runs for 50 minutes. 00:53.220 --> 00:56.960 And so we've got our sudden death challenge in, which is even easier. 00:57.780 --> 00:58.780 We sure hope. 00:58.820 --> 01:00.220 This one should be really, really fast. 01:00.220 --> 01:01.680 All the sudden death ones are very, very quick. 01:01.680 --> 01:03.100 It's just even more nerve-wracking. 01:03.100 --> 01:05.020 I feel awful for the players. 01:05.020 --> 01:06.680 I know how stressful that can be. 01:06.720 --> 01:08.340 We're preparing that right now. 01:08.340 --> 01:10.800 We're getting it in the system. 01:11.420 --> 01:14.340 And hopefully we'll be prepared for that soon. 01:18.980 --> 01:20.680 They're getting the config as real. 01:20.680 --> 01:22.460 They're letting the competitors know. 01:22.820 --> 01:24.280 So we'll be back shortly. 01:25.280 --> 01:26.860 What a nail-biter. 01:27.520 --> 01:30.360 So I'm going to pull up the chat again and see if we've missed anything. 01:31.600 --> 01:39.600 So the question in chat that I saw was, because this is a double elimination tournament, if MMM wins, will there be another round? 01:39.600 --> 01:40.940 And unfortunately, no. 01:40.940 --> 01:42.520 This is the last round. 01:42.520 --> 01:50.260 The rules that we published and gave to all the teams several days ago, we basically said the competition is double elimination until the very, very end. 01:50.260 --> 01:56.940 So if you actually look at the livectf.com bracket that's been posted, there is no other match. 01:56.940 --> 01:58.020 This is the last match. 01:58.020 --> 01:59.660 Win or lose, this is it. 01:59.800 --> 02:05.260 It would be a bummer if Hypeboy doesn't get a second chance, but we didn't have enough time on the schedule. 02:05.260 --> 02:08.660 We didn't have enough ability to run that in. 02:08.660 --> 02:13.180 Also, this is a way that you sometimes run double elimination matches. 02:13.260 --> 02:16.520 It sounds like we're ready, so let's go ahead and queue up the competitors. 02:16.520 --> 02:20.300 Let them know that they should be on the page, and we'll do the countdown. 02:20.300 --> 02:25.300 Looks like they're both there right now, so let's go ahead and put this in. 02:25.560 --> 02:30.580 5, 4, 3, 2, 1, go! 02:30.580 --> 02:31.100 And here we go. 02:31.100 --> 02:33.180 And we have the Sudden Death Challenge started. 02:33.180 --> 02:34.560 And this is going to decide... 02:34.560 --> 02:35.980 I know nothing about this challenge. 02:35.980 --> 02:36.540 Do you know? 02:36.540 --> 02:37.960 I know a little bit of this challenge. 02:37.960 --> 02:39.880 This challenge is called Hopscotch. 02:40.980 --> 02:54.720 So they made some changes to it throughout the development, but the basic idea is that you write shellcode, but you control, I think, you control four bytes, and then there are four bytes that you don't control, and so on, repeating. 02:54.780 --> 02:59.640 So basically two bytes of shellcode payload plus a two-byte jump over the next four, and you can arrange anything you want. 02:59.980 --> 03:07.080 As I said, I might not have the latest version of the challenge in my mind, but I think it's something like this. 03:07.500 --> 03:12.460 Just like you said, a two-byte useful, two-byte relative jump, and you continue like that. 03:12.460 --> 03:17.640 I've had a very real-world thing similar to that, actually, many years ago, where I had to write a similar payload. 03:17.640 --> 03:21.300 I got real good at knowing all the one- and two-byte opcodes in the manual. 03:21.320 --> 03:24.580 So Hypeboy went to the debugger very, very quickly as the first thing that they did. 03:25.120 --> 03:30.120 MMM, I saw they pulled it up in IDA earlier, and they're back now. 03:30.120 --> 03:33.380 They're already copying in the remote address, by the way, this time. 03:33.440 --> 03:44.100 In a lot of the matches, we've seen the players not do that until they're actually throwing it against the remote, but now they got it immediately there just to have it so that there's nothing once they have the solution. 03:44.280 --> 03:46.500 It is appropriate that, again, this is another shellcoding. 03:46.500 --> 03:51.480 This is our sudden-death shellcoding challenge, which makes it appropriate for this particular one. 03:52.120 --> 03:53.220 Here it is. 03:53.240 --> 03:56.340 And, yes, the challenges will be all in GitHub like last year. 03:56.340 --> 04:00.500 So we will publish all of the solutions, all of the challenges, all of our solutions anyways. 04:00.500 --> 04:02.380 The teams are welcome to publish theirs as well. 04:03.560 --> 04:10.020 So I see here, and I remember the shell script, their export script was that they were just throwing shellcode immediately. 04:10.240 --> 04:11.340 I mean, this is sudden death. 04:11.340 --> 04:13.740 It's an easy challenge, but it's not that easy. 04:14.180 --> 04:15.500 It's a little more than that. 04:15.500 --> 04:19.600 So maybe they just did that without even... they just tried it. 04:19.600 --> 04:21.680 Like, I don't know, just in case or something. 04:22.580 --> 04:23.780 Without even seeing it. 04:23.780 --> 04:25.680 Yeah, it's very nice. 04:25.680 --> 04:30.060 But I want to switch over to Hypevoid because here we have some actual debugging and stuff going on. 04:30.060 --> 04:34.060 And if they're looking at this stream, the awesome stream, you can see what was written out. 04:34.060 --> 04:37.580 So they're looking at what bytes were changed, how things have been modified. 04:37.660 --> 04:44.060 Now, are the bytes in between actually totally rewritten, or are they just randomized? 04:44.060 --> 04:45.800 Do we know what happens to those bytes? 04:45.800 --> 04:48.180 So I actually don't remember that part. 04:48.220 --> 04:51.100 But if I remember, I think it's a specific byte. 04:51.100 --> 04:54.640 It's a specific byte value that just gets placed there. 04:54.640 --> 04:55.300 Written each time. 04:55.300 --> 04:55.900 Yeah. 04:57.080 --> 05:00.360 But, you know, don't quote me on that. 05:00.440 --> 05:03.180 And we're seeing Hypevoid have that same kind of workflow as before, right? 05:03.180 --> 05:05.560 They're still using that same online assembler, disassembler. 05:05.560 --> 05:07.220 They use that to kind of go back and forth. 05:07.340 --> 05:07.880 It is interesting. 05:07.880 --> 05:11.800 Some people end up using, like, a little command line tool. 05:11.800 --> 05:19.020 Like , you know, I had, like, dis.sh or, you know, asm.sh or a little REPL that they'll put something like Capstan into. 05:19.400 --> 05:22.320 And then, actually, over there on MMM, what's going on over there? 05:22.320 --> 05:22.600 Right. 05:22.600 --> 05:27.080 So it looks like they're putting together a shellcode. 05:29.160 --> 05:32.540 And maybe they are going to attempt something like what you did. 05:32.540 --> 05:34.620 It looks like they're just getting the instructions there. 05:34.620 --> 05:43.120 Maybe they will, you know, do the assembly to get the various bytes and then try to maybe piece this together with some jumps or something else. 05:43.120 --> 05:46.220 So we'll see how that goes. 05:46.220 --> 05:50.340 You see one function there just called remap page as read and executable. 05:50.980 --> 05:56.680 And then the, yeah. 05:56.680 --> 05:59.880 So we have the export script there with what they are trying to do. 06:00.380 --> 06:05.040 Over on Hypeboy, what I've seen, you can see the writing there, again, the hand-coded assembly. 06:05.040 --> 06:06.280 So they're doing a similar kind of approach. 06:06.280 --> 06:12.460 We've got these two-byte opcodes of the moves, single XOR reg reg. 06:14.260 --> 06:21.740 Oh, so if I understand correctly, they are doing the, you see they add some NOPs there? 06:21.740 --> 06:21.940 Yes. 06:21.940 --> 06:26.020 So they are kind of emulating the, like, the modified bytes. 06:26.020 --> 06:27.440 Is it only a single byte that's being written? 06:27.440 --> 06:29.540 So this is where I might have been wrong. 06:29.540 --> 06:33.160 It might have been, like, you had a few bytes then or something like this. 06:34.080 --> 06:36.600 If it's only a single byte that's being written, then I really like that approach. 06:36.600 --> 06:37.120 There's no jumps needed. 06:37.120 --> 06:38.220 You know what it could be? 06:38.220 --> 06:45.760 It could be that they are just adding those NOPs as kind of, like, delimiters to know how to cut up the byte string afterwards. 06:45.780 --> 06:46.400 That's a good point, too. 06:46.400 --> 06:48.040 They could be then reassembling it later. 06:48.040 --> 06:49.700 So, like, you assemble. 06:49.840 --> 06:52.480 Because if you just assemble your shellcode, you would just get a string of bytes. 06:52.480 --> 06:57.680 And you don't know, like, what bytes correspond to what instructions unless you're using some specific tooling for that. 06:57.680 --> 07:03.220 So, like, an easy and hacky way of doing that is to just put that NOP instruction in between each instruction. 07:03.220 --> 07:05.980 Then you can easily see these bytes are... 07:05.980 --> 07:09.480 It would be kind of, like, similar, like, to just assembling one instruction at a time. 07:09.480 --> 07:11.460 But you're doing it in one go, maybe. 07:12.700 --> 07:13.360 Here we go. 07:13.360 --> 07:16.120 So you notice they've got that sleep in there. 07:16.860 --> 07:19.620 I think we're seeing the sleep over on Hypeboy's payload. 07:19.620 --> 07:22.700 Because I think they're a little cautious about, like, the network socket, the remote. 07:22.700 --> 07:25.120 It may be in their head. 07:25.400 --> 07:27.240 They want to run up on something. 07:27.380 --> 07:28.740 Are we possibly this close? 07:28.740 --> 07:30.180 Are we still just looking at how it's working? 07:30.560 --> 07:32.260 It's hard to tell. 07:32.260 --> 07:35.720 Like , you know, when they're running these debuggings, you start to see, you know, is it... 07:36.300 --> 07:38.600 So they've got a full payload now. 07:38.960 --> 07:41.040 And they're going to write that payload into the buffer. 07:41.060 --> 07:41.340 Right. 07:41.340 --> 07:43.520 So they do a staged approach to this one as well. 07:43.520 --> 07:44.620 So they think their stager is working. 07:44.620 --> 07:47.400 They're going to go ahead and test it and see if it works. 07:47.760 --> 07:48.440 But they might still be... 07:48.440 --> 07:49.900 So they're still looking at the payload. 07:49.900 --> 07:50.600 They want to watch it run. 07:50.600 --> 07:51.800 They're going to check their registers. 07:51.800 --> 07:52.340 Yeah. 07:52.580 --> 07:53.300 And then... 07:53.300 --> 07:56.340 Well, I think there was almost working, but there was this... 07:56.340 --> 07:58.280 There's something... 07:58.280 --> 08:00.280 I think there's something that's off. 08:01.420 --> 08:02.600 It's encircling our assignment. 08:02.600 --> 08:03.080 Yeah. 08:03.080 --> 08:07.120 Some, you know, a little bit of, you know, frustration or thinking about that. 08:09.140 --> 08:09.940 But it's... 08:09.940 --> 08:13.040 It seems like they have most of what they need. 08:13.040 --> 08:13.280 Yeah. 08:13.280 --> 08:16.800 Is it the REX instruction that it's being inserted in between? 08:16.800 --> 08:20.680 Well, I don't think I even know what that instruction does. 08:20.680 --> 08:22.380 Well, the REX is right on 64-bit, right? 08:22.380 --> 08:23.660 Isn't that what puts it in? 08:24.360 --> 08:28.260 It's a prefix specifically if it's for... 08:28.260 --> 08:29.560 Oh, right. 08:29.860 --> 08:30.020 Yes. 08:30.220 --> 08:31.280 64-bit or 32-bit. 08:31.280 --> 08:31.880 It was part of... 08:31.880 --> 08:33.780 Most of my shellcoding days were all 32-bit. 08:33.780 --> 08:34.940 I'm just that ancient. 08:35.460 --> 08:37.020 But I believe the REX prefix is... 08:37.020 --> 08:40.000 So how will that modify or how will that change the behavior of... 08:40.000 --> 08:41.180 No, the trick is you just don't want... 08:41.180 --> 08:42.380 You want to avoid it entirely, right? 08:42.380 --> 08:44.320 The answer is your payload should just work around it. 08:44.320 --> 08:44.640 Right . 08:44.640 --> 08:48.600 And in this case, I was just thinking about why... 08:49.180 --> 08:53.560 How did their shellcode behave differently due to those REX bytes? 08:55.380 --> 08:57.620 We're dividing a pointer. 08:57.620 --> 08:58.420 This is interesting. 08:58.420 --> 09:01.660 So what's... 09:01.660 --> 09:04.420 Yeah, I'm wondering how much... 09:04.420 --> 09:05.500 Because, again, there's a lot of ways you could do this. 09:05.500 --> 09:10.140 You could try to account for the bytes that are being written by working them into a working functional command. 09:10.680 --> 09:17.420 We've seen the pop immediate 8-bit, for example, would be one way you could eat a single byte afterwards. 09:17.640 --> 09:17.820 Right . 09:17.820 --> 09:18.720 Or pop... 09:18.720 --> 09:21.740 And now we have the jump approach here going on. 09:21.840 --> 09:22.720 We will see it here. 09:22.720 --> 09:25.860 You can see a push, jump, and they're adding the labels. 09:25.980 --> 09:30.300 And they're just doing the relative jumps to this. 09:30.660 --> 09:34.360 So this, I think, is definitely the way to go, right? 09:34.820 --> 09:35.600 Well, sort of. 09:35.600 --> 09:37.620 Except that push zero, we don't have a size on it. 09:37.620 --> 09:42.620 So depending on if you've got a push zero and it's like a 32-bit immediate, you're going to write five bytes. 09:43.000 --> 09:44.720 So A is actually... 09:44.720 --> 09:45.060 Yeah, but I think... 09:45.060 --> 09:45.160 Right ? 09:45.160 --> 09:46.020 That's not going to be... 09:46.020 --> 09:48.220 No, so let's see. 09:48.240 --> 09:48.600 Push... 09:48.600 --> 09:52.340 I would have just done four nops under that A label if I wanted to skip over the A label. 09:52.340 --> 09:54.060 In fact, actually, I would have used another label. 09:54.440 --> 09:57.420 I just would have put the label after and jumped straight to the label, right? 09:57.420 --> 10:00.020 And then have my garbage there. 10:01.480 --> 10:07.700 Oh, you're saying you put your jump instruction and you put four nops or something. 10:07.700 --> 10:07.980 Exactly. 10:07.980 --> 10:09.240 Like fake nops. 10:09.240 --> 10:10.080 Just put anything you want to get rid of. 10:10.080 --> 10:12.820 And then you do the label instead of doing the label plus an offset. 10:12.840 --> 10:14.240 I feel like you're just setting yourself up for it. 10:17.900 --> 10:20.060 I actually think that push zero is a bad idea. 10:20.060 --> 10:21.760 Because I think it's going to default to five bytes. 10:21.760 --> 10:22.700 It's going to be a... 10:22.700 --> 10:23.680 Was it 68? 10:23.680 --> 10:27.020 Right, because there is no immediate... 10:28.360 --> 10:33.380 Is there no 16-bit push immediate instruction? 10:33.380 --> 10:34.720 No , it's only 8 and 64. 10:34.720 --> 10:44.020 Right, so you would have to do something like XOR racks, racks, push racks instead to get that. 10:45.820 --> 10:47.140 Or something like this. 10:47.140 --> 10:48.340 Let's see. 10:49.260 --> 10:54.240 They're jumping over the A1, but I feel like I still don't see... 10:54.240 --> 11:00.900 If the bytes that are being written, if those are multiple bytes, I would expect to see multiple bytes of just not padding or something, right? 11:00.940 --> 11:01.040 Yeah . 11:01.040 --> 11:02.900 Just put a DB. 11:03.540 --> 11:04.120 Right. 11:04.120 --> 11:06.800 But I mean, this is kind of going in the right direction. 11:06.800 --> 11:14.060 But I guess it takes a little while to wrap your head around this way of thinking with the shellcode and do that in an efficient way. 11:14.200 --> 11:15.420 Let's check back in with... 11:15.420 --> 11:15.620 Hi , boy. 11:15.620 --> 11:16.220 It's been a little bit. 11:16.220 --> 11:17.360 So we've got a whole bunch of A's. 11:17.460 --> 11:19.120 Always a good sign. 11:19.240 --> 11:19.660 Yeah. 11:21.100 --> 11:22.580 It's a buffer overflow. 11:23.060 --> 11:24.700 So a push 44. 11:28.060 --> 11:28.420 So... 11:28.420 --> 11:30.700 And they're verifying that value. 11:30.800 --> 11:31.480 What have we got here? 11:31.480 --> 11:32.220 Okay, so I do... 11:32.220 --> 11:35.480 Okay, now we do see two byte NOPs here. 11:35.480 --> 11:38.040 So we've got two NOPs, or actually more than that in a row. 11:38.040 --> 11:38.960 We've got three. 11:40.540 --> 11:45.840 Okay, so they're doing an interesting pattern. 11:45.840 --> 11:49.440 So it may be that the bytes that are being overwritten are not necessarily contiguous, too. 11:49.440 --> 11:50.480 So if they've... 11:50.480 --> 11:53.340 I think actually one thing it would have been to do is just write in a bunch of nulls. 11:53.340 --> 11:59.960 It probably would have been easier to write a whole bunch of nulls if you could send those and then just see what bytes it ended up at. 11:59.960 --> 12:01.740 It might have been an easier hint. 12:01.740 --> 12:07.420 It certainly would have helped us poor presenters as we tried to do it as we were watching them solve it. 12:07.420 --> 12:14.680 But I'm more confident, at least right now, in the way Hypeboy's payload is looking. 12:14.880 --> 12:18.440 Just looking at it as it has those NOPs kind of built in. 12:18.440 --> 12:20.220 There's a syscall and a read there. 12:21.280 --> 12:23.020 NOPREX, NOPREX, PUSH. 12:23.020 --> 12:26.440 Yeah, but I really thought I saw a... 12:27.900 --> 12:30.000 Okay, so they're checking the register value. 12:30.120 --> 12:30.960 Yeah. 12:31.340 --> 12:32.580 And RCX is not good. 12:32.580 --> 12:33.720 So they're going to need another... 12:33.720 --> 12:35.440 Yeah, so they're working on... 12:40.660 --> 12:41.920 Shift left. 12:42.360 --> 12:43.900 Okay, interesting. 12:44.340 --> 12:47.200 You probably need RCX if it's the whole width measure. 12:47.200 --> 12:49.660 That'll encode more efficiently instead of like the CL. 12:51.540 --> 12:53.060 No, no, but it's shifting... 12:53.060 --> 12:55.460 Because they had a small number and they wanted a larger number. 12:55.460 --> 13:01.160 I think they didn't care about the specific value, right? 13:01.160 --> 13:03.680 Maybe they just wanted a larger number or... 13:04.680 --> 13:05.800 They're trying to... 13:05.800 --> 13:11.640 It seems like they're trying to piece this together from these small instructions. 13:12.480 --> 13:16.560 Oh, is it possible that they are like doing... 13:17.780 --> 13:21.520 Basically making the REX a prefix of the NOP instruction? 13:21.520 --> 13:22.500 Yeah, they've done it several times. 13:22.500 --> 13:23.600 You can actually see them stepping through it. 13:23.600 --> 13:24.420 Right, right. 13:24.420 --> 13:28.360 So you effectively then get three bytes of useful... 13:28.360 --> 13:29.380 You do like... 13:29.380 --> 13:41.380 In each four byte block, you do NOP and then your three bytes of whatever useful stuff, which is actually more efficient than the two bytes plus the relative jump that we were talking about, which MMM is doing. 13:41.380 --> 13:42.580 So this is actually... 13:42.580 --> 13:43.160 I didn't... 13:43.160 --> 13:47.220 So now I'm starting to understand what the NOP idea actually is. 13:47.220 --> 13:49.320 Okay, this makes now complete sense to me. 13:49.320 --> 13:50.500 And I think this is... 13:50.500 --> 13:54.100 I think it's both easier to write and more efficient. 13:54.100 --> 13:55.500 Absolutely, because you're going to get... 13:55.500 --> 13:58.880 For every sort of chunk of unobfuscated stuff, you're going to get three... 13:58.880 --> 14:05.320 And you don't need to fiddle with the labels and stuff when you're writing your assembly. 14:05.460 --> 14:08.260 As long as you put your NOPs... 14:08.260 --> 14:12.500 And you do have to be a little careful, because some of those prefixes can do weird things. 14:13.060 --> 14:14.760 But again, they're stepping through it in the debugger. 14:14.760 --> 14:16.340 As long as the debugger doesn't change the behavior... 14:16.340 --> 14:18.120 Okay, that's off the end. 14:18.560 --> 14:19.980 Where are we at now? 14:20.260 --> 14:25.500 Okay, so now it looks like they're just doing them basically one instruction at a time, inserting it. 14:25.500 --> 14:27.280 So you get the three byte instruction there. 14:27.320 --> 14:28.760 We've seen this pretty consistently. 14:28.760 --> 14:29.060 Right. 14:29.060 --> 14:30.700 It really doesn't do a lot of... 14:31.180 --> 14:35.800 So I would say that this approach is marching steadily towards the answer. 14:35.800 --> 14:36.180 Yes. 14:36.180 --> 14:37.840 And it will work. 14:37.840 --> 14:40.260 The question is, will MMM catch up? 14:40.260 --> 14:43.940 Let's go ahead and take a look back at MMM and see what they're up to as well. 14:43.940 --> 14:47.140 So again, if they've got a full solution, although... 14:47.140 --> 14:48.880 Yeah, so we're still seeing the NOPs, right? 14:48.880 --> 14:51.280 We're seeing single instructions and then jumps and then... 14:51.280 --> 14:54.140 But you can see there at the top, you don't have the push anymore. 14:54.140 --> 14:56.900 You have a XOR AX AX. 14:57.840 --> 15:03.060 So you don't have the push with the immediate, which you pointed out would be an issue. 15:04.660 --> 15:05.620 Was that a solution? 15:05.620 --> 15:07.600 That is... 15:07.600 --> 15:09.260 That is there. 15:09.360 --> 15:10.360 Is that it? 15:10.380 --> 15:11.720 Let me get a... 15:12.380 --> 15:13.140 That's it. 15:13.140 --> 15:14.140 We have a winner. 15:14.360 --> 15:16.160 Congratulations, MMM. 15:18.080 --> 15:18.940 Oh my God. 15:18.940 --> 15:19.720 Clearly it works. 15:19.720 --> 15:20.520 Yeah, it works. 15:20.520 --> 15:21.040 Clearly it works. 15:21.040 --> 15:22.580 It can't argue with success. 15:22.580 --> 15:25.640 Yeah , that's really cool. 15:25.980 --> 15:26.840 That was... 15:26.840 --> 15:27.880 Oh my God. 15:28.140 --> 15:30.520 Congratulations first to both of our finalists. 15:30.520 --> 15:31.280 Yeah, that was... 15:31.280 --> 15:32.200 They're both unbelievable. 15:32.200 --> 15:32.820 They're both fantastic. 15:32.820 --> 15:33.560 Really well played. 15:34.520 --> 15:35.440 Best of luck. 15:35.440 --> 15:38.820 I'm sorry, Hypeboy, we don't have another round for you to be able to try one more time. 15:39.180 --> 15:40.680 But that was fantastic. 15:40.680 --> 15:44.720 We have to get all the scores over to Nautilus. 15:44.720 --> 15:45.620 We got to get the scoreboard. 15:45.620 --> 15:48.140 All the teams are going to go to the final awards ceremony. 15:48.140 --> 15:48.640 Yeah. 15:48.720 --> 15:53.520 And we want to also bring out the live CTF team here too. 15:53.520 --> 15:53.820 Right. 15:53.820 --> 15:55.740 We've had a lot of folks that you haven't seen on camera. 15:55.740 --> 15:56.120 Right. 15:56.120 --> 15:59.940 So basically, just to give a very short recap. 15:59.940 --> 16:06.220 So over these three days, we have run this knockout tournament that's been running as a sub-event of the DEFCON CTF. 16:06.220 --> 16:14.580 We've had all the 12 teams of the DEFCON CTF finals participating in this double elimination, one-on-one bracket, where they each send one person to play. 16:14.580 --> 16:16.260 First one to solve goes on. 16:16.260 --> 16:18.680 The other person, you know, loses. 16:20.040 --> 16:25.080 And yeah, we will, you know, we're going to wrap it up here very soon. 16:25.280 --> 16:30.920 And we will be, we will have recordings of all the matches that we have casted. 16:30.920 --> 16:38.560 We will be publishing all the challenges on our GitHub together with some information about which team played in which match and links to the vaults and everything. 16:38.560 --> 16:40.500 So, you know, if you missed anything, you can go back and watch. 16:40.500 --> 16:41.960 You can try the challenges yourself. 16:41.960 --> 16:44.440 I think we will try to get the solve times as well. 16:44.440 --> 16:47.820 So you can try to like, you know, try to benchmark yourself against those players. 16:47.820 --> 16:51.120 We do know, for example, that we had also some network issues on one of the days. 16:51.120 --> 16:53.540 So we're going to make sure we upload, like, the full quality videos. 16:53.540 --> 16:54.880 So we'll do separate matches. 16:55.400 --> 16:57.360 And you can, yeah, we want to see some races. 16:57.360 --> 16:59.520 Maybe in the future we'll let you race live. 16:59.520 --> 17:02.040 We'll list your challenges as the competitors see it too. 17:02.040 --> 17:03.860 And you and the audience. 17:03.960 --> 17:06.840 Let's get the rest of our live CTF crew up here. 17:07.460 --> 17:10.960 Thanks to all of everybody that was a part of this. 17:11.820 --> 17:12.800 That's what Zoom is for. 17:12.800 --> 17:13.600 We'll Zoom out. 17:13.600 --> 17:18.600 So we've had a bunch of us. 17:19.260 --> 17:24.880 Okay, we have a lot of us people here who have been contributing to this. 17:25.260 --> 17:30.780 We've had multiple commentators including Josh and Mark here. 17:30.780 --> 17:32.600 Thanks to Gamoza for coming out. 17:33.340 --> 17:34.740 And this one is on the team. 17:35.580 --> 17:36.720 That's all right. 17:37.560 --> 17:38.960 Do you want to join us? 17:39.860 --> 17:41.060 Do you want to come on camera? 17:41.900 --> 17:43.400 Do you want to come on camera? 17:44.520 --> 17:45.580 All right. 17:45.580 --> 17:46.740 So we'll get the last one. 17:46.740 --> 17:47.460 We'll get everybody out here. 17:47.460 --> 17:51.380 Yeah, just trying to get everyone here to close out this thing. 17:51.480 --> 17:57.900 That last race challenge was actually a last-minute surprise for Kat who joined us. 17:58.080 --> 17:59.860 So awesome. 17:59.880 --> 18:00.900 All right, we got everybody. 18:00.900 --> 18:01.480 That's it. 18:01.480 --> 18:03.040 I guess that's it for everyone. 18:03.040 --> 18:04.360 We'll say goodbye. 18:04.360 --> 18:04.960 Say goodbye. 18:05.220 --> 18:06.020 Bye.