# FlatSat is a satellite-shaped board with real vulnerabilities, on purpose

> FlatSat is a hardware training platform from PWNSAT and Electronic Cats that simulates satellite subsystems on a Raspberry Pi RP2040 with LoRa radio links, and ships vulnerable firmware with eight attack scripts for it. It is a research and teaching board, not a tool for attacking real spacecraft.

**Pwnsat/FlatSat** — Flatsat v1.0 is a hardware based platform for aerospace cybersecurity research

- Repository: https://github.com/Pwnsat/FlatSat
- Stars: 571 · Forks: 75
- Language: Python
- License: GPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/pwnsat-flatsat

## A satellite you own, vulnerable on purpose, with the attacks written out

FlatSat is described in the README as a hardware-based training platform designed to be vulnerable on purpose, and the banner calls it the world's first open-source and hardware platform vulnerable-by-design, engineered specifically to learn space hacking and aerospace cybersecurity.

The audience is stated clearly. It is built for hackers, engineers and space enthusiasts who want to dive deep into space-grade systems, learn cybersecurity concepts and prototype their own payloads in a safe, controlled environment. The project simulates critical real-world satellite subsystems, orbital telemetry and authentic aerospace communication protocols, and describes itself as a bridge between hardware hacking and aerospace security research.

Four uses are listed. Hands-on learning, with lessons on binary exploitation, secure communication, reverse engineering and space protocols, as the hardware companion to aerospace cybersecurity studies. Exploring and exploiting firmware designed to simulate historical or realistic software failures in orbiting infrastructure. Joining space-themed Capture The Flag challenges that simulate real satellite operation scenarios, turning the board into your own spacecraft. And prototyping your own payload logic, radio communication or telemetry systems before deploying larger projects.

That last one is the most interesting, because it means the board is a development platform as much as a target. The licence is split, with hardware under CERN Open Hardware Licence v1.2 and firmware and attack scripts under GPL-2.0-or-later, and the repository is not archived with the last push on 2026-08-09.

## The hardware: an RP2040, two LoRa radios and exposed buses

The hardware overview is the part that makes this a real research object rather than a training exercise, because every subsystem is something you can probe.

The on-board computer is powered by a dual-core Raspberry Pi RP2040 microcontroller. The RF link subsystem is dual, with two independent Semtech SX1262 sub-GHz LoRa modules dedicated to uplink, meaning receive, and downlink, meaning transmit. The onboard sensors are a BME280 environmental sensor and a LIS2DH12 three-axis accelerometer, there to emulate real spatial telemetry. And there are exposed auditing interfaces, physical header connector breakouts for direct bus monitoring via UART, I2C and SWD debug lines.

Two details carry a lot of weight for a security project. The first is the SWD and UART breakouts, because they are what turns the board from a black box into something you can attach a debugger to and watch. The second is the two-core chip, which pairs with the firmware architecture described later.

The RF compliance note is the other detail worth reading carefully. FlatSat operates exclusively within standard license-free ISM bands, typically 433 MHz or 915 MHz depending on your region, and the README says this ensures a legal, safe educational ecosystem that does not interfere with production space systems or critical ground infrastructure. That is a deliberate design constraint on the radio, not an accident of the modules chosen.

The repository top level reflects the split: a Firmware/ directory, an Attacks/ directory, a Hardware/ directory, and separate LICENSE_FIRMWARE.md and LICENSE_HARDWARE.md files.

## The firmware ships vulnerable, and the diff against the baseline is documented

The firmware directory holds the vulnerable-by-design firmware source, a pre-built .uf2 file that is ready to flash in Firmware/build/, and a platformio.ini to build it yourself.

The important detail is that the README points at Firmware/README.md for the full diff against the public baseline. That is what turns this from a claim into something checkable. A board whose firmware is deliberately broken is only useful for teaching if you can see what was broken and how, and a published diff gives the learner the exact change rather than asking them to find it.

The releases show what this looks like in practice. There are two tags, v1.0.3 as FlatSat Firmware v1.0.3 and v1.0.0 as FlatSat Firmware v1.0.0 with the label Legacy Public Baseline, both dated 2026-08-08, minutes apart. So the public baseline and the current release were published together, which is a sensible thing to do for a project whose whole premise is that the difference between the two is the interesting part.

The firmware is built with PlatformIO, described in the README as platformio.ini to build it yourself, and the wiki's Quick Start guide covers toolchain setup, compiling the firmware, flashing the RP2040 and verifying hardware operations. The primary language of the repository is Python, which is presumably what the attack scripts are written in.

## Eight attacks, each in a radio variant and a USB variant

The Attacks/ directory holds eight attack scripts, numbered 00 to 07, exploiting the vulnerabilities in the firmware, and each one exists in an RF variant using HackRF or RTL-SDR and a USB variant. The README points at Attacks/README.md for what is there, and at the wiki for the full step-by-step walkthrough of each one.

The dual variant structure is the design decision that makes this practical. An RF variant means the attack arrives over the air, through the same radio path a real ground station would use, so you are testing the actual attack surface. A USB variant means the same attack logic is delivered over a wired connection, which removes the radio from the equation when you are debugging the exploit itself.

That separation matters for how you learn. The confusion when learning satellite attacks is usually in the exploit, not in the transport, and having the same attack available over USB means you can isolate the two.

