Drone Bug report


I’ve recently purchased a Parrot AR Drone 2.0. I’ve found a couple of bugs with the drone software (that is, program.elf on the drone specifically) V2.4.8 that I would like to report. One is a mundane command injection bug, the other is a more severe denial-of-service bug which causes the drone software to go unresponsive and enter uncontrolled flight. Is there a proper channel that I should use to disclose the particulars of these bugs to the Parrot developer team?

In particular, I intend to write a short post about the issues I’ve found (more specifically, about how I found them) and publish it by the 30th of August. In the spirit of responsible disclosure, I’d be open to pushing back writing/posting this article to give the Parrot dev team more time to release a fix.


Hi njjewers,

In the spirit of responsible disclosure…

That’s quite commendable of you! However, the Parrot team has long abandoned SDK v2 and now advises everyone to purchase a newer drone (such as the Bebop) which uses SDK v3.

causes the drone software to go unresponsive and enter uncontrolled flight.

Ha! Yeah, that sounds quite familiar! A couple of times now I’ve watched in horror as my AR Drone sails off over the horizon! It’s quite embarrassing during the subsequent search and rescue operations having to ask people if they’ve seen my drone!


Eh, figured as much. Guess I’ll be posting it as planned.


Could you post a link to your article here, so we can all have a read!?


Sorry for the delay, I finally got around to posting it.


A really good read, thanks.

The security aspect doesn’t bother me; as you say, it’s a toy - I’m not storing my company secrets on there! But the 4097 bug is really interesting.

After checking my own Drone SDK it seems I don’t make UDP datagram size checks before sending. But that would have been based on 2 factors:

  1. The SDK documentation states:

    6.1 AT Commands syntax
    The maximum length of the total command cannot exceed 1024 characters; otherwise the entire command line is rejected. This limit is hard coded in the drone software.

  2. I don’t see how 1 or 2 standard AT commands, even concatenated, would even approach the 1024 bytes, let alone the 4096 limit. I guess I’ll have to start logging the datagram lengths to find out!

Armed with this new information, maybe it’s safe for me to unpack the drone once again!? :smiley:

Though given point 2 above, I’m still a bit concerned there maybe a second unresponsive bug lurking somewhere.

But thanks for investigating, I’ve not read machine code for a while!