10 years ago I "reverse engineered" the protocol of their controllers so that I could use it for …

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.

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.