Skip to content
Romel edited this page Aug 8, 2026 · 8 revisions

FlatSat Satellite Security Research Platform Banner

FlatSat Wiki

The world’s first open-source, dual-core hardware platform vulnerable-by-design, engineered specifically to learn aerospace cybersecurity adn satellite hacking.


Welcome to the official FlatSat v1.0 documentation hub. FlatSat is an open-source, dual-core hardware-in-the-loop (HIL) platform designed to simulate satellite sub-systems, orbital telemetry, and real aerospace communication protocols.

Developed as a community-driven project for satellite cybersecurity training, firmware prototyping, and aerospace CTFs (Capture The Flag), FlatSat provides a hands-on, un-sanitized environment for discovering, exploiting, and mitigating vulnerabilities in space systems.

Warning

RF Compliance & Safety Notice FlatSat operates within standard license-free ISM bands (433 MHz / 915 MHz). Users must strictly adhere to local amateur radio and telecommunications regulations regarding transmission power, duty cycles, and frequency allocation.


Technical Specifications & Architecture Breakdown

1. On-Board Computer (OBC) & Core Isolation

The processing core relies on the Raspberry Pi RP2040 dual-core ARM Cortex-M0+ microcontroller implementing Asymmetric Multiprocessing (AMP) to divide mission critical tasks:

  • Core 0 (Flight Operations): Runs the primary satellite main loop, manages real-time sensor updates, handles active telemetry/telecommand state registers, and drives the hardware SPI buses connected to the radio modules.
  • Core 1 (Diagnostics Interface): Dedicated exclusively to maintaining high-speed payload data pipelines over the USB interface utilizing the TinyUSB stack (usbCDC). This isolates communication overhead from freezing the flight software running on Core 0.

2. Sensor Payload Subsystems

FlatSat integrates dedicated peripherals over its internal lines to emulate actual space telemetry packets:

  • Attitude Determination: A LIS2DH12 3-axis accelerometer connected via the primary I2C bus tracks simulated coordinate and tilt vectors.
  • Environmental Metrics: A BME280 sensor samples ambient temperature, barometric pressure, and relative humidity parameters.
  • Asynchronous Execution: Rather than calling blocking delay functions, the system schedules sensor reads dynamically using an advanced non-blocking timeout_worker_t infrastructure to keep interfaces continuously open.

3. Dual RF Link Subsystem

The communication hardware is built out to support separate uplink and downlink RF configurations natively:

  • Transceivers: Dual independent Semtech SX1262 sub-GHz LoRa modules routed via hardware control pins on the shared SPI0 bus interface.
  • Radio 0 (Uplink Channel): Fixed to function as a receiver, continuously waiting to capture over-the-air Telecommands (TC).
  • Radio 1 (Downlink Channel): Fixed to function as a transmitter, broadcasting periodic Telemetry (TM) frames or acknowledging requests.
  • Protocol Framing: Data frames map directly to the CCSDS Space Packet Protocol standard layout. Packets are parsed via the internal spp_unpack_packet and routed downstream through application process identifiers (APIDs) without cryptographic verification.

4. Hardware Auditing Breakouts

A designated physical Header Connector breaks out internal copper lines directly for bus analysis:

  • Sniffing Ports: Pins expose the active UART serial logs, the primary I2C line, and the raw SWD debug interface, allowing operators to hook up logic analyzers for direct hardware monitoring or hardware debugging.

Navigation & Deep Dive Documentation

Note

Technical Sections Index


Quick Reference Links