🚀 RF Swift 📡

August 1, 2026 · View on GitHub

https://github.com/user-attachments/assets/518c5045-4380-48d0-a731-6ec0273a02c5

🔍 What is RF Swift?

RF Swift builds you a complete hardware and RF security lab in seconds — on the machine you already use. 🔄 From a ham shack on a Sunday afternoon to a full James Bond-grade engagement on Monday morning: same tool, different image.

Unlike traditional approaches that force you to sacrifice your primary OS, RF Swift brings 200+ containerized RF, hardware and security tools to your existing environment — on Linux, Windows and macOS, across x86_64, ARM64 and RISC-V64. 🏠

🆕 v3.0.0 "Resonance" — images rebased on Ubuntu 26.04 "Resolute", CLI rebuilt on the new Moby SDK, and new ad, android and osint images for full engagements. See What's new in v3.0.0.

⚡ Why RF Swift Outperforms Dedicated OS Solutions

Feature	RF Swift	Dedicated OS
🏠 Host OS Preservation	✅ Keep your existing OS	❌ Requires dedicated partition or VM
🛡️ Tool Isolation	✅ Tools contained without system impact	❌ Tools can destabilize system
⚡ Deployment Speed	✅ Seconds to deploy	❌ Hours for full installation
💾 Disk Space	✅ Only install tools you need	❌ Requires 20-50GB minimum
🔄 Updates	✅ Update individual tools without risk	❌ System-wide updates can break functionality
🌐 Multi-architecture	✅ x86_64, ARM64, RISCV64 and more!	❌ Limited architecture support
🔁 Reproducibility	✅ Identical environments everywhere	❌ System drift between other installations
💼 Work Environment	✅ Use alongside productivity tools	❌ Switch contexts between systems
📹 Session Recording	✅ Built-in recording for documentation	❌ Manual setup required
🎨 Easy Customization	✅ Simple YAML recipes for custom images	❌ Complex OS modifications

🆕 What's new in v3.0.0 "Resonance"

📦 New base: Ubuntu Noble → Resolute (26.04)

Every official image (penthertz/rfswift_resolute:*) now runs on Ubuntu 26.04. This was the heaviest part of the release: GCC 15 promoted long-tolerated K&R C patterns to hard errors, CMake 4 dropped compatibility with cmake_minimum_required(VERSION < 3.5), Boost 1.90 removed the io_context APIs much of the SDR ecosystem depends on, and Python 3.14 / Java 25 became the defaults.

Rather than pinning an old base, we patched the software and maintain the forks publicly, so 50+ GNU Radio out-of-tree modules build on a current LTS again:

gr-osmosdr · gr-gsm · gr-fosphor · gr-dvbs2 · gr-nordic · gr-grnet · gr-pdu_utils · gr-sandia_utils · gr-fhss_utils · gr-timing_utils · srsRAN 4G · YATE · OpenBTS · OpenBTS-UMTS

OpenBTS and OpenBTS-UMTS are legacy C++ that GCC 15 rejects outright; both are maintained on the resolute branches of our forks.

📡 Telecom: 5G SA now runs on OCUDU

The 5G SA stack shipped in the telecom images has moved from srsRAN Project to OCUDU as the CU/DU stack. srsRAN 4G (and the 4G/5G-NSA path) still ships from our patched srsRAN_4G_resolute fork, so 2G through 5G remains one pull.

⚡ GNU Radio 4, testable in seconds

Want to try GNU Radio 4 without building it from source or risking your working 3.10 install? There's now a dedicated image — your existing setup stays untouched:

rfswift run -i penthertz/rfswift_resolute:sdr_gnuradio4

⚙️ Rebuilt CLI

Container operations moved from the legacy Docker Go client to the new Moby SDK (moby/moby/api + moby/moby/client)
Full Go dependency tree brought up to date
Dependabot, a module-audit workflow and security scanning in CI
Signed build attestations published with every release

🧰 New images for full engagements

