0
votes

If this kind of question is not allowed or suitable here I apologies and in such case please delete my question.

I’m trying to reverse engineer a protocol between two embedded devices. They send multicast UDP packets.

The payload part in a UDP-packet look like this:

00000000: 00 00 00 01 5d 28 52 c5 26 30 30 3a 30 32 3a 39 |....](R.&00:02:9|
00000010: 42 3a 39 33 3a 34 41 3a 38 34 26 31 32 39 26 31 |B:93:4A:84&129&1|

I have found that the payload part consists of

  1. The first 4 binary bytes always being: 00 00 00 01
  2. The next 4 binary bytes being some type of hash/crc32 (I guess) [above: 5d 28 52 c5]
  3. The next 1+17 bytes in plain text being a MAC-address [above: &00:02:9B:93:4A:84]
  4. The next 1+3 bytes in plain text being a command with value 128-136 [above: &129]
  5. The next 1+(1-3) bytes in plain text being a sequence number between 0-254 [above: &1]

The MAC-address could be either an always constant address like above (being the MAC-address of the receiving device of the multicast UDP-packets) or &FF:FF:FF:FF:FF:FF used like a broadcast when the receiving device is unknown.

Another example with the broadcast MAC-address (and another command value) looks like this:

00000000: 00 00 00 01 95 46 84 1e 26 46 46 3a 46 46 3a 46 |.....F..&FF:FF:F|
00000010: 46 3a 46 46 3a 46 46 3a 46 46 26 31 32 38 26 31 |F:FF:FF:FF&128&1|

Here the hash/crc is: 95 46 84 1e

The combination of the same MAC-address, the same command value and the same sequence number repeats in different UDP-packets with some time interval and will always result in the same hash/crc. So my guess is that the hash/crc in some way only depends on the value of the MAC-address, command value and sequence number.

I have tried a free windows hash/crc calculator called HashCalc from Slavesoft, but I can’t get the same hash/crc, even removing any combinations of ampersand and colon.

I also tried a hash algorithm called djb2 found here and here.

But I cannot figure out the hash/crc algorithm, and therefore I need some help from someone with more knowledge. I need help to first find the algorithm for how to calculate the 4 byte hash/crc based on the mac-address, command and sequence number.

Secondly when the algorithm is found I also need an implementation, preferably in Python.

Any help would be very much appreciated, also if you could just point me in the right direction for where to look and learn more.

I also have a small file (19 kB) with much more examples, but I don’t know how to attach that and if it’s necessary.

I would be very grateful for all the help I can get.

1
If it is some custom protocol, it could be either crc32, or adler32, or just anything, including even simple sum of the fields. Moreover, consider taking some long hash, say SHA-1, and leaving only 32 lowest bits of it. You can only guess, what it is, and find it by pure luck only.Matt

1 Answers

1
votes

You can use CRC RevEng to search for CRCs. This one turns out to be easy, as it is a standard CRC:

% ./reveng -w 32 -s 2630303a30323a39423a39333a34413a38342631323926315d2852c5   
width=32  poly=0x04c11db7  init=0xffffffff  refin=false  refout=false  xorout=0x00000000  check=0x0376e6e7  name="CRC-32/MPEG-2"

% ./reveng -w 32 -s 2646463a46463a46463a46463a46463a46462631323826319546841e
width=32  poly=0x04c11db7  init=0xffffffff  refin=false  refout=false  xorout=0x00000000  check=0x0376e6e7  name="CRC-32/MPEG-2"

This will compute that CRC:

#include <stddef.h>
#include <stdint.h>

#define POLY 0x04c11db7

/* Compute CRC of buf[0..len-1] with initial CRC crc.  This permits the
   computation of a CRC by feeding this routine a chunk of the input data at a
   time.  The value of crc for the first chunk should be 0xffffffff. */
uint32_t crc32c(uint32_t crc, const unsigned char *buf, size_t len)
{
    int k;

    while (len--) {
        crc ^= (uint32_t)(*buf++) << 24;
        for (k = 0; k < 8; k++)
            crc = crc & 0x80000000 ? (crc << 1) ^ POLY : crc << 1;
    }
    return crc;
}