Hi there, let's dig into figuring out that unknown 2-byte checksum/CRC field in your device's protocol. Based on the details you shared, here's a structured approach to narrow down the possibilities:

1. First, Confirm Byte Breakdown & Variable Fields #

Let's start by splitting your sample packets into individual bytes to clarify what's fixed and what's changing:

• Fixed prefix: 9A 56 F1 FE 0E B9 00 (first 7 bytes across all samples)
• Temperature value: 8th byte (0x11 → 0x12 → 0x13 → 0x14 → 0x15)
• Middle segment: 00 00 01 00 (bytes 9-12, fixed)
• Mystery correlated byte: 13th byte (0x64 → 0x67 → 0x66 → 0x61 → 0x60) – this also shifts with the temperature value! It's almost certainly part of the payload that feeds into the checksum, so don't exclude it from your calculations.
• Checksum/CRC: Last 2 bytes (varies with temperature and the mystery byte)

2. Rule Out Common CRC Variants & Try Non-CRC Checksums #

You mentioned using RevEng and online CRC tools without luck – this likely means you're dealing with a custom CRC configuration or a non-CRC checksum. Let's explore both:

Custom CRC Parameters #

RevEng defaults to standard CRC models, but many embedded devices tweak parameters like initial value, input/output bit reversal, or final XOR value. Try these targeted RevEng commands to cover more variants:

# Test CRC-16 (IBM polynomial) with no bit reversal, initial value 0xFFFF, final XOR 0x0000
./reveng -w 16 -p 0x8005 -i 0xFFFF -o 0x0000 -r 0 -s 9A56F1FE0EB9001100000100641C 9A56F1FE0EB90012000001006720 9A56F1FE0EB90013000001006620 9A56F1FE0EB9001400000100611C 9A56F1FE0EB9001500000100601C

# Try CRC-16-CCITT variant with initial value 0x0000
./reveng -w 16 -p 0x1021 -i 0x0000 -o 0x0000 -r 0 -s 9A56F1FE0EB9001100000100641C 9A56F1FE0EB90012000001006720 9A56F1FE0EB90013000001006620 9A56F1FE0EB9001400000100611C 9A56F1FE0EB9001500000100601C

If those fail, run a full scan of all possible 16-bit CRC polynomials with:

./reveng -w 16 -a -s 9A56F1FE0EB9001100000100641C 9A56F1FE0EB90012000001006720 9A56F1FE0EB90013000001006620 9A56F1FE0EB9001400000100611C 9A56F1FE0EB9001500000100601C

This will take longer, but covers every potential 16-bit CRC polynomial.

Non-CRC Checksum Options #

If CRC doesn't pan out, check for simpler algorithms:

• Sum-based checksums: Calculate the 8-bit or 16-bit sum of all payload bytes (excluding the checksum itself), then compare to the checksum (or its two's complement, or shifted value). For your first packet, the sum of 9A 56 F1 FE 0E B9 00 11 00 00 01 00 64 equals 0x41C – notice the lower byte matches the last byte of the checksum (0x1C). Test this pattern with more samples.
• XOR-based checksums: Compute the XOR of all payload bytes and see if it aligns with the checksum (or a combination with a fixed key).
• LRC (Longitudinal Redundancy Check): A byte-wise XOR or cumulative sum of all payload bytes, common in serial protocols.

3. Collect More Sample Packets #

Your current 5 samples only vary the temperature field. To narrow down the algorithm:

• Generate packets with unrelated temperature values (e.g., 0x10, 0x16, 0x00, 0xFF) to observe how the checksum responds to larger input changes.
• If possible, modify other device parameters (e.g., setpoint, fan speed) to get packets where different payload bytes change. This will confirm exactly which bytes are included in the checksum calculation.

4. Advanced Troubleshooting #

If the above steps don't work:

• Sniff gateway-device communication: Use a logic analyzer or RS-485 sniffer to capture the exact packets the gateway sends to the device when you send Modbus commands. Compare these to your manually injected packets to ensure you're not missing hidden fields.
• Reverse-engineer the gateway firmware: If you have physical access to the gateway, dump its firmware and search for checksum/CRC calculation code using tools like Ghidra or IDA (this requires embedded systems and reverse engineering familiarity).
• Check community resources: Search for your device/gateway model in forums or reverse engineering communities – someone else may have already cracked the protocol.

内容的提问来源于stack exchange，提问作者José Morais