After reading a lot of posts here and their solutions, Punching lines in CRC calculators for several days now. I can't seem to find on which Checksum this code is based.


This is a data snippet of serial communication between a Control panel and Mainframe of a videomixer of Echolab. Echolab went broke 7 years ago and there hardware is collecting dust for years. As a project to re-purpose the still good control panels to new hardware i need to interface a protocol converter to these panels.

I had already a different serie of their panels up and running. But these panels were from the last serie they have build. So, it seems they put a checksum on their commands. And, I need to manipulate the data inside of those strings so I need to figure out which checksum they used.









Here a sample of 8 messages that were sequential send.

FFFFFF is the header on ALL messages in the protocol followed by a message identifier [03] then a black byte followed by an address byte (68 - 6F in this case).

I picked these messages as the payload is completely empty. So i could show in this example that the Checksum does jump a lot..

077CDDDE7A20   Addr 68  
078221EDC040   Addr 69  
0785774B0FC0   Addr 6A  
078B0C63AA00   Addr 6B  
078E5A2D1920   Addr 6C  
0791974997E0   Addr 6D  
079A775A4720   Addr 6E  
079D3AEC7440   Addr 6F  

So with the change of only the Address number the checksum does change a lot. This tells me it is not a simple Xor or Add/count and Mod Checksum. So my guess is it is somewhere in the CRC domain?? But spending 2 days on online Checksum calculators like Scandacore and Defuse.. Trying a lot of different combinations with and without Header, Message ID, etc etc.. But i can't seem to find the right combination.. So i'm a bit lost on this one..

I ruled out that there is a timer inside the checksum. As messages re-apear at a later stage and still have the same checksum when the same payload is there.

Here are some messages with data in them. (you can see Message ID 05 gets repeated twice every set of messages)






So after the discovery of the 4 / 6 byte checksum. I went down deeper to find out why this is.

Burning half trough the night looking into and cleaning up (make it more readable) the source capture (1000+ lines) I could not get myself a satisfing anwser.

And while the mainframe that was used for this capture is a few weeks away, I needed to find myself a Mainframe.

Got a mainframe 2 hours drive from here this morning which was not exactly sure if it would work with my panel. As there could be a firmware difference between them.

And so there was! But in a good way! I don't have an empty message like we had before for easy comparison.. But the tailing makes a lot more clear about the build of the message. In particular the Checksum.
And so I also discovered that i was looking at the wrong piece of the checksum. (and missed out 2 bytes that should be included in the string for the Checksum.

First a few samples, below that some more description:






In these samples we have the following:

Header          FFFFFF  
Message Type    03    
Address double byte   0158  
Data   120 bytes big  
X number  6F68  Seems to be data    
Checksum  FEEB80A0   

The X number is new! This did change a bit with the other mainframe. But at this mainframe it stayed the same for all 346 messages that write an array to some LCD smart buttons. So the Checksum is indeed 4 byte.

Yesterday I toughed those 2 X number bytes were from the Checksum. And in the older samples the 1st character was a 0.. So i assumed they put a 0 in front and back of the Checksum..

Now we know the checksum is only 4 bytes. The thing that stands out is that it always ends with a 0. I think this is done on purpose.. As 4 bits Padding is a bit strange don't you think?

So after I post this message i will go re-do the CRC websites with this new knowledge. But I toughed want to update this post first.

  • There is something strange here. The empty messages appear to have a 6?-Byte checksum and the messages with data seem to have a 4-byte checksum, unless the empty messages are not empty – Nordwald Oct 13 '17 at 5:41
  • do you have access to the code which generates correct commands (Control panel) or checks them (Mainframe)? – Igor Skochinsky Oct 13 '17 at 8:43
  • Both are Hardware devices build based on Xilinx FPGA's. So unfortunatly there is no way in my opinion to do a code reverse engineering. – RevDaniel Oct 13 '17 at 11:59
  • @Nordwald Yes i discovered that too last night.. And after getting a different mainframe and new captures it got clear to me.. Added more info in the mainpost. Which does explain a bit more about that. – RevDaniel Oct 13 '17 at 13:00
  • to me the last two bytes before the checksum look to be a sequence number, i don't think they are part of the checksum – Willem Hengeveld Oct 13 '17 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.