4

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.

Background

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.

FFFFFF030068000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000077CDDDE7A20

FFFFFF030069000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078221EDC040

FFFFFF03006A0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000785774B0FC0

FFFFFF03006B000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078B0C63AA00

FFFFFF03006C000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078E5A2D1920

FFFFFF03006D0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000791974997E0

FFFFFF03006E000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000079A775A4720

FFFFFF03006F000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000079D3AEC7440

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)

FFFFFF0507FF07FF40800000030000000010100001000000000000000000000000000000000000000000000000000000303A3130303A31300000000000000000313A3030313A30300000000000000000000000000000000000300032003301210039003A003B00380035009F00AB0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007F5F6C0

FFFFFF01546F70204D656E752020202020202020202020204C6F6164204672616D6573746F72652031362020202020202020202020202020202020202020202020202020202020202020202020202020202020202D2D2D2D2D2D2050414E454C202D2D2D2D2D2D20202D2D2D2D2D204B45594D454D202D2D2D2D2D2D202020736176652020202020726563616C6C20202020207361766520202020206F6E2F6F6666202064D63D40

FFFFFF0507FF07FF40800000030000000010100001000000000000000000000000000000000000000000000000000000303A3130303A31300000000000000000313A3030313A30300000000000000000000000000000000000300032003301210039003A003B00380035009F00AB0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007F5F6C0

FFFFFF07426C6B20504331205043322054696D6543616D3143616D33437574205353726346426631464266322020202020202020D7E2A640

UPDATE EDIT 1

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:

FFFFFF0301560000000000000000000000000000001F43333F3C0143330C6601431E0C060F430C0C3C01430C0C6001430C0C661F5F0C0C3C000000000000000000000000000000000000000000000E000000001B000000001B000000000E000000001B000000001B000000000E00000000000000000000000000000000006F686ABF4D60

FFFFFF03015700000000000000000000000000000000063E1F80000663318000060331800006031F8000060331800006633180003E3E318000000000000000000000000000000000000000000D7D4E1C3F0C0D4E1C630C0D5E36630C7D5E363F0C0D763E030C0D7663037D7D6663030000000000000000000000000000006F6874AEFEE0

FFFFFF03015800000000000000000000000000000007763161E00036316330003363303003736331E000336373000031461B3007714619E000000000000000000000000000000000000000000D7D4E1C3F0C0D4E1C630C0D5E36630C7D5E363F0C0D763E030C0D7663037D7D6663030000000000000000000000000000006F68FEEB80A0

FFFFFF03015900063E1F80000663318000060331800006031F8000060331800006633180003E3E318000000000001C39787EFC1C3B0D460C1E7B0D460C1E7B0C7E7C1B5B0D460C1B5B0D460C181979460C000000000000337B470000381B470000301B6F0000317B6F0000301B3B0000301B3B0000337B030000000000006F68FC406620

FFFFFF03015A00063E1F80000663318000060331800006031F8000060331800006633180003E3E318000000000001C39787EFC1C3B0D460C1E7B0D460C1E7B0C7E7C1B5B0D460C1B5B0D460C181979460C000000000000397D6380006C0D6380006C0D7780006C7D7780006C0D5D80006C0D5D8000397D418000000000006F688396C200

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.