Included tools

This page lists the tools inside each RF Swift toolbox (container image). It is a reference: you don’t need to read it from top to bottom. If you are still choosing a toolbox, start with Choose a toolbox.

How to use this page

• Find a tool. Long tables have a filter box above them: type part of a name to narrow the table down. To search the whole documentation at once, press Ctrl K.

• Read the status columns.

  • Yes: the tool is installed by default: it is in the image when you pull or build it.
  • No: install it manually: the image ships an installation function for it, which you run after creating your lab.
  • Limited: the tool may have architecture-specific issues.

• Add a tool marked No. Create your lab, then run the function named in the Installation function column:

  bashCopy

  rfswift container install -c my_lab -i <installation_function_name>

  Leave out -i to pick the function from a searchable list. Add more software compares this with the other ways to add tools, and container install has every option.

Image hierarchy

Each RF Swift image builds upon a foundation of tools, with specialized images adding domain-specific capabilities: corebuild is the base, sdrsa_devices adds the SDR drivers, sdr_light builds on it, sdr_full on sdr_light, and so on. The full diagram is in Choose a toolbox. A tool listed for a base image is also in every image built on it.

Tools by image

Core SDR device support

The sdrsa_devices image serves as the foundation for many RF Swift images, providing essential drivers and utilities for software-defined radio hardware.

Common device troubleshooting

RTL-SDR kernel module conflicts

If your RTL-SDR device is unavailable when using tools like nfc-spy, the DVB-T kernel module may have claimed it. Blacklist the module with:

echo "blacklist dvb_usb_rtl28xxu" | sudo tee /etc/modprobe.d/blacklist-dvb_usb_rtl28xxu.conf

You’ll need to restart your host system after adding this blacklist entry.

PlutoSDR connection issues

If the PlutoSDR doesn’t appear with iio_info -s and you see errors like:

with backends: local xml ip usb
Unable to create Local IIO context : No such file or directory (2)
ERROR: Unable to create Avahi DNS-SD client :Daemon not running
Scanning for IIO contexts failed: Text file busy (26)

This can be resolved in two ways:

1. On Linux hosts: Ensure avahi-daemon is running on your host system
2. Inside the container: Run the Avahi daemon with:
   bashCopy

   avahi-daemon --no-drop-root --no-rlimits

SDR light

The sdr_light image includes essential software-defined radio tools for signal capture, analysis, and basic decoding.

SDR full

The sdr_full image builds on sdr_light to provide a complete SDR development and analysis environment, including GNU Radio and specialized plugins.

GNU Radio out-of-tree modules

These modules extend GNU Radio’s capabilities for specific protocols and signal types:

Additional SDR software

GNU Radio 4.0

The sdr_gnuradio4 image builds GNU Radio 4.0 (RC2) from source alongside the GNU Radio 3.10 already present in sdr_light. GR4 is a separate C++23 codebase with its own headers, namespace and prefix, so nothing about your existing 3.10 flowgraphs changes:

rfswift container create -i penthertz/rfswift_resolute:sdr_gnuradio4 -n gr4

RFID

The rfid image focuses on radio-frequency identification analysis and exploitation:

# When creating a new container
rfswift container create -i rfid -n rfid_tools -s /dev/ttyACM0:/dev/ttyACM0

# Or with an existing container
rfswift config bindings add -c rfid_tools -d -t /dev/ttyACM0   # serial port, attached on demand

Bluetooth

The bluetooth image contains specialized tools for Bluetooth protocol analysis and security testing:

rfswift container create -i bluetooth -n bt_tools -a NET_ADMIN

Wi-Fi

The wifi image provides tools for Wi-Fi network analysis, packet capture, and security assessment:

rfswift container create -i wifi -n wifi_tools -a NET_ADMIN

Telecommunications

The telecommunications images are divided into several categories based on mobile network generations:

Telecom utilities

Foundation tools for cellular network analysis:

2G/3G

Tools for GSM, UMTS, and related technologies:

4G/5G

Tools for LTE and 5G-NSA:

5G standalone

Tools for 5G standalone (SA) and core networks:

Automotive

The automotive image contains tools for vehicle network analysis and communication:

Reverse engineering & SAST

The reversing image provides tools for firmware analysis, hardware reverse engineering and static application security testing:

Network

The network image contains general network analysis and security tools:

Active directory

The ad image builds on network and packs the tooling needed for Windows domain engagements, the part of an assessment that starts once you are past the radio layer:

Mobile / Android

The android image covers Android application and device assessment, from pulling an APK off a handset to running it through a full static analysis pipeline:

rfswift container create -i android -n mobile_lab -s /dev/bus/usb:/dev/bus/usb

OSINT

