Question regarding the calculation method of SymbolCRC in ItemAddress

[lircy]

Hello,

First, thank you for your great work on the S7CommPlusDriver project. It has been an invaluable resource for understanding and working with the S7CommPlus protocol.

I'm currently studying the ItemAddress class and have a question about the SymbolCRC property. Throughout the codebase, I've noticed that SymbolCRC is only ever initialized with a value of 0, and I couldn't find any logic that calculates or sets this property to a non-zero value.

Could you please clarify:

What is the intended purpose of the SymbolCRC property in the S7CommPlus protocol context?
How is the SymbolCRC value supposed to be calculated?
Is there a specific algorithm or reference for generating this CRC value?
If this functionality isn't yet implemented, are there any plans to add it in the future?
Understanding how this CRC should be calculated would be very helpful for ensuring protocol compliance, especially when accessing symbolic addresses or dealing with more advanced PLC data structures.

Any insights or documentation references you could provide would be greatly appreciated.

Thank you for your time and contribution to the open-source community.

Best regards,
lircy

[thomas-v2]

The idea behind this is from what I think, when a variable name is changed in the plc, then you won't read possible wrong values. For example, there's a variable TempBottom which you can read with the corresponding Id sequence. You calculate the checksum from the symbolic name, add this to the request and you'll get the value. If the plc programmer would change TempBottom to TempTop, the Id would still be the same, but the symbol name checksum would be wrong, and the read request would fail.

The checksum algorithm has changed with the TIA portal version. But I believe in all TLS supporting Plcs it's the same. It's a 32 bit CRC which uses the generator polynom of the Profisafe protocol. The datablock does not go into the checksum. Then you concatenate the symbolic names, as struct delimiter "." you use the value 0x09 instead. And at the end you add the byte for the datatype (e.g. 0x05 for Int). And if I remember correctly, you must run the result again through the crc method.

If you browse the Plc it answeres with the calculated checksum, which you also can use for access instead of calculate it on your own.

If you enter the value 0 for the crc as I'm doing this now, then the checksum is ignored.

[lircy]

Thank you for your detailed explanation about the SymbolCRC calculation in your previous response. It was very helpful in understanding the purpose and algorithm behind this checksum. Based on your mention that "when you browse the Plc it answers with the calculated checksum, which you also can use for access instead of calculate it on your own," I have a follow-up question: In the PLC browse response data structure, which specific part contains this pre-calculated SymbolCRC value, and what is the proper way to parse it? Looking at the current S7CommPlusDriver codebase, I can see various response structures in the browsing functionality, but I'm not sure which field corresponds to the SymbolCRC. Could you please point me to: 1. The specific response class/structure that contains the SymbolCRC value during PLC browsing 2. The field name or byte offset where this CRC32 value is located in the response data 3. Any parsing logic needed to extract this value (endianness, data type, etc.) For example, is it in: * BrowseResponse class? * VariableInfo or SymbolInfo structures? * A specific attribute in the response packet? * A particular byte range that needs special interpretation? Having this information would be extremely valuable for implementing proper symbolic address validation and avoiding the need to recalculate the CRC locally.

…

