Secure Autonomous Systems

Instructor: Prof. Sibin Mohan, The George Washington University

CSCI 6907/3907 | Fall 2022 | TR 12:45PM - 02:00PM PT | SMTH 115

MP II: PX4 Autopilot & Flight Controller Security


Announcement Date Oct 10, 2022
Submission Date Oct 21, 2022
Submission Time 11:59PM EDT
Total Points 20


There are multiple flight firmwares with different architecture/design principles but understanding one of them helps with understanding others. In this MP, we look into PX4 autopilot, an open-source autopilot firmware. The following objectives are designed to help you familiarize with flight controller firmware: After we've familiarized ourselves with PX4, we will focus on Man-In-The-Middle attacks on PX4, we will implement a Man-In-The-Middle (MitM) attack on the PX4 firwmare.


The usage of drones is gaining popularity: from agricultural usage to a more safety critical usage such as firefighting and search and rescue. Therefore, MP2 will focus on a auto-pilot flight controller. There are two popular opensource auto-pilot flight controller: PX4 and Ardupilot. Despite the architectural difference between the two, they both rely on the usage of a middleware to exchange messages between their components. In this MP, we will be using PX4 and its Software-In-The-Loop (SITL) flight controller simulation with Gazebo physics simulation.
  1. PX4 is a popular opensource autopilot that controls multicopters, fixed-wing aircrafts, rovers and submarines. Archetecture of PX4 from PX4 Documentation As shown in the diagram, PX4 is composed of modules and the modules communicate using the uORB middleware.
  2. uORB middware is a publish-subscribe middleware where a module can publish certain message topics and other modules can subscribe to the topic to get the message.
  3. PX4 provides Software-In-The-Loop(SITL) simulation platform where PX4 controls a simulated vehicle in the host machine. Archetecture of PX4 SITL from PX4 Documentation
  4. By default, SITL provides simplistic physics simulation. However, it supports Gazebo for more complex simulation.
  5. PX4 also provides Hardware-In-The-Loop where the environment is simulated in the host machine but the flight controller runs in the flgiht hardware.
Middleware, also called Data Distribution Service (DDS), is an integral part in autonomous vehicles. The middleware we have explored is uORB which is used by PX4 autopilot.

There also exists Ardupilot, another autopilot software, which uses Robotic Operating System (ROS) as middleware. uORB is similar to the original ROS since they follow the publish/subscribe paradigm.

Because application of these middleswares are safety-critical in nature, there are some security concerns since both were not initially designed with security in mind. ROS2, a newer standard of ROS with major changes, which was released (late 2010s) follows a DDS security specification The specification allows authentication, authorization, and encryption.

Therefore, in this MP, we will investigate why such security measures are necessary by performing MitM by hijacking a uORB topic. We assume the adversary (you) can deploy its malicious module into PX4 and can slightly change particular module of the firmware(specifically the EKF module).

Setting up PX4

We prepared a VM image which has the PX4 setup. The setup has the following system requirement: To setup, download the VM image from here. The username and password for the VM image is student

Running the PX4-SITL

Running the simulator
  1. Download the VM image here.
  2. Inside the VM, change the directory to the PX4: cd /home/student/Desktop/MP2/PX4-Autopilot/
  3. To compile and start the simulation run: make px4_sitl gazebo px4_running
  4. In PX4 command prompt, start the mp2 module mp2 start module_running
  5. In another terminal, change the directory to MP2 base directory: cd /home/student/Desktop/MP2/PX4-Autopilot/
  6. If the run is successful, you should see the following: gazebo_running
  7. In another terminal, change the directory to the MP2 base directory and run the offboard control: python3 offboard_control_running

