[00:10.060 --> 00:14.560] Alright, we're still getting that challenge ready. I want to go ahead and give everybody an update of just kind of where we're at. [00:14.560 --> 00:21.200] Again, this is the final round. We've got MMM and we've got Hypeboy. 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:47.000] And unfortunately, because we have a hard stop that we have to attend to and we want to have consistent rules, [00:47.000 --> 00:49.840] 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 --> 01:01.680] We sure hope. This one should be really, really fast. All the sudden death ones are very, very quick. [01:01.680 --> 01:06.680] It's just even more nerve-wracking. I feel awful for the players. I know how stressful that can be. [01:06.720 --> 01:10.800] We're preparing that right now. 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:22.460] They're getting the config as real. 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:34.920] So the question in chat that I saw was, [01:34.920 --> 01:39.600] because this is a double elimination tournament, if MMM wins, will there be another round? [01:39.600 --> 01:42.520] And unfortunately, no. This is the last round. [01:42.520 --> 01:45.660] The rules that we published and gave to all the teams several days ago, [01:45.660 --> 01:50.260] we basically said the competition is double elimination until the very, very end. [01:50.260 --> 01:55.420] So if you actually look at the livectf.com bracket that's been posted, [01:55.420 --> 01:59.660] there is no other match. This is the last match. Win or lose, this is it. [01:59.800 --> 02:02.820] It would be a bummer if Hypeboy doesn't get a second chance, [02:02.820 --> 02:05.260] 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:36.540] I know nothing about this challenge. Do you know? [02:36.540 --> 02:39.880] I know a little bit of this challenge. This challenge is called Hopscotch. [02:40.980 --> 02:43.980] So they made some changes to it throughout the development, [02:43.980 --> 02:48.960] but the basic idea is that you write shellcode, but you control, I think, [02:48.960 --> 02:52.840] you control four bytes, and then there are four bytes that you don't control, [02:52.840 --> 02:54.720] and so on, repeating. [02:54.780 --> 02:58.920] So basically two bytes of shellcode payload plus a two-byte jump over the next four, [02:58.920 --> 02:59.640] and you can arrange anything you want. [02:59.980 --> 03:05.740] As I said, I might not have the latest version of the challenge in my mind, [03:05.740 --> 03:07.080] 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:16.440] I've had a very real-world thing similar to that, actually, many years ago, [03:16.440 --> 03:17.640] 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:38.240] In a lot of the matches, we've seen the players not do that until they're actually throwing it against the remote, [03:38.240 --> 03:44.100] 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:13.740] I mean, this is sudden death. 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:43.520] Right. 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:30.020] Oh, right. 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:46.020] Right? That's not going to be... [09:46.020 --> 09:48.600] No, so let's see. 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 --> 10:56.740] If the bytes that are being written, if those are multiple bytes, [10:56.740 --> 11:00.900] 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:12.480] But I guess it takes a little while to wrap your head around this way of thinking with the shellcode [11:12.480 --> 11:14.060] 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:34.160] In each four byte block, you do NOP and then your three bytes of whatever useful stuff, [13:34.160 --> 13:39.360] which is actually more efficient than the two bytes plus the relative jump that we were talking about, [13:39.360 --> 13:41.380] 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:10.360] That is there. Is that it? [15:10.380 --> 15:11.720] Let me get a... [15:12.380 --> 15:16.160] That's it. We have a winner. 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:13.600] That's what Zoom is for. 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:47.460] So we'll get the last one. 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:01.480] All right, we got everybody. That's it. [18:01.480 --> 18:04.360] I guess that's it for everyone. We'll say goodbye. [18:04.360 --> 18:04.960] Say goodbye. [18:05.220 --> 18:06.020] Bye.