10
2
Fork 0
has-writeup/payload/calendar
xenia 1d4e3c29eb calendar 2020-05-26 22:33:28 -04:00
..
Dockerfile calendar 2020-05-26 22:33:28 -04:00
README.md calendar 2020-05-26 22:33:28 -04:00
cosmos1.png calendar 2020-05-26 22:33:28 -04:00
cosmos2.png calendar 2020-05-26 22:33:28 -04:00
cosmos3.png calendar 2020-05-26 22:33:28 -04:00
cosmos4.png calendar 2020-05-26 22:33:28 -04:00
cosmos5.png calendar 2020-05-26 22:33:28 -04:00
launch-docker.sh calendar 2020-05-26 22:33:28 -04:00

README.md

That's not on my calendar

Category: Payload Modules Points (final): 80 Solves: 52

Time for a really gentle introduction to cFS and Cosmos, hopefully you can schedule time to learn it!

Build instructions:

./setup.sh source ~/.bashrc rm Gemfile.lock bundle install

Hint: You will need to enable telemetry locally on the satellite, the udp forwarder will provide it to you as TCP from there

Write-up

by haskal

Two files are provided, one is a COSMOS directory tree for accessing a virtual satellite running NASA's Core Flight System that can be booted up using the provided netcat endpoint. COSMOS is an open-source command and control framework for satellites using cFS. Booting up COSMOS is enormously complicated, so Docker can be used to automate the setup. We adapted the Ball Aerospace COSMOS Docker image, and created a script to configure COSMOS to connect to the CTF's satellite instance automatically by writing the configuration file at cosmos/config/tools/cmd_tlm_server/cmd_tlm_server.txt. When COSMOS is successfully connected to the CTF instance it looks like this (no themes were installed in the Docker container so it looks like Windows 95, I'm so sorry,)

Main COSMOS screen

The second file is an archive of some JSON configuration for the satellite operating system. Importantly, it contains the types of telemetry messages the satellite can send, and the default scheduler table that configures when the satellite sends the messages. There is a telemetry packet that sends us the flag configured here

      {"message": {
         "name":  "KIT_TO_SEND_FLAG_MID",
         "descr": "Super Secret Flag Sending Telemetry Message",
         "id": 42,
         "stream-id": 33304,
         "seq-seg": 192,
         "length": 256
      }},

As hinted in the description, we can send a KIT_TO ENABLE_TELEMETRY command using the COSMOS command sender. KIT_TO is the subsystem for Telemetry Output, and it has commands available to control the telemetry sending.

COSMOS sending an ENABLE_TELEMETRY command

However we find that even after telemetry is enabled, we're not getting the flag telemetry even though we start to receive other types of telemetry messages.

COSMOS telemetry viewer, we have 0 flag packets

This is because, if we look back at the JSON config we find that the scheduler doesn't have any slots where it sends flag telemetry packets. The key part of this challenge is that the scheduler can be configured at runtime using commands for KIT_SCH (the scheduler subsystem), as we found out by exploring the available commands in COSMOS. Particularly there is a command LOAD_SCH_ENTRY that allows us to overwrite one of the scheduler entries. We can use the command sender to send this command and load slot 0, activity 0 (or any slot, it doesn't matter) to be for message ID 42 (the flag packet ID), and to be enabled (1).

COSMOS sending this LOAD_SCH_ENTRY command

Once we write the scheduler entry, the satellite will start sending COSMOS flags, which can be seen in the Packet Viewer.

COSMOS packet viewer showing the flag

Resources and other writeups