DJI Protocol – Day 2 – Progress Report

The first impressions while investigating the dump file were quite confusing. Several DNS requests against DJI domains have been sent, which led me to this interesting article. Without further research, one may assume that data could be collected and sent to those specific remote servers. Candidates: Statistics about the app performance, crash reports and fly-safe zone updates.

However, this might be worth investigating at a later point in time. Focusing on the packets itself, it it quite noticable that the drone sends, compared to the client, packets with a max. size of 1472 bytes. The max. Ethernet MTU size equals 1518 bytes: 14 bytes header, 1500 bytes payload and 4 bytes of FCS. Thus, when we substract the UDP header, with a length of 8 bytes, from the max. payload size, we end up at 1472 bytes. So maybe, due to the size limitation, one actual data-packet, interpretable by the client application, might consist of n + 1 UDP packets (from now on called: application layer data; ALD), whereas n equals packets of size 1472 bytes. (See different color separated entries) Moreover, it is quite safe to assume that those packets include camera updates. Sticking to this assumption, we require to find following information within our dump

  1. Payload size, spanning several UDP packets OR
  2. Termination sequence, indicating end of stream

According to our theory each packet chunk (e.g.: 135 – 137) has to start with its actual combined payload size. Hence, packet number 135 has to contain the total size of: 1472 bytes + 1472 bytes + 1468 bytes = 4412 bytes = 113CH. Neither packet number 134 nor 135 contains such a length information within the payload.

Our second theory depends on a magic binary sequence, indicating the end of a binary stream. With that said, we only require to compare the last packet of two different ALD sequences. And vola, each ALD terminates with: 0x00 0x00 0x00 0x01 0x09 0x10. Proven our point, it does make sense over our first theory. A lost UDP packet won’t corrupt future transmissions – worst case: The termination sequence packet gets lost.

Next up: DJI Protocol – Day 3 – Progress Report

0 0 votes
Article Rating
Subscribe
Notify of
2 Comments
Most Voted
Newest Oldest
Inline Feedbacks
View all comments

[…] Next up: DJI Protocol – Day 2 – Packet Inspection […]

[…] the last post we were able to find the termination sequence for rather large UDP packets. However, we decided to […]