7

I need help identifying the checksum algorithm in the following packets please.

So, packets format is:

sd ?? dd dd dd ??

where

s = start nibble d = data (binary coded decimal) ? = unknown - possibly checksum

Here are five packets (number being transmitted in brackets) and the actual packet sent on the wire in hex on the right.

(1112694): f1 f7 11 26 94 74

(5432432): f5 7c 43 24 32 a2

(6430116): f6 dc 43 01 16 48

(3254817): f3 d8 25 48 17 e9

(0042863): f0 ce 04 28 63 b2

I've tried XOR and summing but they dont seem to work. The packets are transmitted using UART.

any help appreciated!

user3780104
  • 173
  • 1
  • 8
  • 4
    How is this related to electronics? – pipe Mar 04 '16 at 14:23
  • What device is it? It might be just documented. – Eugene Sh. Mar 04 '16 at 14:35
  • It's not documented unfortunately, it's propriety. – user3780104 Mar 04 '16 at 14:36
  • There's numerous checksums out there, you can't even know if it is a CRC or something else. – Lundin Mar 04 '16 at 14:37
  • 3
    @pipe I would say it is. Communication protocols are more of EE than programmers stuff.. – Eugene Sh. Mar 04 '16 at 14:41
  • 1
    You'll need a lot more than five random samples to figure this out. To what extent can you control the contents of the transmission? For example, can you try sending 0000000, 0000001, 0000002, etc.? Such a pattern would provide a lot of clues. What does the data represent, anyway? – Dave Tweed Mar 04 '16 at 15:01
  • no sadly I cant control it I'm afraid. The data is just a unique identifier, like a transponder code. – user3780104 Mar 04 '16 at 15:05
  • Is the transmitted code unique for each number or does it change from one instance to the next? – Spehro Pefhany Mar 04 '16 at 15:12
  • 3
    It is my judgement that this question should not be closed. Almost any electrical engineer that has had their hands in embedded coding as part of their project has faced the problem of either getting a CRC code working for their project or reverse engineering a CRC from something that they have to connect to. Checking codes play a huge role in electronics whether those codes be generated and checked in hardware, FPGA or microcontroller firmware. – Michael Karas Mar 04 '16 at 15:25

1 Answers1

16

Take your first data row:

(1112694): f1 f7 11 26 94 74

Make a byte stream of hex numbers as:

0x94

0x26

0x11

0xF1

Run those bytes in that order through a CRC-CCITT (XModem) CRC algorithm to arrive at a CRC of 0xF774. The high byte of the CRC goes to the second position of the message and the low byte of the CRC goes to the last position of the message.

This same technique works for each of the messages in your sample. I used the online calculator to show the result as here:

enter image description here

The polynomial function for the CRC-CCITT algorithm is as follows:

enter image description here

I leave it to you to look up and find source code for the CRC-CCITT algorithm and understand the specific nuances of using that code in the old XModem methodology. The 0x1021 polynomial is well known and I have used it for years in my projects for everything from communications protocols to check codes on data sets stored in serial EEPROMs and FRAM chips. The usage nuances come into play as to whether the CRC fields of the packet are preset to something like 0x0000 or 0xFFFF and whether those preset fields are also passed through the CRC calculator to arrive at a result. Note that there is a plethora of information online.

Michael Karas
  • 56,889
  • 3
  • 70
  • 138
  • Well done! The calculator link could be useful. – Spehro Pefhany Mar 04 '16 at 15:29
  • Ha. Good work.. – Eugene Sh. Mar 04 '16 at 16:11
  • I love you. Seriously. Thank you so so much. I'd just started disassembling the firmware to work out how it was doing it!!!! – user3780104 Mar 04 '16 at 16:41
  • Hats off to you. I don't think I'd have looked for the MSB of the checksum in the second byte. That's pretty weird. And padding the msn with an F rather than a 0? – WhatRoughBeast Mar 04 '16 at 20:35
  • @WhatRoughBeast Maybe it's to guarantee a non-zero input value for the checksum? Regardless, this is stellar work on Michael's part. – Adam Haun Mar 04 '16 at 22:27
  • Wow thanks guys. I think I just got lucky. Although I have deciphered several CRCs in the past. The calculator at the linked site is so great because it shows results for many of the common coding algorithms. – Michael Karas Mar 05 '16 at 03:10
  • Michael, I'm just blogging about the whole protocol. Do you mind if I include your name as a thanks? – user3780104 Mar 06 '16 at 23:02
  • You can but it is a little disingenuous to take information from a Stack Exchange site and re-use it to author your own blog. If you have the time to write blogs maybe instead you could contribute to this site and make it a better place. – Michael Karas Mar 07 '16 at 04:29
  • Michael, I'm not sure I follow. I'm blogging about the whole protocol and the process of reverse engineering it for others seeking the info, and including a direct link to this post for help identifying the checksum... I'm not passing your/stackoverflow's help off as my own achievement! Nor am I reusing anything from stackoverflow, other than pointing out the name of the checksum algorithm and giving a link to here. It's a tutorial post and the checksum algorithm is only a very small part. – user3780104 Mar 07 '16 at 08:58
  • OK sounds good. Your further explanation surely clears up everything for me. – Michael Karas Mar 07 '16 at 13:20