79 lines
3.3 KiB
Markdown
79 lines
3.3 KiB
Markdown
# 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](https://awoo.systems)
|
|
|
|
Two files are provided, one is a [COSMOS](https://cosmosrb.com/) directory tree for accessing a
|
|
virtual satellite running [NASA's Core Flight System](https://cfs.gsfc.nasa.gov/) 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
|
|
|
|
```json
|
|
{"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.
|
|
|
|
|
|
|
|
## Resources and other writeups
|
|
|
|
* <https://cosmosrb.com/>
|
|
* <https://cfs.gsfc.nasa.gov/>
|