A drone fleet does not fly itself. Behind every airframe is an operator, behind every operator is a Ground Control Station application, and behind every GCS is a workstation with the usual problems: a browser, a chat client, a personal email tab, three years of stale software. Adversarial testing of an autonomous platform that ignores the GCS will produce a report that describes a flight controller in clinical isolation. The platform the operator actually runs is the union of vehicle, link, GCS, and operator. This document is a methodology for testing the second half of that union.

The methodology is organised in four phases: enumeration, application surface, network surface, and operator surface. Each phase produces evidence that feeds the next. The phases assume legal authorisation to test the operator workstation and the operator network in the scope ASEC negotiates for the engagement.

Phase 1, enumeration

The first finding of any GCS engagement is what the GCS actually is. There are perhaps a dozen GCS applications in real-world use against ArduPilot and PX4 platforms: Mission Planner (Windows, .NET), QGroundControl (cross-platform, Qt, C++), MAVProxy (CLI, Python), APM Planner 2, UgCS, AutoPilot (mobile), and a long tail of OEM custom GCS clients shipped with commercial platforms. Each ships its own attack surface. The methodology branches at this point. Mission Planner work looks like .NET assembly review and DLL hijack hunting. QGroundControl work looks like Qt parser fuzzing and supply-chain dependency audit. Custom OEM work looks like classical desktop application pentest.

Enumeration completes when the engineer can name the GCS, its exact version, the underlying runtime, the install path, and the set of files the GCS reads at startup. The set of startup files matters because it almost always includes parameter files, mission files, and configuration files the user may have downloaded from a community forum or received as an attachment. Each of those is a parser feed into a complex application that was not threat-modelled assuming hostile input.

Phase 2, application surface

Application surface review proceeds along three axes: the network protocol parsers, the file parsers, and the IPC surfaces. MAVLink itself is the dominant network parser. The GCS opens a UDP socket on 14550 (the convention) or a TCP socket or a serial port, reads bytes, frames MAVLink messages, dispatches per message ID to a handler. The handler family is the surface. A handler that does not bounds-check a STRING field or that allocates based on an attacker-controlled count is the path to a parser bug. Coverage-guided fuzzing of the MAVLink parser with a small corpus and a couple of CPU days of execution will find non-trivial bugs in roughly any GCS that has not been hardened.

File parsers are the next axis. A waypoint file (.waypoints), a parameter file (.param), and a log file (.bin or .tlog) are all formats the GCS will open from disk. The user-facing model is "open mission." The under-the-hood model is "parse attacker-supplied file." Fuzz each format with a structure-aware mutator. The TLOG format in particular has a generous structure (binary MAVLink frames inside a timestamped wrapper) and historically has produced parser issues across multiple GCS implementations.

IPC surfaces matter on the platforms that expose them. Mission Planner has a long history of plugin support and DLL loading. QGroundControl has a QML scripting surface. A custom OEM GCS may expose an unauthenticated localhost HTTP endpoint for fleet integration. Each is a surface that an attacker with code execution on the operator workstation can pivot through, and each is a surface that an attacker with a craft input may be able to reach without code execution.

Phase 3, network surface

The GCS does not operate in a vacuum. In the field it is on a laptop or a tablet, joined to a Wi-Fi network the operator brought with them or to the operator hotspot. The network surface review begins by sniffing the operator network for MAVLink traffic. The convention is UDP 14550. The reality is that operators often broadcast the MAVLink stream from the GCS to a second display tablet or to a payload integration laptop, and that broadcast goes out on the operator subnet without authentication.

The diagnostic move is `tcpdump -nn -i wlan0 udp port 14550`, then `mavlogdump.py` against the capture. If the capture contains the vehicle telemetry stream, the network is leaking the vehicle. If the capture contains command messages (`COMMAND_LONG`, `SET_MODE`, `MANUAL_CONTROL`), the network can inject commands back. The mitigation lives at the GCS configuration layer (point-to-point UDP with the second tablet, MAVLink2 signing, a VPN over the operator network) and at the workstation layer (network segmentation, firewall on the GCS host).

The other network surface that pays off is the auxiliary-service surface. A modern GCS often ships a tile-map cache that reaches out to an OSM or Bing tile endpoint. It may ship a telemetry-upload feature that reaches out to a vendor cloud. It may ship a check-for-updates endpoint. Each is a TLS connection to an internet endpoint, and each is a place where the integrator may have skipped certificate pinning. The diagnostic move is a workstation proxy (mitmproxy) with a self-signed CA installed in the GCS user store, then watching what the GCS connects to and how it validates.

Phase 4, operator surface

The operator surface is the workstation as a whole. It is the most uncomfortable phase of the engagement because it is no longer about flight controllers and radios. It is about a Windows or macOS laptop that the operator uses for email, slides, and operations. The phase begins with a standard workstation enumeration: OS version, patch level, EDR presence, browser version, installed software inventory. The phase continues with the GCS-specific concerns: where the parameter files live, where the mission files live, where the keys live (if MAVLink2 signing is on, the signing key is on disk somewhere), and what permissions those files carry.

The phase concludes with a phishing simulation that is scoped against the operator role. A field operator is reachable through email, through community forums (the ArduPilot forum is a hub for parameter sharing), and through chat platforms used by the operator organisation. A pretext that delivers a craft parameter file as an attachment from a familiar-looking community profile is realistic, low cost, and frequently successful. The deliverable from the phase is a triaged map of operator-reachable vectors with an honest assessment of which are likely to land.

A worked example, anonymised

In a recent commercial engagement the in-scope platform was a fixed-wing survey aircraft running ArduPlane and Mission Planner. Phase 1 identified the GCS as Mission Planner 1.3.x. Phase 2 identified a TLOG parser path that crashed on a craft tlog. Phase 3 identified the GCS broadcasting MAVLink on UDP 14550 to a payload-integration laptop on the same operator subnet with no signing. Phase 4 identified the operator workstation as a contractor-owned laptop with a months-stale browser and EDR misconfigured to exclude the GCS install directory. None of the findings were a vulnerability in ArduPilot or in MAVLink. All of the findings were exploitable against the platform. The remediation plan that landed with the client was a workstation refresh, a GCS configuration baseline with signing enabled, a network segmentation policy for the operator subnet, and a quarterly cadence of phishing exercises against the operator role. The platform did not get rebuilt. The platform got defended.

Closing

The GCS is the part of the autonomous platform where the operator lives and the part where most adversary work actually wins. A penetration test that scopes the GCS in and follows the four-phase methodology above produces findings that the operator can act on within a quarter. A penetration test that scopes the GCS out produces a clean-bill-of-health on the flight controller and an unaddressed compromise risk on the operator laptop. The first deliverable is more useful. The methodology to produce it is here.