I'm currently trying to replicate some HDLC messages received from a device, and I've managed to determine their entire contents except for the CRC. Consecutive messages are delimited by the standard HDLC 0x7E flag, and contain a 1B address, a 1B control section, a variable number of information bytes (between 4-8) and a 2B CRC-16 (I'm actually not certain that it's a CRC, but HDLC supposedly uses CRCs at the end of frames, and this 2B section varies exactly how you'd expect from a CRC). I've seen many other CRC-related questions on here, but I feel like I've exhausted the relevant methods I found there.
I've tried to guess what CRC it is just by running many known CRC-16 algorithms over the frame contents (excluding frame CRC) and seeing if the output matches the frame CRC. None of the CRC-16 algorithms offered in either of the fastcrc or reversebox Python modules succeeded. I tried all permutations of switching MSB/LSB and endianness in both the frame contents and CRC, and including/not including the flag in the CRC input. I then tried to use RevEng to guess the CRC, but to no avail (got lots of "no models found", but I may have been using it incorrectly...I can provide that code for reference if desired).
I'm not sure what else I can try: are there general methods for decoding CRC's? I'm new to CRCs, but I have a pretty strong background in math, so technical solutions are welcome. Otherwise, are there other good tools I've failed to find?
I may have done a check incorrectly at some point, so I'll provide a few sample messages (with flags removed, CRCs included as last 2 bytes):
476000008000f510
476000c0c100f591
4760000081000b6e
47600040c000c623
47600000800221f2d3
47600000800411377a
47600000800c190a7c61
47600000801c99b6990fbf
47600000801e7f7fffffe37e
To include the flag, the frames need to just be prepended by 7E. It's probably worth noting that the HDLC decoding involved undoing bitstuffing, but I tried a quick CRC check with bitstuffing left in and no avail.
Edit: @MarkAdler pointed out that the above frame-CRC combinations cannot fit any possible CRC. Are there any other types of 16-bit error detection codes that would be worth checking? I tried Fletchler's and BSD checksums, but they didn't seem to match.
It might be worth saying that the packets sent by the device consist of blocks of multiple frames at a time, back-to-back. They follow the pattern of:
- 1 "start" frame
- 5 "message" frames, all identical except for the last frame which has one bit in the information section toggled (and so the last 16b are changed as well, being some error detection code).
- 1 "end" frame
An example of one entire packet, split by the 7E delimiter, is:
00
476000008000f510
476000008000f510
476000008000f510
476000008000f510
4760100080002cc1
9fffffffff
Does this method of communication change what might be good guesses for how the error detection code is constructed? Alternatively, is this type of communication common for HDLC devices, and might that be a hint? I've done some pretty extensive Googleing, but with no success.