The first time a security engineer hears the phrase "command and control link" applied to a commercial drone the mental model is military. In practice a meaningful share of the commercial small UAS market runs over an unlicensed ISM band, on a SiK-derived telemetry radio, with a SiK-default NetID, and with a transmit power tuned for line-of-sight at a kilometre or two. The link is real, it carries the operator commands, and it carries the vehicle telemetry. It is also, in most field deployments, a link that an adversary with a hundred dollars of hardware and a free weekend can intercept end to end.
This article is a working primer on the RF link layer in commercial UAS. It is written for security teams who can read a tcpdump but who have not used GnuRadio in anger. It is not a course on RF engineering. It is a tour of where the link sits, what it actually protects, and what an adversary working at the link layer can realistically do.
The three link families
A small-UAS RF link will almost always belong to one of three families. Knowing which family the platform under test belongs to is the first question to answer.
The first family is the SiK Radio family. SiK is the open-source firmware for the HM-TRP and HopeRF radios. It runs on the venerable 3DR Telemetry, the RFD900x, and a long tail of clones. It defaults to 433 MHz in EU regions and 915 MHz in North American regions. It defaults to no AES. It defaults to NetID 25. It uses a Frequency-Hopping Spread Spectrum scheme with a hop sequence derived from the NetID. The MAVLink frames ride inside SiK packets, often with no application-layer authentication.
The second family is the encrypted long-range link. RFD900x with the AES build, Doodle Labs Mesh Rider, Microhard pDDL, Silvus StreamCaster. These are higher-end products aimed at integrators who needed to harden the link. They ship with AES on by default and with a key-management workflow that integrators do or do not follow.
The third family is the consumer-grade proprietary link. DJI OcuSync, Autel Skylink, Parrot SkyController. These are vendor-specific, frequency-hopping, encrypted, and (for the security researcher) largely opaque without specialised tooling. They are not the focus of this article because the realistic adversary against the small-commercial market most often meets family one.
What the SiK link actually protects
A default SiK deployment protects nothing. The bytes on the air are MAVLink frames with the standard 6 or 10 byte header, the standard payload, and the standard CRC. There is no link-layer authentication. There is no application-layer signature (MAVLink2 signing is an opt-in feature that in practice is off by default). There is a frequency-hopping pattern that an adversary derives from the NetID, and the NetID is sent in the clear in the SiK packet header.
The mental model that travels: the link is a shared physical medium with no access control. If the adversary can match the hopping pattern and the data rate, the adversary is on the bus. SiK provides obscurity through frequency hopping at a low level. It does not provide confidentiality or integrity.
The adversary toolkit
The adversary toolkit at this layer is mature, well documented, and inexpensive. A HackRF One or a LimeSDR Mini provides full-duplex transmit and receive across the 433 MHz and 915 MHz ISM bands. A quarter-wavelength dipole or a small Yagi extends range from a few metres to a few hundred metres. GnuRadio Companion provides the demodulation pipeline. A patched copy of the SiK source provides reference for the framing. `pymavlink` provides the application-layer encode and decode. The full software bill of materials for an adversary capable of intercepting and injecting on a SiK link is open source.
The diagnostic that confirms the link is the link the team thinks it is: a GnuRadio flowgraph that demodulates a small chunk of spectrum during a known operator-to-vehicle exchange (preflight checks, mode switch, mission upload), then a file-write of the demodulated bits, then a `mavlogdump.py` against the resulting binary. If the dump contains readable MAVLink messages, the team has confirmed the link family, the NetID, the absence of link-layer encryption, and the absence of application-layer signing. The team has, in other words, ground truth.
What an adversary can do at this layer
The realistic adversary at the RF link layer has four moves.
Move one is passive observation. The adversary listens, demodulates, and decodes. The adversary now knows the vehicle position (every HEARTBEAT and GLOBAL_POSITION_INT broadcasts it in the clear), the mission (uploaded MISSION_ITEM_INT frames during preflight), the operator location to within the directional resolution of the antenna (RSSI of the uplink), and any unencrypted payload telemetry the operator chose to add to the stream (camera state, sensor data).
Move two is replay. The adversary captures an operator command (a MISSION_CLEAR_ALL, a SET_MODE to LAND, a COMMAND_LONG for MAV_CMD_NAV_RETURN_TO_LAUNCH) and retransmits it. Without signing, the vehicle accepts the replayed command. Without per-command sequence numbers, the vehicle has no protocol-layer defence.
Move three is injection. The adversary fabricates a well-formed MAVLink frame, transmits it on the right channel at the right time, and the vehicle accepts it. The adversary needs the system ID and component ID of the operator (visible in any captured packet), the right channel from the hopping sequence (derivable from the NetID), and a transmit power high enough to dominate the operator at the vehicle receiver (the radio equation problem).
Move four is denial. The adversary transmits a continuous wave or a wideband noise burst across the band. The link drops, the vehicle hits its link-loss failsafe, the failsafe action (RTL, LAND, CONTINUE) executes. The realistic adversary who wants the vehicle to leave a particular location without compromising it can sometimes accomplish that goal with a single jamming move and the operator-configured failsafe action.
Mitigations that actually move the needle
The mitigations that move the needle against a realistic RF-layer adversary are not theoretical. They are off-the-shelf and cheap. First: enable MAVLink2 signing across the fleet. This forecloses the replay and injection moves. The adversary keeps passive observation and denial. The first two are the higher-impact moves. Second: rotate the SiK NetID off the default, and rotate it on a defined cadence. This raises the cost of joining the hopping pattern. Third: where the threat model justifies it, move to an encrypted-link product (RFD900x AES, Doodle Labs, Microhard) and follow the key-management workflow the integrator publishes. Fourth: have the operator-configured failsafe actions be the actions the operator actually wants under jamming. The default RTL is rarely correct in a contested environment, but the right action is a deliberate design choice, not a left-as-shipped accident.
For the security team that is asked to red team an UAS platform: the RF link is the cheapest layer to test, the layer that produces the loudest findings, and the layer that has the cleanest mitigations. Test it first. Report what is there. Hand the operator a list of changes they can land in a sprint. The next time the platform comes back for assessment, the adversary will have moved up the stack.