The ArduPilot firmware can be found at: https://github.com/ArduPilot/ardupilot/
This is an open-source software system that many drone manufactures fork and modify for their own purposes and run on their products. We will focus on the ArduCopter portion of this software for since this is what is typically used on drones.
This is a good resource to get started learning with ArduPilot: http://ardupilot.org/dev/docs/learning-ardupilot-introduction.html
There are multiple layers to this software system that should be understood in order to properly figure out where our attacks can be launched. Specifically, I am aiming to target the flight code which is beneath the public API but above the OS and software of the system in these demonstrations. Ultimately, we want to attack the hardware sensors, to prove the feasibility of these attack, we want to more properly understand the flight code that takes the data from the hardware sensors and makes actuation decisions based on these inputs.
The flight code can be separated into three parts. Vehicle Specific Flight Code, Shared Libraries, and Hardware Abstraction Layer (HAL). In our current research, we want to pay attention to the shared libraries and HAL layers. The shared libraries contain the driver code for the on board sensors as well as the Extended Kalman Filter (EKF) which makes actuation decisions and corrections based on the current and past sensor readings.
The HAL is responsible for the portability of the code to many different platforms. This allows the layers above the HAL to remain the same across all the different platforms while using a standardized HAL API that it uses to interact with the hardware. As of now there are Linux, ChibiOS, and SITL HAL implementations. For the current work, we want to focus on the Software in a Loop (SITL) implementation which allows us to run a software simulation of the firmware.