xenia 1d4e3c29eb | ||
---|---|---|
.. | ||
Dockerfile | ||
README.md | ||
cosmos1.png | ||
cosmos2.png | ||
cosmos3.png | ||
cosmos4.png | ||
cosmos5.png | ||
launch-docker.sh |
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 ~/.bashrcrm Gemfile.lock
bundle installHint: 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,)
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.
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.
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).
Once we write the scheduler entry, the satellite will start sending COSMOS flags, which can be seen in the Packet Viewer.