search

proto17 / dji_droneid

MIT License
370 stars 85 forks source link

Ocusync 4 cannot be resolved #50

Open wanhongwu1998 opened 5 months ago

wanhongwu1998 commented 5 months ago

Hello, thank you very much for your sharing. Our research has found that this burst does not exist in LightBrige technology, so it is impossible to parse such a drone. In addition, although the burst can be found in Ocusync 4 technology and the constellation image can be demodulated successfully, the signal of the drone cannot be solved, as it seems to be encrypted. I wonder if you have encountered the same problem in the future.

proto17 commented 5 months ago

I have not done any work with newer drones. If you have a collect that you're willing to share I would be happy to have a look (keeping in mind your physical location could be present in the collect!), but the only drone I have is a Mini 2. If the constellation comes out clean and you get data back then I would suggest looking at that data with a hex editor to see if there are any strings present. IIRC the serial number of the drone shows up in the demodulated output. If you see that serial number in the output then you can be pretty sure that the link isn't encrypted. It could be that the CRC changed, or that the format of the demodulated output changed. But it's definitely still possible that the link has been encrypted. There's been lots of calls for that to happen.

It could also be that you have a really noisy collect that's failing to properly demodulate. The process_file.m script doesn't output the frame hex if the CRC fails. You can change this by commenting out [1]. Doing so will output the hex for all frames even if they are not valid according to the CRC.

Good luck!

[1] https://github.com/proto17/dji_droneid/blob/main/cpp/remove_turbo.cc#L156

wanhongwu1998 commented 5 months ago

Thank you for your reply. I'm sorry that it is not convenient to export the data I collected to you! To be sure, CRC was successful, so I'm more confident that the format of the demodulated output changed or was encrypted.

jianjianliu0918 commented 5 months ago

Thank you for your reply. I'm sorry that it is not convenient to export the data I collected to you! To be sure, CRC was successful, so I'm more confident that the format of the demodulated output changed or was encrypted.

DJI officially said it was encrypted, but recently a company claimed it had successfully decrypted it.

wanhongwu1998 commented 5 months ago

Thank you for your reply. I'm sorry that it is not convenient to export the data I collected to you! To be sure, CRC was successful, so I'm more confident that the format of the demodulated output changed or was encrypted.

DJI officially said it was encrypted, but recently a company claimed it had successfully decrypted it.

I doubt they can parse encrypted data. If encrypted data can still be parsed, then DJI's engineers are useless, and of course it doesn't rule out that they have superior abilities or have some special deal with DJI.

ozymandiasleo commented 3 days ago

Hello, thank you very much for your sharing. Our research has found that this burst does not exist in LightBrige technology, so it is impossible to parse such a drone. In addition, although the burst can be found in Ocusync 4 technology and the constellation image can be demodulated successfully, the signal of the drone cannot be solved, as it seems to be encrypted. I wonder if you have encountered the same problem in the future.

Did you revolve ocusync 3.0 ?

alphafox02 commented 3 days ago

Even if the signal can’t be decrypted, there’s still value in knowing it exists. If a drone signal is within range of your receiver, and you deploy additional receivers positioned at strategic distances, maybe you could triangulate the signal’s location based on the strength detected by each sensor.

This assumes the signal can still be identified, even if it’s encrypted. I believe the AntSDR e200 firmware works similarly—it detects encrypted signals and flags them as such, without decoding the contents.