DJI Protocol – Day 4 – Progress Report

We dived into a specific packet-type last time, but couldn’t extract each and every byte purpose. However, we were able to identify one important thingy: 0x00-0x01. Those two bytes indicate the packet’s content. Hence, now we are capable of assigning each sent packet (operator to drone) to a specific group, based on their unique identifier. This will hopefully create a better overview and will facilitate our future reverse-engineering process. In order to group packets, we came up with a .NET 5.0 console application, capable of reading .pcap files and extracting the most important bits.

using System;
using System.Collections.Generic;
using System.Diagnostics.CodeAnalysis;
using System.Linq;
using Tako.CRC;

public class NetworkPacket : IEqualityComparer<NetworkPacket>
{
    public NetworkPacket(byte[] data) => Data = data;

    public byte[] Data { get; init; }

    // 14 bytes
    public byte[] Ethernet => Data[0..14];

    // 20 bytes
    public byte[] IP => Data[14..34];

    // 8 bytes
    public byte[] UDP => Data[34..42];

    public byte[] Payload => Data[42..];

    public static string ToHexString(byte data) => ToHexString(new byte[] { data });

    public static string ToHexString(byte[] data) => string.Join(" ", data.Select(d => $"0x{d.ToString("X2")}"));

    public string Src => $"{(uint)Data[26]}.{(uint)Data[27]}.{(uint)Data[28]}.{(uint)Data[29]}";

    public bool Equals(NetworkPacket x, NetworkPacket y) => x.Data.SequenceEqual(y.Data);

    public int GetHashCode([DisallowNull] NetworkPacket obj) => HashCode.Combine(obj.Data);
}

public class DjiPacket
{
    private const EnumCRCProvider _crc_16_provider = EnumCRCProvider.CRC16Kermit;
    private static CRCManager _crc_manager = new CRCManager();

    public DjiPacket(byte[] data) : this(new NetworkPacket(data)) { }

    public DjiPacket(NetworkPacket networkPacket) => NetworkPacket = networkPacket;

    public NetworkPacket NetworkPacket { get; init; }

    public byte Id => NetworkPacket.Payload[0];

    public byte Length => NetworkPacket.Payload[0];

    public byte ProtocolVersion => NetworkPacket.Payload[1];

    public byte[] Session => NetworkPacket.Payload[2..4];

    public static byte[] CRC_16(byte[] data) => _crc_manager.CreateCRCProvider(_crc_16_provider).GetCRC(data).CrcArray;
}

Grouping packets based on their Id leads to following taxonomy:

To avoid yet another deep dive into the bits and bytes of each and every listed packet type, we try to provoke specific types of packets to be sent. E.g. moving the drone around its own axis should result in a “rotate” packet type request. As we don’t know which packet type relates to which input action, we require a statistic based approach. We setup two scenarios. 1.) Connect the drone for 20 seconds and provide zero input. 2.) Connect the drone and constantly move the drone in a circle for 20 seconds. Then we should see a higher occurance of the rotation packet type. In order to exclude unrelated packets, we apply following filter within wireshark:

ip.src == 192.168.12.139 && udp && !dns && !icmp && !mdns

Packets only occurring on idle control mode haven’t been listed within the table above, as they are likely not relevant. Upon a brief comparison, the packet type 0x38 seems to be of our interest. Conveniently its size is unique across all packets, such that we can investigate within wireshark directly.

* Might be: ACK/CMD/Type/Encryption/..?

The hard part of the reverse-engineering was by far the CRC checksum. The last two bytes did never equal, hence it had to be some kind of CRC. However, since the CRC’s poly-function, final XOR,… could be chosen arbitrary but fixed within the handshake, we had to bruteforce our way to the result. However, the bruteforce-crc didn’t return any useable values and thus, lead to the conclusion that the CRC might not cover the full payload. As the first 8 bytes yield the same content within each rotation-control packet, the CRC might not include the whole header of the payload. Therefore, we removed bit by bit as long as the CRC hasn’t been found. We concluded, that the bytes from 0x00 – 0x23 represent the header of the packet and isn’t refelcted within the payload’s CRC function.

The drone did only respond once to a rotation packet with the 0x35 byte set to 0x01. Hence, rotation packets do not require an acknowledgement from the drone. Assumption: the byte at position n – 2 might indicate whether the packet requires an acknowledgment. (n = payload-length)

Next up: DJI Protocol – Day 5 – Progress Report