Hijacking drones with a MAVLink exploit

From Shellintel (via Hackaday)

Recently some of us here at shellntel have been building quadcopters and autonomous vehicles for fun.  We are big fans of the Pixhawk flight controller for its awesome autonomous capabilities.  We are also big fans of privacy.  As much as we like to build and fly these drones, we realize doing so in an irresponsible way can cause concern. We started looking into the various drone communications and discovered a design flaw that allowed us to take control of any drone flying with a specific telemetry protocol.

Telemetry allows the drone to exchange information and commands wirelessly with a ground station. This includes sending/receiving GPS coordinates, waypoints, throttle adjustments, arm and disarm commands, pretty much anything, including a serial shell.

The design flaw is not unique to PixHawk, but rather with the Mavlink protocol. Mavlink is used by many companies including:  Parrot AR.Drone (with Flight Recorder), ArduPilot, PX4FMU, pxIMU, SmartAP, MatrixPilot, Armazila 10dM3UOP88, Hexo+, TauLabs and AutoQuad. All of these companies make great products, but if they adopt the Mavlink protocol as is, it may be possible to hijack their drones (and any other drone using Mavlink).

According to its documentation, each Mavlink radio pair is setup with a NetID or channel.  This is done to prevent two radio pairs from interfering with each other.  By default this value is set to 25, but the user can change this setting. To hijack one of these drones, all you'd need to do is set your transmitter to the same NetID as the target drone.

Looking at the protocol spec, each data packet sent by the radio includes the NetID in its transmission!  This means that all we need to do is listen for a single packet within the frequency spectrum, capture it, carve the NetID, and set our radio to use it.  This, is surprisingly easy.

Using these radios, we can modify the OSS firmware to simply do this.  The following changes were made to  radio.c which when compiled is flashed to the transmitter.

Original Code:

 // decode the header     
errcount = golay_decode(6, buf, gout);
if (gout[0] != netid[0] || gout[1] != netid[1]) {
// its not for our network ID
debug("netid %x %x\n",
goto failed; }

Modified Code:

// decode the header         
errcount = golay_decode(6, buf, gout);
if (gout[0] != netid[0] || gout[1] != netid[1]) {
// its not for our network ID
/* Modified by __int128 */
// Set our radio to use the captured packets NetID
param_set(PARAM_NETID, gout[0]))
// Save the value to flash
// To read the new value we need to reboot. Rebooting
RSTSRC |= (1 4);
/* End of what was added by __int128*/ }

The variable gout[0] is set earlier in the radio.c; which is populated with the NetID of all captured packets.  This block of code is only hit when our radio hears a packet from another radio set on a different NetID from ours (which is good because don’t want to reboot each time we hear a new packet).  Anyway, that’s it, 3 lines of code is all it takes to hijack any drone using Mavlink.  Compile it, flash the radio and you’re good to go.  It works surprisingly well and is super quick.  

Views: 6577

Comment by Dusan on October 15, 2015 at 8:51pm

So I guess its tie to implement some sort of authentication  in mavlink protocol

Comment by John Dennings on October 15, 2015 at 9:36pm

Yes, time for authentication and encryption.

Btw, not really a "design flaw". It would be if mavlink and the Sik radios were meant to be secure, but they were not.

Comment by Martin Rüedi on October 15, 2015 at 10:21pm

Another argument to use 3G based telemetry. Just yesterday I introduced my project Flightzoomer over at the telemetry-over-cellular-ip-group:


Comment by JB on October 15, 2015 at 10:28pm

I'm not quite sure if labelling it a Mavlink flaw or exploit is correct. From my point of view it's the radio and SIk code that is not securing the serial stream, which in this case is the Mavlink messages. From what I understand the NetID package headers are from the radio not the APM/PXH mavlink code.

The question is where the security should be implemented, either on the radio to secure all communications regardless of protocol ie Mavlink or in the serial encapsulation itself. I'd expect that radio security would get better mileage and be more universally adopted. 

BTW the RFD900+ supports AES out of the box, I'm not sure about the other HopeRF based radios as I don't use them much anymore. Might be time to turn it on.

It's nice to know how to find out the NetID of other users though. Should come in handy for a stir! ;-)

Comment by Christian on October 16, 2015 at 12:37am

I remember there was a discussion about secure Mavlink (sMavlink) started by Lorenz Meier in 2013.

I don't know what was the result of this discussion...

And i found the SMACCMPilot project, that uses a secured Mavlink communication:


I haven't fully understood how this works in detail, but i assume they use a custom firmware for the SiK radios and a protocol wrapper between pure Mavlink protocol and the SiK radio protocol:


Comment by Patrick Poirier on October 16, 2015 at 5:48am


"The changes result in an overhead of 16 bytes of additional bandwidth use per MAVLink frame, which is potentially composed of many message. The computational overhead is dominated by encryption and decryption operations for each message send and receive."

Means that you add additionnal processing and latency in your control link. Migt work if you get a lot of processing power, but it rules out most of the arduino bases autopilots.  

So basically it is a question of purpose:

do you want to make a conrol link for an application that is -by design - running on a Personnal Aera Network ??

Comment by Oleksandr Chendekov on October 16, 2015 at 9:06am

This may force release of SiK AES128 firmware for Si1030 based radios which is already partially developed.

Comment by David McCallister on October 16, 2015 at 3:02pm

Excellent find. Exposing a vulnerability like this will bring about competition and change for a more secure and robust telemetry network for drones. As a user, I'm glad to hear that there are already some options from the comments above. 

Comment by Philip Giacalone on October 16, 2015 at 10:05pm

Very nice find. Thank you for posting the code. 

The ability to hijack MAVLink is a bit more complicated than just knowing the NetID, although this will work if the many other radio configuration settings are left unchanged.

There's a great analysis by a U.S. Air Force Captain given at the link below. As explained on pages 52 & 53 of the report, there are 3,790,800 possible radio configuration combinations! Therein lies the complication for a radio hijacker. For those worried about being hijacked, simply change a few of your radio config settings to greatly enhance your security. 

Note: The link below will download a 2.9MB PDF file containing the report.


Comment by joebar.rc on October 16, 2015 at 11:37pm

The context of the article is not correct, it is NOT about hacking mavlink. Mavlink in itself is not secure, it is not designed to be at the moment so there is nothing to hack.

It is about 'hacking' a specific 3DR radio, so any other telemetry link (bluetooth, xbee, wifi etc) using mavlink would in this context be without problems.

But on the topic of taking control, that is really only possible IF the mavlink command implementation on the flightcontroller allows it. For example AutoQuad that is mentioned.. There is no control schema that makes it possible to take over the flightcontroller during flight. It is not in the code to take mavlink commands during flight. 

Only on alternate codes follow me or point to flight exists and can take commands, but a simple switch to manual is all needed to stop it.

So.. although a good find on the 3DR radio exploit, it is NOT about a mavlink exploit hence the article heading and context is not correct.


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service