Welcome back, aspiring investigators!
ArduPilot is one of the most widely used open-source autopilot stacks in the drone world, and it is not limited to flying drones alone. The official project describes it as a versatile autopilot system for multicopters, helicopters, fixed-wing aircraft, rovers, boats, submarines, and antenna trackers, which is why it shows up across a wide range of environments. You install ArduPilot firmware on a flight controller board such as a Pixhawk-class board, a Cube autopilot, or hardware from vendors like Holybro and Matek, and that board becomes the vehicle’s brain. Once flashed and configured, it can control movement, navigation, mission execution, and a wide range of sensors and peripherals. The ongoing war in Ukraine has also made drones an even bigger part of modern conflict.
That makes ArduPilot an interesting subject for digital forensics. When one of these vehicles crashes or is recovered after a mission, it can leave behind valuable artifacts.
Forensically Valuable Files
There are two main forensically valuable files that can be extracted from these drones. The first is the .bin file. ArduPilot stores flight data in DataFlash logs, usually on the autopilot’s SD card or internal flash, and Mission Planner lets you download those logs after the flight. The data inside is recorded in MAVLink-related log formats and includes GPS, altitude, speed, battery status, system events, and many other telemetry fields. In other words, this is the drone’s memory of the entire flight.
The second file is the .plan file. This is the waypoint mission file, stored in JSON format, and it contains the autonomous mission the drone was meant to fly. QGroundControl’s Plan View is built for planning and uploading these missions, and the plan file itself can contain mission items plus optional geofence and rally-point data. If you recover it, you can see the route the operator intended the drone to follow.
To extract the .bin files, remove the microSD card from the flight controller, insert it into your PC using a card reader, and navigate to the APM/LOGS/ directory on the card. This folder contains the .bin flight logs, which can be copied directly for analysis.
If the flight controller still powers on, you can also recover the .plan file by connecting the vehicle to Mission Planner over USB. Open the Flight Plan screen, click Read (sometimes shown as Download from APM), and then save the retrieved mission to your PC as a .plan file.
Together, these two files give you a useful forensic pair. The .plan file shows intent, while the .bin file shows reality.
Analysis
For the analysis, we need the recovered files and QGroundControl to visualize the extracted .plan file. QGroundControl is an official ground control station for MAVLink-enabled vehicles, and its Plan View is designed to plan autonomous missions, upload them to the vehicle, and then switch to flight monitoring. That makes it a natural fit for mission reconstruction work.
We will skip the installation process of QGroundControl here, since the developer documentation already covers it well and the Linux instructions are generally straightforward. The important part for our work is not the installation itself, but how the tool helps us read the mission in a visual way.
Visualizing the Mission Plan
Once you open the application, click the logo in the upper left corner and then choose Plan Flight. That brings up the mission-planning view.
When you open the recovered .plan file, you can immediately see the intended path the drone was supposed to follow.
The mission route in this case is made up of spline waypoints. Spline waypoints are designed to make the vehicle fly smooth, curved paths rather than sharp corners, which is useful when the mission was created for stable video capture or visually clean movement.
When you click individual waypoints, each one reveals details about altitude, direction, and timing.
In our example, when the drone reached the 18th waypoint, it was programmed to climb to 100 meters and hold for 30 seconds in order to capture the Citadella in Budapest.
Just remember that this is only the planned mission. It does not prove the drone completed the route. For that, we need the .bin log file.
Reading the Log File
Now we move from intention to execution. These .bin logs are used to reconstruct the flight from the drone’s own perspective.
We can extract the needed information using the mavlogdump.py script and then search through the resulting text output.
kali > wget https://github.com/ArduPilot/pymavlink/blob/master/tools/mavlogdump.py
kali > python3 -m venv venv; source venv/bin/activate
kali > pip3 install pymavlink
kali > python3 mavlogdump.py log.bin | tee output.txt
Once we do that, the file tends to produce a lot of entries, so filtering is essential.
The first useful thing we can confirm is the takeoff point.
kali > cat output.txt | grep -ai takeoff -A 50 | grep -ai lat
The latitude and longitude should line up with the route shown in the mission plan.
The log also keeps track of crash-related events and the speed at the time of impact. If you search around the hit event, you can usually recover the latitude, longitude, altitude, and speed near the point where the drone struck the ground.
kali > cat output.txt | grep -ai “Hit” -B 50 -A 100 | grep -aiE “Lat|Hit”
You can see that it was moving at a speed (Spd) of 3.2 m/s, and before impact its speed increased, hitting the ground at approximately 12 m/s at 47.4903055, 17.046047 (Lat, Lng). The altitude (Alt) was 121.76 meters.
You can also calculate how long the vehicle spent in the air by comparing takeoff and hit timestamps.
kali > cat output.txt | grep -aiE "takeoff|hit"
Here, you can see that it was flying for roughly 11 minutes before it crashed. ArduPilot logs also include timing fields such as TimeUS, which is measured in microseconds since the flight controller started.
Finally, the log can reveal information about the firmware, vehicle ID, and airframe type. This can help you identify the exact platform and configuration involved.
kali > tail output.txt
Summary
The .plan file shows the mission design, while the .bin files records the flight in detail. Together, they let you reconstruct the route, the timing, the altitude changes, the speed profile, and the final failure point. Because ArduPilot is used across such a wide range of systems, from aerial drones to boats, submarines, and ground vehicles, these forensic methods are valuable far beyond one type of crash.
The data comes from the vehicle itself. If you can read the plan and the log together, you can usually tell a much clearer story than the broken hardware alone would ever reveal.
If you like what we’re doing here and want to get started in forensics or advance your skills, we recommend our training for both beginners and more experienced students.
Source: HackersArise
Source Link: https://hackers-arise.com/digital-forensics-analyzing-crashed-ardupilot-drones/