I Reversed a Drone and Landed It with My PC(hardbreak.wiki)
hardbreak.wiki
I Reversed a Drone and Landed It with My PC
https://www.hardbreak.wiki/network-analysis/protocols/application-layer/proprietary-protocols/parrot-anafi-drone-reverse-engineering
50 comments
I am confused... isn't Parrot's ground SDK open source? https://github.com/Parrot-Developers/groundsdk-android
Why reverse it?
Why reverse it?
For context, this drone was reversed back in 2018 as part of my bachelor thesis. At the time, the SDK hadn’t been released yet I believe, so reversing was the only available option. Recently, I revisited this work and decided to include it on my new hardware hacking wiki - HardBreak.
Hmm. Parrot has had SDKs for their drones years (at least 5) before 2018. Maybe it happened during the few months between the moment they shipped the Anafi and the moment they shipped the corresponding SDK, then.
But anyway, for educational purposes it's interesting to reverse engineer anything you want!
But anyway, for educational purposes it's interesting to reverse engineer anything you want!
That was my thought, at least one of those packets in their snooping (src. port 14551 / dest port 14550) is the standard Mavlink port to send to the GCS.
I wonder if the proprietary packet they decoded here is actually just a MAV_CMD_DO_SET_MODE setting the drone into a takeoff flight mode.
I wonder if the proprietary packet they decoded here is actually just a MAV_CMD_DO_SET_MODE setting the drone into a takeoff flight mode.
[deleted]
I’m not very familiar with drones but apparently this company makes some models in the US, which is great for those of us concerned about privacy / security with Chinese companies like DJI:
https://www.parrot.com/us/drones/anafi-usa
But I can’t seem to buy these directly from them? So only through third party resellers? Or is it discontinued?
But I can’t seem to buy these directly from them? So only through third party resellers? Or is it discontinued?
Like most drone companies (Skydio etc.), they haven’t been able to keep up with DJI and have moved out of the consumer space and into the regulatory captured space with Blue UAS/NDAA compliant drones and high end enterprise offerings for organizations who can’t buy DJI. Their products are available only through dealers/resellers and only their expensive enterprise options are still in production.
Parrot were quite cool; they had one of the only fixed wing consumer drones (Disco) and always offered some of the most open APIs and best SDKs for their drones. Unfortunately their products don’t really hold a candle to modern DJI in terms of flight characteristics and especially wireless link.
Parrot were quite cool; they had one of the only fixed wing consumer drones (Disco) and always offered some of the most open APIs and best SDKs for their drones. Unfortunately their products don’t really hold a candle to modern DJI in terms of flight characteristics and especially wireless link.
Skydio are the ones leaning on Stefanovik and others to push the DJI ban, stoking xenophobic fears just so they can corner the market with an inferior product.
Stefanik would rather have her husband, the gun lobbyist, push to let kids have more guns.
https://www.timesunion.com/news/article/Stefanik-s-husband-K...
https://www.timesunion.com/news/article/Stefanik-s-husband-K...
From what I understand, they exited the consumer market entirely because they just couldn't compete on quality with DJI.
My first drone was a Parrot purchased at a Verizon store ~10 years ago. They definitely have been around for a while but not sure about the current state of the company.
All of "USA" variants of drones are government/large institutions only at >10x price. They aren't consumer products.
Curious why “enterprise” would need capabilities that seem tailored to hunting down people
DJI drones can already do all the stuff that's not tailored to hunting down people, and they can't compete on quality with DJI, so they're trying what little niche remains.
well there are many enterprise farming use cases, or security use cases that can be useful for them. I think the fact that parrot's been working with the army too much they dont know really how to sell to enterprises so thats all the marketing they have.
They should start by comparing their Anafi to a DJI Mavic for mapping. If I make a map with an Anafi, how does it compare to one made with a Mavic?
Because even a 10k Anafi USA does actually compete with the Anzu Robotics alternative. So if it's good enough for surveyors, there is definitely a market in the US.
I just don't understand why Parrot doesn't do that.
Because even a 10k Anafi USA does actually compete with the Anzu Robotics alternative. So if it's good enough for surveyors, there is definitely a market in the US.
I just don't understand why Parrot doesn't do that.
can anyone advise me on a drone brand or something that comes with an "API" that allows me to use it like a programmable interface, on the fly.
Would love to write some script to make my drones do predefined things depending on API calls - any clues?
Would love to write some script to make my drones do predefined things depending on API calls - any clues?
Just build one yourself... It's quite simple and a lot cheaper. All the components you need are open source. Open hardware and software. When something inevitably breaks you know what exactly to replace.
If you don't mind paying a little more and want a ready to fly / kit versions: pick any of these. I remember the Holybro x500 kit used to be very popular (review: https://m.youtube.com/watch?v=cTVtFYONHiY )
https://ardupilot.org/copter/docs/common-rtf.html
You can control them using mavlink / mavsdk etc... the python libraries are good enough.
https://mavsdk.mavlink.io/main/en/index.html
If you don't mind paying a little more and want a ready to fly / kit versions: pick any of these. I remember the Holybro x500 kit used to be very popular (review: https://m.youtube.com/watch?v=cTVtFYONHiY )
https://ardupilot.org/copter/docs/common-rtf.html
You can control them using mavlink / mavsdk etc... the python libraries are good enough.
https://mavsdk.mavlink.io/main/en/index.html
Lots of no-name or DIY drones use flight controller running a BetaFlight [1] firmware, which is open source and quite hackable. If you want low-level real-time programmatic control (like manipulating servos, lights or camera), that is most likely the easiest way. There is also ArduPilot [2] firmware, which is focused more on the high-level control (like managing GPS waypoints and autonomous takeoff/landing).
In both cases you can piggyback your control signals using standard radio or use serial port via dedicated wireless bridge.
[1] https://github.com/betaflight/betaflight
[2] https://ardupilot.org/
In both cases you can piggyback your control signals using standard radio or use serial port via dedicated wireless bridge.
[1] https://github.com/betaflight/betaflight
[2] https://ardupilot.org/
Any reason BetaFlight doesn't appear to have even basic pre-shared key symmetric encryption? Some ciphers aren't that CPU intensive.
Betaflight doesn't really care about what Radio receiver you're using - as long as it can talk to it over uart (/SPI) via one of its supported protocols like crsf, ibus, sbus etc..
If you really want encryption, you can simply use a PiZero that talks CRSF to Betaflight and has an encrypted channel to your ground station over 4G LTE/Wifi/Wfb-ng/what not.
But if you're dealing with 4G and PiZero, might as well use Ardupilot + mavlink. Those tools already support this use case much better.
Betaflight is more of a proximity racing drone kind of use case. Only recently did it's GPS return to home functionality got some improvements.
If you really want encryption, you can simply use a PiZero that talks CRSF to Betaflight and has an encrypted channel to your ground station over 4G LTE/Wifi/Wfb-ng/what not.
But if you're dealing with 4G and PiZero, might as well use Ardupilot + mavlink. Those tools already support this use case much better.
Betaflight is more of a proximity racing drone kind of use case. Only recently did it's GPS return to home functionality got some improvements.
Crossfire supports encryption.
Mainline ELRS can't add encryption support because the whole idea of ELRS was to reduce LoRa packet size to the bare minimum needed for 4 full res channels + a bit extra for arming and time multiplexed aux channels. There's some discussion on protocol security and scope here [0].
I'm sure these days there are multiple LoRa based links (independent and ELRS forks) that support authenticated encryption.
[0] https://github.com/ExpressLRS/ExpressLRS/pull/1411
[0] https://github.com/ExpressLRS/ExpressLRS/pull/1411
Betaflight doesn't handle communications, but also it's just meant for hobby FPV usage.
If you want autonomous stuff with more advanced features ArduCopter is the way to go.
If you want autonomous stuff with more advanced features ArduCopter is the way to go.
I think ciphering is not always allowed on remote control hobbyist bands. Some jurisdictions allow stronger radio output in exchange for such restrictions.
That and lack of demand. Most people are nice, key management is PITA, losing expensive toy from a crypto library bug is going to be frustrating.
WPA2 should be still strong enough for most purposes too(threat_model != CIA).
That and lack of demand. Most people are nice, key management is PITA, losing expensive toy from a crypto library bug is going to be frustrating.
WPA2 should be still strong enough for most purposes too(threat_model != CIA).
BetaFlight doesn't deal with over-the-air bits, it just receives PWM/PPM/S-Bus/whatever signals your receiver provides. There is no point to have encryption in firmware, because connection between RX and FC is hardwired and can be trusted.
Lack of OTA frames encryption, as far as I can tell, is mostly due to legacy reasons. In DYI FPV there are only couple of transmission standards, most of them using 2.4GHz FHSS or some CC2500 clone so you can mix-and-match transmitters and receivers as you wish. If you use custom TX/RX devices, you are pretty much locked in to that specific vendor. Also, designing a nice transmitter UX-wise requires quite a different skillset than designing nice transmitter RF-wise, so manufacturers tend to choose off-the-shelf RF modules.
Lack of OTA frames encryption, as far as I can tell, is mostly due to legacy reasons. In DYI FPV there are only couple of transmission standards, most of them using 2.4GHz FHSS or some CC2500 clone so you can mix-and-match transmitters and receivers as you wish. If you use custom TX/RX devices, you are pretty much locked in to that specific vendor. Also, designing a nice transmitter UX-wise requires quite a different skillset than designing nice transmitter RF-wise, so manufacturers tend to choose off-the-shelf RF modules.
The threat model for most FPV pilots (either hobbyists or people in Ukraine) doesn't really include hijacking of the air link. It's trivial to just shoot something down with interference, sometimes inadvertently.
Pretty much everyone in FPV is now using ExpressLRS, which is an open protocol. If you want an encrypted air link, then the best option I'm aware of is the proprietary TBS Crossfire protocol.
https://www.expresslrs.org/
https://www.team-blacksheep.com/
Pretty much everyone in FPV is now using ExpressLRS, which is an open protocol. If you want an encrypted air link, then the best option I'm aware of is the proprietary TBS Crossfire protocol.
https://www.expresslrs.org/
https://www.team-blacksheep.com/
It's probably the wrong place in the stack to implement this, these are very low-cost commodity microcontrollers running the firmware and the design of flight controller software is focused on time guarantees and reliability.
With the exception of low-cost consumer drones, most larger drones have at least a "Flight Controller" (embedded MCU handling guidance, navigation, and control) and a "Flight Computer" (Higher level *nix based computer running autonomy software), and the flight computer is IMO a more appropriate place to put this.
You could encrypt any Mavlink or proprietary protocol at the application layer if you're using an IP link, or you could also just rely on the telemetry radio to perform encryption between the drone and your ground station.
With the exception of low-cost consumer drones, most larger drones have at least a "Flight Controller" (embedded MCU handling guidance, navigation, and control) and a "Flight Computer" (Higher level *nix based computer running autonomy software), and the flight computer is IMO a more appropriate place to put this.
You could encrypt any Mavlink or proprietary protocol at the application layer if you're using an IP link, or you could also just rely on the telemetry radio to perform encryption between the drone and your ground station.
Onboard or via a phone/controller?
Parrot had very good SDKs but they stopped making consumer drones. You could get one used but beware that the batteries are mostly aging out.
DJI have a Mobile SDK, although it has a quite confusing support matrix and is artificially hamstrung on consumer drones. I think the latest mobile SDK for Android still supports the Mini 3 Pro, so that might be a good starting point (but not the newer 4 Pro). They also have a Payload SDK for their enterprise drones.
Autel also have a mobile SDK although I would describe it as simply a mess.
You can always build your own drone with Ardupilot or PX4 but you’ll have to deep dive into DIY, reimplement or forego a ton of basic flight functions that commercial drones already handle, like visual odometry, and you don’t get a nice camera built in. It’s a viable option for a hobby use but you won’t get anything close to even the most basic commercial drone functionality.
Parrot had very good SDKs but they stopped making consumer drones. You could get one used but beware that the batteries are mostly aging out.
DJI have a Mobile SDK, although it has a quite confusing support matrix and is artificially hamstrung on consumer drones. I think the latest mobile SDK for Android still supports the Mini 3 Pro, so that might be a good starting point (but not the newer 4 Pro). They also have a Payload SDK for their enterprise drones.
Autel also have a mobile SDK although I would describe it as simply a mess.
You can always build your own drone with Ardupilot or PX4 but you’ll have to deep dive into DIY, reimplement or forego a ton of basic flight functions that commercial drones already handle, like visual odometry, and you don’t get a nice camera built in. It’s a viable option for a hobby use but you won’t get anything close to even the most basic commercial drone functionality.
Have you considered DIY options? There's lots of advanced control software out there. It wasn't so long ago that all the best ones were homemade.
Depends a lot on what you want to do.
- What kind of vehicle do you want? A fixed wing? A multicopter? Something else?
- What kind of payload do you want? A stabilised camera (i.e. camera + gimbal)? Something else?
If there is a DJI drone that does what you want (i.e. a multicopter with a gimbal and a camera), then you can't beat DJI.
- What kind of vehicle do you want? A fixed wing? A multicopter? Something else?
- What kind of payload do you want? A stabilised camera (i.e. camera + gimbal)? Something else?
If there is a DJI drone that does what you want (i.e. a multicopter with a gimbal and a camera), then you can't beat DJI.
DJI Tello Drone is a “toy” drone costing around 100€/$ with the cool feature of being able to access/control via wifi with python.
Anything that speaks mavlink is this. It's also much harder to get from 0 to 1 with this than it should be.
Check out ardupilot
There was a good defcon talk of someone going way deeper than that https://youtu.be/5CzURm7OpAA
Fantastic work!
Are Parrot drones insecure or deliberately built with zero security? I thought they're French made, and France tended to be more scared with technological resistance to government interventions than US or China.
What are you talking about?
The Anafi drone uses regular wifi, with ESSID and password, and that's how the security is achieved. There is no need for additional encryption on protocol level.
It's really the best way - instead of making ad-hoc security mechanisms, rely on well-researched and well-tested wifi security.
(That first sentence, "Start by connecting your PC to the Parrot Anafi’s Wi-Fi network", really carries a lot of load... As Raymond Chen likes to say, "It rather involved being on the other side of this airtight hatchway")
The Anafi drone uses regular wifi, with ESSID and password, and that's how the security is achieved. There is no need for additional encryption on protocol level.
It's really the best way - instead of making ad-hoc security mechanisms, rely on well-researched and well-tested wifi security.
(That first sentence, "Start by connecting your PC to the Parrot Anafi’s Wi-Fi network", really carries a lot of load... As Raymond Chen likes to say, "It rather involved being on the other side of this airtight hatchway")
They used to have root shell on telnet in early consumer drones. It was a long time ago, but that can't happen by accident; they could have used dropbear with known fixed password, Wi-Fi MAC as password, etc. They also had wildly different mass than competitors - realistically DJI - at same price/performance ranges.
So I assumed ever since that they have their unique opinions about security and architecture of a flying machine control software. Is that odd?
So I assumed ever since that they have their unique opinions about security and architecture of a flying machine control software. Is that odd?
> They used to have root shell on telnet in early consumer drones.
Is that a problem as long as the drone WiFi is protected?
Is that a problem as long as the drone WiFi is protected?
> Is that odd?
A little bit, yeah. They used to make toys, and you assume that the threat model for the toys is probably the same they would use to build anything else, and then you criticise them based on that assumption.
A little bit, yeah. They used to make toys, and you assume that the threat model for the toys is probably the same they would use to build anything else, and then you criticise them based on that assumption.
Yeah, as if defending against the actual user of the drone would have been a good thing.
Nice! Have you looked into using AI agents for reverse engineering? I would like to know if that would be possible.
Those first generation consumer drones were so wack. Hard to fly, and very brittle software. I lost it when it randomly decided to "fly home" when I took off from a new location without storing a new gps location. I just had to watch it go straight north and out of view.