2

I'm trying to understand how is calculated the CRC at the end of a radio packet.

Here are a few examples:

  • 11 00 01 0D 30 10 05 1F 11 ED 7E 01 00 01 B9 33
  • 11 00 01 0D 30 10 05 1F 11 ED 7E 01 00 00 B9 32
  • 11 00 01 1D 30 10 05 1F 11 ED 7E 01 00 00 EA CC
  • 11 00 01 2D 30 10 05 1F 11 ED 7E 01 00 00 1E CE

The 4th byte is a sequence number. All other bytes are constant. The last 2 bytes definitely look like a CRC16, as these are the only ones changing when the sequence byte increases. The last 2 bytes are not related to the time, as I can reproduce that exact same sequence anytime.

Here are a few more examples, from the same device but with a different command:

  • 16 00 01 60 20 10 05 1F 11 ED 7E 01 02 00 04 00 02 00 65 32 CC
  • 16 00 01 CB 20 10 31 53 11 ED 7E 01 42 00 04 00 02 00 65 B4 B9

This time again, the last 2 bytes look like a CRC16.

I've tried many CRC calculations, using online calculators like crccalc.com. I've also used the RevEng tool, but got no results.

I can't figure out the method of calculation, so I must be missing something. Any help to determine the calculation would be welcome. Thanks!

Guillaume
  • 33
  • 5

1 Answers1

1

It is the CRC-16/XMODEM, computed on your examples with the first three bytes and the last two bytes before the CRC removed, and then, oddly, that CRC exclusive-or'ed with the two bytes that precede it (those that were excluded from the CRC calculation). The resulting 16-bit value is appended in big-endian order.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • You're 100% right. Using CRC16/XMODEM, then XOR on those bytes is always correct for each packet I've tested. I'm impressed you came up with the solution so quickly for such an odd "encryption". Many thanks! – Guillaume Jan 24 '23 at 05:17