ArduPilot is the open-source autopilot stack that quietly underwrites a substantial slice of the commercial and hobbyist drone economy. It runs on quadcopters, planes, rovers, submarines, and antenna trackers. It is the flight controller of choice for academic robotics labs, university competition teams, defense research programs, and several commercial OEMs who never advertise the dependency on a marketing page. When a security team is asked to red team an autonomous platform in 2026, the realistic prior is: the platform runs ArduPilot, talks MAVLink, and was integrated by people who treated security as a downstream concern.

This piece is a working primer for that engagement. It is written for offensive-security practitioners who have to assess an ArduPilot-based vehicle but who did not grow up inside the autopilot community. It maps the attack surface as a layered model: physical bus, link layer, MAVLink protocol, parameter store, mission code, and ground control station. For each layer it names the realistic adversary, the typical control failures, and the diagnostic moves that produce evidence quickly. It is not a CVE catalogue. CVE catalogues age out the moment they ship. This is a methodology document, and methodologies travel further.

Why ArduPilot first

PX4 and ArduPilot are the two large open-source autopilots a Western security team will meet most often. They share the MAVLink protocol and overlap in tooling. ArduPilot earns the lead in this primer for three reasons. First, its install base across small commercial platforms is meaningfully larger than PX4. Second, its parameter surface (more than 1,200 named parameters in a modern Copter build) is the broader attack surface to reason about. Third, its mission storage and failsafe semantics ship with defaults that produce repeatable adversary wins across hardware refresh cycles.

Everything in this document also applies, with translation work, to PX4. The bus layers and MAVLink semantics are shared. The parameter names and failsafe behaviours differ. The methodology does not.

The layered attack surface

The mental model that produces results inside an engagement is a strict layering. Higher layers depend on lower layers for confidentiality and integrity that lower layers do not actually provide. The discipline is to test each layer in isolation and then test the trust assumption between layers.

Layer 0, physical bus

A modern Copter flight controller exposes a UART debug header, an SD card slot, a USB-C port, and a CAN bus for smart peripherals such as digital ESCs or smart batteries. None of these are authenticated. Physical access to any of them is total compromise. The realistic adversary at this layer is the insider, the supply chain technician, or the field operator who recovers a downed vehicle. The diagnostic move is to enumerate every header on the board, dump the SD card to a known-good workstation, and walk the CAN bus with a SLCAN adapter. The expected finding is that the logs contain plaintext mission data, the parameters are dumped to a binary blob with no signature, and the CAN traffic broadcasts the ESC arming state in clear.

Layer 1, radio link

The radio link is most commonly a SiK Radio (433 MHz or 915 MHz, depending on region) running a stock firmware variant of the open-source SiK project. Many integrators leave the default NetID, run with no AES, and never rotate the channel. The realistic adversary is anyone within a few hundred metres with a USB SDR and a quarter-wavelength antenna. The diagnostic move is a GnuRadio capture across the relevant ISM band, a constant-envelope demodulator, and the standard SiK packet shape. The expected finding is the full MAVLink stream in the clear, plus enough RSSI to identify the operator location through a directional re-scan.

Newer integrations have moved to encrypted long-range links (RFD900x with the AES build, Doodle Labs, Microhard). Encryption at this layer does not absolve the layers above it. Encrypted radio with no per-message integrity at the MAVLink layer still admits a replay attack at the application layer once you sit between the operator and the vehicle.

Layer 2, MAVLink

MAVLink is the application protocol that rides the radio. It is a packet-oriented binary protocol with a 6 byte fixed header, a variable payload, a 2 byte CRC, and an optional message signature. Two versions are in active use: MAVLink 1 (six byte header, no signature support) and MAVLink 2 (ten byte header, optional 13 byte signature using HMAC-SHA-256). The interesting clause is "optional." The protocol designers gave operators a per-message integrity primitive. The integrators who matter to a red team almost never turn it on.

The diagnostic move is to capture a session on the wire (or off the SDR), demodulate, decode the MAVLink frames, and grep the signature field for non-zero bytes. The expected finding is that signatures are absent. That single finding unlocks every command-injection abuse downstream. Without per-message signing, the vehicle accepts any well-formed packet from any source with the right system and component IDs. A red team that can transmit at the right channel and power can inject MISSION_CLEAR_ALL, COMMAND_LONG, SET_MODE, or PARAM_SET freely. The diagnostic that confirms it is `pymavlink` plus a transmit-capable radio, paired with the captured system and component IDs, sending a `MAV_CMD_DO_SET_MODE` to LAND in clear and watching the vehicle respond.

Layer 3, parameter store

ArduPilot parameters are the persistent configuration that defines what the vehicle does at the edge of its envelope. The parameter store is large, sparsely documented at the operator level, and reachable over MAVLink through `PARAM_REQUEST_READ`, `PARAM_SET`, and `MISSION_WRITE_PARTIAL_LIST`. The realistic adversary is anyone who has reached Layer 2 with write access. The diagnostic move is to dump all parameters (a ten second exercise with `mavparam.py` or the equivalent), diff against the AP-defaults for the relevant version, and triage anything that looks like a tightening of the safety envelope. The categories that pay off are failsafes (`FS_*`), geofences (`FENCE_*`), arming checks (`ARMING_*`), throttle limits (`THR_*`), and tuning gains (`*_P`, `*_I`, `*_D`).

