Running a Software Defined Radio CTF using challengectl

Running a Software Defined Radio CTF using challengectl

Speakers: Dan Perret

Conference: RF Village

YouTube: https://www.youtube.com/watch?v=98_3eRPuuYM

Overview

Dan Perret's presentation at RF Village, "Running a Software Defined Radio CTF using challengectl," provides an in-depth look at the open-source software powering the RF Capture the Flag (RFCTF) event. The talk introduces challengectl, a Python-based application designed to streamline the creation, management, and transmission of diverse software-defined radio (SDR) challenges. Perret, a key contributor to the RFCTF and challengectl, details the evolution of the event's infrastructure, highlighting the challenges faced with ad-hoc setups and dedicated hardware, and how challengectl addresses these issues through automation and scalability.

The core motivation behind challengectl and the RFCTF is two-fold: competition and, more importantly, learning and experimentation. The event aims to provide a safe, legal environment for participants to explore various wireless protocols, signals, and attack vectors using readily available SDR hardware. By enabling organizers to run a multitude of challenges simultaneously and consistently, challengectl lowers the barrier to entry for both CTF organizers and participants, fostering a deeper understanding of radio frequency technologies and their security implications. This article delves into the technical intricacies of challengectl, its operational capabilities, and its potential for future development in the realm of RF security education.

Background

▶ Watch: Introduction and talk agenda for challengectl (0:00)

The RF Capture the Flag (RFCTF) is a unique competition focused on radio frequency communication, challenging participants to capture, identify, decode, or interact with a wide array of wireless signals. These signals span from common protocols like Wi-Fi and Bluetooth to more specialized areas such as RFID, amateur radio, tire pressure monitoring systems (TPMS), and industrial control systems. The primary goals of the RFCTF extend beyond mere competition; it serves as a vital educational platform where individuals can experiment with their tools and techniques in a controlled environment, fostering hands-on learning in a domain often restricted by legal or practical constraints.

Historically, running an RFCTF presented significant logistical and technical hurdles. Early iterations relied heavily on dedicated hardware for each challenge type, such as restaurant pagers, TPMS sensors, or specialized DVB-T transmitters. While realistic and reliable, this approach suffered from severe scalability issues, increasing the cost, weight, and complexity of equipment transportation and setup. Furthermore, changing challenge keys or replacing failed hardware was often difficult or impossible, limiting the event's flexibility and longevity.

The next step in the evolution involved using individual SDR flow graphs, typically built with tools like GNU Radio, to transmit challenges via general-purpose SDRs like the HackRF, BladeRF, or USRP. This improved prototyping and key rolling but still tied a single SDR device to a single challenge, limiting concurrency. The first attempt at coordinating multiple SDRs, dubbed "SDR football" around 2014 by Russ Handorf, utilized Raspberry Pis and multiple HackRFs synchronized through a database. This early system laid the groundwork for centralized management, recognizing the need to efficiently cycle challenges across available devices. However, it was still a collection of individual scripts rather than a unified application. This historical progression underscored the necessity for a robust, automated system capable of orchestrating numerous diverse SDR challenges simultaneously, leading directly to the development of challengectl.

Key Findings

▶ Watch: Defining RFCTF and its core learning goals (2:20)

The central contribution of Dan Perret's talk is the introduction and detailed exposition of challengectl, a sophisticated open-source Python application that fundamentally redefines how RFCTFs can be organized and executed. The key findings and contributions of challengectl are multifaceted:

Firstly, challengectl serves as a unified management system for SDR challenges, moving beyond ad-hoc scripts and dedicated hardware. It effectively abstracts the complexities of transmitting diverse RF signals, allowing organizers to define challenges in a standardized format within a flags file. This standardization significantly reduces setup time and enhances the repeatability of challenges, a critical requirement for multi-day events where challenges must be transmitted hundreds or thousands of times consistently.

Secondly, the software dramatically improves scalability and concurrency by intelligently managing multiple SDR devices. Unlike previous setups where one SDR typically handled one challenge, challengectl employs a multi-threaded Python architecture to cycle through a list of defined challenges, assigning them dynamically to available SDRs. This means that an SDR box equipped with, for instance, three BladeRF 2.0 devices, can simultaneously transmit three different challenges, significantly reducing contestant wait times and enriching the overall CTF experience. The talk highlights that their current SDR box, utilizing three BladeRFs, can send out 15-16 different flags by cycling them across the devices.