Image	What it covers
🏛 `ad`	Active Directory assessments
📱 `android`	Mobile app testing and instrumentation
🕵️ `osint`	Open-source intelligence and recon
⚡ `sdr_gnuradio4`	GNU Radio 4, ready to run (see above)

Plus new tooling inside the existing images — SAST/DAST in reversing (Semgrep, Joern, cppcheck, honggfuzz, clang static analyzer, Trivy), grimoire in the shell harness, and WhisperPair (CVE-2025-36911) and caeruleus on the RF/Bluetooth side.

✨ Key Features

Core Capabilities

🏠 Non-disruptive Integration: Run specialized RF tools while continuing to use your preferred OS for daily work
🧩 Modular Tool Selection: Deploy only the tools you need, when you need them
🛡️ Containerized Isolation: Prevent RF tools from affecting system stability or security
🌍 Cross-platform Compatibility: Works seamlessly on Linux, Windows, and macOS
🔌 Dynamic Hardware Integration: Connect and disconnect USB devices, ports, capabilities, and resources without recreating containers
🌐 NAT Networking: Isolated container networks with configurable subnets for multi-container RF lab setups
📋 Container Profiles: YAML presets for quick deployment of preconfigured container environments
⚡ GPU Acceleration: Dedicated images with OpenCL support for Intel and NVIDIA GPUs
💾 Space Efficiency: Use a fraction of the disk space required by dedicated OS solutions

🐳🦭 Container Engine Support

RF Swift supports both Docker and Podman as container engines, giving you the freedom to choose the runtime that best fits your environment:

	Docker	Podman	Lima
Architecture	Client-server daemon	Daemonless, fork-exec	Docker inside QEMU VM
Root required	Yes (daemon runs as root)	No (rootless by default)	No (VM managed by Lima)
USB passthrough	Linux only	Linux only	macOS via QMP hot-plug
Best for	Broad ecosystem, Windows/macOS	Security-focused, air-gapped	macOS + USB RF hardware

Auto-detection

RF Swift automatically detects the available container engine at startup. If both are installed, Docker is used by default. Override with:

rfswift --engine podman run -n mycontainer -i penthertz/rfswift_resolute:sdr_light
rfswift --engine docker run -n mycontainer -i penthertz/rfswift_resolute:sdr_light
rfswift --engine lima run -n mycontainer -i penthertz/rfswift_resolute:sdr_light  # macOS USB

Podman support example

https://github.com/user-attachments/assets/14b6d50f-5250-420e-94e4-474991113372

Podman Highlights

Rootless containers: No daemon, no root - ideal for locked-down environments and shared lab machines
OCI-compatible images: All existing RF Swift images work out of the box with Podman
Seamless device passthrough: USB SDR dongles, serial adapters, and GPUs work with both engines
Automatic cgroup handling: RF Swift detects cgroup v1/v2 and configures device access rules accordingly

🦙 macOS USB Passthrough (Lima)

Docker Desktop and Podman on macOS cannot forward USB devices (SDR dongles, HackRF, RTL-SDR, etc.) into containers. RF Swift solves this with Lima, which runs a QEMU VM with USB hot-plug support:

# Install QEMU + official Lima (USB passthrough works via the VM's video.display)
brew install qemu lima

# Attach your SDR dongle to the Lima VM
rfswift macusb list                              # see host USB devices
rfswift macusb attach --vid 0x1d50 --pid 0x604b  # forward HackRF to VM

# Run container via Lima's Docker (where USB device lives)
rfswift --engine lima run -i penthertz/rfswift_resolute:sdr_light -n sdr_work

# When done, detach
rfswift macusb detach --vid 0x1d50 --pid 0x604b

Lima auto-creates the VM on first use with Docker, USB libraries, kernel modules, and udev rules for all supported RF hardware pre-configured. Use --engine lima when you need USB devices; use Docker Desktop normally for everything else.

🎮 GPU acceleration on Apple Silicon (opt-in)

