DJI Protocol – Day 3 – Progress Report

Within the last post we were able to find the termination sequence for rather large UDP packets. However, we decided to change the direction of our analysis from drone-to-client packets to client-to-drone packets, as they carry a much smaller payload and may provide a better foundation for the overall reverse-engineering process.

Besides the AES encryption we circumvent via MIT, the payload itself might still be encrypted with some kind of cipher, as state of the art security measurements would suggest. Therefore, we assume that the client and drone might use symmetric encryption, initialized via. diffie-hellman, elliptic curve or RSA. Before we start searching for the key-exchange UDP packets, we want to ensure that the protocol does indeed use payload encryption in first place. Hence, we will search for recurring patterns within sent packages. For that purpose we decided to analyse a frequently sent packet: 75 bytes in total, 33 bytes payload only. Occurrence: Here and there

We simply compare two sent packets and try to obtain any hints of encryption. It is quite safe to assume that no encryption is present, as both packets are too similar. Recurring patterns are present and the differences don’t indicate any usage of AES ECB encryption. We continue to analyse the payload structure with a static and dynamic (live-feed data) analysis:

0x001Packet Identifier / Packet Length – All packets with an ethernet frame-length of 75 bytes start with the static byte sequence of: 0x21
0x011Protocol Version
0x02 – 0x032Session Identifier – Unique for each connection
0x04 – 0x052Counter – increments by 8. Little endian byte order
0x0C – 0x0F4Padding – Zero bits
0x0C – 0x102Packet Counter – None-exclusive global packet counter
0x12 – 0x132Padding – Zero bits
0x14 – 0x1B8???
0x1C1??? 0x40
0x1D – 0x0E2???
0x1F – 0x202CRC-16 – KERMIT

Next up: DJI Protocol – Day 4 – Progress Report

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

[…] Heartbeat […]

[…] dived into a specific packet-type last time, but couldn’t extract each and every byte purpose. However, we were able to identify one […]