Thirdly, challengectl introduces programmatic key rolling for many challenge types, addressing a major pain point of previous systems. While some digital modes still require external tools like FL Digi for wave file generation, challenges like Morse code and Amplitude Shift Keying (ASK) can have their flags directly embedded into the flags file, allowing for instantaneous key changes. This capability ensures that challenges can be refreshed between conferences or even during an event, preventing flag leakage and maintaining challenge integrity.

Finally, the talk reveals the integration of spectrum painting as an innovative feature. Before transmitting a challenge, challengectl can broadcast a visual identifier, such as a sponsor logo, onto the radio spectrum. This serves as an "advertisement" to contestants, indicating that an RFCTF challenge is imminent on a particular frequency, guiding their efforts and adding an engaging visual element to the RF environment. This feature underscores challengectl's role not just as a functional tool but also as an enhancer of the CTF experience.

Technical Deep Dive

▶ Watch: The importance of scoring and using CTFD (4:00)

challengectl is a multi-threaded Python application designed for robust management of Software Defined Radio (SDR) challenges. Its architecture is built around two primary inputs: a devices file and a flags file, which together define the available hardware and the challenges to be transmitted.

The devices file, typically named devices.txt, lists the SDR hardware connected to the system. It uses a simple format, providing a device ID/index and the OsmoSDR device string. A utility script, create_devices.py, automates the discovery of connected SDRs (e.g., BladeRF, HackRF, USRP) and populates this file, simplifying initial setup. For example, a single BladeRF might appear as 0:bladeRF=0.

The flags file is the core configuration for the challenges. It begins with the conference name and start/end times, followed by individual challenge definitions. Each challenge entry specifies a name, the type of challenge, and various parameters. Perret highlights several challenge types currently integrated into challengectl:

• Morse Code (CW): One of the "ideal state" challenges. It requires only the text of the flag and the transmission frequency. Parameters for Morse code speed can also be adjusted. This is fully generated within the flow graph.
• Amplitude Shift Keying (ASK): Similar to Morse code, requiring only the flag text and frequency, with direct generation in the flow graph.
• Narrowband FM (NBFM) and Upper Sideband (USB): These modes are used for transmitting amateur radio digital modes (e.g., RTTY, Thor, Feld Hell). Currently, these rely on pre-generated wave files, typically created using external software like FL Digi. The flags file specifies the wave file path, audio sample rate, and transmission frequency. The challenge here is that generating these wave files with FL Digi is a real-time process, making programmatic key rolling time-consuming (e.g., two hours for multiple flags).
• PocSag: A common pager protocol. This challenge requires a cap code in addition to the flag text and frequency.
• Long Range Systems (LRS) Restaurant Pager: This is an intermediate case where parameters are passed directly to a script that generates a BIN file on the fly, which is then transmitted. This is more dynamic than pre-generated wave files but not fully integrated into the flow graph itself.
• Slow-Scan Television (SSTV): Similar to other digital modes, this requires pre-generated wave files (e.g., from QSSTV) containing an image, along with frequency and sample rate.

The challengectl.py script continuously polls the configured SDR devices. When a device is available and a challenge is due for transmission, it loads the appropriate GNU Radio flow graph (or other script) and passes the challenge-specific parameters. This dynamic allocation ensures that multiple challenges can be in the air simultaneously across different SDRs, or sequentially on a single SDR.

A notable feature is spectrum painting. Before transmitting a challenge, challengectl can broadcast a visual pattern, such as a sponsor logo, on the target frequency. This acts as a visual cue for contestants monitoring the spectrum, signaling an upcoming challenge.

Signal Generation Strategies:

Perret elaborates on three main approaches to signal generation within the CTF context:

1. Capture and Replay: Recording raw IQ (In-phase and Quadrature) data from a real device and replaying it. While functional, it can be noisy and less flexible. challengectl does not currently have a dedicated flow graph for this, but it's a potential future addition.
2. Generating Binary or Audio Files: This is common for digital modes and SSTV, where external tools (FL Digi, QSSTV) create WAV or BIN files that the SDR then transmits. This method is reliable but makes key rolling cumbersome due to the manual generation process.
3. Generating Signals Entirely Within the Flow Graph: The ideal state, exemplified by Morse code and ASK challenges. Here, the flag text is directly fed into the GNU Radio flow graph, which synthesizes the signal in real-time. This allows for immediate key changes and maximum flexibility.