On Apple Silicon, USB passthrough and GPU acceleration need different VM backends and cannot coexist in one VM. The Lima VM above uses QEMU for USB/SDR devices. For GPU compute (e.g. Vulkan-accelerated ML/DSP) there is a separate opt-in profile that uses the krunkit backend (libkrun), which exposes the Apple GPU to containers as a Vulkan device (Mesa Venus -> MoltenVK -> Metal). It is Vulkan, not CUDA, and provides no USB passthrough.

# One-time: install Lima + the krunkit backend
brew install lima
brew tap slp/krunkit && brew install krunkit

# Run a container in the GPU VM (auto-created on first use). --gpu implies --engine lima
# and uses a separate instance (rfswift-gpu), leaving your USB/SDR VM untouched.
rfswift --gpu run -i penthertz/rfswift_resolute:sdr_light -n gpu_work --devices /dev/dri

Use --gpu for GPU compute; use --engine lima (without --gpu) for SDR hardware. Requires macOS ≥ 14 and a guest kernel with virtio-gpu Venus support (Linux ≥ 6.13).

Quick Setup

# Install with the interactive installer (offers Docker, Podman, or both)
curl -fsSL "https://raw.githubusercontent.com/PentHertz/RF-Swift/refs/heads/main/scripts/get_rfswift.sh" | sh

# Or install Podman manually
sudo apt install podman          # Debian/Ubuntu
sudo dnf install podman          # Fedora/RHEL
sudo pacman -S podman            # Arch Linux
brew install podman              # macOS

Verifying downloads: The installer offers to check each binary's Sigstore-backed build provenance attestation automatically. To verify manually with the GitHub CLI: gh attestation verify <downloaded.tar.gz> --repo PentHertz/RF-Swift. This proves the artifact was built by the official RF Swift release workflow from a specific commit - not swapped afterwards.

Note: When using Podman in rootless mode, some operations (like direct device passthrough) may require additional configuration. RF Swift handles most of this automatically, but see the documentation for details.

graph TD;
    A[corebuild]-->B[sdrsa_devices];
    A-->C[rfid];
    A-->D[automotive];
    A-->E[reversing];
    A-->H[network];
    A-->T[osint];
    A-->U[android];
    B-->I[sdr_light];
    B-->J[bluetooth];
    B-->K[telecom_utils];
    B-->L[hardware];
    H-->M[wifi];
    H-->V[ad];
    I-->N[sdr_full];
    I-->W[sdr_gnuradio4];
    K-->P[telecom_2Gto3G];
    K-->Q[telecom_4G_5GNSA];
    K-->R[telecom_4Gto5G];
    K-->S[telecom_5G];

