[00:11.930 --> 00:17.810]  Welcome back to Space Security Challenge 2020, or Mathesat, as one of our competitors fondly
[00:17.810 --> 00:23.830]  called it. At least, we hope it was fondly. Anyway, I'm your host, Jordan Wines. It's
[00:23.830 --> 00:28.490]  been a quiet few hours since our last update, with, I think, no changes on the scoreboard.
[00:28.490 --> 00:33.410]  However, the teams have surprised us in the past, scoring in the middle of updates. So
[00:33.410 --> 00:38.490]  let's actually take a quick look at the scoreboard now to confirm that. If we look at the octagon,
[00:38.490 --> 00:44.270]  it does indeed look like our teams are scoring the same. Our last two solves with SolarWine
[00:44.270 --> 00:49.670]  and FluxRepeatRocket in Challenge 3. So we're still looking at Challenge 4 and 5 for the
[00:49.670 --> 00:54.870]  rest of the day. While the score hasn't changed, we have had one important game milestone pass
[00:54.870 --> 00:59.970]  us by. We timed out unavailable points for Challenge 3. That means those two teams, SolarWine
[00:59.970 --> 01:04.270]  and FluxRepeatRocket, they've obtained points for that challenge, and all other teams were
[01:04.270 --> 01:08.570]  given a solution script so they can focus on the next challenge. But before we move
[01:08.570 --> 01:12.570]  on to our explainer video for Challenge 3, we actually missed getting you the full explanation
[01:12.570 --> 01:16.150]  for Challenge 2 during our last update, so let's start with that.
[01:17.350 --> 01:24.410]  Challenge 2. The satellite is spinning out of control because the Attitude Determination
[01:24.410 --> 01:31.390]  and Control System, ADCS, has been manipulated. We suspect sabotage. The challenge? Teams
[01:31.390 --> 01:36.330]  must repair the ADCS system as quickly as possible to stop the dangerous spinning.
[01:36.410 --> 01:40.890]  Here's how they do it. Teams may first search the provided documentation for the appropriate
[01:40.890 --> 01:47.030]  command to reset the ADCS. They find it and execute it. But the reset does not work. The
[01:47.030 --> 01:52.630]  ADCS system begins communicating again, but it is not functioning properly. Teams discover
[01:52.630 --> 01:57.850]  that the ADCS configuration tables have been altered and must be restored. They have to
[01:57.850 --> 02:02.650]  the nominal parameters for the configuration tables from the provided user documentation.
[02:02.730 --> 02:07.730]  The teams then have to upload a new table to the vehicle and command the ADCS to load the table.
[02:07.830 --> 02:14.130]  This is how they will restore nominal operation of the ADCS. Good news! With the ADCS configuration
[02:14.130 --> 02:19.790]  table updated, they receive nominal status from the ADCS, but the majority of the ADCS
[02:19.790 --> 02:25.010]  commands still don't work. Teams realize that they can point the satellite by uploading various
[02:25.010 --> 02:30.490]  ADCS configuration tables, each with different pointing modes and configuration parameters,
[02:30.490 --> 02:35.470]  and loading them at different points in the orbit of the satellite. This allows the teams to stop
[02:35.470 --> 02:40.070]  the spin of the vehicle and point the solar arrays at the sun to charge the batteries.
[02:44.350 --> 02:48.210]  All right, now that we're caught up, here's a little bit more about the intended solution to
[02:48.210 --> 02:57.030]  Challenge 3. Challenge 3. Here's what we know. With the update to the ADCS, the teams have
[02:57.030 --> 03:01.350]  regained control of the satellite, but we still can't communicate with the payload module or
[03:01.350 --> 03:06.110]  operate the imager. In addition, the majority of useful commands are not being accepted by
[03:06.110 --> 03:10.910]  the flight software. We have to ask ourselves, what else did they damage on this satellite?
[03:11.090 --> 03:15.790]  The challenge? Teams must restore communication with the payload module so we can get it working
[03:15.790 --> 03:20.970]  again. Here's how they do it. The teams find that their initial commands to communicate with the
[03:20.970 --> 03:25.490]  payload module are not being accepted by the flight software. It's clear that the command
[03:25.490 --> 03:31.830]  and data handling C and DH system is not working appropriately. In fact, payload commands and the
[03:31.830 --> 03:37.690]  majority of the other commands have been disabled in the C and DH system. It turns out the attacker
[03:37.690 --> 03:42.910]  has modified the C and DH flight software and are now running their own code on board the space
[03:42.910 --> 03:47.670]  vehicle. The attacker code is rejecting the majority of commands to the satellite, including
[03:47.670 --> 03:54.510]  firmware updates, firmware restore, and ADCS commands. As a result, it is not possible to
[03:54.510 --> 04:00.210]  restore the failsafe image as the restore command has been disabled. Lucky for the teams, the attacker
[04:00.210 --> 04:05.390]  was sloppy and inadvertently introduced a vulnerability in the new firmware image. Teams
[04:05.390 --> 04:11.210]  exploit this vulnerability and use it to repair the system and restore the C and DH software back
[04:11.210 --> 04:16.250]  to normal operation. Once that is complete, they are able to communicate with the payload module
[04:16.250 --> 04:25.860]  once again. Challenge 3 happens to be my personal favorite as it, along with challenge 0, are probably
[04:25.860 --> 04:31.020]  the most similar to regular CTF challenges. I always love a good pwnable. Since we have some
[04:31.020 --> 04:36.080]  time in this update, I want to introduce a new graphic to you that we call the Race to Space.
[04:36.400 --> 04:41.820]  This will be a visualization we'll be using later on today to measure the team's on-orbit submissions.
[04:41.920 --> 04:46.460]  The closer to the center of the bullseye, the more accurate the solution. And of course, the minimum
[04:46.460 --> 04:51.600]  acceptance bar will let us see the solutions that were not accurate enough to be accepted. Each team
[04:51.600 --> 04:56.660]  gets their own little slice of the pie, and we'll be able to see how many tries it took to become
[04:56.660 --> 05:03.840]  accepted and or how accurate teams got. You may remember that we have four teams that all
[05:03.840 --> 05:09.300]  submitted accepted solutions before the 4 p.m pacific cutoff yesterday. They were Poland Cannon
[05:09.300 --> 05:15.620]  to Space ahead of the pack, and then ADD Vulcan, Flux Repeat Rocket, and finally Samurai. Speaking
[05:15.620 --> 05:19.920]  of ADD Vulcan, we haven't yet had a chance to show off their biography, so let's let's check
[05:19.920 --> 05:26.360]  them out now in recognition of them being the second accepted solution to the on-orbit challenge.
[05:54.360 --> 05:58.000]  Apparently, the real reason ADD Vulcan is participating in HackASAT
[05:58.000 --> 06:02.920]  was just as an excuse to make pink Starfleet uniforms. Go check out their Twitter Team Twitter
[06:02.920 --> 06:08.160]  account for more info on that. Also, one of the main team members, AmyDD, was on the recent TV
[06:08.160 --> 06:13.180]  show Lego Masters and also hosts an awesome STEM for Girls scholarship. That's it for this
[06:13.180 --> 06:18.800]  competition update. I'll see you back here in one hour at 11 50 a.m pacific, 2 50 p.m eastern.