The osint image collects open-source intelligence and reconnaissance tooling on top of corebuild:

Hardware security

The hardware image focuses on general hardware security testing and analysis:

Native Nix environments

The same categories exist as native environments for the Nix engine, defined in RF-Swift-nix. rfswift env catalog lists them on your machine, rfswift env tools <name> shows what one carries, and rfswift env run <environment> <tool> runs a single tool without creating anything. This table comes from the catalog (RF-Swift-nix 4.0.0):

Packages are nixpkgs attribute names (python3Packages.impacket, gnuradioPackages.gr-osmosdr), which is also what rfswift env install and rfswift env search --nixpkgs accept, so a tool the catalog does not carry is one env install away. The catalog records the packages that do not build on an architecture, and the environment ships without them there. See Installing software for how this compares with the images.

Tips for using the tools

Where tools are installed

RF Swift organizes tools in specialized directories for easier discovery:

• /rftools/ - Radio frequency analysis tools
• /rftools/sdr/ - SDR software and utilities
• /rftools/bluetooth/ - Bluetooth tools and firmwares
• /rftools/wifi/ - WiFi security tools
• /rftools/rfid/ - RFID readers and utilities
• /rftools/calibration/ - VNA and calibration tools
• /rftools/analysers/ - Spectrum analyzer software
• /rftools/generators/ - Signal generator software
• /hardware/ - Hardware security and testing tools
• /automotive/ - Vehicle communication and analysis tools
• /reverse/ - Reverse engineering and firmware analysis tools
• /telecom/ - Telecommunications tools
• /telecom/2G/ - GSM/2G base stations
• /telecom/3G/ - UMTS/3G tools
• /telecom/4G/ - LTE/4G tools
• /telecom/5G/ - 5G SA/NSA tools
• /telecom/SIM/ - SIM card tools
• /security/ - Security testing tools (Caido, etc.)
• /opt/network/ - Network security tools
• /opt/ad/ - Active Directory tooling (ad image)
• /opt/osint/ - OSINT frameworks in their own venvs (osint image)
• /mobile/ - Android and mobile tooling (android image)
• /opt/gnuradio4/ - GNU Radio 4.0 tree and its Python venv (sdr_gnuradio4 image)
• /opt/fuzzing/ - Wordlists and fuzzing resources (SecLists)
• /nettools/ - Network monitoring tools built from source
• /opt/crack/ - Password cracking tools
• /sast/ - Static analysis security testing

These directories complement the standard system paths (/usr/bin, /usr/local/bin) and contain specialized tools, scripts, and resources.

Finding available tools

To discover which tools are available in your current container:

# List all executable commands in standard paths
find /usr/bin /usr/local/bin -type f -executable | sort

# List RF tools in the dedicated directory
ls -la /rftools

# List tools in other specialized directories
ls -la /hardware
ls -la /automotive
ls -la /reverse
ls -la /telecom

# Search for a specific tool across all locations
find /usr/bin /usr/local/bin /rftools /hardware /automotive /reverse /telecom -name "*sdr*" -type f -executable

Installing tools manually

Some tools are not installed by default but can be added after container creation. To install these tools:

rfswift container install -c container_name -i <installation_function_name>

The Installing software page compares this with apt inside the container, committing the result, recipes, and the Nix engine’s env install and env run.

Common manually-installed tools:

• mdk3_soft_install - WiFi DoS testing
• wifipumpkin3_soft_install - Rogue AP framework
• install_soapy_modules - Additional SoapySDR device support
• pocketvna_sa_device - PocketVNA software (x86_64 only)
• srsran5GSA_bladerf_soft_install - 5G SA gNB fork with bladeRF support

To find out what is available in a given image, check the Installation function column of the tables above. Every entry marked No can be installed this way.

cat /var/lib/db/rfswift_build_report.tsv

Tool documentation

Most tools include built-in help available through the -h or --help flags:

tool_name --help

For more detailed documentation, many tools include man pages:

man tool_name

Creating tool aliases

For frequently used tools with complex options, consider creating aliases in your container:

echo 'alias rtlpower-optimized="rtl_power -f 88M:108M:25k -g 50 -i 10 -e 1h power.csv"' >> ~/.zshrc
source ~/.zshrc

Architecture-specific notes

x86_64 / AMD64

• Broadest tool support
• All GPU-accelerated tools available
• SignalHound and specialized SA software supported

ARM64 / aarch64

• Most tools fully supported
• Some GUI applications require AppImage extraction
• Limited SA software support (no SignalHound Spike/VSG60)
• Python tools may need building from source

RISC-V64

• Growing support, most core SDR tools work
• Some tools installed from source due to package availability
• Limited pre-built binary support
• Python packages may require longer build times

Next steps