________________________________ 发件人: thomas-v2 ***@***.***> 发送时间: 2025年10月29日 18:51 收件人: thomas-v2/S7CommPlusDriver ***@***.***> 抄送: lircy ***@***.***>; Author ***@***.***> 主题: Re: [thomas-v2/S7CommPlusDriver] Question regarding the calculation method of SymbolCRC in ItemAddress (Issue #73) [https://avatars.githubusercontent.com/u/63162188?s=20&v=4]thomas-v2 left a comment (thomas-v2/S7CommPlusDriver#73)<#73 (comment)> The idea behind this is from what I think, when a variable name is changed in the plc, then you won't read possible wrong values. For example, there's a variable TempBottom which you can read with the corresponding Id sequence. You calculate the checksum from the symbolic name, add this to the request and you'll get the value. If the plc programmer would change TempBottom to TempTop, the Id would still be the same, but the symbol name checksum would be wrong, and the read request would fail. The checksum algorithm has changed with the TIA portal version. But I believe in all TLS supporting Plcs it's the same. It's a 32 bit CRC which uses the generator polynom of the Profisafe protocol. The datablock does not go into the checksum. Then you concatenate the symbolic names, as struct delimiter "." you use the value 0x09 instead. And at the end you add the byte for the datatype (e.g. 0x05 for Int). And if I remember correctly, you must run the result again through the crc method. If you browse the Plc it answeres with the calculated checksum, which you also can use for access instead of calculate it on your own. If you enter the value 0 for the crc as I'm doing this now, then the checksum is ignored. ― Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKXJSGOVY2TS6MUUDKM4OHD32EEDNAVCNFSM6AAAAACKRST4XSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINRTGI3DKNJSGM>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[lircy]

I've made progress and can now successfully extract the SymbolCRC values from the PLC browse response data structure. However, I'm encountering an issue when using these extracted SymbolCRC values to access symbolic variables - the PLC returns a "CRC invalid" error. To investigate further, I used ACCON-AGLink software to access the same symbolic variables and captured the network traffic. The CRC32 values used by ACCON-AGLink in its successful requests are different from the SymbolCRC values I'm extracting from the browse response in S7CommPlusDriver. This suggests there might be one of several issues: 1. Incorrect parsing of the SymbolCRC from the browse response in S7CommPlusDriver 2. Different CRC calculation method used for access vs what's returned in browse 3. Additional processing needed on the browse-response CRC before using it for access 4. Version differences in how the CRC is handled What I've verified: * I'm correctly parsing the browse response and extracting what appears to be CRC values * The data types and symbolic names match between my tests and ACCON-AGLink * The issue is consistent across multiple variables Questions: 1. Could there be a bug in how S7CommPlusDriver extracts SymbolCRC from browse responses? 2. Is the CRC value from the browse response meant to be used directly for variable access, or does it need transformation? 3. Are you aware of any differences between how different TIA Portal versions handle these CRCs? 4. Have you successfully used browse-response CRCs for variable access in your testing?

…

________________________________ 发件人: thomas-v2 ***@***.***> 发送时间: 2025年10月29日 18:51 收件人: thomas-v2/S7CommPlusDriver ***@***.***> 抄送: lircy ***@***.***>; Author ***@***.***> 主题: Re: [thomas-v2/S7CommPlusDriver] Question regarding the calculation method of SymbolCRC in ItemAddress (Issue #73) [https://avatars.githubusercontent.com/u/63162188?s=20&v=4]thomas-v2 left a comment (thomas-v2/S7CommPlusDriver#73)<#73 (comment)> The idea behind this is from what I think, when a variable name is changed in the plc, then you won't read possible wrong values. For example, there's a variable TempBottom which you can read with the corresponding Id sequence. You calculate the checksum from the symbolic name, add this to the request and you'll get the value. If the plc programmer would change TempBottom to TempTop, the Id would still be the same, but the symbol name checksum would be wrong, and the read request would fail. The checksum algorithm has changed with the TIA portal version. But I believe in all TLS supporting Plcs it's the same. It's a 32 bit CRC which uses the generator polynom of the Profisafe protocol. The datablock does not go into the checksum. Then you concatenate the symbolic names, as struct delimiter "." you use the value 0x09 instead. And at the end you add the byte for the datatype (e.g. 0x05 for Int). And if I remember correctly, you must run the result again through the crc method. If you browse the Plc it answeres with the calculated checksum, which you also can use for access instead of calculate it on your own. If you enter the value 0 for the crc as I'm doing this now, then the checksum is ignored. ― Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKXJSGOVY2TS6MUUDKM4OHD32EEDNAVCNFSM6AAAAACKRST4XSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINRTGI3DKNJSGM>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[rbmafra]

I have not used this protocol in a long time now, but I have worked deeply with symbolic addresses, I remember seeing extra bytes in the address referencing the symbolic, it was the CRC, so, I assume we are talking about the same thing, one place where you can check this address with the CRC is WinCC Explorer.

[rbmafra]

I compared the CRC extracted from the HMI file, and the one in WinCC Explorer. They are not the same, so I am not sure, I never had to use those values for anything, that is all I know.

I am not even sure, if those bytes really represent the CRC.

[thomas-v2]

The crc you get from browsing the plc, must be run again through the crc generator, then you get the crc for the access.

[lircy]

Hi @thomas-v2 and @rbmafra, Thank you both for your continued guidance on this SymbolCRC issue. @thomas-v2, your latest clue is very helpful - "The crc you get from browsing the plc, must be run again through the crc generator, then you get the crc for the access." This explains why the browse-response CRC values don't work directly. However, I need some clarification on the practical implementation: Questions about the CRC regeneration process: 1. What exactly does "run again through the crc generator" mean? * Should I take the 4-byte CRC value from the browse response and pass it as input to the same CRC32 algorithm? * Are there any modifications needed (byte order, initial value, final XOR) for this second pass? 2. Could you provide a code example or pseudocode? For example: csharp uint browseCrc = GetFromBrowseResponse(); // The CRC from PLC browse uint accessCrc = Crc32Generator(browseCrc); // How exactly? 3. Is this a one-time transformation or does it involve additional data? @rbmafra, regarding your suggestion to test with WinCC - I've actually used ACCON-AGLink as a reference implementation and found something very revealing: When I extract the CRC values from ACCON-AGLink's successful network packets and use them directly in S7CommPlusDriver, the variable access works perfectly. This confirms that: * The CRC algorithm itself is correct in my implementation * The issue is specifically with how we're processing browse-response CRCs * ACCON-AGLink is either calculating the CRC differently or applying the same "second pass" that @thomas-v2 mentioned What I've verified: * My CRC32 implementation matches ACCON-AGLink's when calculating from scratch * The browse-response CRC values need transformation before use * ACCON-AGLink's transformed CRCs work flawlessly in S7CommPlusDriver Next steps I need help with: Could you @thomas-v2 provide more specific details about the CRC regeneration process? Even a rough algorithm outline would be tremendously helpful. Alternatively, if either of you have packet captures showing both the browse response and subsequent variable access for the same symbol, that would help me reverse-engineer the transformation. Thank you both for your expertise and time - we're getting very close to solving this!

…

________________________________ 发件人: thomas-v2 ***@***.***> 发送时间: 2025年10月30日 21:04 收件人: thomas-v2/S7CommPlusDriver ***@***.***> 抄送: lircy ***@***.***>; Author ***@***.***> 主题: Re: [thomas-v2/S7CommPlusDriver] Question regarding the calculation method of SymbolCRC in ItemAddress (Issue #73) [https://avatars.githubusercontent.com/u/63162188?s=20&v=4]thomas-v2 left a comment (thomas-v2/S7CommPlusDriver#73)<#73 (comment)> The crc you get from browsing the plc, must be run again through the crc generator, then you get the crc for the access. ― Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKXJSGNYMDYHLSO2FWDRTKL32J4M5AVCNFSM6AAAAACKRST4XSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINZQGIZDOOBUHE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jogibear9988]

There seem to be 2 Versions of the CRC.
There is a TypesafeAddressCRCProvider (lives in Siemens.Automation.DomainServices Assembly), but it has 2 Versions of the CRC Calculation. Don't know when wich is used.
I can read this info wich CRC in the TIA Project from a Property of the CPU:

see: LocalIdentifierCRCVersion

[jogibear9988]

I've now looked into a few projects, also some 1500 PLC in TIA V13 from year 2017 seem to use CRC Version 2.

But I've now actual 1200er PLC Project.
I only have one from TIA V11 (a siemens sample project), and this CPU seems to use CRC V1:

[lircy]

Hi @jogibear9988, Thank you for looking into this and sharing your findings about CRC Version 2 in TIA V13 with 1500 PLCs! That's really valuable information. Since you've researched multiple projects and have hands-on experience with both 1500 and 1200 PLCs, I'm wondering if you might have any concrete implementation code or algorithm details for this CRC Version 2? Specifically, I'd be very interested to know: 1. Do you have any code snippets (in any language) that show how CRC Version 2 is calculated? 2. What are the key differences between CRC Version 1 and Version 2 that you've observed? 3. How did you determine which CRC version a particular PLC/project uses? 4. In your 1200 PLC project, which CRC version is being used and have you successfully implemented symbolic access? Any code examples, polynomial details, or even pseudocode would be incredibly helpful. I'm particularly stuck on the "run the CRC through the generator again" transformation that @thomas-v2 mentioned. Your expertise with multiple PLC types and TIA versions would be tremendously valuable in solving this puzzle! Thanks in advance for any implementation details you can share.

…

________________________________ 发件人: Jochen Kühner ***@***.***> 发送时间: 2025年10月31日 5:38 收件人: thomas-v2/S7CommPlusDriver ***@***.***> 抄送: lircy ***@***.***>; Author ***@***.***> 主题: Re: [thomas-v2/S7CommPlusDriver] Question regarding the calculation method of SymbolCRC in ItemAddress (Issue #73) [https://avatars.githubusercontent.com/u/364896?s=20&v=4]jogibear9988 left a comment (thomas-v2/S7CommPlusDriver#73)<#73 (comment)> I've now looked into a few projects, also some 1500 PLC in TIA V13 from year 2017 seem to use CRC Version 2. But I've now actual 1200er PLC Project. I only have one from TIA V11 (a siemens sample project), and this CPU seems to use CRC V1: image.png (view on web)<https://github.com/user-attachments/assets/cd5fb566-85f9-4618-85ee-40c9e36c5dac> ― Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKXJSGP6FGP25NG46V2D52L32LYWBAVCNFSM6AAAAACKRST4XSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINZRGQYTKMJRG4>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jogibear9988]

Look into TypesafeAddressCRCProvider with IlSpy...
Don't know if there is the concrete implementation...

[jogibear9988]

Do you have any code snippets (in any language) that show how CRC Version 2 is calculated?

as i said, look with ilspy

What are the key differences between CRC Version 1 and Version 2 that you've observed?

don't know

How did you determine which CRC version a particular PLC/project uses?

I also don't know. I only lookt into TIA project files. Don't know how we get this info from the PLC.
Maybe it is hardcoded (1200 CRCv1, 1500 CRCv2). But it can also be firmware dependent, I don't know, I've no 1200 PLC.

In your 1200 PLC project, which CRC version is being used and have you successfully implemented symbolic access?

I've no 1200 PLC

[lircy]

Thank you so much for taking the time to look into my questions and provide detailed responses! I really appreciate your efforts and expertise, even though we haven't found the complete solution yet. Your insights into the CRC versions and PLC compatibility are valuable additions to our collective understanding of the S7CommPlus protocol. Sometimes the process of elimination and gathering information from multiple sources is exactly what's needed to eventually crack these protocol mysteries. I'll continue investigating on my end, and I'm sure your contributions will prove helpful as we piece together the complete picture. The open-source community thrives on collaborative efforts like this! Thanks again for your time and willingness to help - it's contributors like you that make these projects so valuable.

…

________________________________ 发件人: Jochen Kühner ***@***.***> 发送时间: 2025年10月31日 6:19 收件人: thomas-v2/S7CommPlusDriver ***@***.***> 抄送: lircy ***@***.***>; Author ***@***.***> 主题: Re: [thomas-v2/S7CommPlusDriver] Question regarding the calculation method of SymbolCRC in ItemAddress (Issue #73) [https://avatars.githubusercontent.com/u/364896?s=20&v=4]jogibear9988 left a comment (thomas-v2/S7CommPlusDriver#73)<#73 (comment)> 1. Do you have any code snippets (in any language) that show how CRC Version 2 is calculated? as i said, look with ilspy 1. What are the key differences between CRC Version 1 and Version 2 that you've observed? don't know 1. How did you determine which CRC version a particular PLC/project uses? I also don't know. I only lookt into TIA project files. Don't know how we get this info from the PLC. Maybe it is hardcoded (1200 CRCv1, 1500 CRCv2). But it can also be firmware dependent, I don't know, I've no 1200 PLC. 1. In your 1200 PLC project, which CRC version is being used and have you successfully implemented symbolic access? I've no 1200 PLC ― Reply to this email directly, view it on GitHub<#73 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKXJSGMK2CCQHE75REWOZ2T32L5P5AVCNFSM6AAAAACKRST4XSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINZRGQ4DMMRUGU>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jogibear9988]

I've now tried a few more...
I've added
1200 PLC to a TIA Project -> CRC V1
1200 G2 -> CRC V2
1200 with FW4.7 -> CRC V2

(don't know what the difference between 1200G2 and 1200 is)

so there are some 1200 Firmwares with CRCv1 and newer ones with CRCv2
on 1500 side I don't know, I added a 1511 with Firmware V1, it seems to use CRCv2

[jogibear9988]

If you need to look into TIA projects for yourself, you can do with my tool: https://github.com/jfk-solutions/TiaProjectBrowser