Integrity check / Checksum ?

[buffyslays]

Hi Thomas and community, two questions:

1. What is the purpose of checking the IntegrityId?

UInt32 reqIntegCheck = (UInt32)request.SequenceNumber + request.IntegrityId;
if (response.IntegrityId != reqIntegCheck)

Is the reason simply just to make sure the response is the correct response to the request? Or is there another reason we do this?

2. Do you know how to know if the controller's database has changed? I don't see a checksum request in your code, do you know if there is one? Or any other way to check? We need to know if anything has changed on the controller so that we know when to do another download/browse. It does not make sense in our case to redownload the tags and the tag information on each read or write.

Any info or advice is appreciated!

[thomas-v2]

For 1:
I just use it as additional check if all the previous data processing was correct, because the number of zero bytes between this field and the start of the trailer isn't always the same. Sometimes 4 or 5 bytes, I haven't found out why and when theres this difference. In Wireshark I fill when I'm at the end of processing the difference between the length in the header and the current position with the "Data unknown" to know when the trailer starts. I think it has nothing to do with any kind of integrity, I don't know why I've choosen this name. But the field was always in the protocol, even in the first generation of 1200 controller which hadn't any kind of authentication or digital signature.

For 2:
It should be possible to read the attribute ID 2479, which represents a change counter, for the object ID of the plc program (NativeObjects_thePLCProgram_Rid). As far as I know, the value should be incremented on every program change.

The protocol allows to create a CRC checksum for the symbol. For now I enter the value 0 into this field, means there's no checksum check in the plc. Otherwise the plc does check the CRC and you will get a read / write error if the value doesn't match. The CRC is calculated from the complete symbol path, with some specific value as delimiter. The latest version also adds the value for the datatype into the calculation, but that was not always the case as far as I can remember. But I guess that all TLS supporting controllers use the same calculation. For the CRC calculation the same generator polynom as in the Profisafe protocol is used.

[buffyslays]

Thanks Thomas, finally getting a chance to come back to this. When you say complete symbol path are you referring to this: [Item address sequence: 8A0E0001.A] ? If so, do you know if it is this value: "0x8a0e0001" that is used or the hex value from the server: "88d0b88001"?

I also see that in the initial download of the tag information (explore request/response), the tags do have a SymbolCrc associated with them. It appears to be a different value than what is used in the read/write requests. Do you know more about this?

Any further details on this calculation would be greatly appreciated!

[thomas-v2]

0x88d0b88001 is the value 0x8a0e0001 variable length encoded (VLQ). This encoding should shorten the transmitted bytes on the wire if you have for example in 32 bit integerst mostly low numbers. For fixed encoding value of 1 would take 4 bytes, with the variable length encoding only 1 byte. In this case the encoding takes one more byte than the fixed encoding would need.

As said, I don't transfer the symbol crc in my read or write requests. Did you use Wireshark with the S7commplus plugin to analyze this? I should show the field for "Symbol CRC" directly. On the wire it's only one byte with 0x00, as it's also variable length encoded. I haven't checked if the checksum from browsing the plc can be used directly in accessing the variable value.

[buffyslays]

Yes, I am using Wireshark to analyze. I did figure out that 0x8a0e0001 is the VLQ of 0x88d0b88001. What I am unsure of is, is this the value that you are referring to when you say the polynomial includes the complete symbol path? I imagine that the complete symbol path is the access base area (0x8a0e0001) plus each LID value for that tag, the "Item address sequence" as it's referred to in Wireshark. Is this right? My second question around this is, do you know if the hex value or the VLQ value is what is used to calculate the SymbolCrc? I know that your driver is currently using 0 in that field, just wondering if you happen to know more about the polynomial. I know it's probably a long shot but thought I'd ask!

I got the initial symbolCrc from the explore response with all the tag information. I am using Wireshark to read the wire of another driver as well. That driver has the symbolCrc for the tag, so I know what it is supposed to be for that tag (as long as there are no changes to the plc). I was wondering if you have any information regarding the differences of these values? It makes me wonder if that initial SymbolCrc is also part of the calculation.

The photos below help explain what I am referring to.

SymbolCrc for tag "myInt1" from the explore response, your driver:

SymboCrc for same tag "myInt1" from the getmultivariable request in a different driver:

I know the server is expecting the symbolCrc from the getmultivariable request because I don't get an error and am able to read the tag value.