Future Development Ideas:

Perret outlines several areas for future enhancement:

• Virtual Challenge Integration: Currently, challengectl only manages physical SDR transmissions. A separate system handles virtual challenges (streaming wave files over ZeroMQ sync). The goal is to unify these, allowing a single flags file format to support both physical (frequency, bandwidth) and virtual (port) parameters.
• Coordinated SDR Boxes: To further scale, implementing network communication between multiple challengectl instances running on different SDR boxes would prevent challenge collisions and maximize airtime.
• Multiple Transmit Front Ends: Utilizing SDRs with multiple transmit ports (e.g., BladeRF 2.0) to simultaneously transmit different signals or use different antennas/filters.
• Sensible Gain Defaults: Automating gain settings based on the specific SDR type (HackRF, BladeRF, USRP) to ensure consistent and optimal signal strength across challenges.
• BladeRF Gate Calibration: Integrating the BladeRF 2.0's gain calibration curve to provide a flat, consistent transmit gain across the spectrum.
• Programmatic FL Digi Key Rolling: Finding a way to automate the wave file generation process in FL Digi to streamline the creation of new digital mode flags.

Demo / Proof of Concept

▶ Watch: What constitutes a discrete RFCTF challenge (5:10)

Dan Perret conducted a live demonstration showcasing the ease of setting up and running challengectl with a single SDR device. The entire challengectl software is open source and available on GitHub at github.com/rfhs/challengectl. Additionally, a flags archive containing challenges from previous CTFs (e.g., ShmooCon 2025) is provided, allowing anyone to replicate past events.

The demonstration began by cloning the challengectl repository. The first step for a new setup is to create the devices.txt file, which lists the available SDRs. Perret executed the create_devices.py script, which automatically queried his laptop for connected SDR devices and populated devices.txt. In this specific demo, only a single BladeRF was detected and added to the file.

Next, Perret displayed the structure of a flags file, using the ShmooCon 2025 flags file as an example. He walked through various challenge entries, highlighting their parameters:

• Ham Digital Challenges (NBFM/USB): These entries specified a wave_file path (e.g., for RTTY, Thor, Feld Hell modes), an audio_sample_rate, and a frequency. He pointed out that some challenges, like ham440, can use randomized frequencies within a specified amateur radio band (e.g., 440 MHz), making them more difficult to solve.
• Morse Code Challenges: These were shown as the "ideal state," requiring only the desired text for the flag and the transmission frequency. Parameters for adjusting Morse code speed were also available.
• Amplitude Shift Keying (ASK) Challenges: Similar to Morse, requiring just the flag text and frequency.
• PocSag Challenges: Required an additional cap_code parameter alongside the flag text and frequency.
• LRS Pager Challenges: Parameters were passed directly to a script to generate a temporary BIN file for transmission.
• SSTV Challenges: Like other digital modes, these specified a wave_file (generated from an image using QSSTV), audio_sample_rate, and frequency.

With the devices.txt and flags files in place (along with the necessary wave files from the flags archive), Perret demonstrated running the CTF by executing challengectl.py with both files as arguments. The application successfully identified his single BladeRF and began transmitting the ShmooCon 2025 challenges, including the spectrum painting feature, on the specified frequencies (e.g., 905.5 MHz). This demonstrated how easily an individual can set up and run a full RFCTF environment on their local machine for practice or small-scale events.

He further illustrated the process of generating new flags for digital modes using FL Digi. By selecting a mode (e.g., RTTY 45), typing a test flag, and using the "TX generate wave file" option in FL Digi's audio menu, a new .wav file can be created. He emphasized the importance of verifying the sample rate of the generated audio file against the rate expected by the GNU Radio flow graph, a common pitfall. Similarly, QSSTV was shown as the tool for generating .wav files for SSTV challenges from image inputs.

Defensive Implications

▶ Watch: Legal requirements for running RFCTF challenges (6:00)

