Hacker News Reader

Comment by matsemann | Hacker News Reader

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/

View on HN

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?

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.

It's called DUML/DUSS, there's a lot of documentation about it in http://github.com/o-gs/dji-firmware-tools

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.

Reply on news.ycombinator.com