10 years ago I "reverse engineered" the protocol of their controllers so that I could use it for drone simulators on my PC. When plugging in the controller to update the firmware, I noticed their software could read stick positions. So I just dumped all the data on the serial and looked at what changed and what remained static when moving one stick all the way to the left, right etc. And just copied the patterns of whatever the software used to prod the controller. Then I used a joystick library to emulate my readings as an xbox controller.
I worked for a company that had a cloud solution to manage drone fleets, and we tried ingesting log files. We had a small team working on that, and we were grateful to use and/or learn from what was available in GitHub repositories like yours (although I don't recognize yours specifically). There was a lot of trial and error, a lot of magic numbers, and stuff was still wrong half the time. And then... they leveled up the encryption of the log files, and it was game-over. Their new solution gave limited access to vendors willing to work through the legalities. If I remember correctly, it required the log file, or at least parts of it to be uploaded to get the keys to unlock it. Not something US companies, like big utilities, were very keen on.
I've always been interested in buying a dji drone but never pulled the trigger precisely because of crap like this. Give me a well documented interface and don't call home/include IoT.
It's not that hard, but that's not what DJI offers. Their business (and, who knows, maybe political) incentives are different, so they chose a closed, guarded system. By the way, it's what everyone did in the 80's/90's, so why would some contingent of companies not be that way now.
Seems like it's basically impossible to ever prevent this kind of black box strategy. It's similar to the problem of secure DRM on videos-- at some point you need to decode the stuff to play it on the screen, and you can intercept it at that point. They need to send the commands to the drone in a timely way for it to work, and you can control those commands and know what commands you're sending. Although I guess they could XOR that command stream with some kind of one-time pad or something so you can never mimic it going forward, so maybe not? But whatever the stream of bits getting XORed to the command stream, that would need to exist in the memory in the drone unit, so with enough persistence and skill maybe you could crack it for a particular drone at least. I guess all they need to do is make it uneconomically hard to do for an arbitrary individual drone unit.
This looks like the DJI can bus protocol used for the accessory ports on at least the DJI RS2. There's some documentation for the headers in the protocol in the DJI RS2 SDK pdf.
Cool that it's now a usable SDK. Afaik there was nothing when I made this a decade ago, but perhaps I didn't look in the correct places or asked the correct people.
There's also something fishy about DJI in that their Android app to control their drones is intentionally not listed on the Play Store. I've never seen a manufacturer require side loading.
Anyone know why it's not on the Play Store? (On iOS it is on the App Store, well because there isn't another way till this DMA thing kicks in)
The play store is banned in China. So sideloading/alternate app stores are the main way most users install apps there.
Their china-based engineers might not even consider it important to support the play store.
As a non-US citizen, I frequently see how US based engineering teams just don't understand local markets/customs. This is just being on the other side of that.
Android isn’t a huge market segment for high end drones, and when it is, it’s almost always purpose specific/dedicated devices. ‘Juice not worth the squeeze’ and all.
They recently dropped support for the iOS SDK and stopped releasing new versions, they've been moving away from iOS in general in favour of using their own controllers.
That they don't want to release through the official android app stores for a free app is a bit sus.
We clamped down our MDM policies to disallow sideloading on corporate devices, when we asked DJI when they planned to submit their app on the Play Store and they basically told us never, we decided to remove all DJI drones from our fleet.
You can side load android, you can't side load Apple (without jailbreak). Having to deal with two review processes instead of just one saves money and headaches. Also since they are dealing with US sanctions they probably had to fill out all kinds of stuff and submit that to Apple which they would also have to do for Google but again, they can just side load instead.
I don't use their app at all, I just use the DJI RC. In any case I wouldn't recommend controlling a drone from a phone running a bunch of background tasks that may pop up notifications and phone calls while you're trying to dodge obstacles.
The phone doesn't need to broadcast anything to control the drone directly. The phone talks to the remote control unit, which is what broadcasts signals to control the drone. You don't need wifi or mobile internet, or even bluetooth to fly a DJI drone (the phone connects by cable to the remote control unit).
(Actually, that's not 100% true -- if you're in a locked zone that requires permission to fly (such as near airfields or other protected sites), you will need internet access to start your flight and unlock the zone using your DJI account. Otherwise the drone may refuse to fly into restricted zones.)
You don't even need the phone at all -- the remote unit is quite capable of controlling the drone in flight with the phone switched off.
Here's a dark conspiracy theory for ya:
Consumer drones (including DJIs) are being used in warfare more and more frequently, including the war in Ukraine.
The Chinese government, while not openly supporting Russia, has been repeatedly accused of covertly doing so. Imagine what kind of harm a device used for reconnaissance could do if it secretly works for the other side.
no even that - DJI are potentially collecting thousands if not millions of hours of telemetry about how small drones are used in real-life combat. This is absolutely invaluable to developing countermeasures or optimising their own offensive platforms.
Also mapping all of the western world, and sending the most detailed 3d maps of western infrastructure to servers of a company that's a part of the chinese military complex.
I very much assume, involved militaries are aware of this possibility and are not blindly trusting Chinese consumer drones right off the shelves, have soldiers in every unit install random sideloaded apps. Lol.
They likely flash verified firmware and use a verified app version, not the latest one from DJI's website... Maybe they have their own code, by now. Especially with reconnaissance drones. The Ukrainians probably need to do this, not just because of the obvious possibility of a "backdoor", but RF adaptability in the EM warfare situation.
I would worry more about contractor John Doe bringing a compromised private phone to a government or industrial facility. Not sure a highres video feed from a drone could be easily exfiltrated unnoticed, anyway, since they usually don't come with WWAN hardware built-in. But the phone itself would be able do all sorts of reconnaissance and become an attack vector in a sensitive context. Then again, this is not specific to drone (software), but all untrusted software people install.
It's not any different from people that do not shop at WalMart, Amazon, etc because of differences with the corporation. It's not hard once you quit making excuses
To submit an app you'd have to give free access to your source code to a potential rival, DJI is a huge brand, it'd be easy for the US government to basically get access to such code and clone it.
I'm surprised people really think it's anything other than wanting to protect their IP.
This, and also they still have the firmware which stays in the drone hardware and very likely is where the most important code is. Cloning the app wouldn't give much advantage to a competitor.
Google accepts obfuscated apps though (even ones that are heavily obfuscated). I've never heard of anyone getting their app rejected due to obsfucation.
It is pretty standard stuff to obfuscate your code when you distribute your app to a phone to protect against decompiling and sometimes just to save space.
It's also pretty standard stuff to obfuscate your code when you're doing something dirty. The problem with obfuscation is that, for the end user, there's not a great way to determine which use case the developer had in mind which means one should probably approach such an application with extreme caution.
How is it user-hostile to obfuscate your source code? It doesn’t change the user experience, just makes it more difficult to reverse engineer which would be against the EULA anyway.
Most anti-reversing clauses in EULAs wouldn't get past a court because of public policy concerns (i.e, recovering the systems/methods/algorithms used by an app is a legitimate form of competition and we don't want copyright or contract law to get in the way of that)
mommyyy dji didn't upload their source code to github so we could clone it then ban them on the grounds of national security, mooooom!!1
I'm sure TSMC also not bringing their latest node tech to their US fabs also happens to be because they're doing something dirty! oh wait, corporations want to protect their IP, and countries have time and time again proven that they're willing to enter the private business to give their country an edge.
That ban wouldn't be lifted if DJI rrleased all their source code, showed their belly and wagged their tail.
I mean, the central point is straight where everyone's focusing:
> But broadly speaking, U.S. drone makers say they expect to see a sales bump this year even though the new ban on federal purchases is not yet in effect.
Oh come on. It definitely couldn't be that it's surveillance technology produced in a country known on a massive scale for stealing information via electronic means, especially against the US, right?
Your statement reflects little knowledge on US national defense matters, shows a lack of knowledge about the technology, ignores recent historical knowledge of China's hacking efforts against the US, and provides zero information to back up your claim.
Surely we apply the same level of scrutiny to everyone right? Don't pretend that this is about China being a bad actor in the space. Everyone is a bad actor here, and arguably the NSA is worse.
I'm not trying to say DJI shouldn't be banned for government applications. It definitely has a hardware kill switch back home. But let's not pretend that facebook et al + Google + Apple are any different.
> But let's not pretend that facebook et al + Google + Apple are any different.
Were we pretending this? Was anyone pretending this? It would likewise be quite wise for China to ban the use of products made by these companies in their own sensitive federal applications, and my understanding is that broadly, they have.
> The packer contains some countermeasures, as partially described in this issue, to prevent the use of dynamic tools. Fortunately, these can be easily bypassed.
Does anyone have more details on this step? The linked issue is devoid of information and was closed because the person refused to release the technique publicly.
It's a rabbit hole, but try googling "anti-debugging" (you may want to include "ptrace" or not). It's only if you are curious about it more in general, if you are wondering about this specific protector (secneo?), then that won't help you much, sadly.
As I understood the protection talked about here is a bit different from ptracing your own processes, which is already talked about just above grandparent’s quoted statement.
On that note, I’ll just remark how RE tutorials avoid talking about anything but the basics, and the advanced writeups handwave away the challenging parts, leaving a major void for learners.
I'd love to see some analysis of their OTA transmission formats. Currently the DJI headsets must communicate with the drone somehow in order to receive the video stream - this means the headset is constantly transmitting to the drone and this can effect other people even on different frequencies flying drones and it makes spectating rather difficult (and racing in groups impossible, not that you would want to race DJI drones as the variable latency does not really lend itself to drone racing).
There is already some signal analysis done by those in the field on Youtube but an open source method to pull packets from transmitting drones and redisplay them without transmitting to the drone would be wonderful.
> pull packets from transmitting drones and redisplay them without transmitting to the drone
You can see what happens when you try this by putting DJI FPV Goggles in Audience Mode. It's horrible and not suitable for flying. The DJI link is fundamentally two-way and aggressively uses sounding and HARQ.
The solution to flying with DJI FPV users at your field is to not use Raceband 6 at all (DJI uses this for link negotiation), and otherwise look up the Raceband to DJI correlation chart and allocate separate channels as usual.
Interesting that they go through all that work to protect against modern deobfuscation attacks and reversing - and then use RC4 and MD5. They may be ok in this context, but the choice is sort of odd.
I bought a DJI mavic when it first came out - and it would not allow me to fly it - even with the small 2-stick controller - without installing the app, which required an account.
I sent it back.
Later, I found out HOW MUCH data was sent back to DJI. It was basically everything. It was sent to a variety of sites, with stuff like flight profiles, images, all kinds of stuff.
I wonder if this obfuscation was implemented at the behest of some government or other to make entering no-fly zones much harder. It seems overkill for something that's otherwise such a simple app.
Also, I think the 'no fly zone' stuff is entirely implemented on the drone itself and the app could be fully opensource if needed without compromising that functionality.
Even if this was the case, the contents of this list might change significantly between the time of manufacture and the time of use. The forcing of updates basically makes sure that the newest list is always written to the drone as soon as it is released.
With cheap drones appearing to be critical to the future of warfare, is there a chance that the US will develop a domestic drone industry that rivals China's, or has that ship sailed?
There's plenty of military drones companies, the US military has the budget for them. But now I'm wondering, who would win, 1,000 military drones or 1,000,000 consumer DJI ones?
"Quantity has a quality of its own". Consumer DJI Drones are useless in a fight (good only for reconnaissance or maybe crashing into military drones to disrupt them), but Russia is showing that drones can be made on the cheap (e.g. there was footage of a drone of theirs using a plastic soda bottle as the fuel reservoir) and still be disruptive.
DJI drones are ubiquitous on both sides in the Ukraine conflict. They have excellent cameras and long flight durations, which make them an ideal aerial observation platform. The battlefield is a very different place if you can't hide behind terrain and have to assume that if you can see the sky, then you can be seen by the enemy. These drones have drastically improved the effectiveness of conventional artillery, because you can seek out targets and get real-time reports on exactly where you shells are landing. Consumer/prosumer drones are vulnerable to jamming or being shot down, but they're also cheap enough to be essentially expendable. Ukraine are reportedly losing 10,000 drones a month, but that's a bargain for what they achieve on the battlefield.
DJI drones fitted with grenade-dropping mechanisms have been used extensively and still see some use, but DIY FPV drones are now the preferred offensive weapon, used in a kamikaze role as a kind of cheap guided missile. They're cheaper, faster and more agile than the DJI drones. A good FPV pilot can hit the weak spots on a moving tank, or fly through a narrow opening to hit troops sheltering in a bunker. They're invariably used with DJI drones in hunter-killer teams, with a DJI drone acting as a spotter for an FPV pilot.
The sound of a DJI drone is known to everyone on the front line and it means exactly one thing - that you need to find hard cover now. If you can hear it, then chances are that it has spotted you, the pilot has passed on your coordinates and a kamikaze drone or an artillery shell is already flying towards you. If you ignore it or take pot shots at it, then you're gambling with your life.
UKR also has limited access to latest PRC drones, DJI T60 is $8000 consumer agriculture drone with 60kg payload and AESA radar. That's enough to start swarming and engaging almost any ground vehicles.
Getting signal through a hostile radio environment comes to mind. But as it stands now it looks like this might be a field were a hundred "macguyvers on typewriters" adapting consumer drones are more effective than a Shakespeare trapped in the bowels of the military industrial complex.
Even basic consumer drones use frequency hopping and have relatively complex signal integrity logic - necessary even for using ‘free’ frequencies like 2.4 and 5.4 ghz in typical urban environments. And they’re pretty good, frankly.
"Frequency hopping" does nothing when your adversary can blow out the entire 2.4 and 5.4GHz bands, even before getting into sophisticated radio-specific attacks.
Urban radio environments are crowded, not actively hostile.
And yet, plenty of field success right now with consumer (even basic amateur level) drones.
The issue with high energy jamming (broad frequency band denial) is it makes your jammer a super tempting (and easy) target for a HARM or equivalent, and consumes quite a bit of power. If someone is actively denying such a wide frequency band, any high school level electronics student can design a pretty effective seeker.
And the whole 'radio power drops off as a cube of the distance' thing means the equipment needs to be pretty close to operations, so it's going to get attacked pretty often.
The noise level in a typical urban environment from wifi is already pretty terrible, 'hostile' or not. Way more terrible than a typical remote environment, which is where these drones are being used, unless there are active countermeasures pretty close.
Counter measures, counter-counter measures, etc. But I'm not seeing much mention of effective jamming happening in-theatre right now.
They do. In fact they graduated from simply dropping grenades on soldiers and IFVs to suicide roles taking out actual tanks. I'm not sure actual DJIs are being used in suicide missions or custom, still inexpensive, drones.
The video footage of suicide drones you can find on r/combatfootage is nearly always from custom drones, the giveaway is the analog video transmission. As the poster before said, DJI drones are only used for reconnaisance (for example DJI Matrice), where high-quality digital video transmission (and thermal image cameras) are very useful.
There's a coalition to supply Ukraine with a million drones (although that figure might be exaggerated) I'm guessing they'll be slightly cheaper than the Black Hornet ($100K+)
In what volume of space? You don't want them to be packed densely enough that the enemy can fire a buckshot in a random direction and shoot down two dozen drones.
> Next thing will be assassinating people with their own phone by causing it to blow up next to their head
I don't know if this was an intentional reference or not, but that has definitely already been done (with a rigged phone). Plus the widespread use of phone position data for targeting.
> the problem is that "we" still think killing each other is some sort of solution
The problem is that violence works against everything except more violence.
Does anyone know of any "decompilation"/bytecode lessons or online resources to learn more and become more comfortable with dealing with bytecode, obfuscation, etc. in Java? Keep in mind it doesn't need to teach the very basics, but just be a full in depth learning.
This feels to me like an order from a Chinese project manager to have their code "obfuscated". The developers had to comply and put something that satisfies him. This doesn't matter in the least, and the conspiracy theories about this being used for military or intelligence purposes are ridiculous. Any obfuscation will be overcome and the only way around it is for DJI to release both their own hardware and software.
My summary of DJI apps, which I have extensively reverse engineered, is:
If you opt into DJI's Flight Record Sync service, you send them your flight records. If you send DJI the additional logs they request for a warranty claim, you send them basically every imaginable bit of data from your drone. Both of these things make sense intuitively.
Overall, DJI appear to be earnestly attempting to respect data privacy, especially in their newer apps, DJI Fly and DJI Pilot 2. DJI Fly overall attempts to honor the user's flight analytics and flight log transfer preferences. DJI Pilot 2 in Local Data Mode genuinely stops using the network entirely. DJI's newer "Clear All Data" feature genuinely (but insecurely) erases all stored historic flight and user data on a drone and controller. DJI's efforts towards obfuscation seem generally directed at preventing reverse-engineering by their competitors, not hiding CCP malware.
HOWEVER:
DJI are a hardware company and lack competence in the software space, so they frequently make egregious mistakes which expose users to information disclosure or device security issues. This is especially bad in their older apps (DJI Go and DJI Pilot 1). They occasionally ship third-party libraries containing their own analytics and forget to disable these third-party analytics. Their information security practice seems quite bad overall, including a very prominent leak where all of their AWS data was downloaded in 2017, including synced flight logs, warranty logs, and app telemetry data.
DJI's consumer apps (DJI Fly) are loaded with product-manager-requested mobile app telemetry, as are most American phone apps of all kinds, and require app login to activate a drone. This enables powerful cross-correlation against a user's activities in the app. Sufficiently advanced telemetry is indistinguishable from surveillance malware. There is no evidence of a massive conspiracy where DJI are trying to siphon data to the CCP, but a malicious actor with access to their mobile app analytics dashboard could definitely infer a lot more information than a sensitive customer would like to disclose, including locations where the app was used, with what drone model and for how long it was used for, and whether or not special no-fly zone authorization was requested from DJI.
My summary of DJI is:
I would use a modern DJI drone, enterprise or consumer, in a casual home or business application. However, I would only use a DJI drone with DJI Remote Controllers (which are Android tablets), not my own phone. I would activate the drone, then forget the WiFi network I used to activate it. This provides an end-run around the product telemetry features present in the app, and avoids security issues on your local device introduced by DJI's poor programming practice.
DJI Enterprise hardware and software genuinely attempts to provide offline functionality. I would use it with one of the professional standalone RC units, even in a moderately sensitive situation (say, Law Enforcement use), after auditing one specific app version's behavior (to ensure they didn't accidentally introduce a library with telemetry enabled, which they've been known to do).
Also, be aware that all DJI drones broadcast a local proprietary beacon, sometimes referred to as Drone ID or Aeroscope (not to be confused with US Remote ID standards), containing drone serial number and current location data. On newer consumer drones, this broadcast is encrypted. Regardless, it should be assumed that if you are flying a DJI drone, it can and will be tracked by nearby parties. This should be assumed for any drone, realistically. In the usual use case, you are controlling a giant RF emitter using another giant RF emitter.
https://github.com/Matsemann/mDjiController/