While challengectl is primarily a tool for running offensive-oriented capture the flag challenges, its implications for defensive security are significant, albeit indirect. The RFCTF, powered by challengectl, acts as a critical training ground for RF security practitioners and those looking to understand the wireless attack surface.

For defenders, participating in or studying the types of challenges created and transmitted by challengectl provides invaluable hands-on experience in:

1. Signal Identification and Analysis: Defenders learn to identify various RF protocols (Morse code, ASK, PocSag, digital amateur radio modes, LRS pagers, SSTV) in a noisy spectrum. This skill is crucial for detecting anomalous or malicious transmissions in real-world environments, such as unauthorized devices, data exfiltration attempts, or jamming signals. Tools like Inspectrum or GNU Radio Companion are commonly used by CTF participants to analyze these signals, building proficiency that translates directly to defensive operations.

1. Protocol Understanding: Each challenge typically requires understanding the underlying protocol to decode the flag. This deep dive into how different wireless systems operate, their modulation schemes, encoding methods, and vulnerabilities, is fundamental for designing secure wireless systems or identifying weaknesses in existing ones. For instance, understanding PocSag's cap codes helps in recognizing how pagers can be spoofed or intercepted.

1. Tool Proficiency: The CTF encourages the use of a wide array of Software Defined Radio (SDR) tools (e.g., RTL-SDR, HackRF, BladeRF, GNU Radio, FL Digi, QSSTV, Multimon-NG). Defenders gain practical experience with these tools, which are equally vital for spectrum monitoring, forensic analysis of RF incidents, and developing countermeasures.

1. Threat Emulation and Countermeasure Development: By understanding how adversaries might create and transmit various signals (as demonstrated by challengectl), defenders can better anticipate potential threats. This knowledge can inform the development of more effective intrusion detection systems for wireless networks, RF jamming detection, or secure protocol design. For instance, if a CTF challenge involves exploiting a weakness in a custom low-power wireless protocol, defenders can apply that learning to secure similar industrial control systems (ICS) or IoT devices.

In essence, challengectl facilitates a learning environment that directly enhances the skills required for RF threat intelligence, vulnerability research, and defensive wireless security. By providing a legal and repeatable way to interact with a diverse set of RF signals, it bridges the gap between theoretical knowledge and practical application, empowering defenders to better protect against the growing landscape of wireless attacks.

Key Takeaways

• challengectl Centralizes RF CTF Management: It's an open-source, multi-threaded Python application that automates the creation, scheduling, and transmission of diverse Software Defined Radio (SDR) challenges, replacing ad-hoc scripts and dedicated hardware.
• Enhanced Scalability and Concurrency: The software efficiently manages multiple SDR devices (e.g., BladeRF 2.0s) to transmit numerous challenges simultaneously or cycle them dynamically, significantly improving the CTF experience and reducing participant wait times.
• Streamlined Challenge Creation: challengectl uses standardized devices.txt and flags files to define hardware and challenges, enabling easier setup, repeatability, and programmatic key rolling for many challenge types like Morse code and ASK.
• Diverse Challenge Support: It supports a wide range of RF challenges, including Morse code, Amplitude Shift Keying (ASK), Narrowband FM, Upper Sideband (for amateur radio digital modes), PocSag, and Long Range Systems (LRS) restaurant pagers.
• Educational Impact: The RFCTF, powered by challengectl, provides a crucial, legal environment for learning and experimentation in RF security, fostering hands-on skills in signal identification, protocol analysis, and SDR tool proficiency for both offensive and defensive practitioners.
• Active Development Roadmap: Future plans include integrating virtual challenges, enabling coordination between multiple challengectl instances, supporting multiple transmit front ends on SDRs, and improving programmatic key rolling for complex digital modes.

About the Speaker(s)

Dan Perret is a significant contributor to the RF Capture the Flag (RFCTF) and the primary speaker for this presentation at RF Village. He has played a key role in the development and evolution of challengectl, the software central to running the RFCTF challenges. His involvement with the RFCTF, likely as part of the RFHS (RF Hackerspace) staff or friends of the village, demonstrates his expertise in software-defined radio, wireless security, and the organization of technical security competitions. While specific titles or company affiliations are not detailed in the transcript, his talk highlights his deep technical understanding of SDR systems and his commitment to fostering education and experimentation in the RF domain.