-
Notifications
You must be signed in to change notification settings - Fork 61
Satellite Hacking & Attack Vectors
This section analyzes the low-level memory corruption vulnerabilities embedded within the FlatSat firmware architecture, specifically targeting input handling and boundary validation.
In worker.cpp, the application handler designated for SPP_APID_TC_BROADCAST_MSG contains a classic integer underflow vulnerability that directly leads to a massive stack-based buffer overflow.
The vulnerability is located within the commandApidHandler function when processing broadcast telecommands:
void commandApidHandler(space_packet_t *space_packet) {
uint16_t apid = space_packet->header.identification & 0x7FF;
// ...
else if (apid == SPP_APID_TC_BROADCAST_MSG) {
// No payload validation
uint16_t frequency = ((uint16_t)space_packet->data[0] << 8) | (uint16_t)space_packet->data[1];
size_t payload_total = space_packet->header.length + 1;
size_t msg_len = payload_total - 2; // <- Vulnerability here
uint8_t buffer_msg[SPP_MAX_PAYLOAD_CHUNK] = {0};
// ...`Technical Root Cause
Lack of Validation: The firmware performs no boundary or size validation on the incoming packet's payload before computing lengths.
The Underflow: The header.length field is a 16-bit integer completely controlled by the attacker via the CCSDS structure. If an attacker crafts and transmits a packet where header.length is 0, the variable payload_total evaluates to 1.
The Trigger: When the firmware executes size_t msg_len = payload_total - 2, it subtracts 2 from 1. Since size_t is an unsigned integer type, this operation causes an integer underflow, wrapping the value to its maximum limit of 0xFFFFFFFF on a 32-bit architecture like the RP2040.
When the system subsequently executes memory copy routines like memcpy using msg_len as the size parameter, it will attempt to copy approximately 4GB of data into the small 128-byte stack buffer buffer_msg.
This results in:
- ** Immediate stack smashing**.
- ** Severe memory corruption**.
- ** Remote Code Execution (RCE)**: The RP2040 microcontroller will either crash immediately or jump execution to an arbitrary memory address controlled by the attacker's payload.
To simulate this vulnerability, an attacker can craft a specific Space Packet Protocol (SPP) packet with APID 0x06 and a CCSDS length field explicitly set to 0.
data = b"\x00"
header = SpHeader.tc(apid=0x06, seq_count=1, data_len=len(data) - 1)
packet = header.pack() + dataWhen packed, the structural anatomy of the malicious exploit frame mirrors the following parameters:
=========== Space Packet ===========
Version: 0
Type: 01 (TC)
Secondary Header: 0
APID: 0x0006
Sequence Flags: 0x3 (Unsegmented)
Sequence Count: 1
Data Length: 0
[HEADER] 00000000 10 06 C0 01 00 00 ......
[PAYLOAD] 00000000 00 .This section details the vulnerabilities inherent in the communication logic and protocol parsing of the FlatSat firmware, focusing on authentication bypasses, structural insecurities, and data processing flaws.
The firmware processes application process identifiers (APIDs) sequentially. The specific command mapped to SPP_APID_TC_RESETC triggers an immediate hardware watchdog reboot without enforcing any cryptographic challenge, validation loop, or session verification.
The logic flow inside worker.cpp processes the reset command directly upon matching the target APID:
else if (apid == SPP_APID_TC_RESETC) {
softwareReset(); // Calls watchdog_reboot
}Broken Authorization: Because the flight control system does not require an operational key, rolling window token, or command signature to authorize a system reset, any single packet received with the correct APID parameter can immediately terminate spacecraft processes.
Mission Loss: An attacker can weaponize this structural gap to initiate a permanent Denial of Service (DoS) loop, freezing satellite operations entirely and forcing the mission into an infinite reboot state.
An operator or attacker can issue a targeted Space Packet Protocol (SPP) command matching APID 0x02 to trigger the watchdog routine remotely.
data = b"\x00"
header = SpHeader.tc(apid=0x02, seq_count=1, data_len=len(data) - 1)
packet = header.pack() + data=========== Space Packet ===========
Version: 0
Type: 01 (TC)
Secondary Header: 0
APID: 0x0002
Sequence Flags: 0x3 (Unsegmented)
Sequence Count: 1
Data Length: 0
[HEADER] 00000000 10 02 C0 01 00 00 ......
[PAYLOAD] 00000000 00 .The core architecture of the Space Packet Protocol (SPP) framework deployed across the system handles communication entirely in cleartext.
Absence of Cryptographic Controls: The implementation lacks a Cryptographic Authentication layer, meaning mechanisms such as AES-GCM or HMAC-SHA256 are completely absent from the telecommand processing chain.
Exploitation Impact: Because communications are unencrypted and unsigned, any actor possessing a compatible transceiver device can passively sniff telemetry parameters or actively forge legitimate-looking commands to command internal thrusters, corrupt logs, or alter configuration data.
The firmware implements a multi-stage decoding pipeline that introduces a deep logical vulnerability in how data streams are standardized before inspection.
When an incoming payload block is extracted, the firmware routes the transmission through the following processing sequence:
uint8_t parsed[recvLen];
size_t parsedLen = hexStringToBytes(byteArr, recvLen, parsed);
radi_recv_cb(parsed, parsedLen);The Logic Flaw: The system executes a "Double Decode" process. It intercepts an incoming binary frame from the physical transmission layer and then attempts to interpret that content a second time, parsing the internal elements as an ASCII Hex string structure.
Filter Circumvention: This design choice introduces a severe defensive weakness analogous to a Web Application Firewall (WAF) bypass. If an upstream gateway or border security mechanism inspects packets to drop known malicious payloads, an attacker can mask the attack signatures by encoding the binary command payload into an ordinary ASCII Hex string representation.
The Bypass Execution: The inline security filters will evaluate the payload as safe string traffic and permit entry. Once inside the system boundaries, the hexStringToBytes function automatically reconstructs the obfuscated string back into a functional, hazardous binary exploit frame before execution.
This section covers the risks associated with unencrypted telemetry transmission and the exploitation of internal physical interfaces, specifically targeting the data isolation boundaries of the dual-core architecture.
The core routines inside worker.cpp continuously process and distribute the satellite's internal metrics, engineering parameters, and structural variables over the transmission interface.
- Cleartext Exposure: The flight software broadcasts high-resolution sensor metrics (including temperature, pressure, and humidity from the BME280, alongside coordinate vectors from the LIS2DH12) and critical internal state flags (such as real-time thruster power configurations and current firmware version metadata).
- Absence of Confidentiality: Because no encryption or masking algorithms are applied to the outgoing Telemetry (TM) frames, the data stream is susceptible to passive interception and monitoring by any station within range.
An attacker can collect these unencrypted telemetry parameters to compile a highly accurate digital twin of the spacecraft. By tracking precise behavioral patterns, operational cycles, and power states, the adversary gains the intelligence needed to schedule disruptive physical or logical attacks at the most vulnerable operational moments.
The system's processing architecture implements Asymmetric Multiprocessing (AMP) on the RP2040, dedicating Core 1 exclusively to handling the high-speed USB pipeline via the TinyUSB stack (usbCDC) to act as a data bridge for the main flight controller on Core 0.
If an onboard third-party payload component, an auxiliary scientific instrument, or the central On-Board Computer (OBC) itself suffers a security compromise (e.g., via a supply chain flaw), the compromised asset can pivot and launch an exploitation sequence against the core flight firmware across the internal physical boundary.
The attacker leverages the usbCDC serial line to transmit a malformed, specially crafted USB data frame embedded with the specific synchronization tokens FRAME_HEADER_1 and FRAME_HEADER_2.
The vulnerability lies within the processing implementation of the obcUSBRecv routine running on Core 1:
- Lack of Command Origin Verification: The internal routing framework fails to cryptographically distinguish between commands generated locally over the physical wire and commands received from the external ground station.
-
Arbitrary Command Injection: Once the
obcUSBRecvlogic parses the custom synchronization headers, it treats the trailing data payload as a legitimate command stream. The firmware automatically maps and "injects" the malicious instructions directly into the Core 0 processing queue as if they had originated from a trusted, authenticated Ground Station over a verified uplink channel.
This vector directly mirrors a Supply Chain Attack on aerospace infrastructure. If a satellite manufacturer integrates an unverified or vulnerable third-party subsystem (such as a mission camera or sensor pack), an attacker who compromises that minor subsystem can use it as a persistent pivot point to bypass network boundaries, compromise the main satellite bus (OBC), and gain absolute control over the vehicle's flight controls and radio arrays.
This section concludes the offensive analysis of the FlatSat platform, focusing on the vulnerabilities inherent in the RF physical layer and link-layer protocol implementations.
The documentation for active Radio Frequency (RF) exploitation mechanisms, software-defined radio configurations, and live-air capture setups is currently under development. Additional hands-on attack scenarios, wave captures, and detailed procedural guides will be continuously updated and documented over the coming days.
Because the space packet parsing infrastructure processes over-the-air frames in cleartext without implementing cryptographic signatures, the RF communication subsystem is completely vulnerable to command injection.
An attacker utilizes a Software Defined Radio (SDR) platform to passively sniff the active downlink frequency (DOWNLINK_FREQ). By capturing and parsing ordinary Telemetry (TM) frames, the attacker extracts key structural telemetry data, including the unique SPACECRAFT_ID and the real-time Sequence Count.
With these parameters, the attacker crafts a forged Telecommand (TC) frame carrying a valid subsystem APID (such as 0x04 for Thruster manipulation). The attacker then transmits this malicious frame over the uplink channel (UPLINK_FREQ) at a higher transmission amplitude.
Due to the Capture Effect in radio receivers, the onboard LoRa transceiver completely suppresses the legitimate ground station signal and processes the attacker's high-power command frame instead.
In 1998, the ROSAT (Röntgen Satellite) mission suffered an exploit sequence where unauthorized command packets were delivered to the spacecraft. The injected instructions forced the vehicle to orient its solar panels directly at the sun, critically damaging its battery infrastructure and causing total mission loss. FlatSat's unauthenticated RF layer exposes the hardware to identical orbital command injection outcomes.
The underlying physical layer built upon LoRa transceivers provides link resilience but remains vulnerable to deliberate physical spectrum denial and state replay.
An attacker configures an RF transceiver or SDR to emit a continuous, high-duty-cycle signal matching the designated uplink frequency (UPLINK_FREQ). This persistent Radio Frequency Interference (RFI) blocks legitimate ground control transmissions from reaching the satellite's input queues, achieving a complete Denial of Service (DoS).
Because the firmware lacks time-synchronization matrices, anti-replay windows, or rolling cryptographic tokens, command processing depends solely on the arrival of valid APIDs. An attacker can record a legitimate telecommand packet emitted by the ground station—such as an unauthenticated system reset command (APID 0x02)—and retransmit that exact binary sequence at a later time. The satellite will evaluate the packet as valid and re-execute the command.
Radio Frequency Interference (RFI) and jamming constitute the most frequent real-world electronic warfare vectors encountered by orbital networks. Furthermore, satellite systems that fail to implement rolling authentication windows remain deeply vulnerable to replay attacks, enabling adversaries to intercept and blindly re-trigger critical flight operations.
Passive interception of over-the-air signals. Because the communications protocol operates without cryptographic protection or encryption layers, an attacker within radio range can capture raw radio frames transmitted via the downlink channel, leading to the unauthorized disclosure of environmental payload data, internal telemetry values, and structural subsystem states.
The unauthorized insertion of arbitrary commands into the satellite execution queue. Exploiting the lack of command signatures or verification mechanisms, an adversary can forge Space Packet Protocol frames with specific execution flags or payload data values, tricking the core flight system into executing privileged operations like thruster status changes or memory overrides.
The systematic transmission of malformed or mutated protocol units to evaluate input parsing boundaries. By targeted alteration of length bytes, missing sequence flags, or sending out-of-bounds parameters into validation checks such as spp_unpack_packet, an attacker can desynchronize workers, trigger software crashes, or force state machine hang-ups.
Identity impersonation across the communication link. An attacker sniffs valid identifiers from ground-to-satellite channels and replicates them in malicious payloads. By mimicking legitimate command configurations at higher amplification, the attacker overrides standard ground operations due to receiver physical constraints like the capture effect.
| Vulnerability | Type | Complexity | Impact |
|---|---|---|---|
| Command Injection Attack | Injection | Medium | Critical (RCE) |
| Broadcast Underflow | Memory Corruption | Medium | Critical (RCE) |
| No Auth/Enc | Broken Auth | Low | Critical (Takeover) |
| Spoofing Attack | Identity Theft | Medium | Critical (Impersonation) |
| Unauthenticated Reset | DoS | Low | High (Mission Loss) |
| Fuzzing Attack | Protocol/Input | Medium | High (DoS or Crash) |
| Eavesdropping Attack | Information Disclosure | Low | High (Data Leakage) |
| Double Decoding | Logic Flaw | Medium | Medium (Filter Bypass) |
FlatSat Ecosystem v1.0.0 — Maintained by Pwnsat and Electronic Cats. For authorized educational and security research purposes only.