Category	Images	Key Tools
📻 SDR	`sdr_light`, `sdr_full`, `sdr_gnuradio4` 🆕	GNU Radio (3.10 + a dedicated GNU Radio 4 image), GQRX, SDR++, SDRangel, SigDigger, CyberEther, Inspectrum, URH, rtl_433, dump1090, GNSS-SDR, SatDump, Jupyter + 50+ GNU Radio OOT modules (gr-gsm, gr-lora, gr-satellites, gr-ieee802-11, gr-droneid, gr-tempest, ...)
📡 SDR Devices	`sdrsa_devices`	Drivers for USRP (UHD), RTL-SDR, HackRF, BladeRF, Airspy, LimeSDR, PlutoSDR, XTRX, RFNM, HydraSDR, LiteX M2SDR, SignalHound, Harogic, LibreSDR, SoapySDR
📱 Telecom	`telecom_utils`, `telecom_2Gto3G`, `telecom_4G_5GNSA`, `telecom_4Gto5G`, `telecom_5G`	PySIM, pycrate, srsRAN 4G, OCUDU 🆕 (5G SA CU/DU), Open5GS, UERANSIM, YateBTS, OpenBTS, OpenBTS-UMTS, OsmoCom BTS Suite, SigPloit, PyHSS, SCAT, jSS7, 5Greplay
📶 Bluetooth	`bluetooth`	BlueZ, WHAD, Mirage, Sniffle, Bluing, bdaddr, ice9-bluetooth, esp32 BT Classic sniffer
📡 Wi-Fi	`wifi`	Aircrack-ng, hcxdumptool, Reaver, Bully, Pixiewps, EAPHammer, Airgeddon, Wifite2, WPA3 attack suite (Dragonslayer/Dragonforce/Wacker), Hostapd-mana, Wifiphisher
🏷️ RFID	`rfid`	Proxmark3 (RRG/Iceman), libnfc, mfoc, mfcuk, RFIDler, miLazyCracker
🚗 Automotive	`automotive`	can-utils, CANtact, Caring Caribou, SavvyCAN, Gallia, V2GInjector
🔧 Hardware	`hardware`	PulseView, DSView, Logic 2 (Saleae), Arduino IDE, Flashrom, OpenOCD, esptool, openFPGALoader, MTKClient, ngscopeclient, dfu-util, SeerGDB, AVRDUDE
🔍 Reversing & SAST	`reversing`	Ghidra, Radare2, Cutter, ImHex, Binwalk (v2+v3), Unblob, Sasquatch, AFL, Honggfuzz, Kaitai Struct, Qiling, Unicorn/Keystone, plus SAST/DAST: Semgrep, Joern, cppcheck, clang static analyzer, Trivy 🆕
🌐 Network	`network`	Nmap, Wireshark, Metasploit, Burp Suite, Caido, Impacket, NetExec, Responder, Hashcat, John the Ripper, Kismet, Bettercap, SIPVicious, MBTget
🏛 Active Directory 🆕	`ad`	Impacket, NetExec, Responder, BloodHound.py, Certipy, bloodyAD, certsync, mitm6, kerbrute, lsassy, ldapdomaindump, sprayhound, DonPAPI, SharpLAPS, skewrun
📱 Mobile 🆕	`android`	adb/fastboot, apktool, apksigner, zipalign, smali, scrcpy, dex2jar, Frida, objection, androguard, drozer, MobSF
🕵️ OSINT 🆕	`osint`	theHarvester, Sherlock, maigret, holehe, GHunt, toutatis, instaloader, Sublist3r, h8mail, censys, SpiderFoot, recon-ng, FinalRecon

200+ tools across 18+ images, all on x86_64, ARM64, and RISC-V64.

Full image list with detailed tool inventory available at rfswift.io/docs/guide/list-of-tools/

🌟 Real-World Use Cases

👔 For Professionals

🧰 Rapid Assessment Deployment: Deploy a complete RF lab at client sites in minutes
🔄 Consistent Environments: Eliminate "works on my machine" issues
⚙️ Parallel Testing: Run multiple isolated assessments simultaneously
📹 Documentation: Built-in session recording for client reports
🛠️ Custom Toolsets: Create specialized containers for specific engagements

🔬 For Researchers

📊 Reproducible Research: Share exact tool environments with papers
🧪 Experiment Isolation: Keep experimental configurations separate
🌐 Multi-platform Collaboration: Work across Linux, Windows, and macOS
🔢 Version Control: Test with specific tool versions for reproducibility
⚡ Resource Optimization: Allocate resources based on research needs

👨‍🏫 For Educators

🏫 Classroom Deployment: Identical environments for all students
💻 No OS Reinstall: Students keep their existing operating systems
🖥️ Low Requirements: Works on standard lab computers
📚 Focused Learning: Custom containers for specific lessons
🔄 Quick Reset: Easily reset environments between classes

🏭 For Manufacturing & QA

🔍 Production Testing: Consistent RF testing environments
📡 Device Validation: Test wireless product compliance
🔧 Firmware Analysis: Isolated environments for firmware testing
📊 Quality Assurance: Reproducible test configurations

🔒 For Security-Conscious Environments

🦭 Rootless with Podman: No privileged daemon required - ideal for SOC-compliant and hardened systems
🏔️ Air-gapped labs: Pre-pull images, deploy without internet using Podman's daemonless architecture
🛡️ Minimal attack surface: No long-running daemon socket to protect