[00:08.840 --> 00:18.220] All set? Okay, good morning. Welcome, everybody. Welcome back to day two of the Aerospace Village [00:18.220 --> 00:23.880] Theater. The crew has a lot of exciting content for you today. We are happy to kick off day two [00:23.880 --> 00:31.300] with all HackASAT updates. I am very, very proud to tell this entire room that we have successfully [00:32.000 --> 00:37.440] completed and accomplished a space challenge using our on-orbit satellite, quite literally [00:37.440 --> 00:48.420] making us the world's first CTF in space. So, thank you. Big props to our team out there, [00:48.420 --> 00:52.120] the Game Ops, the Satellite Ops, and of course all of our competitors. And thank you all for [00:52.120 --> 00:57.340] being here with us today. So, we do have a lot of very exciting content. Jordan is going to fill you [00:57.340 --> 01:02.560] in. All day yesterday, it was very productive. And even overnight, our teams were continuing [01:02.560 --> 01:07.220] to downlink data from the satellite to parse through all the information that came through. [01:07.280 --> 01:10.280] So, there's a lot of really exciting information to share with you all today. [01:10.540 --> 01:15.580] Before we do so, just in case anybody wasn't around or hasn't had the background of HackASAT, [01:15.580 --> 01:22.020] we do want to get started with just a quick video, a good overview of where we are, [01:22.020 --> 01:38.630] who we are. So, let me get that going for you now. To point B, the United States Air Force [01:38.630 --> 01:45.370] and Space Force had an idea to host a space-based CTF to advance space cybersecurity. While many [01:45.370 --> 01:51.390] were sure it couldn't or shouldn't be done, in 2020, they launched HackASAT, an educational effort [01:51.390 --> 01:56.490] and capture-the-flag style hacking competition. HackASAT is designed to inspire the global [01:56.490 --> 02:01.470] security researcher community to develop the interest and skills necessary to reduce [02:01.470 --> 02:07.670] vulnerabilities and build more secure space systems. Education has been central, from testing [02:07.670 --> 02:12.750] the public with an open hacking challenge, to a tough qualification round introducing space-relevant [02:12.750 --> 02:19.130] topics and skills, to a set of hands-on workshops in the virtual aerospace village at DEFCON Safe Mode, [02:19.130 --> 02:24.850] to a whole library of resources on space and hacking. We developed FlatSAT hardware and [02:24.850 --> 02:30.510] challenges to give security researchers access and experience to space technologies they wouldn't [02:30.510 --> 02:37.130] have otherwise. It all led to a fierce final CTF competition for the top eight teams from QUALS, [02:37.130 --> 02:41.470] and the source code for all QUALS and final challenges are available on GitHub for the [02:41.470 --> 02:47.610] community to keep learning. As HackASAT 1 ended, planning started for HackASAT 2. We enhanced the [02:47.610 --> 02:53.650] HackASAT FlatSAT and assembled a new digital twin to support even more realistic space challenges. [02:53.650 --> 02:59.070] The qualification round took place in June 2021, with the top eight teams making it to the final [02:59.070 --> 03:05.310] event. HackASAT brought a full slate of talks and workshops about space security to DEFCON 29, [03:05.310 --> 03:11.170] and the virtual final CTF took place in December 2021. Challenges were still based [03:11.170 --> 03:16.190] on the FlatSAT, but now teams could test their commands within the digital twin simulation. [03:16.190 --> 03:20.370] And again, the source code from QUALS and finals challenges are available on GitHub [03:20.370 --> 03:27.010] through our player's corner page. As HackASAT 2 ended, planning started for HackASAT 3, [03:27.010 --> 03:32.930] and development was already well underway for Moonlighter, a 3U CubeSat dedicated to furthering [03:33.550 --> 03:39.570] cybersecurity. Its first mission would be to host HackASAT 4. We developed the digital twin-based [03:39.570 --> 03:44.450] final event to mirror the actual Moonlighter satellite, and with help from astrophysicist [03:44.450 --> 03:49.910] Dr. Hakeem Oluseyi, we built an online educational experience for the public to plan, [03:49.910 --> 03:56.190] build, and test their very own 3U CubeSat, just like Moonlighter. HackASAT 3 QUALS took place [03:56.190 --> 04:01.850] virtually in May 2022. In August, the HackASAT team brought space-relevant talks to Aerospace [04:01.850 --> 04:08.170] Village at DEFCON 30. The finals took place in October of 2022, with eight teams working through [04:08.170 --> 04:15.410] 12 challenges over 23 hours in this attack-defense style CTF. And again, source code from QUALS and [04:15.410 --> 04:20.930] final challenges are available on GitHub. As Moonlighter moved from design to the build stage, [04:20.930 --> 04:25.910] the team went deep into HackASAT 4 planning. A space-focused CTF is hard to build and play. [04:25.910 --> 04:31.290] An on-orbit CTF is even harder, and it's never been done before. Our qualification round took [04:31.290 --> 04:38.910] place April 2023. Moonlighter launched on June 5th and deployed from the International Space Station [04:38.910 --> 04:46.210] on July 6th, and is now in low Earth orbit. This is its first mission. Practice is over. [04:46.210 --> 04:53.270] The HackASAT 4 final event has begun. A huge congratulations to the Moonlighter team. [04:53.770 --> 04:55.550] Best of luck with operations. [04:58.510 --> 05:08.470] Awesome. Thank you. So now that you know, definitely, we're HackASAT. We're excited to [05:08.470 --> 05:13.790] be here. But more importantly, DEFCON's no stranger to CTFs, right? But a space CTF, [05:13.790 --> 05:18.330] this is new. This is exciting. So we do want to provide to you, before we get into all the details [05:18.330 --> 05:23.790] of how yesterday unfolded, here's a quick game explainer, and then we'll get Jordan up here to [05:23.790 --> 07:53.110] get all the details for you. To meet the great challenges of our age, here on Earth, and beyond [07:53.110 --> 08:04.990] the Earth, in space. All right, everybody. All right, everybody. Good morning. Can you hear me? [08:05.290 --> 08:08.830] Hold on. We'll get this mic going. I can yell, but I don't want to lose my voice. So [08:09.990 --> 08:11.290] let's try again. Is this... [08:13.750 --> 08:19.750] We'll use this one. We'll use this one if it comes on. There we go. [08:20.170 --> 08:23.090] Which will be tricky as I have to type one-handed later, but we'll figure that out. So [08:23.090 --> 08:29.030] good morning, everybody, and I'm excited here to talk about the details of the capture flag, [08:29.030 --> 08:33.890] kind of what's been happening, give you an update here. I'm Jordan. I'm the sort of CTF [08:33.890 --> 08:38.910] sideline reporter. So my job is to dig into what's been going on, talk about the challenges. [08:39.010 --> 08:42.530] It's a nerve-wracking update, right? Because the beginning, we sort of know what we're going to [08:42.530 --> 08:44.850] talk about. We can't talk about the challenge. We're going to talk about the beginning of the [08:44.850 --> 08:49.350] game. This middle update, we can only talk about things that are already all solved, or we can [08:49.350 --> 08:53.090] talk about scoring events, and at the end, we can talk about all the details. So we can go into [08:53.090 --> 08:57.710] the behind the scenes of all the challenges and whatnot. So this update is the scariest, [08:57.710 --> 09:00.450] because you don't know if you're going to have things to talk about. Are the teams going to [09:00.450 --> 09:04.590] score? Will there be things you can talk about? What will have happened? Thankfully, we've got [09:04.770 --> 09:09.610] a whole bunch of stuff to talk about, so that's a relief. I was excited to have that happen. [09:10.070 --> 09:14.070] Just as a reminder, this is kind of the overall structure of what the teams have been doing, [09:14.070 --> 09:18.650] right? So in the lower left, we have the teams. How many people saw our update yesterday, by the [09:18.650 --> 09:24.350] way? If you were here yesterday morning, good. If it's a mostly new audience, I'll make sure [09:24.350 --> 09:28.990] we're all up to speed at the same time. The lower left are all the teams. They're here in the [09:28.990 --> 09:33.270] other room through that wall. You can see five teams that have made it here into the finals. [09:33.370 --> 09:37.910] They're talking to the satellite through this tasking API. They have this web server interface [09:37.910 --> 09:42.870] that all of their code gets uploaded to, all their downloads come through, but then those go to [09:42.870 --> 09:48.070] this validation system that actually will check all of their submissions, make sure they're well [09:48.070 --> 09:51.570] formed, and then it goes into the command scheduler, and that's all kind of done through the [09:51.570 --> 09:57.330] infrastructure from the game team here, but then the command scheduler goes into the KSAT [09:57.330 --> 10:01.950] ground link network. And so there's actually a commercial provider of satellite ground link [10:01.950 --> 10:06.370] stations, and we've got four locations throughout the globe, and then the next time the satellite [10:06.370 --> 10:10.430] is over top of one of those, there's a whole set of commands that are uploaded and data that's [10:10.430 --> 10:15.910] downloaded, right? And you'll notice, though, that the ground network that goes up is different [10:15.910 --> 10:19.610] than the ground network that goes down. Now, they're the same thing, right? It's the same [10:19.610 --> 10:25.690] four locations. The difference, though ‑‑ oh, sorry. All right. Is that better? All right. Let [10:25.690 --> 10:33.150] me know in the back if I'm getting too quiet. I hear my echo. The ground network, the same [10:34.010 --> 10:38.110] four ground stations that uplink also downlink, but the point here is that they don't do it at [10:38.110 --> 10:43.050] the same time, right? So if I upload something to happen, it happens sort of over the gap [10:43.050 --> 10:47.010] between the communication windows. So the code all gets queued up, it's on the satellite, and [10:47.010 --> 10:50.950] then it gets run while that satellite is going until the next communication window, then it [10:50.950 --> 10:56.090] downloads all the results. So there's a lot of lag. And even beyond that, and because some of [10:56.090 --> 10:59.970] these windows can be quite long, even beyond that, when you have an especially long window [10:59.970 --> 11:05.110] between the communication, you can't even download all of the telemetry, all of the things that [11:05.110 --> 11:09.350] have happened that have run on the satellite, and so it's this very, like, fluid environment [11:09.350 --> 11:14.670] where it may take multiple contacts to download what happened two windows ago, for example. [11:14.790 --> 11:18.730] And so there's a whole lot of things that you've got to kind of juggle and deal with, and you've [11:18.730 --> 11:24.190] got noise, we've had contacts that were interrupted by just bad RF where the communication link [11:24.190 --> 11:28.410] couldn't happen because it was just too noisy of a signal between our ground station for whatever [11:28.410 --> 11:32.590] reason. You know, there's a lot of things that are out of our control. And so that can really [11:32.590 --> 11:37.250] make a lot of this challenging. So the data comes back down on the next pass for whatever attempt [11:37.250 --> 11:41.230] you made, whatever challenge you tried to solve, goes through the ground network into the [11:41.230 --> 11:45.650] telemetry data that goes back into the teams, and they get to evaluate kind of what they did. [11:48.870 --> 11:55.290] So this is the sort of, like, overall look where you can see the windows that teams have are [11:55.290 --> 12:01.310] not fixed, right? And these are determined by the physics of the orbit. We didn't even know, [12:01.310 --> 12:06.930] in fact, the exact details of when we would have access to the satellite until this week. It's [12:06.930 --> 12:11.810] really been rather, you know, sort of sudden in terms of trying to figure out now how does this [12:11.810 --> 12:15.990] impact the challenges? How many times can the teams talk to the satellite? So you'll see even, [12:15.990 --> 12:20.510] for example, today, there's very few contact windows. We really only have two contact [12:20.510 --> 12:30.110] windows that teams can queue up their commands to the satellite. And so it means that you better [12:30.110 --> 12:33.730] get things right, right? There's not a lot of room for mistakes. And then a lot of these [12:33.730 --> 12:39.470] contacts do happen after hours, though. So the good news slash bad news is that, as I said, [12:39.470 --> 12:43.290] in these long windows, it takes a while to download all the data, but we've got more [12:43.290 --> 12:46.310] windows. And that's also why we're not really announcing the winners, because we don't know [12:46.310 --> 12:50.450] the winners until much later tomorrow morning when we've pulled all the data, we've combed [12:50.450 --> 12:54.030] through all the results, and we can really see what actually happens. So even the scoreboard [12:54.030 --> 12:58.490] that we're going to show is not actually real, right, in the sense that there's probably [12:58.490 --> 13:01.610] things that have happened since then that just haven't been downloaded or haven't been [13:01.610 --> 13:06.130] processed. There's multiple stages that are happening in this. So it's a kind of long, like, [13:06.130 --> 13:11.490] tail before you find out about some of these things happening. Specifically, though, you'll [13:11.490 --> 13:18.650] notice that teams can interact with these windows in sort of three primary ways. The first is [13:18.650 --> 13:23.230] they can upload a script. They can run a script. The second is that they can use the [13:23.230 --> 13:27.630] scripts to take a picture. There's an imager, there's a camera on Moonlighter. And the third [13:27.630 --> 13:33.650] thing is they can download some of that data. They can download results back out. In fact, it's [13:33.650 --> 13:37.990] up to them then to figure out what they're going to do throughout all of these windows. You'll [13:37.990 --> 13:41.390] notice, so yesterday, again, was the start of the game. Teams had the beginning of their [13:41.390 --> 13:45.710] access then, and there's these two windows, those little kind of white blocks of the [13:45.710 --> 13:50.310] communication windows, very, very quickly. And so the teams wouldn't have been able to get a [13:50.310 --> 13:53.950] whole lot done then. Turns out, they couldn't even communicate with the satellite at all. We [13:53.950 --> 13:58.010] actually had, unfortunately, had two errors that resulted in these windows kind of being [13:58.010 --> 14:03.110] unavailable. One was due to some testing infrastructure, because unlike a server where you [14:03.110 --> 14:06.690] can have two servers and one's prod and one's testing and they can be identical, well, [14:06.690 --> 14:10.030] that's a satellite in space, so nothing is identical. And so some of the testing [14:10.030 --> 14:14.750] infrastructure that was in place sort of blocked the upload to the satellite during that [14:14.750 --> 14:18.950] first window, and so unfortunately we lost that opportunity. And then the second window, [14:18.950 --> 14:25.010] again, we're at the sort of mercy of our ground network operator. They just dropped our [14:25.010 --> 14:28.890] connection, essentially. We don't really know. Sometimes it happens. You lose access to [14:28.890 --> 14:32.830] these windows. So those two windows didn't actually even happen. Teams had queued up [14:32.830 --> 14:37.030] commands. The good news was we looked through the results. None of the teams lost scoring. [14:37.030 --> 14:41.530] Nobody had anything that was going to be a solution that would have actually scored on any [14:41.530 --> 14:48.430] of the challenges. Awesome. Let's see if this one works. Let's try this one. Can you guys hear me [14:48.430 --> 14:52.430] now? Still a little quiet. There we go. They're going to bring me up. Perfect. All right. [14:52.430 --> 14:59.310] Thank you. So the teams here, they missed a couple of little sort of learning opportunities, [14:59.310 --> 15:03.490] right? These could have been good chances for them to be able to find out how things worked. [15:03.590 --> 15:08.210] And so, for example, one change or one thing that happens is that all the telemetry and the [15:08.210 --> 15:14.450] log data that comes back is shared with all teams. So this is kind of an interesting twist, [15:14.450 --> 15:19.030] right? You as a team, if you run a script and there's some output, everyone can potentially [15:19.030 --> 15:23.050] see that. So teams had to account for that. And we wanted them to learn that in the sort [15:23.050 --> 15:28.030] of first two windows as they were sort of testing the earlier tests. But because they [15:28.030 --> 15:34.110] didn't have that opportunity, what we did was we essentially on the third window, when any [15:34.110 --> 15:37.710] data came ‑‑ or the next window that came back to teams when they first had data back, we [15:37.710 --> 15:42.830] said, we're separating your logs for this run once, just because you didn't know. So everyone [15:42.830 --> 15:48.030] got their own logs separately. But just so you know, from now on, your logs are coming back [15:48.030 --> 15:52.150] with everybody's, right? So they have to kind of account for that as they're participating in [15:52.150 --> 15:57.530] the game. This is a concept called consensus logging or consensus evaluation. It was [15:57.530 --> 16:03.130] actually kind of popularized in Capture the Flag a few years ago at DARPA's Cyber Grand [16:03.130 --> 16:07.770] Challenge where it was one of the first major Capture the Flags where everything you did, [16:07.770 --> 16:12.470] every change you made to your environment, every team got to see. And it really changes the [16:12.470 --> 16:17.230] playing field. It's a very different game when I submit a change to a binary, I try to patch [16:17.230 --> 16:21.090] or make a fix, if other teams can see what I'm doing. You have to account for that in terms [16:21.090 --> 16:25.770] of how you play the game. And this is kind of a really interesting trade‑off that exists in [16:25.770 --> 16:29.730] the real world, too. Because sometimes you can keep things secret from attackers. Sometimes [16:29.730 --> 16:33.790] the attackers don't know what kind of infrastructure you're running. Sometimes they do. [16:33.790 --> 16:38.070] Like they can download Windows. They can download the antivirus software you're using and [16:38.070 --> 16:42.290] they can analyze it. They get full visibility into some of the things on your network or [16:42.290 --> 16:45.850] some of the software you're running. And so it is this interesting trade‑off that you see in [16:45.850 --> 16:50.070] Capture the Flag events where they try to balance between, like, is it realistic, is it not? [16:50.070 --> 16:54.910] And in consensus evaluation is one of those things that absolutely exists in kind of the [16:54.910 --> 17:01.150] real world, too. So after those Windows, we have a couple more kind of Windows later on [17:01.150 --> 17:04.430] where teams really start getting into it. They start uploading their attempts and we start [17:04.430 --> 17:09.730] seeing what they're doing. Let me go to this actual score chart and let's talk about this, [17:09.730 --> 17:14.810] too. So our scoreboard here has all five teams and we had to update this right before the talk [17:14.810 --> 17:21.390] because, again, we had some scoring events that came through. And, again, this is itself [17:21.390 --> 17:25.970] even delayed, right? So we got this update, the data was coming through, but we don't [17:25.970 --> 17:30.290] actually know if this is the current sort of state of reality. We have to let everything [17:30.290 --> 17:36.290] kind of settle out and we'll find out later. The five teams, you see the last minute, [17:36.290 --> 17:42.370] pulling can into space has jumped into first place. And then tied for second place, we [17:42.370 --> 17:51.250] have jump FS and space bits are us and we've got in fourth place crowd set and then macaroni [17:51.250 --> 17:55.650] or M macaroni and in the fifth place spot now. But, again, there's a lot of room for [17:55.650 --> 18:01.850] teams to jump it down because you can see, like, one update could bring you several spots [18:01.850 --> 18:06.070] up pretty easily because there are a number of challenges that are left. Let's go ahead [18:06.070 --> 18:10.530] and talk about the overall score chart. I like this one for looking at what's happening in [18:10.530 --> 18:14.990] the game. If you go to our website, again, you can pull up this data. You have to click the [18:14.990 --> 18:21.470] plus signs on the left to bring up the little ‑‑ the key, the legend that shows you who [18:21.470 --> 18:25.350] is ‑‑ which color is which if you don't remember off the top of your head. But you can [18:25.350 --> 18:29.630] see the total points for each one of these challenges. These are the ones that have been [18:29.630 --> 18:33.510] solved so far. So this is, as I said, this is nerve wracking when you're a competition [18:33.510 --> 18:38.630] organizer just seeing those first solves come in is fantastic and exciting. The top two [18:38.630 --> 18:46.130] challenges, password manager and flight software freebies, these are challenges that existed [18:46.130 --> 18:50.270] in our ground network. So they were solved by all the teams because they probably had more [18:50.270 --> 18:53.650] time to work on it and they had software they could work with and analyze. But these are [18:53.650 --> 18:57.450] not necessarily, like, give me challenges. I'll show you in much more detail we can talk [18:57.450 --> 19:01.570] about that. So the good news is because everyone solved it, we can analyze and we can look [19:01.570 --> 19:05.190] and we can see what they did. And those are going to be kind of more traditional software [19:05.190 --> 19:09.710] security vulnerabilities, binary analysis, decompilation, exploitation that the teams [19:09.710 --> 19:13.750] had to do. Because, again, that's very much a part of the ground station network. And [19:13.750 --> 19:17.750] the satellite ecosystem includes not only the satellite itself, but the ground stations [19:17.750 --> 19:22.190] that it's talking to. And so making sure that they're secure is equally as important because [19:22.190 --> 19:27.830] if the controllers are hijacked, well, then so can the satellites. And so you'll see thankfully [19:27.830 --> 19:31.390] all teams have solved that. I'm going to go give them a high five on the way out because [19:31.390 --> 19:35.090] that makes my life easier because we can talk about those. These other challenges we can't [19:35.090 --> 19:39.190] go into full detail on because not every team has solved them. So tomorrow if you come back [19:39.190 --> 19:42.330] at the awards ceremony, we can talk in a little bit more detail about how they happened. But [19:42.330 --> 19:47.410] we can at least talk about the sort of general shape of the challenges, what the teams know [19:47.410 --> 19:52.590] about what they had to do. So this third challenge you see here is called script kitty. And the [19:52.590 --> 19:56.550] idea here is you just have to run a script. Remember I said earlier that there's this [19:56.550 --> 20:01.270] command interface that lets the teams upload their code. Their code is running on the [20:01.270 --> 20:05.270] satellites. They're not like sending a packet to the satellite and getting a response back. [20:05.270 --> 20:09.690] Everything that they run has to run on the satellite. It's a Lua scripting engine that [20:09.690 --> 20:15.190] they're running with. And it's got a whole bunch of access to the imager, to the GPS [20:15.190 --> 20:19.310] module, to all these different things. They're writing their code as these payloads and [20:19.310 --> 20:23.390] then they upload it. That's also where I said that log data that comes back from the scripts [20:23.390 --> 20:27.890] comes into that log and that telemetry that gets distributed to all of the teams. So we saw [20:27.890 --> 20:33.310] three teams in the same scoring window were able to score on that script kitty challenge. We [20:33.310 --> 20:41.410] had PFS, PFS RCX or jump PFS or jump as they get called. We had Poland can and we had [20:41.410 --> 20:46.650] CrowdStat all score in the 19th scoring round. So let's talk a little bit, too, about those [20:46.650 --> 20:50.830] scoring rounds. Because if you look up top, you'll see there's 1, 2, 3, 4, 5, 6, 7, 18, 19, [20:50.830 --> 20:55.690] 20, 21. The fact that they're not contiguous is just sort of an artifact of some kind of [20:55.690 --> 21:01.490] internal, some testing that was happening. But the whole point is, this is the rounds as [21:01.490 --> 21:06.150] they happen with scoring windows. So this is not linear. This looks nice and linear and you [21:06.150 --> 21:10.590] look here like it happened all, like it kind of chunked at a time. But the scoring windows, [21:10.590 --> 21:18.930] as we saw earlier, if I can get back to them, the scoring windows, as we saw earlier, don't [21:18.930 --> 21:23.150] always happen at the same time. The time stamps are a little small. The website has the [21:23.150 --> 21:27.790] details and you can pull them up. But they're not like every hour. They can be very random. [21:28.010 --> 21:31.490] Actually, this one has the better one. You can see the gaps between each one of those [21:31.490 --> 21:36.530] windows. And so when we talk about these rounds, some of these rounds are rounds that [21:36.530 --> 21:40.030] happened last night, but the teams had uploaded the data before they left and it finally [21:40.030 --> 21:43.510] made it up to the satellite. The results happened. We got the data back in a later round. [21:43.790 --> 21:48.970] And so that's why you see it's sort of like this nice, pretty regular chart here and here. [21:49.090 --> 21:53.070] It's not so clean. It's not so easy in terms of how it actually has happened. [21:53.070 --> 21:57.990] So again, script kitty is your code execution, like running a code. This is part of a normal [21:57.990 --> 22:03.550] API. You're allowed to task. You get a time slice. You get to run your script. But then [22:03.550 --> 22:07.870] can you violate certain properties? Can you do certain things or some of these later challenges? [22:07.870 --> 22:12.850] So this is sort of, yes, hello, world, you can run code. Now go on and actually do something [22:12.850 --> 22:16.510] with it. And that's what we're going to see with these next two challenges. [22:16.510 --> 22:25.090] Silver medal is a challenge of just take a picture. You had to take a picture. And teams [22:25.090 --> 22:30.510] didn't have access earlier in the day yesterday to controlling the attitude of the satellite. [22:30.590 --> 22:35.830] So there was only a window of time overnight that they were actually able to adjust the [22:35.830 --> 22:40.870] orientation for pointing. And so if they want to take a picture of a specific place, you [22:40.870 --> 22:44.250] have to be able to point the satellite. And so that data is still coming in and we'll [22:44.250 --> 22:47.530] see what they did and hopefully see some of those images. I'm really looking forward [22:47.530 --> 22:53.370] to seeing the first captured flag picture from space that live happened. We did actually [22:53.370 --> 22:58.930] have one a few years ago. So we called it a moonshot on a previous version of Hackassat. [22:58.930 --> 23:02.770] But it wasn't the CTF happening on the satellite. It was like a separate challenge that they [23:02.770 --> 23:06.710] could run a little bit of code that was tested and then their pointing map was uploaded to [23:06.810 --> 23:10.110] a satellite and a picture was taken. So that actually let them take a picture. But this [23:10.110 --> 23:13.710] is like no kidding really. They're writing all the code. They're doing all the orientation [23:13.710 --> 23:18.590] on the satellite. Their code is running it and triggering it. So cross your fingers that [23:18.590 --> 23:22.410] tomorrow we're going to have some of those coming back. Like I said, from about 1 a.m. [23:22.410 --> 23:26.850] last night until just before we started speaking now was the period of time where the [23:26.850 --> 23:32.910] satellite was moving. Partly because the control system is a physical artifact. So [23:32.910 --> 23:38.710] there's actually, it's not like a digital on off exact pointing mechanism. And the fly [23:38.710 --> 23:42.270] wheels, the systems that actually do the orientation require a lot of maintenance and [23:42.270 --> 23:46.170] tuning and tweaking. So there's only kind of a narrow window of time that they can [23:46.170 --> 23:50.010] actually do that. Of course there's also power concerns too. But they've got to like, [23:50.010 --> 23:55.550] they've got to kind of reset and adjust the system so it doesn't kind of like become [23:55.550 --> 23:59.870] usable again. Go talk to all the people that do the real space stuff for the details on how [23:59.870 --> 24:03.890] that system works and why they need to kind of reorient it. Because that's, like I said, I'm [24:03.890 --> 24:09.510] just the hacker commentator here to talk about the security stuff. So at 11 a.m. is when [24:09.510 --> 24:14.830] they had that window to orient. So we'll see what images come down later. This one, as the [24:14.830 --> 24:18.250] satellite is spinning, so again, outside of that window I just mentioned where it's under [24:18.250 --> 24:21.750] control and it's actually, they can orient it, the satellite is actually kind of free [24:21.750 --> 24:25.330] floating. Like its orbit is fixed and they know where it is. But it actually is aiming in [24:25.330 --> 24:28.990] all different directions. And the teams didn't actually control that. But they could still [24:28.990 --> 24:33.910] take a picture. So that's what we're seeing here in the silver medal challenge that we have [24:33.910 --> 24:39.930] both JumpFS and Poland can solving. They were able to take a picture. So we will at some [24:39.930 --> 24:43.450] point be able to get that picture. It will probably just be black or looking at space. So [24:43.450 --> 24:47.970] there may not be much to it because they didn't control where it was aimed. In fact, one of [24:47.970 --> 24:53.850] the teams got bit by a little bit of bad luck. They triggered take a picture. But they were [24:53.850 --> 25:00.050] in a region that is what we call, we've got band regions. And this is not actual band [25:00.050 --> 25:05.010] regions. They literally did bands around the globe. So there's a bunch of longitudes that you [25:05.010 --> 25:08.810] can't take a picture of the earth for. And the idea is that this is, again, one of those [25:08.810 --> 25:13.490] exercises they have to solve. So this is one we're not seeing on this view. But this is [25:13.490 --> 25:21.370] called unintended bug. And that challenge means you have to take a picture of one of these [25:21.370 --> 25:24.790] locations where you're not supposed to be able to take a picture. There's code that prevents [25:24.790 --> 25:30.030] them from actually taking a picture out of a big chunk of the globe. We'll talk more [25:30.030 --> 25:34.150] about that tomorrow, how they had to solve it and how they could do that. But hopefully [25:34.150 --> 25:37.510] somebody actually gets that one kind of figured out. And I think they will from something [25:37.510 --> 25:42.550] we're going to talk about later. But one of the teams, which is randomly snapping a picture [25:42.550 --> 25:46.790] during one of their code windows, they happened to be over a band region and they happened [25:46.790 --> 25:50.670] to be aimed at the earth. And so the thing said, no, I'm sorry, I can't take that picture [25:50.670 --> 25:54.990] because I'm in a band region. So it prevented them from actually solving this. So it's [25:54.990 --> 25:58.110] unfortunately a little bit of bad luck, but that's going to happen. And they could have [25:58.110 --> 26:01.930] maybe controlled it, for example, if they would have calculated where in the window [26:02.630 --> 26:06.370] the flat sat would be above one of those band regions and where it wouldn't, they could [26:06.370 --> 26:12.790] have intentionally chosen that. So we'll see if that is something that they can solve or [26:12.790 --> 26:15.830] not. They're going to know, though, when they get back the results and they're told, no, [26:15.830 --> 26:19.470] your picture didn't get taken. They already know that's a problem. They figured that out. [26:19.470 --> 26:24.670] We'll see if they can actually solve it, though, already. So the last one that we've seen [26:24.670 --> 26:28.090] solves for, again, this is the one that happened just before we came into this event, is [26:28.090 --> 26:33.570] called Christmas in August. It's so called because you have to visit the North Pole. What [26:33.570 --> 26:38.730] you're supposed to do is have the satellite show up over the North Pole. However, I [26:38.730 --> 26:43.810] mentioned yesterday, there's no boosters on this satellite. There's no propulsion. There's [26:43.810 --> 26:49.070] no ability to move it. The budget wasn't there for, like, a fully autonomous vehicle in [26:49.070 --> 26:54.010] space that can move around. So how are teams supposed to do this? And the competition [26:54.010 --> 26:58.810] organizers did communicate to them, you have to basically get the GPS to be wrong, right? [26:58.810 --> 27:02.890] Because there's a GPS receiver on the satellite. So they have to do something to basically [27:02.890 --> 27:08.750] get the satellite to think it's somewhere else. And so that is going to let them, you know, lie [27:08.750 --> 27:12.530] and say that they're at a particular location. So two of the teams have figured that out. They [27:12.530 --> 27:18.630] were able to use a cool trick that we'll talk about tomorrow to be able to get the satellite [27:18.630 --> 27:22.870] to be somewhere else. And they were able to go visit Santa, pick up some cookies, have [27:22.870 --> 27:28.470] their Christmas in August, which is that particular challenge. So those are the points that [27:28.470 --> 27:32.750] the teams have been able to score. It's a great start. And again, we've got, while we only [27:32.750 --> 27:36.290] have these two more kind of windows today, the good news is, again, there's still data coming [27:36.290 --> 27:40.310] down. There's still a lot of things that we're getting from both that happened kind of [27:40.310 --> 27:44.630] overnight, that are happening today, and they're going to happen even over tonight as we [27:44.630 --> 27:48.110] continue to process and pull everything out. And so we'll see everything else that's going to [27:48.110 --> 27:52.470] happen. I'm going to go through some challenge walkthroughs, though, right? So for those [27:52.470 --> 27:55.250] of you that want kind of a little more detail of, like, well, what does it mean when you say [27:55.250 --> 27:59.530] that they're doing an exploit or they're solving a challenge? Because all five teams have [27:59.530 --> 28:03.130] solved these two ground station challenges, we can take a look at it. We can actually pull [28:03.130 --> 28:06.770] them up and show you all the details and talk about what exactly they're doing. And you can [28:06.770 --> 28:13.610] see, like, kind of what goes into their solving one of these. So the first one is a tool [28:13.610 --> 28:18.990] called Password Manager. And this is a ‑‑ it's actually ‑‑ the actual binary name is [28:18.990 --> 28:23.670] Final Pass, which I think is kind of a play on words from Last Pass, which is a password [28:23.670 --> 28:27.790] manager you might be familiar with. And the idea, the original idea, actually, for this [28:27.790 --> 28:31.630] challenge was it was going to be a challenge you had to solve at the very, very beginning [28:32.170 --> 28:35.950] before you would unlock a ‑‑ use that to unlock a separate server, and then that would [28:35.950 --> 28:39.050] unlock to give you all the binaries for the rest of the challenges, and you would kind of have [28:39.050 --> 28:43.310] to solve these kind of sequentially. However, when the organizers looked at the [28:43.310 --> 28:47.270] communication windows and they saw how few sort of communication slots there were, they [28:47.270 --> 28:50.130] actually changed the challenge up a little bit, made this one a little bit easier, and [28:50.130 --> 28:54.970] made it so you can just solve it and it doesn't block your access to any of their challenges. [28:54.970 --> 28:58.110] And, again, this just comes down to you have to be flexible because the environment you [28:58.110 --> 29:02.390] get in space may not be the one that you think you're going to get when you're in planning. [29:02.390 --> 29:05.730] And so they actually changed this before the competition started. To be clear, all this [29:05.730 --> 29:09.370] is done before anything has happened, and so it's fair. All teams got the same binary. [29:09.370 --> 29:12.870] Because that's also another really big concept in Capture the Flag, is that anything you [29:12.870 --> 29:15.950] tell the teams, you have to stick with it. Anything you communicate has to be even to [29:15.950 --> 29:19.870] everyone. Everyone has to have the same kind of scoring opportunities. So let's take a [29:19.870 --> 29:25.350] look at the password manager here. And we're going to use a tool called Binary Ninja. [29:25.350 --> 29:30.630] Shameless plug. My company builds this product. But it's basically a decompiler, right? So [29:30.630 --> 29:35.050] this takes apart and analyzes binary code, turns it back into source code or something like [29:35.050 --> 29:40.910] it that you can try to analyze to find out, like, what the code actually does. And so the font [29:40.910 --> 29:45.390] is going to be really small. I apologize in advance. Actually, maybe I can ‑‑ we'll bring [29:45.390 --> 29:50.310] up the font size a little bit and see if we can make this a little bit more readable. But the [29:50.310 --> 29:56.070] idea is, again, the code that runs on the satellite or runs on your computer or your phone is [29:56.070 --> 30:00.790] just binary, right? And the CPU is going to execute that directly. But what you want to know [30:00.790 --> 30:05.750] as a human is, what is this actually doing? Like, can you tell me something meaningful about [30:05.750 --> 30:15.990] that? So tools like Binary Ninja turn that binary back into something ‑‑ something [30:15.990 --> 30:20.290] understandable by humans. So that's a little bit ‑‑ all right, let's go back to the right [30:20.290 --> 30:25.550] one. A little bit more readable, hopefully. Like I said, we'll put the videos online so you [30:25.550 --> 30:29.830] can pull it up full screen later as well, too, so you can see it there. But the idea here is, [30:29.830 --> 30:33.330] you can just see a bunch of yellow on the screen. So let me talk about that for a second. [30:33.330 --> 30:38.490] When you give a binary to teams, you have a couple of choices as an organizer. You can give [30:38.490 --> 30:42.750] them something with what we call full symbols or with debug information. And that basically [30:42.750 --> 30:46.510] gives them a lot more data about what's actually happening. You're sort of including some of [30:46.510 --> 30:49.510] the stuff from your source code. So we can actually see that here. We see a whole bunch of [30:49.510 --> 30:55.790] C++ namespace symbols. So we have a lot of that included in this particular binary. We see [30:55.790 --> 30:59.070] some that are compiled in the binary. We see some that are imports from libraries, like [30:59.070 --> 31:03.770] standard IO stream libraries. And so we can start, like, this is the code as it runs. But [31:03.770 --> 31:08.070] thankfully, the teams had a lot more hints on what this binary is doing because they can [31:08.070 --> 31:11.550] actually kind of read some of the code. We can see here, this is, we know it's called a [31:11.550 --> 31:17.050] password manager. We can see it creates this manager object here. And it's got this process [31:17.050 --> 31:21.550] choice menu, for example. So we can look at the process choice and you can scroll through [31:21.550 --> 31:26.430] here and you can see, view a password, add a password, delete a password. So, yeah, it's a [31:26.430 --> 31:30.630] password manager. It's what you would expect. But there's this interesting thing you can do [31:30.630 --> 31:35.650] with a password manager, which is that you can load a database. You can actually give it a [31:36.210 --> 31:40.550] preformed database, like you could, like you have created your own. And so if you got this [31:40.550 --> 31:44.030] binary and you can analyze it, you can figure out what does a valid password database look [31:44.030 --> 31:48.230] like for this custom service. And so you would go into there, you would look at what it's [31:48.330 --> 31:52.350] doing. And even before you get there, you might see this is a little interesting. Start DB [31:52.350 --> 31:57.490] thread. Like, oh, no, this is sort of a dreaded thing. If you've ever done any multi‑threaded [31:57.490 --> 32:02.010] programming, how many people have written multi‑threaded code where it's like you've got to [32:02.010 --> 32:05.150] deal with different threads. This is actually really, it can be a lot of work, multi‑process, [32:05.150 --> 32:08.850] multi‑thread stuff, because now you have to worry about race conditions. Now you have to [32:08.850 --> 32:13.210] worry about, like, well, you have to have mutexes or locks, things that control access. So [32:13.610 --> 32:17.390] multiple threads are just like running sort of two processes that then talk to each other, [32:17.390 --> 32:20.970] right? So they can run at the same time because your computer has lots of CPUs that can run at [32:20.970 --> 32:25.290] the same time, so you can run these separate processes, but they increase the complexity of [32:25.290 --> 32:29.750] the code a lot. So in this particular challenge, trying to reverse engineer it was pretty [32:29.750 --> 32:34.550] easy. Like, you can look at this, all the symbols are there, it tells me what it's doing, I [32:34.550 --> 32:40.250] know what libraries it's importing, I can read the start DB thread, it's got a get database [32:40.250 --> 32:43.450] from the user, so it's actually going to open a data connection, it's going to parse some [32:43.450 --> 32:48.430] database. I have not seen this binary until literally a few hours ago this morning. They [32:48.430 --> 32:52.290] showed me this, like, on the spot when they made it, and this was pretty straightforward. You [32:52.290 --> 32:57.110] can just kind of read through it to understand what it's doing. It's got pretty error messages [32:57.110 --> 33:00.770] that you can see right here, so it's, oh, could not create a user, so there's a problem with [33:00.770 --> 33:06.510] user creation. What the teams had to figure out, though, was that this ‑‑ every time they [33:06.510 --> 33:12.510] opened up, whenever they uploaded a file, a new port was opened, a new socket was opened, and [33:12.510 --> 33:16.590] then they would upload the file to that socket. This is a little bit like how FTP works, if [33:16.590 --> 33:20.530] you're familiar with the file transfer protocol. When you upload a file, you say, I have a [33:20.530 --> 33:23.990] file, I'd like to upload it, and it's like, no problem, send it over here, and it gives you a [33:23.990 --> 33:28.330] new port. Most of the time nowadays, we have websites where we upload files, it all just [33:28.330 --> 33:31.890] uses the same kind of web connection, and we make a bunch of requests over and over to the [33:31.890 --> 33:35.690] same connection. So this is sort of a different way of transferring files, a little more old [33:36.110 --> 33:40.370] school, but in this case, it hints to teams, like, something weird is going on. You wouldn't [33:40.370 --> 33:44.550] normally build something like this without a good reason. And in this particular case, if [33:44.550 --> 33:51.270] you're able to open a separate connection, and then you can change some information on the [33:51.270 --> 33:55.530] server at the same time, you can trigger this sort of like a race condition. So what you're [33:55.530 --> 33:59.610] uploading, instead of overwriting your database or your information, you can overwrite [33:59.610 --> 34:03.410] something else. And what you would essentially do is you would use this to change your name [34:03.410 --> 34:07.670] and become, now I'm an admin. So you would essentially use this trick to become an [34:07.670 --> 34:10.950] administrator. What I think is especially interesting about this is a lot of these [34:12.090 --> 34:15.990] exploitation challenges, you're looking for memory corruption. If you've heard of a buffer [34:15.990 --> 34:20.470] overflow, where you have a specific size of data and you write too much into it and you [34:20.470 --> 34:24.030] overwrite some pointers or a return address and you're trying to basically get the [34:24.030 --> 34:28.950] computer to execute your code instead of the code it's supposed to run, treat your data as if [34:28.950 --> 34:32.490] it were code or you're trying to hijack the control of where it goes. Control flow [34:32.490 --> 34:38.870] hijacking or remote code execution. So this is what we often think of when we think of the [34:38.870 --> 34:43.590] most hardcore capture the flag kind of challenges. And this one, you never get code [34:43.590 --> 34:48.050] execution. You don't need to. You just need the password that's in the admin's password [34:48.050 --> 34:52.230] database and you can do that by using sort of this race condition, which is a memory [34:52.230 --> 34:55.870] corruption, you're changing bytes you're not supposed to be able to change because it's [34:55.870 --> 34:58.950] sort of confused about what you should have access to by having these two different [34:58.950 --> 35:03.950] processes running at the same time. And when you do that, all of a sudden you're just an [35:03.950 --> 35:07.950] admin and you can now read a password that you shouldn't have had access to, right? [35:07.950 --> 35:14.490] So I think this challenge is really interesting. Every team solved this, right? I kind of [35:14.490 --> 35:18.210] blew through the explanation, but there's a lot of code here. It's a lot to look through. [35:18.210 --> 35:20.790] And so these are all very good teams that they would have put this together and essentially [35:20.790 --> 35:26.030] done it midway through the day yesterday to be able to, like, solve this as well as the [35:26.030 --> 35:31.050] next one with the resources that they had. So like I said, this one, the exploitation is a [35:31.050 --> 35:35.050] little bit tricky. Figuring out how you have to kind of win the race is the phrase that we [35:35.050 --> 35:39.730] use in exploitation when there's a race condition. But they did have a lot of symbols. [35:40.310 --> 35:45.910] Now, the next challenge that they had was a little bit different. I'll just leave it up here [35:45.910 --> 35:51.650] in this mode instead of the full screen mode. Because the next one is called flight [35:51.650 --> 35:55.930] software freebies. So again, you saw on the score board, you can see the names, the [35:55.930 --> 35:59.830] password manager and flight software freebies. Flight software freebies is just a web [35:59.830 --> 36:03.750] server, right? So you can access the web server and they've actually been using this to [36:03.750 --> 36:08.530] send things to teams. They make files available. There's things on the web server. You can [36:08.530 --> 36:12.770] see here there's like documentation, there's tasking API information. So this is actually [36:12.770 --> 36:17.070] kind of a part of like how to access the game. All that information comes from this web [36:17.070 --> 36:21.730] server. But it's a custom written web server that the teams could actually use a couple [36:21.730 --> 36:27.710] different vulnerabilities on to achieve different things. Now, again, originally these two [36:27.710 --> 36:31.350] challenges, first you were going to have to hack the password manager, get the password, then [36:31.350 --> 36:36.410] you were going to have to hack the web server and that would give you all of the challenges, [36:36.410 --> 36:39.970] binaries, the documentation information that you would then use to access the remainder of [36:39.970 --> 36:43.710] the challenges. But when they took a look at the Windows and how difficult it was going to [36:43.710 --> 36:47.710] be, they said, you know what, we're not going to let this block things. So at the beginning of [36:47.710 --> 36:51.850] the game, all of these downloads were available. So all the teams could get all the files [36:51.850 --> 36:55.650] and kind of work in parallel. But they still had to solve this because there's still points [36:55.650 --> 37:00.470] behind this challenge. So there were a couple different ways that teams could do this. The [37:00.470 --> 37:03.430] teams were not given, unlike the last one where they just kind of had the binary and they [37:03.430 --> 37:07.110] were just given it and told it, here you go, analyze it, here's your password manager. And [37:07.110 --> 37:12.250] this particular one, they had to actually figure out how to even get the binary in the first [37:12.250 --> 37:17.010] place. And so it turned out that there is a, there's a couple ways they could do this, but [37:17.010 --> 37:22.870] the web server itself had sort of like a web security vulnerability. There was an API that [37:22.870 --> 37:26.490] you could access. So if we look on this screen shot of it, you can see there's like a [37:26.490 --> 37:32.050] server status page, which just includes some random information. One of which, let's see [37:32.050 --> 37:36.830] here. Oh, no, I went all the way back to the beginning. I hit the wrong one. That's all right, [37:36.830 --> 37:46.500] we'll scroll. Sorry, if I turn my head sideways, I think I make a, make noise. So if we look [37:46.500 --> 37:53.760] at the server status page, does anybody see anything slightly unusual on this page? [37:53.760 --> 37:58.060] Actually, audience participation. I like to do it that way. Let's see, does anybody, so [37:58.060 --> 38:02.800] there's just a bunch of like, like headers and text. One of the things on the right column [38:02.800 --> 38:10.260] has something that's like a little not like the rest of it. Does anybody see it? That's how I [38:10.260 --> 38:15.560] know everyone's still awake. It's early, I know, on Saturday. Anybody see anything? So [38:15.560 --> 38:20.500] we've got like has for HTTP, there's a server name, there's a document root, there's a bunch [38:20.500 --> 38:26.720] of values and true, false, boolean things. There's this host OS that includes Linux, AWS, [38:27.140 --> 38:32.000] it's running Ubuntu, timestamp. And what's that there at the very end? There's like this long [38:32.000 --> 38:38.120] number. And this was sort of like a little bit of a gimme. There's actually a value. That's [38:38.120 --> 38:43.360] actually a running pointer. It's a pointer that got accidentally leaked in the server. And [38:43.360 --> 38:47.440] so if you're able to download the copy of the server using a separate vulnerability, you can [38:47.440 --> 38:51.140] use that to figure out where it's running in memory. One of the techniques that's used in [38:51.140 --> 38:55.440] computers nowadays to make your software harder to hack is that the programs are randomized [38:55.440 --> 39:00.000] where they run. You have memory, you talk about 8 gigs of RAM in your phone or 16 gigs of RAM [39:00.000 --> 39:04.760] or 64 gigs of RAM in your computer. Well, that memory is like a big chunk of memory and when [39:04.760 --> 39:08.040] you load a program into it, it used to be your programs were always loaded at the same [39:08.040 --> 39:11.800] place. So when I wrote an exploit, I could just go to the same place if I kind of hijacked [39:11.800 --> 39:15.180] control and know what was going to be there. You don't have that nowadays. We have what's [39:15.180 --> 39:19.740] called ASLR. We move things around. This lets you beat that. This was sort of leaking [39:20.460 --> 39:24.780] information and telling the person visiting the website where this process was running in [39:24.780 --> 39:29.020] memory. So by combining that with the separate vulnerability that let them include a local [39:29.020 --> 39:33.280] file, pull something out of a proc self, if you really want to go into the geeky details, you [39:33.280 --> 39:37.660] could proc self and pull out the memory of the current process and that gets you the bytes of [39:37.660 --> 39:43.320] the binary so they could get the binary and they could get where it was loaded and that gave [39:43.320 --> 39:47.080] them a lot more information to access another vulnerability. So we're not going to go into [39:47.080 --> 39:54.380] like the full details of exactly how to exploit that vulnerability. We'll save that for maybe a [39:54.380 --> 39:57.860] wrap up later. But I do want to show you kind of a difference because I think it's [39:57.860 --> 40:03.480] instructive to just see, as I said earlier, you can see on this binary we have symbol names, we [40:03.480 --> 40:07.320] know that we see a bunch of information, we knew what it was doing. If we pull up the web [40:07.320 --> 40:12.880] server, I don't see anything readable here. I see, okay, there's a string, web server [40:12.880 --> 40:18.420] starting up, but all of these functions just are a random address. There's no name on them. [40:18.420 --> 40:21.920] This is what's called a stripped binary. Because, again, the computer doesn't need to know [40:21.920 --> 40:26.720] the human readable names. And most binaries don't have any human readable information in [40:26.720 --> 40:30.280] them except for the strings that are going to be sent to users or if there's things that are [40:30.280 --> 40:36.120] part of the program. But the actual code doesn't need that. The code just runs on all the [40:36.120 --> 40:40.440] addresses. So here you can see this is a very different, much harder to analyze binary. Not [40:40.440 --> 40:44.740] only is there no symbol information, there's no details about what these functions are doing, [40:44.740 --> 40:49.280] this is what's called a statically compiled binary. Which means that normally when you [40:49.280 --> 40:53.340] call other libraries, you want to include some other standard pieces of code that every C [40:53.340 --> 40:58.320] program might want to access. Like when you do a hello world, you would print to a screen, [40:58.320 --> 41:03.360] you'd say print F or puts or something, you'd write to the screen. You're not writing all the [41:03.360 --> 41:06.960] code to tell it how to write to the screen every time, you just tell it what text to put on the [41:06.960 --> 41:11.200] screen. The library that does that code is like a standard library. And here it's all [41:11.200 --> 41:16.780] compiled into one giant binary. None of which has names. So that actually makes the reverse [41:16.780 --> 41:20.160] engineering of this binary a very different process. So when I looked at this this [41:20.160 --> 41:23.800] morning, I was like, I don't know, how would I reverse engineer this? Well, the answer here [41:23.800 --> 41:27.020] would be something like you might look in all the strings. You might search the strings and [41:27.020 --> 41:33.680] you know it's a web server. So you might look for post, for example. Right? Post is an HTTP [41:33.680 --> 41:37.860] verb a web server would use. So I could find that string, okay, let's go look for post. [41:37.860 --> 41:41.360] All right, well that gets referenced from this piece of code. So now you'd start from that and [41:41.360 --> 41:44.700] you'd work kind of backwards. Whereas the other binary, I could just start from the top and [41:44.700 --> 41:48.060] just read what it was doing. I could look at the source code, look at the names. It was almost [41:48.060 --> 41:52.360] like reading source code. This is much harder to read and it's much more work. So I really [41:52.360 --> 41:57.320] think it's interesting to look at the difference between these two processes, like how you [41:57.700 --> 42:00.900] would solve these two challenges are kind of very different, even though they're both just [42:00.900 --> 42:05.980] sort of binary challenges. So as a web server, you had this local file inclusion [42:05.980 --> 42:09.960] vulnerability. You could read yourself, you could read other files and the teams could use [42:09.960 --> 42:13.460] that to get the flag or they could access another, there was actually a buffer overflow in the [42:13.460 --> 42:18.840] binary with a whole bunch of other stuff beyond that. So again, those are the two easy [42:18.840 --> 42:24.240] challenges. Those are the easiest ones. The teams did the quickest. So we're looking forward [42:24.240 --> 42:29.680] to seeing what else they can do throughout the rest of the competition. Really quickly, I'm [42:29.680 --> 42:33.180] just going to summarize some of the remaining tasks. The teams all know that they've been told [42:33.180 --> 42:36.940] this. They've got to point the satellite and take a picture at a particular location, which [42:36.940 --> 42:40.260] requires them to figure out the aiming and we'll see if they've done that overnight. They've [42:40.260 --> 42:44.080] got to take a picture of one of those blacklisted, those banned locations, which requires them [42:44.080 --> 42:48.720] to combine the fact that they need to figure out how to lie about where they are or where [42:48.720 --> 42:54.420] they're aiming and then be able to take a picture. And then there's another one as well, [42:54.420 --> 43:00.300] there's another challenge called the Iron Bank that involves some cryptography breaking that [43:00.300 --> 43:04.640] they have to do on the satellite. They have to break some crypto properties and exploit the [43:04.640 --> 43:09.500] service on the actual satellite itself, too. So lots more, we'll see if they do. And with [43:09.500 --> 43:19.340] that, I'll turn it over to Kevin. If I can push the right button, it's not F5, what's the other [43:19.340 --> 43:25.940] one from current slide? There we go. All right. Check, check. All right. Thank you, Jordan. [43:26.240 --> 43:32.320] So in case you had missed it... Hello. Whoa. Hello. Sorry, check. So you're probably [43:32.320 --> 43:36.100] wondering what is on this table right here and this is actually an engineering model of [43:36.100 --> 43:41.300] Moonlighter, the satellite that's over in low Earth orbit right now. And so we started this [43:41.300 --> 43:47.140] talk about 45 minutes ago. So it's gone halfway around the entire Earth since we all sat down [43:47.140 --> 43:52.000] and started talking. So it's about 17,000 miles per hour. So it's going really quickly. [43:52.000 --> 43:55.860] And Jordan had explained really well how some of the issues and challenges actually that [43:55.860 --> 44:00.200] are faced with the satellite moving that fast. You have to plan way ahead of when you have [44:00.200 --> 44:04.260] that limited contact window with Moonlighter. And so that makes it all the more challenging [44:04.260 --> 44:09.560] as the first CTF in space. So again, this is a digital, or sorry, engineering model [44:09.560 --> 44:15.160] of it. And I have some more breakout of it. So here is a chart that shows Moonlighter [44:15.240 --> 44:19.440] a little bit up close. Again, we launched and deployed this summer. We have good footage [44:19.440 --> 44:24.500] of that launch and deployment on our website, hackasat.com. And we also have a lot of other [44:24.500 --> 44:29.260] tons of good content that describes previous year's challenges and a lot of educational [44:29.260 --> 44:35.140] material as well. Hackasat here at DEF CON is the first use case of Moonlighter, but [44:35.140 --> 44:40.640] we're certainly finding different possibilities of using it in a similar way to help us become [44:40.640 --> 44:46.460] better and more cybersecure. So here's a chart. It's a little bit difficult to read, but we [44:46.460 --> 44:51.640] have the poster of this over in the contest area where we're mainly located. So you can [44:51.640 --> 44:56.340] look a little bit closer at where each of the, all the different components of Moonlighter. [44:56.340 --> 45:01.120] It has everything that's in a real satellite, because that's what it is. Its primary payload [45:01.120 --> 45:06.540] is a camera that's located on the top of it. You can see it right here. And like Jordan [45:06.540 --> 45:11.500] had mentioned, one of the challenges will be taking a photo of Earth. One of the ways [45:11.500 --> 45:15.540] you do that is by finding out where you're oriented. So in space, it's really hard for [45:15.660 --> 45:20.420] a satellite to do that just on gravity, because there is no gravity. So it uses sun sensor, [45:20.420 --> 45:25.820] star trackers to sort of look and orient where it's at. And then it sends commands to the [45:25.820 --> 45:31.460] reaction wheels within it to sort of go and face and point it with good accuracy. So check [45:31.460 --> 45:37.500] out the poster right next door and just talk and ask us a little bit more about it. Essentially, [45:37.500 --> 45:42.900] it's a flying computer that's going 17,000 miles an hour away from you. So it's really [45:42.900 --> 45:48.600] difficult to operate and work with. But it still makes it all the more challenging. And [45:48.600 --> 45:53.640] here's another, more photos of it. Again, this is, that was the actual Moonlighter itself [45:53.640 --> 45:58.120] that we took photos of. That middle photo is the stowed position. That's how it looked [45:58.120 --> 46:04.320] before the solar array panels came out. And it's important to make sure that these solar [46:04.320 --> 46:09.340] array panels are facing towards the sun, obviously, to do resource management with your battery. [46:10.520 --> 46:16.020] Next slide shows... so this is what the competitors see, but it's also what all of you can see, [46:16.020 --> 46:21.560] too. If you go to hackasat.com, we have live tracking of the Moonlighter space vehicle. [46:21.560 --> 46:26.880] We're showing who scored points when, live updates. It also shows the next contact windows [46:26.880 --> 46:30.680] of when people are going to be able to talk to the different ground stations. So we have [46:30.680 --> 46:34.920] four dedicated ground stations specifically for this competition. And you can see there's [46:34.920 --> 46:42.240] one just on the very, very end or bottom of Chile in Punta Arenas. And that's just one [46:42.240 --> 46:46.240] of them. So most of them are in the lower hemisphere. It also shows the different areas [46:46.240 --> 46:50.020] where they can take photos and where they can't take photos. So definitely recommend [46:50.020 --> 46:54.520] checking out the website throughout the competition to find out a little bit more about where [46:54.520 --> 46:59.080] Moonlighter's at. Again, it has a lifetime of about a year and a half before gravity [46:59.080 --> 47:03.980] eventually brings it down and it fizzles up in the atmosphere like a shooting star. But [47:03.980 --> 47:08.480] for now, if you want to keep tracking it, just go to our website. And to close things [47:08.480 --> 47:11.720] off, I'll invite Steve up here. Thank you. [47:15.510 --> 47:21.330] All right. So quickly wrapping things up. A lot of good content, still a lot of competition [47:21.330 --> 47:25.050] to be had, still a lot of things we're getting back from the satellite. So we're going to [47:25.050 --> 47:28.410] have some more things to expose pretty soon. But I just wanted to give you the schedule [47:28.410 --> 47:35.050] for tomorrow that's going to be really important. Whoops, not that. All right. So tomorrow at [47:35.050 --> 47:37.790] noon we're going to announce the winners. So we already talked about why we're going [47:37.790 --> 47:41.390] to announce the winners tomorrow and we can't do it earlier. But also we're going to have [47:41.390 --> 47:44.750] the game designers, we're going to have Jordan, and all the teams are going to be here. But [47:44.750 --> 47:48.710] mostly the game designers are going to talk about some of the, in more detail, what Jordan [47:48.710 --> 47:52.410] couldn't expose today. So it's going to be a really, really deep dive technically. So [47:52.410 --> 47:56.830] if you're into that, please join us. And our announcement, or the special guest will be [47:56.830 --> 48:00.290] announcing the winners. So that will be kind of cool also. So much appreciated for your [48:00.290 --> 48:02.050] time and we look forward to seeing you next door.