The wiki's attack walkthroughs page describes the format for each of the eight validated attacks, with prerequisites, the exact command, and how to confirm each one worked against real hardware. That last part matters. A script that is claimed to work is not the same as a script whose success you can verify on a board in front of you, and the walkthrough is where that verification is documented.

## The firmware architecture and the space protocols being simulated

The wiki carries the deep technical documentation, and two of its sections describe what the platform is actually modelling.

The core firmware architecture page is a deep dive into the Asymmetric Multiprocessing architecture dividing tasks across Core 0 and Core 1. That is the reason the hardware has a dual-core microcontroller rather than a single one, and it is a real architectural decision that shows up in how the radio handling, the telemetry and the bus access are separated.

The space protocols page covers the Space Packet Protocol under CCSDS, the aerospace framing standards, with packet encapsulation structure and the active APID registry. An APID is the identifier that says which kind of packet this is, and having a registry of them is what makes the simulation faithful rather than decorative.

Then there is the offensive attack vectors page, which the README calls the security playground and which explains packet fuzzing, telecommand spoofing, buffer overflows and unauthorised subsystem manipulation.

That list is the taxonomy of the whole project. Telecommand spoofing is the classic satellite problem, where a ground station sends commands and an attacker sends something that looks the same. Packet fuzzing finds parser bugs. Buffer overflows are the binary exploitation lesson. And unauthorised subsystem manipulation is the outcome that makes any of it matter in the real world.

## Where FlatSat is the wrong tool, and what the licence and disclaimer restrict

The boundary is the same as it is for any deliberately vulnerable system, and the project states it itself.

The disclaimer says the project was created for educational purposes, to teach and learn aerospace cybersecurity, that neither PWNSAT nor Electronic Cats are responsible for how the knowledge, code or tools hosted in the repository are used, and that you should use it only against hardware, firmware or signal sources you own or are explicitly authorised to test.

So the scope is a board on your desk. What makes FlatSat interesting is not that its exploits would work against a spacecraft, but that the attack surface is real hardware with a real radio, and the difference between success and failure is visible on a screen.

There is a second, quieter limitation. Everything here is a simulation of satellite subsystems, orbital telemetry and aerospace protocols, so a FlatSat exercise tells you about the security properties of the simulation, which are designed to be realistic but are not the same thing as the security properties of a specific flight software build. The wiki's hardware anatomy page has the schematics and pinouts, and the firmware architecture page has the internals, so the gap between the model and the real thing is documented rather than hidden, but it is a gap.

The hardware is also a Raspberry Pi RP2040 with LoRa modules, not flight hardware. Anyone expecting to evaluate a real flight computer or a real S-band transceiver should treat FlatSat as the teaching instrument it is.

The licence terms are the other constraint. Firmware and attack scripts are GPL-2.0-or-later, the hardware is CERN Open Hardware Licence v1.2, and PWNSAT and Electronic Cats are a registered trademark that the README asks you not to use if you sell the PCBs.

## Conclusion

Adopt FlatSat if you teach or learn aerospace cybersecurity and want a physical board with real firmware, real radio links and validated attacks to work through, rather than a simulation on a laptop. Do not adopt it if you need a satellite, a flight-ready radio or a tool you can point at infrastructure you do not own, since the disclaimer restricts use to hardware, firmware and signal sources you own or are authorised to test. Before you buy a board, read the wiki Quick Start for the toolchain and flashing steps, and check the firmware diff in Firmware/README.md so you know which vulnerabilities are in the release you are flashing.

## FAQ

### What is FlatSat?

FlatSat is a hardware-based training platform designed to be vulnerable on purpose, built by PWNSAT and Electronic Cats. It simulates critical satellite subsystems, orbital telemetry and aerospace communication protocols, so people can learn binary exploitation, reverse engineering and space protocols on hardware they own.

### What hardware does the FlatSat board use?

A dual-core Raspberry Pi RP2040 as the on-board computer, two independent Semtech SX1262 sub-GHz LoRa modules for uplink and downlink, a BME280 environmental sensor and a LIS2DH12 accelerometer, and exposed header breakouts for UART, I2C and SWD debug lines.

### What attacks come with FlatSat?

Eight attack scripts numbered 00 to 07 in the Attacks directory, each in an RF variant using HackRF or RTL-SDR and a USB variant, with step-by-step walkthroughs on the wiki including the exact command and how to confirm each attack worked.

### Is FlatSat legal to use?

The README says the project was created for educational purposes and that you should use it only against hardware, firmware or signal sources you own or are explicitly authorised to test. It also notes the board operates in license-free ISM bands so it does not interfere with production space systems.

### Under which licences is FlatSat released?

The hardware is released under the CERN Open Hardware Licence v1.2, in the LICENSE_HARDWARE file, and the firmware and attack scripts are released under GPL-2.0-or-later, in LICENSE_FIRMWARE and the Attacks/LICENSE file. PWNSAT and Electronic Cats are a registered trademark and the brand name should not be used on resold PCBs.

## Sources

- [Issues](https://github.com/Pwnsat/FlatSat/issues)
- [License: GPL-2.0](https://github.com/Pwnsat/FlatSat/blob/main/LICENSE)
- [Pwnsat/FlatSat on GitHub](https://github.com/Pwnsat/FlatSat)
- [README](https://github.com/Pwnsat/FlatSat/blob/main/README.md)
- [Releases](https://github.com/Pwnsat/FlatSat/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pwnsat-flatsat