MP II Instructions

  1. Mavlink and Offboard Control
  2. uORB: Understanding the middleware
  3. Man-In-The-Middle
    For this section:
    1. Adjustments in Running the PX4-SITL
      For this section, there is an extra step where you have to run a server script. There are additional files which you must download from here which contains the and mp2_lib. Later instructional steps will describe where to correctly extract the additional files.

      Running the simulator
      1. Start with the MP2 base directory: cd /home/student/Desktop/MP2
      2. Run the MP2 server: python3 which should wait for the mp2 module in the PX4 to run mp2_server_running
      3. In another terminal, change the directoy to cd /home/student/Desktop/MP2/PX4-Autopilot
      4. Compile and start the simulation by running: make px4_sitl gazebo px4_running
      5. In PX4 command prompt, start the mp2 module mp2 start module_running
      6. In the third terminal, change the directory to the MP2 base directory and run the offboard control: python3 offboard_control_running

    2. Implementation Steps
      1. Create a custom message that has the same structure as the vehicle_local_position under a different name.
        1. Go to the msg in PX4-Autopilot directory
        2. Copy the vehicle_local_position.msg under a different name of your choosing.
        3. We will refer to it as vehicle_local_position_copy
        4. At the bottom of the vehicle_local_position.msg, there should be two commented out lines msg_1
        5. The commented out lines are responsible for it will be declared in #inlcude.
        6. Therefore, modify vehicle_local_position_copy.msg to make it distict from the original. msg_2
        7. Modify the msg/CMakeLists.txt by adding vehicle_local_position_copy.msg to set(msg_files).
      2. Hijack the vehicle_local_position topic.
        1. We want to modify the EKF module so that it publishes under the malicious topic.
        2. In side PX4-Autopilot/src/modules/ekf2/ we need to modify the EKF2Selector.cpp and EKF2Selector.hpp.
        3. In side EKF2Selector.hpp, first include the new message #include <uORB/topics/vehicle_local_position_copy.h>
        4. Then find the line uORB::Publication<vehicle_local_position_s> _vehicle_local_position_pub{ORB_ID(vehicle_local_position)}; which is responsible for publishing the topic.
        5. Replace it with uORB::Publication<vehicle_local_position_copy_s> _vehicle_local_position_pub{ORB_ID(vehicle_local_position_copy)}; to make the variable publish under different topic.
        6. Go to the EKF2Selector.cpp and find the function PublishVehicleLocalPosition().
        7. In the very last few lines of code, find the line where _vehicle_local_position_pub is used, create a struct of the new malicious and copy the vehicle_local_position struct to it using memcpy()
        8. Should look like this: pub
      3. Make the mp2 module communicate with the
        1. Download the additional files here which contains and mp2_lib.cpp and mp2_lib.h
        2. Extract the in the ~/Desktop/MP2/ directory.
        3. Extract the mp2_lib.cpp and mp2_lib.h in the ~/Desktop/MP2/PX4-Autopilot/src/modules/mp2 directory.
        4. Modify the mp2.hpp inside the modules/mp2
          1. Include the mp2_lib.h in mp2.hpp mp2_lib
          2. Add the following line Mp2Server * mp2server; to the private section of the MP2 class.
        5. Add mp2_lib.cpp and mp2_lib.h in CMakeLists.txt under SRC
        6. Modify the mp2.cpp inside the modules/mp2 to read the new topic.
          1. Initizlize the mp2server in the MP2contructor mp2_module_1
          2. Subscribe to vehicle_local_position_copy instead of vehicle_local_position (refer to MP2 part A, remember to change the struct type as well).
          3. Inside the run() function, use mp2server.exfiltrate() to send the subscribed data to the server and mp2server.recieve() to get the offset values back from the server. mp2_module_2
          4. Create vehicle_local_position struct and memcpy() the subscribed data to the struct.
          5. Add the values recieved from the server to the x, y, z position of the struct.
          6. Create publishing id (similar to how there was subscribe id in part A) using orb_advertise()
          7. Publish the topic using orb_publish() mp2_module_3
      4. Implement the attack types in the
        1. Find the "TODO:" flags in the script and implement the corresponding attack.
        2. Fixed offset attack adds fixed constant value (of your choosing) to each of the position values (specify the value you used in the report).
        3. Random offset attack adds random value in a specified range (of your choosing) to each of the position values (specify the range of values you used in the report).
        4. Flipped attack causes move in a trajectory where the X and Y positions are flipped.
        5. Scaled attack causes move in a trajectory where the X and Y movements are scaled by a constant (i.e., if the mission is for the vehicle to move along x axis by 2 meters, in actualality it would move by 2*constant).
        6. The outputs exfil_traj.npy which can be used by the prior plotting script by finding changing the "traj.npy" to "exfil_traj.npy".
        Note: For each of the above missions, repeat them for the missions from the first section of this MP's Instructions, i.e. linear and circular.

        Also, the "mission" is finite time and only should attack between the interval where drone takes off and stop when it lands.
  4. Submission Instructions

    1. PX4
      • Plot of the trajectory of the two missions [3 points]
      • Your mp2_offboard_control and describe the implementation details in the report [4 points]
      • Your mp2.cpp module code [3 point]
    2. Man-in-the-Middle Implementation
      • Man-In-The-Middle implementation (fixed offset, random offset, flipped, and scaled) description [2 points]
      • Plot of the missions with MitM implementations: two missions (linear and circular) on the four attack types [8 points]