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