I did something similar but opposite, reverse engineered the serial protocol of my phantom joystick so I could use it to play drone simulators on my laptop and practice. Ten years ago now, so hopefully not needed anymore, but was a fun project:
https://github.com/Matsemann/mDjiController
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.
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.
palata 16 days ago [-]
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!
hw-f3nter 16 days ago [-]
I think I searched for the corresponding SDK back then, but couldn't find anything. Maybe I was just too stupid haha
Yeah I learned a lot doing it!
palata 16 days ago [-]
Sounds good! I just wasn't sure if I was missing something. Good work otherwise!
chrisdalke 17 days ago [-]
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.
16 days ago [-]
blackeyeblitzar 17 days ago [-]
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?
bri3d 17 days ago [-]
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.
snypher 17 days ago [-]
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.
kotaKat 17 days ago [-]
Stefanik would rather have her husband, the gun lobbyist, push to let kids have more guns.
From what I understand, they exited the consumer market entirely because they just couldn't compete on quality with DJI.
sanex 17 days ago [-]
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.
numpad0 17 days ago [-]
All of "USA" variants of drones are government/large institutions only at >10x price. They aren't consumer products.
saagarjha 17 days ago [-]
Curious why “enterprise” would need capabilities that seem tailored to hunting down people
crooked-v 17 days ago [-]
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.
throwawayaghas1 17 days ago [-]
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.
palata 17 days ago [-]
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.
orliesaurus 17 days ago [-]
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?
saidinesh5 17 days ago [-]
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 )
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.
Any reason BetaFlight doesn't appear to have even basic pre-shared key symmetric encryption? Some ciphers aren't that CPU intensive.
chrisdalke 17 days ago [-]
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.
magnat 17 days ago [-]
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.
jdietrich 16 days ago [-]
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.
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.
05 16 days ago [-]
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.
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).
Saris 16 days ago [-]
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.
bri3d 17 days ago [-]
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.
fc417fc802 17 days ago [-]
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.
palata 17 days ago [-]
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.
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.
theamk 17 days ago [-]
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")
numpad0 17 days ago [-]
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?
echoangle 16 days ago [-]
> They used to have root shell on telnet in early consumer drones.
Is that a problem as long as the drone WiFi is protected?
palata 15 days ago [-]
> 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.
jojobas 17 days ago [-]
Yeah, as if defending against the actual user of the drone would have been a good thing.
lomkju 16 days ago [-]
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.
Why reverse it?
But anyway, for educational purposes it's interesting to reverse engineer anything you want!
Yeah I learned a lot doing it!
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.
But I can’t seem to buy these directly from them? So only through third party resellers? Or is it discontinued?
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.
https://www.timesunion.com/news/article/Stefanik-s-husband-K...
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.
Would love to write some script to make my drones do predefined things depending on API calls - any clues?
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
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/
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.
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.
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/
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.
[0] https://github.com/ExpressLRS/ExpressLRS/pull/1411
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).
If you want autonomous stuff with more advanced features ArduCopter is the way to go.
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.
- 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.
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")
So I assumed ever since that they have their unique opinions about security and architecture of a flying machine control software. Is that odd?
Is that a problem as long as the drone WiFi is protected?
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.