[00:05.160 --> 00:11.940]  Welcome to Space Security Challenge 2020, HackASAT, the final event. As the democratization
[00:11.940 --> 00:17.400]  of space opens up a new frontier for exploration and innovation, we see new cybersecurity
[00:17.400 --> 00:24.040]  vulnerabilities emerging. The Space Security Challenge is designed to inspire the world's
[00:24.040 --> 00:29.740]  top cybersecurity talent to develop the skills necessary to secure this last frontier of
[00:29.740 --> 00:37.280]  cybersecurity, space. And already we've made a ton of progress. I'll catch you up. This
[00:37.280 --> 00:42.080]  spring, we hosted over 2,000 teams who worked their way through a set of foundational space
[00:42.080 --> 00:48.000]  cybersecurity challenges in our HackASAT qualification round. Now, eight finalist
[00:48.000 --> 00:54.080]  teams are stepping up to the ultimate challenge. They are hacking a satellite.
[01:00.860 --> 01:06.420]  Welcome to the Saturday daily recap of Space Security Challenge 2020, or HackASAT.
[01:06.960 --> 01:12.080]  For the second to last time, I'm your host, Jordan Wines, and it's time to fill you in on how our
[01:12.080 --> 01:17.420]  competitors did on day two of this first-of-its-kind satellite hacking competition. Okay, let's get
[01:17.420 --> 01:22.500]  right to the moment everyone's been waiting for. Here is our video to show which team was selected
[01:22.500 --> 01:31.260]  for the on-orbit challenge. Oh, I'm sorry. Actually, it appears that we're experiencing
[01:31.260 --> 01:35.600]  some technical difficulties. Yeah, I guess that means you're going to have to listen to the rest
[01:35.600 --> 01:40.560]  of this update, and then we'll play the big reveal at the end instead. So let's take a look back at
[01:40.560 --> 01:52.380]  today's action. In fact, let's go ahead and take a look at the scoreboard now in our live Octagon
[01:52.380 --> 01:58.400]  feed. And they definitely haven't slowed down. You'll notice that Solarwine actually scored first
[01:58.400 --> 02:03.900]  blood on Challenge 3. Congratulations to them for the great work overnight. You can also see Flux
[02:03.900 --> 02:09.660]  Repeat Rocket scoring just before this broadcast with only a 5% reduction in total points. That
[02:09.660 --> 02:14.760]  means Solarwine and Flux Repeat Rocket are both moving on to Challenge 4. While the score hasn't
[02:14.760 --> 02:19.960]  changed, we have had one important game milestone pass us by. We timed out unavailable points for
[02:19.960 --> 02:24.960]  Challenge 3. That means those two teams, Solarwine and Flux Repeat Rocket, they've obtained points
[02:24.960 --> 02:29.420]  for that challenge, and all other teams were given a solution script so they can focus on the next
[02:29.420 --> 02:39.180]  challenge. If you've been following along at home, you know that we sprung our on-orbit challenge on
[02:39.180 --> 02:44.520]  our teams yesterday. We had four teams submit their solutions by 4 p.m. Pacific, our deadline
[02:44.520 --> 02:49.740]  for evaluation for on-orbit, but only one was selected to have their code sent to the live
[02:49.740 --> 02:54.800]  satellite to capture a moonshot. We will learn who that lucky team is later on in the broadcast.
[02:55.840 --> 03:00.960]  While today's action started strong with several early scores, teams really struggled their way
[03:00.960 --> 03:05.560]  through Challenge 4 today. While the organizers knew it would be the hardest challenge, the hope
[03:05.560 --> 03:10.300]  was that it would be solved before this point. In fact, in the last hour of the competitions, some
[03:10.300 --> 03:15.440]  team had run so low on power that the organizers offered to take the flatsats offline so they
[03:15.440 --> 03:21.440]  could plug them into power. This would mean teams would have challenges in solving Challenge 5,
[03:21.440 --> 03:26.440]  but hopefully it would give them enough power and time to solve Challenge 4 in the last few minutes.
[03:26.640 --> 03:31.760]  Given that, here is our explanation for the Challenge 4 solution.
[03:32.740 --> 03:39.240]  Challenge 4. Here's what we know. We've restored communication with the payload module, but we
[03:39.240 --> 03:44.440]  still can't operate it. The challenge? Now teams must restore normal operations of the payload
[03:44.440 --> 03:49.800]  module so we can access the imager. Here's how they do it. Teams discover that the payload
[03:49.800 --> 03:54.720]  module bootloader has been corrupted, which is why the payload module is not operating normally.
[03:54.720 --> 03:59.060]  The teams discover a system console to the payload module and the ability to access the
[03:59.060 --> 04:05.160]  payload module system console by controlling an undocumented GPIO and multiplexer on the CNDH
[04:05.160 --> 04:10.080]  board. The teams must write a custom flight software application that can control the GPIO
[04:10.080 --> 04:14.820]  and enable access to the payload system console. After writing the application,
[04:14.820 --> 04:19.820]  the teams must upload it to the CNDH and execute it. Once the teams have access to the system
[04:19.820 --> 04:24.580]  console, they will identify that it has been corrupted. The teams will need to research
[04:24.580 --> 04:29.360]  nominal kubos bootloader configuration and repair the payload module's bootloader to resume proper
[04:29.360 --> 04:39.840]  operation of the payload module. As I mentioned during a previous update, there was always a
[04:39.840 --> 04:43.880]  chance that the scoreboard was going to go dark. And sure enough, with 30 minutes left in the
[04:43.880 --> 04:48.300]  competition, as teams were hopefully nearing it on a challenge four solution, the organizers
[04:48.300 --> 04:53.060]  decided to keep us all in suspense. Here's a look at our final scoreboard that everyone saw
[04:53.060 --> 05:00.600]  before it went dark. As we can tell, we had a couple of solves later on, but early was where
[05:00.600 --> 05:05.220]  most of the action happened. However, with our accepted and rejected on orbit status,
[05:05.220 --> 05:09.200]  we knew that there was two teams who would not be eligible for final prizes.
[05:09.200 --> 05:14.700]  We will make the final actual scores available tomorrow during the closing ceremony. Before you
[05:14.700 --> 05:18.840]  make your predictions on our podium winners, let's take a look at the final challenge five
[05:18.840 --> 05:23.240]  to see what it was teams would have had to solve after they finished challenge four.
[05:24.600 --> 05:30.780]  Challenge five. Here's what we know. We've done our best work and it seems that we've regained
[05:30.780 --> 05:36.900]  control of the satellite. But how do we know for sure? The challenge? Teams must prove that we are
[05:36.900 --> 05:41.000]  fully in control of the satellite system by successfully imaging the moon.
[05:51.240 --> 05:54.700]  Thought I could have solved some of these challenges and the answer was almost certainly
[05:54.700 --> 05:59.040]  not. I've got a lot of respect for the teams out there who made progress at all through this event
[05:59.040 --> 06:04.160]  with a very difficult environment, very different to what many other CTFs have to do. There's a lot
[06:04.160 --> 06:08.720]  of extra constraints you have to worry about. For more information on that, let's do one last Q&A
[06:08.720 --> 06:14.140]  session with Jason Latimer to talk about how teams were approaching challenge four. Let's see if we
[06:14.140 --> 06:20.120]  can get him in here. Jason, do you hear me? Yeah, I got you. Excellent. I hear you as well. Great.
[06:20.120 --> 06:27.420]  So, we're wrapped up. The game is over. I hopped into a couple of your calls and I was listening
[06:27.420 --> 06:32.580]  to you guys describe some of the approaches teams were taking on challenge four. I thought
[06:32.580 --> 06:34.880]  there's some really, really interesting things that came out of that. I'd love to hear a little
[06:34.880 --> 06:40.980]  bit more from your perspective. Yeah, so the background on challenge four was that, you know,
[06:40.980 --> 06:45.760]  teams had gotten past the implant that the adversary had put on the satellite and that
[06:45.760 --> 06:50.420]  they were trying to use the payload and quickly found that the payload wasn't functional.
[06:51.720 --> 06:57.420]  So, what the adversary had done was corrupted the bootloader. And so, they had to, you know,
[06:57.420 --> 07:02.560]  uncorrupt the bootloader. There were a number of approaches. Teams seemed to be struggling in the
[07:02.560 --> 07:07.380]  beginning. So, at one point, we gave a hint that said, hey, you need to write an application that's
[07:07.380 --> 07:13.400]  capable of communicating with the system console and enabling that system console via GPIO.
[07:13.480 --> 07:20.360]  Very quickly, teams started uploading their custom CFS applications. Some teams were just
[07:20.360 --> 07:25.860]  trying to enable the GPIO to control the system console based on other GPIOs that were already
[07:25.860 --> 07:31.100]  on the system. And they had done that successfully. And then we had some unique approaches where
[07:31.100 --> 07:37.120]  teams were trying to upload applications that could do like TFTP transfers to the device. So,
[07:37.320 --> 07:43.800]  a number of different approaches. I was going to say, so, the application that they're compiling,
[07:43.800 --> 07:48.580]  was this like just a standard compiler they could use? Or what sort of information about
[07:48.580 --> 07:53.280]  that environment did they have to have to build these custom applications? Yeah, so, it's actually
[07:53.460 --> 07:57.300]  a little bit more complicated than that. And we didn't want that to be the challenge behind the
[07:57.300 --> 08:01.420]  whole, you know, restoring the bootloader. So, we actually did provide to the teams ahead of time
[08:01.420 --> 08:07.000]  the RTEMS build environment they would need to build an application. And then we provided also
[08:08.120 --> 08:13.680]  a set of example applications that they could use as a template for creating this application
[08:13.680 --> 08:18.180]  that would restore the bootloader on the payload. There was still quite a bit of challenges there
[08:18.180 --> 08:21.800]  because there were specific peripherals that they'd have to be able to control. So,
[08:21.800 --> 08:30.520]  talking to, you know, specific UART and GPIO drivers to do that. So, it was non-trivial.
[08:30.520 --> 08:33.100]  Yeah, what did your solution look like? I mean, it just sort of like,
[08:33.100 --> 08:36.680]  did it rebuild it? Or how did your intended solution work on that?
[08:36.880 --> 08:44.060]  So, we had a custom application that ran in CFS that could talk to the Raspberry Pi system console
[08:44.060 --> 08:48.740]  over the UART. So, it was literally like talking to this, you know, system console. We would send
[08:48.860 --> 08:53.700]  a command and we could, you know, do an LS on the shell or whatever it was. And through that,
[08:53.700 --> 09:00.400]  we could restore the bootloader via just typical system console commands. But in order to actually
[09:00.400 --> 09:08.280]  enable that UART, we had a GPIO that was hidden. So, one of the challenges for Challenge 4 was
[09:08.280 --> 09:14.340]  actually looking through the FPGA Verilog and VHDL code and finding that that actually existed. So,
[09:14.340 --> 09:18.640]  we had gotten some feedback during quals that, you know, teams were really interested in doing
[09:18.640 --> 09:24.320]  that kind of documentation reverse engineering. So, we went to a lot of effort to make sure that
[09:24.320 --> 09:30.160]  that existed. So, to even identify that that was there, they were doing code inspections of the
[09:30.160 --> 09:34.960]  Verilog for the FPGA. Now, I heard hints that, like, at least one team was doing something
[09:34.960 --> 09:43.740]  creative with, like, direct memory writes. What do we know about that? All we know about that, well,
[09:44.720 --> 09:49.640]  teams were doing uploads of applications, but it looked like some teams were using the direct
[09:49.640 --> 09:55.040]  memory writes to actually interact with that shell, the Raspberry Pi shell. So, a little
[09:55.040 --> 10:00.380]  different than our approach, but yeah, it was interesting. If it gets your code running,
[10:00.380 --> 10:05.120]  it gets it working, right? There's no points for the jankiness or the cleverness. It's just,
[10:05.120 --> 10:08.680]  does it solve the challenge, right? So, one of the things that I just mentioned to people,
[10:08.680 --> 10:13.360]  of course, was the power constraints and how many of the satellites were running low on power at the
[10:13.360 --> 10:18.140]  end from a lot of movement throughout the day and a lot of usage and the sort of option they had to
[10:18.140 --> 10:22.700]  get connected to a ground power. Tell me how that changed the sort of Challenge 5 requirements. And
[10:22.700 --> 10:27.720]  if a team was able to solve a Challenge 4 after the SCOBR went dark, would they have been able to
[10:27.720 --> 10:32.620]  do it from the ground or was that completely impossible or what happened there? Yeah. So,
[10:32.620 --> 10:36.580]  we talked with the organizers and based on the fact that we had these power constraints
[10:37.480 --> 10:42.020]  and that the teams that had elected to be put on the ground wouldn't be able to get a picture of
[10:42.020 --> 10:47.580]  the moon, we adjusted the criteria for Challenge 5 to just be get a picture. It was interesting to
[10:48.320 --> 10:58.220]  the different teams were doing as far as power. Some teams had conserved their power throughout
[10:58.220 --> 11:03.080]  the day and other teams had not. So, we had some teams that were in the running to solve Challenge
[11:03.080 --> 11:08.760]  4 that said, hey, we don't want to be put on the ground. We'll just stay on the carousel. We've
[11:08.760 --> 11:12.180]  been good with the batteries all day. And we actually mentioned that in an earlier update
[11:12.180 --> 11:16.100]  here that power was potentially a concern. And it was nice that teams weren't entirely
[11:16.100 --> 11:19.980]  out of the running, right? There was sort of a backup mechanism, but it cost them time while
[11:20.660 --> 11:24.920]  their flat set was taken down, was rewired in. And so, that was sort of a penalty for exercising
[11:24.920 --> 11:29.100]  that option, although they weren't kind of out of the running entirely. That works out great.
[11:29.280 --> 11:33.700]  All right. Well, thank you very much for taking time to talk to us and we'll continue on with
[11:33.700 --> 11:40.340]  the rest of our update. Thank you. All right. Now, the moment that you hopefully have actually
[11:40.340 --> 11:45.040]  been waiting for. We're going to answer the question as to which team had their code sent
[11:45.040 --> 11:50.640]  into space tonight. So, the video that we're going to look at here is the same one that I
[11:50.640 --> 11:56.040]  previewed earlier. So, we can see Poland Can is the very first team to get an acceptable payload.
[11:56.040 --> 12:00.760]  We knew that from watching the scoreboard and got reasonably close. Next coming in are going to be
[12:00.760 --> 12:05.640]  several other teams. ADD Vulcan, number two, and then number three, Flux Repeat Rocket. So,
[12:05.640 --> 12:10.440]  we've got the three quickest ones and then we're going to have right here a Samurai come in. So,
[12:10.440 --> 12:14.000]  these were the four that came in before the timeline. So, if we stop right now,
[12:14.000 --> 12:18.700]  this is our launch cutoff, right? So, these were the teams that came in. And if we look at closest
[12:18.700 --> 12:24.740]  to the bullseye, you can see that Poland Candidate Space just beat out Flux Repeat Rocket with the
[12:24.740 --> 12:30.700]  most accurate solution during our window. And this is the payload that's being run on an actual
[12:30.700 --> 12:36.340]  satellite right now. So, we're looking forward to getting the results back from that tonight as it
[12:36.340 --> 12:40.300]  runs. And then tomorrow during the live event, we're going to show you hopefully the moonshot.
[12:40.300 --> 12:44.340]  Find out how accurate it was. And of course, we're going to continue the run here because
[12:44.340 --> 12:49.500]  as I mentioned earlier, we know there was that sort of like sudden death for the last two slots,
[12:49.500 --> 12:53.480]  right? And we could see the teams that were... two more slots that were available. And so,
[12:53.480 --> 12:57.980]  after that 7 p.m. cutoff, we had a quick 1550 tree that was able to make it in. But we also
[12:57.980 --> 13:02.620]  noticed that Poland Candidate really got in close. And so, they got a really, really nice solution.
[13:02.620 --> 13:06.920]  They kept iterating on it. There was no points for it. There was no extra... it was not considered
[13:06.920 --> 13:12.540]  for the on-orbit. But it was so good that the individuals we had evaluating all of the
[13:12.540 --> 13:17.460]  solutions, they had a lot of automation. But there was also, I guess, a little bit of an art to it.
[13:17.460 --> 13:22.380]  They were explaining that they thought that final Poland Candidate was so beautiful that it was like
[13:22.480 --> 13:29.120]  a piece of art. They loved that final solution. And then of course, we had our last solve here
[13:29.120 --> 13:34.500]  coming in that's going to be from PFS, which we've already revealed. They were the last team
[13:34.500 --> 13:39.700]  to make it into the qualifying minimal acceptable range, which unfortunately left our two other
[13:39.700 --> 13:48.240]  teams, which were Solarwine and 1064 Seabread, not in the running for that. So, first of all,
[13:48.240 --> 13:53.460]  congrats to Team Poland Candidate into space for submitting not only the best solution overall
[13:53.460 --> 13:59.240]  throughout the whole evaluation period, but the solution that is going to space. Let's see their
[13:59.240 --> 14:37.380]  team bio again. And into space, I can confirm that your commands were uplinked to our comms
[14:37.380 --> 14:41.880]  in our comms window earlier today. We expect the moonshot to happen in a couple of hours at 630
[14:41.880 --> 14:47.020]  Pacific, and that picture will be sent down to earth at about 1am Pacific. We will review what
[14:47.020 --> 14:51.680]  is hopefully a clear moonshot picture at tomorrow's closing ceremonies. It all depends on how accurate
[14:51.680 --> 14:56.360]  your command really was. Fingers crossed. You'd think that just watching instead of playing would
[14:56.360 --> 15:00.300]  be less stressful, and I'm sure it was worse for our competitors. But even in the production room,
[15:00.300 --> 15:03.640]  we were cheering and sweating along with our teams as they worked their way through these
[15:03.640 --> 15:09.060]  challenges. Thanks very much for joining us throughout this event. That's it for today's
[15:09.060 --> 15:14.460]  recap. Make sure you tune in to HackASAC closing ceremonies tomorrow at 11 Pacific, where we will
[15:14.460 --> 15:20.060]  hopefully reveal the world's first CTF moonshot taken by Poland Candid to space. We'll also show
[15:20.060 --> 15:24.660]  you the overall contest results and award the prizes to our teams and reveal what happened
[15:24.660 --> 15:29.020]  after the scoreboard went dark. We'll also hear closing remarks by Dr. Will Roper from the U.S.
[15:29.020 --> 15:33.660]  Space Force and Air Force Acquisition Chief. Be sure to also check out all the great happenings
[15:33.660 --> 15:38.340]  going on at DEFCON and in the Aerospace Village. See you tomorrow at 11 Pacific for the closing
[15:38.340 --> 15:39.220]  ceremonies.