crc

Determine CRC algorithm from recorded data

I have the following recorded command packets, 32 byte each:

3da89fc200180010000000000000000024100001240400010000000000000000 
d427eb5a00180010000000000000000024100001240300010000000000000000 
984870ff00180010000000000000000024100001240200010000000000000000 
4ab8076100180010000000000000000024100001240100010000000000000000 
06d79cc400180010000000000000000024100001240000010000000000000000

The first 4 bytes are supposed to be a "Ethernet CRC-32" checksum of the remaining 28 bytes. I want to create custom commands, so I need to figure out how to calculate the CRC.

I tried any variation of CRC32 that I can think of and even tried "reveng -w 32 -c " on the data given above, hoping to find the right CRC settings. No luck. I suspect there is some weird data reordering happening before and maybe even after the CRC calculation.

How can I approach this problem? Is there an automated way to try different permutations of the data?

Solution

  • Thanks Mark for the great input.

    I spent some more time looking into the rest of the message (excluding the CRC) and found that the data is ordered differently from what I expected. It is byte-swapped. I have seen that with other TI SPI code: they create the command packets as an array of uint32_t in little endian order, but have the SPI module configured for 16-bit transfers with MSB first.

    Value: 0x00012410

Memory Address   0     1    2    3
Memory Bytes     0x10  0x24 0x01 0x00
Memory Words     0x2410     0x0001

SPI Bytes        0x24 0x10 0x00 0x01

    So I byte-swapped the recorded packets to recreate the memory layout that was used to calculate the CRC. To make it work with reveng, I also moved the CRC to the end of the message as recommended by Mark.

    Reordered data:

    18001000000000000000000010240100042401000000000000000000a83dc29f
1800100000000000000000001024010003240100000000000000000027d45aeb
180010000000000000000000102401000224010000000000000000004898ff70
18001000000000000000000010240100012401000000000000000000b84a6107
18001000000000000000000010240100002401000000000000000000d706c49c

    Now, reveng confirms that it's a pretty normal CRC:

    ~/reveng-3.0.6/reveng -w 32 -s 18001000000000000000000010240100042401000000000000000000a83dc29f 1800100000000000000000001024010003240100000000000000000027d45aeb 180010000000000000000000102401000224010000000000000000004898ff70 18001000000000000000000010240100012401000000000000000000b84a6107 18001000000000000000000010240100002401000000000000000000d706c49c
width=32  poly=0x04c11db7  init=0xffffffff  refin=true  refout=true  xorout=0xffffffff  check=0xcbf43926  residue=0xdebb20e3  name="CRC-32/ISO-HDLC"