Anyway, I know this isn't currently part of your driver but just thought I'd try! Figuring out the calculation is starting to feel impossible. Thanks again for your responses and for sharing your hard work!

[thomas-v2]

As written above, the polynomial used here is the same as in the Profisafe protocol. The delimiter which needs to be added can be found by brute force. I don't know if I have checked if and what must be added to the symbol CRC from browsing the plc to get the access CRC. I guess it's the datatype, as this wasn't included in the CRC in the first versions of the protocol (where I may be have checked this). Siemens has tried to release a patent on this (EP2246757A1) but it's withdrawn. I've heard some US PLC manufactures did this first.

I'll try to add at least a method to get the CRC for a symbol path. From what I've seen, most 3rd party drivers don't use the symbol CRC, and I believe it's not because they don't know how to do this.

[thomas-v2]

I've made some tests. For simple variables the calculation is:
DBNAME.VARNAME
ACCESSCRC = CRC(CRC(VARNAME + DATATYPE))

If the datatype is Int, then you need to add a byte with value 5, for word 4 and so on.
The CRC which is transmitted by the Plc via browsing, is CRC(VARNAME + DATATYPE). Thus if you do a CRC from the browse result, you get the access CRC. For variables in the M/Q/I area this works as well.

But if you have a struct or UDT it's different.
DBNAME.STRUCTNAME.VARNAME
From browsing the plc you get the CRC for only the STRUCTNAME and as DATATYPE you have to add a 17.
The browse result for VARNAME is only valid for the name and datatype of the VARNAME.

I think it was 7-8 years ago, when you just needed to add a 0x09 as delimiter between STRUCTNAME and VARNAME, which I just have tried out in a loop until I got the correct CRC -> CRC(CRC(STRUCTNAME + 0x09 + VARNAME + DATATYPE)). But this doesn't work anymore. I've tried some other versions and values but without success.

Example:
DB_TestCRC.TestStruct1.Int1, where Int1 is of type Int inside the struct TestStruct1.
The Explore results are: TestStruct1 = 0x26b869b5, Int1 = 0x22f3c385.
And to get access to the variable the CRC 0x61ab03f3 is used.

For array I haven't tested this yet.

Do you need this feature, or what improvement do you expect from using the checksum? I wasn't aware that the datablock name does not go into the checksum calculation, which feels for me some kind of incomplete.

[buffyslays]

We are looking for the best way to detect tag changes on the controller side, to avoid reading / writing the wrong values or getting a device exception.

Reading the controller attribute 2479 does the check accurately but requires an extra transaction. The Symbol CRC seems to be a more efficient way to detect changes but appears to be incomplete, this could be the way to go but will require an extensive amount of trial and error testing. Or, do you know how (if possible) to send multiple COTP packets in one request? Can we send the explore request to read the controller attribute in the same transaction as the getMultiVar request?

As far as the SymbolCRC goes, I am having trouble getting the initial browse CRC (sumsymbol CRC?) by using the VARNAME and DATATYPE. For instance, my tag myINT1 is an int (0x05) has the Subsymbol CRC: 0x040de366. Using the polynomial 0xF4ACFB13 I am unable to replicate how VARNAME + DATATYPE = 0x040de366. Are we using the right polynomial?

[thomas-v2]

My base crc method I'm using is:

public static UInt32 GetCrc(byte[] data) { UInt32 mask = 0xF4ACFB13; UInt32 crc32 = 0; int i; int j; byte x; for (i = 0; i < data.Length; ++i) { x = data[i]; for (j = 0; j < 8; ++j) { if ((crc32 & 0x80000000) == 0) { if ((x & 0x80) == 0) { crc32 <<= 1; } else { crc32 = (crc32 << 1) ^ mask; } } else { if ((x & 0x80) == 0) { crc32 = (crc32 << 1) ^ mask; } else { crc32 <<= 1; } } x <<= 1; } } return crc32; }

Then to get the first checksum I use:
List<byte> b = new List<byte>(); b.AddRange(Encoding.ASCII.GetBytes(stringSymbol)); b.Add(softdatatype); crc = GetCrc(b.ToArray());
This should be the checksum you get via browing the plc, for all variables of simple datatype (not array and not inside of a struct/udt). To get the access checksum for reading/writing the variable, just put the bytes of the checksum again through the crc method.