[00:01.110 --> 00:05.330]  Challenge 3 Here's what we know.
[00:05.330 --> 00:09.350]  With the update to the ADCS, the teams have regained control of the satellite.
[00:09.350 --> 00:13.350]  But we still can't communicate with the payload module or operate the imager.
[00:13.390 --> 00:17.990]  In addition, the majority of useful commands are not being accepted by the flight software.
[00:17.990 --> 00:21.510]  We have to ask ourselves, what else did they damage on this satellite?
[00:21.610 --> 00:25.210]  The challenge? Teams must restore communication with the payload module
[00:25.210 --> 00:28.930]  so we can get it working again. Here's how they do it.
[00:28.930 --> 00:32.410]  The teams find that their initial commands to communicate with the payload module are
[00:32.410 --> 00:36.930]  not being accepted by the flight software. It's clear that the command and data handling
[00:36.930 --> 00:42.770]  C&DH system is not working appropriately. In fact, payload commands, and the majority
[00:42.770 --> 00:46.830]  of the other commands, have been disabled in the C&DH system.
[00:47.010 --> 00:50.750]  It turns out the attacker has modified the C&DH flight software
[00:50.750 --> 00:54.470]  and are now running their own code on board the space vehicle.
[00:54.570 --> 00:58.710]  The attacker code is rejecting the majority of commands to the satellite including firmware
[00:58.710 --> 01:05.410]  updates, firmware restore, and ADCS commands. As a result, it is not possible to restore
[01:05.410 --> 01:08.490]  the failsafe image as the restore command has been disabled.
[01:09.210 --> 01:13.650]  Lucky for the teams, the attacker was sloppy and inadvertently introduced a vulnerability
[01:13.650 --> 01:19.230]  in the new firmware image. Teams exploit this vulnerability and use it to repair the system
[01:19.230 --> 01:23.390]  and restore the C&DH software back to normal operation.
[01:23.450 --> 01:27.790]  Once that is complete, they are able to communicate with the payload module once again.