National space security is an expression of national security in the space domain. With the increasing application of space technology in various fields such as politics, economics, military, and culture, space has become one of the lifelines for national survival and development, embodying enormous national interests, and the importance of space security is becoming increasingly prominent[1]. In the information age, space security is closely integrated with information security.
On September 4, 2020, the White House released the first directive on space cybersecurity – “Space Policy Directive-5”, which is the first comprehensive policy on network security for satellites and related systems in the United States, marking a new height in the importance the U.S. places on space network security. Against this backdrop, the U.S. has held the “Hack-A-Sat” space information security competition for two consecutive years since 2020. A detailed introduction can be found in “In-Depth Analysis of the Hack-A-Sat Space Information Security Challenge”, and this article discusses the solution process for the Hack-A-Sat satellite hacking challenge’s payload task scheduling (monroe) problem.
Problem Introduction
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:
cosmos.tar.gz calendar_hint1.zip
Connect to the challenge on calendar.satellitesabove.me:5061.
From the problem description, the following information can be obtained:
(1) Related to cFS and COSMOS, the basic introduction of these two systems will be provided in the following text.
(2) This problem requires enabling the satellite’s telemetry function first.
(3) Two compressed packages are provided, among which cosmos.tar.gz is a customized COSMOS, and installation instructions are given; calendar_hint1.zip contains three files in JSON format, the specific meanings of which are still unknown and will be analyzed later.
-
cpu1_kit_sch_msg_tbl.json
-
cpu1_kit_sch_sch_tbl.json
-
cpu1_kit_to_pkt_tbl.json
The above is all the information about the problem, and more comprehensive information may be obtained after installing COSMOS.
Compilation and Testing
To verify that the downloaded source code is correct, you can compile and test it first. Enter the monroe directory of hackasat2020 and compile directly, which is relatively smooth, but may take some time.
sudo make build
Use the following command for testing, the test result is shown in Figure 6-1. From Figure 6-1, it can be seen that the flag value was correctly obtained.
sudo make test
Figure 6-1 Monroe test results
Related Background Knowledge
1. COSMOS
COSMOS (Command and Control of Embedded Systems) is an application used to control a group of embedded systems, including test equipment (power supplies, oscilloscopes, switch power boards, UPS devices, etc.), development boards (Arduinos, Raspberry Pi, Beaglebone, etc.), satellites, etc. At the time of writing, the latest version of COSMOS is V5, which is a web page version, but this challenge provides a customized COSMOS using V4, so this book introduces COSMOS V4.
COSMOS V4 is a client/server (C/S) architecture, not a web page version. Its architecture is introduced in Chapter 3 of this book, for the convenience of readers, a brief explanation is given here. The architecture of COSMOS V4 is shown in Figure 6-2.
(1) The center is the Command & Telemetry Server, which can interact with various targets (including satellites, aircraft, etc.) via TCP, UDP, serial port, etc.
(2) The upper left corner is the Realtime Commanding and Scripting Tools.
(3) The upper right corner is the Realtime Telemetry Visualization Tools.
(4) The lower left corner is auxiliary tools, including Config Editor, etc.
(5) The lower right corner is offline analysis tools, including Telemetry Viewer, etc.
Figure 6-2 COSMOS V4 architecture
To install COSMOS V4, you can download the source code from its official website for installation, but the COSMOS for this challenge is customized by the organizers. To solve this challenge, you must use the COSMOS provided by the organizers. Therefore, according to the problem prompt, install the COSMOS provided by the organizers. After testing, it needs to be installed on Ubuntu 14.04 64bit, for this, you need to install a virtual machine of Ubuntu 14.04 64bit. In the virtual machine, first update the Ruby version using the following command:
sudo add-apt-repository ppa:brightbox/ruby-ng
sudo apt-get update
sudo apt-get purge –auto-remove ruby
sudo apt update
sudo apt-get install ruby2.6 ruby2.6-dev
sudo gem install bundle
source ~/.bashrc
rm Gemfile.lock
sudo bundle install
Then execute the following installation command:
./setup.sh $ source ~/.bashrc $ rm Gemfile.lock $ bundle install
After successful installation, there will be a prompt as shown in Figure 6-3.
Figure 6-3 COSMOS installation success prompt
At this point, input the following command to run COSMOS, its interface is shown in Figure 6-4. From this, it can be seen that the categorization of each small program is basically according to the architecture shown in Figure 6-2.
sudo ruby ~/cosmos/tools/Launcher
Figure 6-4 COSMOS main interface
To simulate the environment set by the organizers for this challenge, first execute the following command on the host machine, where the IP address needs to be modified according to the actual situation. The purpose of this command is to run a container and run the monroe challenge server within it.
sudo docker run –rm -i -e SERVICE_HOST=192.168.31.43 -e SERVICE_PORT=19021 -e SEED=1 -e FLAG=flag{zulu49225delta:G1EnNVMK3-hPvlNKAdEJxcujvp9WK4rEchuEdlDp3yv_Wh_uvB5ehGq-fyRowvwkWpdAMTKbidqhK4JhFsaz1k} -p 19021:54321 monroe:challenge
In the virtual machine, first run the following command to use socat for port forwarding.
socat -d -d TCP-L:54321,fork,reuseaddr TCP:192.168.31.43:19021
Then open COSMOS in the virtual machine, click the Config Editor button, and in the pop-up interface as shown in Figure 6-5, set the telemetry server address to 127.0.0.1 and the port to 54321.
Figure 6-5 Setting telemetry server address and port information in COSMOS
Run COSMOS again, click the HAS Quals button, and a pop-up interface as shown in Figure 6-6 will appear, indicating that COSMOS successfully connected to the telemetry server.
Switch to the Tlm Packets tab, and you will find that the number of telemetry packets is 0, indicating that no telemetry data packets have been received, as shown in Figure 6-7.
The problem mentions that the telemetry function needs to be enabled first, so you need to click the Command Sender button on the COSMOS main interface, pop up the command sending interface, select the KIT_TO option in the Target drop-down list, at this time, the ENABLE_TELEMETRY option will appear in the Command drop-down list, as shown in Figure 6-8. Then click the Send button to send this command, and it can be seen that telemetry packets are received quickly, as shown in Figure 6-9, indicating that the satellite’s telemetry function has been enabled. The next step to obtain the flag value requires further analysis.
Figure 6-6 COSMOS successfully connected to the telemetry server
Figure 6-7 Telemetry data packet reception interface
Figure 6-8 Enabling telemetry function
Figure 6-9 Received telemetry data packets
2. cFS
Having successfully enabled the telemetry information sending function through COSMOS, telemetry information has been received. However, to ultimately obtain the flag, some basic knowledge needs to be understood. Through the COSMOS operation interface, such as the Target drop-down list in the command sending interface, as shown in Figure 6-10, it can be found that there are many Targets starting with CFE, which are related to cFS. The specific content of cFS can be found in section 3.2.3 “cFS”.
3. OpenSatKit
OpenSatKit, abbreviated as OSK, integrates COSMOS and cFS and makes some extensions, which can be simplified as shown in Figure 6-11.
Figure 6-10 Target drop-down list in the command sending interface
Figure 6-11 Simplified composition of OSK
From Figure 6-11, it can be seen that OSK has added several applications, as indicated by the dark boxes in the figure, with the following functions:
-
KIT_CI (Kit Command Ingest): Used to receive commands in CCSDS format sent from COSMOS and publish them to the software bus.
-
KIT_TO (Kit Telemetry Output): Reads CCSDS-formatted telemetry data reports (also known as messages) from the software bus and sends them to COSMOS. It can use a filtering table to select which messages to send to COSMOS.
-
KIT_SCH (Kit Scheduler): A scheduler that contains several tables defining how messages are published to the software bus. It uses two tables, one for messages and one for scheduling. The scheduler executes once per second, sending messages from the message table according to the scheduling requirements in the scheduling table.
When enabling the telemetry function, the selected Target is KIT_TO, and the selected Command is ENABLE_TELEMETRY, which sets the KIT_TO of OSK to output telemetry information and send it to COSMOS.
From the names of the three files provided in the problem, it can be inferred that these three files correspond to the three tables of KIT_TO and KIT_SCH, as follows:
-
cpu1_kit_sch_msg_tbl.json: Message table of KIT_SCH.
-
cpu1_kit_sch_sch_tbl.json: Scheduling table of KIT_SCH.
-
cpu1_kit_to_pkt_tbl.json: Filtering table of KIT_TO.
As for how to use these three tables, they will be further analyzed in the following text.
Problem Analysis
1. Message Table of KIT_SCH
Open the cpu1_kit_sch_msg_tbl.json file, which has the following description. Here, the message format is defined, and it can be seen that it is a CCSDS message. The details of CCSDS have already been introduced in the previous text, so it will not be repeated, and it is not necessary to know the detailed details to solve this challenge.
“name”: “Scheduler Table Message Table”,
“description”: [
“Maximum of 32 words per CCSDS message. The first three words are”,
“the primary header that must be big endian: “,
“uint16 StreamId; /* packet identifier word (stream ID) */ “,
” /* bits shift description */”,
” /* 0x07FF 0 : application ID */”,
” /* 0x0800 11 : secondary header: 0 = absent, 1 = present */”,
” /* 0x1000 12 : packet type: 0 = TLM, 1 = CMD */”,
” /* 0xE000 13 : CCSDS version, always set to 0 */”,
“uint16 Sequence; /* packet sequence word */ “,
” /* bits shift description */”,
” /* 0x3FFF 0 : sequence count */”,
” /* 0xC000 14 : segmentation flags: 3 = complete packet */”,
“uint16 Length; /* packet length word */ “,
” /* bits shift description */”,
” /* 0xFFFF 0 : (total packet length) – 7 */”
],
After the definition, there are some specific messages. It is worth noting that there is a message related to the flag, and from the name analysis, this should be the message that instructs KIT_TO to send the flag.
{“message”: {
“name”: “KIT_TO_SEND_FLAG_MID“,
“descr”: “Super Secret Flag Sending Telemetry Message”,
“id”: 42,
“stream-id”: 33304,
“seq-seg”: 192,
“length”: 256
}},
2. Scheduling Table of KIT_SCH
Open the cpu1_kit_sch_sch_tbl.json file, which has the following description. This table describes the function of scheduling five slots per second, with a maximum of ten activities (activities) per slot. It can be understood that KIT_SCH executes the corresponding activities periodically based on the information in this table.
“name”: “Scheduler Activity Table”,
“description”: [“Activities are defined in time slots. There are 5 slots per second”,
“and 10 entries per slot. This kit table is organized based on app”,
“role. A flight table would be based on real-time needs.”,
“The boolean property uses a string for simplicity.”,
“The FSW parser uses named objects for callbacks, but named objects”,
“can’t be array elements which is why they are in brackets.”]
],
For example, the content of the first slot is as follows. Note that each activity has a property with a msg-id, which should correspond to the id of each message in the KIT_SCH message table.
{“slot”: {
“index”: 0,
“activity-array” : [
{“activity”: {
“name”: “cFE ES Housekeeping”,
“descr”: “”,
“index”: 0,
“enable”: “true”,
“frequency”: 4,
“offset”: 0,
“msg-id”: 0
}},
……
{“activity”: {
“name”: “Time Housekeeping”,
“descr”: “”,
“index”: 4,
“enable”: “true”,
“frequency”: 4,
“offset”: 0,
“msg-id”: 4
}}
]
}},
3. Filtering Table of KIT_TO
Open the cpu1_kit_to_pkt_tbl.json file, which initially has the following description, defining the telemetry packets that will be sent by KIT_TO. The KIT_TO used here does not have filtering capabilities. The file defines the telemetry packet corresponding to the flag message. Later it was found that this file was not used in the process of solving this challenge.
{
“name”: “Telemetry Output Table”,
“description”: “Define default telemetry packets that are forwarded by KIT_TO.
KIT_TO does not have any filtering capabilities.
Each packet entry contains:
CFE_SB_MsgId_t, CFE_SB_Qos_t (Priority,Reliability), Buffer Limit”,
……
“packet”: {
“name”: “KIT_TO_TLM_FLAG_MID”,
“stream-id”: “”,
“dec-id”: 2182,
“priority”: 0,
“reliability”: 0,
“buf-limit”: 4
},
4. Analysis of KIT_SCH Working Process
The documentation for OSK provides very little description about KIT_SCH, and the specific workings inside it need to be analyzed through code. Download the OSK code, open kit_sch_app.c, and find the KIT_SCH_AppMain function, which calls the InitApp function. In the InitApp function, the two tables mentioned earlier, the KIT_SCH message table and the KIT_SCH scheduling table, are loaded. The code is as follows:
#define KIT_SCH_DEF_MSG_TBL_FILE_NAME “/cf/kit_sch_msg_tbl.json”
#define KIT_SCH_DEF_SCH_TBL_FILE_NAME “/cf/kit_sch_sch_tbl.json”
……
TBLMGR_RegisterTblWithDef(TBLMGR_OBJ, MSGTBL_LoadCmd, MSGTBL_DumpCmd, KIT_SCH_DEF_MSG_TBL_FILE_NAME);
TBLMGR_RegisterTblWithDef(TBLMGR_OBJ, SCHTBL_LoadCmd, SCHTBL_DumpCmd, KIT_SCH_DEF_SCH_TBL_FILE_NAME);
……
Returning to the KIT_SCH_AppMain function, this function then enters a loop, continuously calling the SCHEDULER_Execute function, which sequentially executes the activities defined in the slots of the KIT_SCH scheduling table, primarily sending the messages corresponding to the activities to the software bus. Other corresponding applications will receive this message and perform the corresponding operations. Therefore, to solve this challenge, what needs to be done is to find a way to insert the message KIT_TO_SEND_FLAG_MID from the KIT_SCH message table into the scheduling table of KIT_SCH as one of the activities.
5. Modifying the Activity of the KIT_SCH Scheduling Table
The above text has clarified the problem-solving idea. By using COSMOS, it is found that in the command sending window, when the Target is selected as KIT_SCH, there is a command called LOAD_SCH_ENTRY, as shown in Figure 6-12. Modify the MSG_TBL_IDX to the KIT_TO_SEND_FLAG_MID found in the KIT_SCH message table cpu1_kit_sch_msg_tbl.json, which is 42, and click the Send button.
Figure 6-12 When Target is selected as KIT_SCH, the command can choose LOAD_SCH_ENTRY
Query the FLAG_TLM_PKT in the Tlm Packets tab, as shown in Figure 6-13. Click the corresponding View in Packet Viewer button, and it will display the flag value, as shown in Figure 6-14.
Figure 6-13 Selecting FLAG_TLM_PKT in the Tlm Packets tab
Figure 6-14 Displaying the received flag
Exciting Recommendations
