Reverse engineering unknown CRC

0
votes

I'm trying to reverse engineer a CRC. When I calculate the CRC-16 for the data, it is very similar to the crc send with the data, but not exactly equal.

What is the best way to find out the exact way to calculate this CRC? Can it be that another polynomial is used here or maybe another inital value?

Here are some packets with their own CRC compared to CRC-16:

Packet           CRC    CRC-16  Difference
118080009A28C0 - 603D   6021    28
918080009A28C0 - A8BD   A8A0    29
518080009A28C0 - A47D   A460    29
D18080009A28C0 - 6CFD   6CE1    28
318080009A28C0 - A27D   A200    125
B18080009A28C0 - 6AFD   6A81    124
718080009A28C0 - 6665   6641    36
F18080009A28C0 - AEE5   AEC0    37
098080009A28C0 - 61BD   61B9    4
898080009A28C0 - A93D   A938    5
C98080009A28C0 - 6D7D   6D79    4
298080009A28C0 - A39D   A398    5
A98080009A28C0 - 6B1D   6B19    4
698080009A28C0 - 67DD   67D9    4
B1808800372880 - BAFD   BAF0    13
E18080009A28F8 - BDDD   BDD0    13  
118080009A28FE - B0BD   B0A0    13
8080D728D72880 - 224C   224C    0   
80803728372880 - 02CC   02CC    0   
80803928392880 - 00C4   00C4    0   
8080B928B92880 - 36C4   36C4    0   
8080D728D72846 - 70CC   70CC    0   
80803728372846 - 504C   504C    0   
718080009A28C0 - 6665   6641    36
718080009A28FC - 7765   7741    36
F18080009A28C0 - AEE5   AEC0    37
F18080009A28FC - BFE5   BFC0    37
098080009A28C0 - 61BD   61B9    4
098080009A28FC - 70BD   70B9    4
898080009A28C0 - A93D   A938    5
898080009A28FC - B83D   B838    5
498080009A28FC - B4FD   B4F8    5
C98080009A28C0 - 6D7D   6D79    4
C98080009A28FC - 7C7D   7D79    4
298080009A28C0 - A39D   A398    5
298080009A28FC - B29D   B298    5
A98080009A28C0 - 7B1D   6B19    4
A98080009A28FC - 7A1D   7A19    4
698080009A28C0 - 67DD   67D9    4   
698080009A28FC - 76DD   76D9    4

It seems that CRC-16 is the right algorithm, but next to that there's a small change in de value. It seems to be based on the first to hex digits of the data or maybe even the first part of the CRC.

2
checksumcrccrc16
The easiest way is to look at the code that calculates the CRC. My best efforts at using CRC RevEng ( reveng -w 16 -s 603dc0289a00808011 a8bdc0289a00808091 a47dc0289a00808051 6cfdc0289a008080d1 ), as suggested here, suggest that it is not any normal variant on the standard CRC (init values, polys, final XOR). It's possible that there is a bug in the implementation of a standard CRC... or they intentionally do something subtly odd. – hcs
I think they indeed do something subtly odd. I've tried reveng and I didn't get results when using more than 2 packets. – Douwe66
Another possibility is they initialize the starting CRC value to a non-zero value, and that is equivalent to pre-pending a byte to the input stream, or possibly adding a byte to the end of the stream. – Ryan

2 Answers

0
votes

It is likely that you misidentified the location of one of the CRC bytes. The fact that one byte of the CRC always agrees with your CRC-16 strongly suggests that you have the correct CRC algorithm.

0
votes

Do you have the right implementation of CRC16. There exist several different versions of CRC16. For example the wikipedia lists up CRC16-IBM, CITT, DNP, VÖV and some others. Also it can be a big little problem or the CRC is sampling.