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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
https://github.com/Matsemann/mDjiController/
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.
Is it really that hard?
1 reply →
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.
It's called DUML/DUSS, there's a lot of documentation about it in http://github.com/o-gs/dji-firmware-tools
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.
And yet tons of other apps from China seem to make it to the play store. And it's not like DJI isn't aware of how many devices they sell overseas.
It's almost as if it were intentional.
5 replies →
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.
What did you replace the DJI drones with?
Buy cheap dedicated motorolas?
> Anyone know why it's not on the Play Store?
Can’t think of any reason that isn’t sketchy. The article gives a clue already.
If the app passes Apple’s review, then it could pass Google’s review.
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.
1 reply →
see Epic suit i guess.
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.
do not disturb mode is your friend here, or even airplane mode
5 replies →
As I remember their app downloads a binary package after installation from an unknown source, and that's against Google ToS as far as I know.
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.
That's not a theory as much as it is an acknowledged fact, and why DJI are banned from many 5-Eyes facilities.
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.
1 reply →
DJI's app wasn't on the Play Store for years before Russia invaded Ukraine, so that's somewhat unlikely.
4 replies →
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.
Are you suggesting we should ban Starlink because it is used in warfare both in Ukraine and in the middle east?
5 replies →
No conspiracy here, just hard cold truth.
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.
[dead]
When you are leader in the market, you want to make sure your competition isn't able to reverse engineer your products, including google
Why would sideloading prevent Google from reverse engineering the product?
You meant google can't buy DJI product and Android phone to reverse engineer the product?
3 replies →
Stuff like this is is part of the reason the US DoD banned DJI drone usage in 2020, looks like the ban will likely extend to all federal agencies this year: https://www.govtech.com/em/emergency-blogs/disaster-zone/fed...
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.
4 replies →
Most of the kinds of obfuscating DJI is doing make the app take up more space.
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.
The actual reason is jingoism, regardless of excuse.
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.
4 replies →
> 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.
1 reply →
The issue says at the end what worked for one respondent.
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.
> can effect other people even on different frequencies flying drones and it makes spectating rather difficult (and racing in groups impossible,
It’s a solved problem, spectating is supported out of the box and frequency bands have been public for a long time.
Here’s a JB video with all you need to know to coexist with analog: [1] Here’s Oscar Liang’s frequency chart (updated for O3): [2]
[1] https://youtu.be/P0b99JDcUQs
[2] https://oscarliang.com/fpv-channels/
> 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.
Afair DJI drone link is modified LTE radio.
I thought it was essentially WiFi.
1 reply →
Very impressive analysis!
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 think open source drones are the answer.
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.
11 replies →
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+)
https://breakingdefense.com/2024/02/european-coalition-bids-...
https://en.wikipedia.org/wiki/Black_Hornet_Nano
1,000 electronic warfare-hardened drones vs. 1,000,000 drones using simple, documented radio on ISM bands?
Exactly 0 of those 1,000,000 consumer drones will be flying in US operating areas.
2 replies →
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.
1 reply →
None of those are cheap FPV quadcopters, are they?
Maybe we should stop killing each other instead of banning drones.
Next thing will be assassinating people with their own phone by causing it to blow up next to their head.
The tool isn't the problem, the problem is that "we" still think killing each other is some sort of solution.
> Maybe we should stop killing each other instead of banning drones.
Wishful thinking. Always have, always will. War is even “legal”, think about that, no repercussions for NATO countries.
> 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.
1 reply →
Okay and how do we stop killing each other?
4 replies →
Building drones is very easy from a base requirement point of view.
And the components are easy to buy as most if not all have plenty of other use cases.
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.