Parameter abuse is the slowest, quietest, and most damaging adversary move available at this layer. Disabling `FENCE_ENABLE` is a single PARAM_SET. Disabling `ARMING_CHECK` is a single PARAM_SET. Raising `THR_MAX` past the airframe limit and waiting for the operator to fly at full throttle is a deferred mechanical failure that takes the vehicle out at the next mission. Mitigation is straightforward: enable MAVLink2 signing, require operator confirmation for any PARAM_SET that crosses a safety-envelope parameter, and have the GCS warn the operator at preflight if any parameter has drifted from a signed baseline.

Layer 4, mission and geofence

The mission is the sequence of waypoints, conditional commands, and DO_* commands the vehicle executes when it leaves the operator. It is uploaded over MAVLink with the mission protocol (a small state machine of `MISSION_REQUEST_LIST`, `MISSION_COUNT`, `MISSION_ITEM_INT`, `MISSION_ACK`). The realistic adversary with Layer 2 write access can clear the mission, upload an arbitrary mission, or alter individual items. The diagnostic move is `MISSION_REQUEST_LIST` followed by `MISSION_REQUEST_INT` for each index, decoded against the MAV_CMD enum, then a write test against a non-flying bench rig.

Geofences are the sibling structure. A geofence is a polygon plus altitude band. When properly enabled the vehicle will not leave the polygon. When disabled by PARAM_SET, it is a polygon stored in non-volatile memory that the autopilot will simply not consult. The adversary that wants the vehicle in a place its operator did not put it is the adversary that disables the geofence first.

Layer 5, ground control station

The Ground Control Station is a piece of operator software (Mission Planner, QGroundControl, MAVProxy, an OEM custom build) that the operator runs on a laptop or tablet in the field. It is a normal application target, and it is the part of the system that security teams most often overlook because the work feels like it ought to happen at the radio or the autopilot. It does not. The GCS opens a serial port or a UDP socket, parses an unauthenticated MAVLink stream, plots it on a map, and accepts operator input that becomes commands sent back to the vehicle.

The realistic adversaries at this layer are an attacker on the same Wi-Fi network as the operator (UDP MAVLink streams are commonly broadcast on Wi-Fi for tablet GCS), an attacker who can drop a craft mission file the operator loads, and an attacker who can persist on the operator workstation. The diagnostic moves are to scan the operator network for MAVLink UDP traffic (port 14550 is the convention), fuzz mission file parsers with malformed waypoint files, and audit the GCS application for unsafe deserialisation paths. ASEC has shipped a hands-on environment for this work as `Damn-Vulnerable-Drone`. The reader who is at this point in the article and wants to practice should clone that repository before continuing.

A repeatable engagement shape

A first ArduPilot engagement that produces real evidence in a one to two week window looks like this. Day one and two: scope, paper review of the vehicle build manifest, identification of the radio link, the autopilot firmware version, and the GCS in use. Day three and four: bench-rig the vehicle, capture the radio link with an SDR, decode the MAVLink stream, and confirm the absence or presence of message signing. Day five and six: parameter dump, geofence dump, mission dump, diff against version defaults, triage. Day seven: mission write test on the bench. Day eight: GCS workstation review, MAVLink UDP discovery on the operator network, mission-file fuzzing. Day nine and ten: reporting.

The findings that consistently surface across this shape are: signed messages off, default radio NetID, parameters drifted from baseline in ways the operator cannot account for, GCS broadcasting MAVLink on the operator Wi-Fi without authentication, and at least one CAN peripheral that returns a verbose firmware banner on any unauthenticated query. None of these are zero days. All of them are exploitable. The methodology that surfaces them is durable, and it transfers to PX4 with a parameter-name translation.

What this primer does not cover

GPS spoofing is its own discipline and deserves its own primer. So does companion-computer compromise (Raspberry Pi or NVIDIA Jetson sidecars running ROS, talking MAVLink over UART). So does the OEM custom protocol that sits beneath MAVLink on some commercial platforms, particularly in the inspection and survey market. The reader who wants to push further should treat this document as Layer 0 to Layer 5 and look to follow-on ASEC research for GPS, ROS, and OEM-bridge layers.

For defenders

If you operate an ArduPilot fleet and you have read this far, the three controls that buy down the most risk in the shortest time are: turn on MAVLink2 signing across the fleet and rotate the key on a defined cadence, baseline your parameters and have your GCS alert on drift, and treat the operator workstation as the asset it is, with all the application security hygiene that comes with that. None of those are quick. All of them are tractable. The adversary who reaches your vehicle through any of the layers above has already done the work to find you. The work to make the next layer harder is the work that pays.