I am analyzing calibration binary files of an embedded system (BMS) that likely uses a CRC-15 CAN checksum.
From my firmware analysis, I have found a PECLookup table, which suggests that a CRC-15 CAN calculation is being performed somewhere. However, I do not see a direct 2-byte CRC-15 stored in the calibration binary file.
Instead, the binary file ends with 8 extra bytes, which seem to be linked to a checksum. I suspect these 8 bytes may be derived from the CRC-15 CAN in some way, but I haven't been able to determine the exact transformation.
What I have observed so far:
- The PECLookup table for CRC-15 CAN is present in the firmware, so it is likely used in some form.
- I do not find a direct 2-byte CRC-15 in the file, but the last 8 bytes change systematically when I modify just 1 byte in the calibration file.
- The 8 bytes doesn't seem to be a simple XOR with a fixed key.
- I tested various CRC-64 transformations on top of the CRC15, but none match the final 8 bytes.
- The system processor is a TMS570 (ARM Cortex-R, Big Endian).
What I am looking for:
- Is there a known method in embedded systems where a CRC-15 CAN is expanded or transformed into a longer checksum (e.g., 8 bytes)?
- Could this be a linear transformation, a different CRC format, or another encoding method?
- Has anyone encountered a similar method in automotive/embedded checksum handling?
Any insights into how such a transformation could work in an automotive or industrial embedded system would be greatly appreciated!
Additional observation In the BMS diagnostic software, a Config CRC (4 bytes) is displayed, which seems to be derived from the last 8 bytes of the calibration file. Specifically:
Config_CRC[1] = byte[1] XOR byte[5] Config_CRC[2] = byte[2] XOR byte[6] Config_CRC[3] = byte[3] XOR byte[7] Config_CRC[4] = byte[4] XOR byte[8]
Config_CRC[1] = byte[1] XOR byte[5] Config_CRC[2] = byte[2] XOR byte[6] Config_CRC[3] = byte[3] XOR byte[7] Config_CRC[4] = byte[4] XOR byte[8] 
