OPS-SAT simulator published
Today I published a modified version of my AVR32 emulator. I modified the nanomind branch to make it capable of running the OPS-SAT firmware. During my thesis, I used this modified emulator to search for vulnerabilities in the firmware. However, at that point, the emulator was based on an older version of QEMU.
The ‘OPS-SAT simulator’ contains a few modifications. Because some parts of the peripheral hardware are still not emulated, the firmware cannot be executed in the regular nanomind branch of QEMU. At certain points, the firmware is stuck in an endless loop because it waits for a hardware response that will never come. To circumvent this, I added a few workarounds that skip the related code segments. Later, I will try to add the missing hardware emulation.
Simulation agent and SPP communication
Another new part of this version is the simulation agent. The simulation agent allows us to send Space Packet Protocol packets to the emulated satellite. This is done via a TCP connection that accepts any input from an external program. The input is then sent to the CAN bus where it is handled by the firmware.
Simulation controller
The TCP interface of the simulation agent waits for input from a simulation controller application. Right now, this is a simple command-line application that generates a space packet. The packet is then sent to the simulation agent inside the emulator.
For example, we can request a list of the currently active tasks from the satellite. The image above shows how the command ‘send tasklist’ is sent to the emulator. After the packet is sent, the simulation controller waiting for a response from the satellite. The response consists of multiple packets that contain the strings that are shown in the lower half of the image.
Simulation agent
Inside the emulator, the simulation agent is running in a separate thread and waits for a new command from the TCP connection. The received data is then sent to one of the hardware interfaces.
After that, the firmware starts with the input handling, which is triggered by an interrupt from the emulated hardware. After handling the input, the firmware will respond with the requested tasklist:
The packet that is sent to the emulated antenna is read by the simulation agent and then passed to the simulation controller via the TCP connection. Because the size limit for a packet is 200 bytes, the firmware sends three packets that are also transmitted separately over TCP.
Exploitation
During my Master’s Thesis, I showed that the OPS-SAT contains two vulnerabilities that can be used to change the firmware’s execution flow. Later, my supervisor, Johannes Wilbold, and I developed an exploit for one of those vulnerabilities. The exploit was tested with my emulator and allows the execution of arbitrary code.
We can use the simulation controller to send a manipulated Space Packet to the simulated OPS-SAT. The packet contains shellcode that overwrites the input handling function and implements a ‘password check’. After that, only space packets that contain a password set by us are executed. All other commands are ignored, and the satellite operator can no longer control the satellite. For now, the exploit only overwrites the firmware in memory, but it is possible to make the exploit persistent by overwriting the firmware on the flash memory.
The exploit is described in the paper SpaceOdyssey. If you are interested in the details, have a look at the paper; it’s worth a read. The exploit was also shown in a talk by Johannes at CySat 2023.
Future development
I plan to add more functionality to the simulator in the future. For example, it would be interesting to provide different readings for the emulated sensors. The simulation controller could be used to send a parameter to the simulation agent, which then sets the measured value in the emulated sensor. The simulation controller could also be extended with a GUI to provide a more user-friendly experience.