1
\$\begingroup\$

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]
\$\endgroup\$
4
  • \$\begingroup\$ Anything is possible. I think the question might be unanswerable or too broad. Software can do anything it wants to some bytes and transmit them. \$\endgroup\$ Commented Mar 17 at 13:00
  • 1
    \$\begingroup\$ You have access to the firmware, and presumably know of IDA Pro and Ghidra. So, you should be able to answer all of those questions much better than we can. As for the methods: it's whatever someone can come up with, just to make it harder to reverse engineer. In my experience, to stump very basic attempts it's sufficient to use a non-standard CRC polynomial, and a non-standard CRC length, say 19 bits. You can presumably also run the firmware with a debugger and set breakpoints on access to the CRC lookup table. That will lead you to the CRC routine in the code. \$\endgroup\$ Commented Mar 17 at 13:11
  • \$\begingroup\$ Of course, that table may just be a decoy to thwart reverse-engineering. Without a debug session or deeper reverse-engineering you won't know if the table is ever used. \$\endgroup\$ Commented Mar 17 at 13:13
  • 1
    \$\begingroup\$ On any CRC code using a look-up table of some sort, you aren't likely to find the actual polynomial in the source. \$\endgroup\$ Commented Mar 17 at 15:10

3 Answers 3

Reset to default
2
\$\begingroup\$

Could a CAN CRC-15 be transformed into 8 bytes in an embedded system?

Yes it could be. Assuming that there is actually a CAN CRC-15 in use, and not just a decoy. As for how it may be transformed: it's up to whoever designed the firmware. There's no "standard" method. Anyone who does embedded firmware long enough can come up with a thousand more and less creative ways of doing it.

The best bang for the buck would be to attach a debugger to the target and snoop out what's really happening.

\$\endgroup\$
1
  • \$\begingroup\$ I'm not sure that table is a decoy since another product from the same brand also uses it. However, in that case, it only uses the 2-byte CRC, not the 8-byte version. Thanks, I'll try connecting to the JTAG pins and debugging from there. \$\endgroup\$ Commented Mar 18 at 13:09
2
\$\begingroup\$

CRC-15 CAN is as you probably know used for CAN bus, so that could easily explain the presence of such a function in embedded firmware.

As the hash on the file seems to be 8 bytes, it's probably not CRC-15 CAN.

\$\endgroup\$
1
\$\begingroup\$

The CRC blocks on that processor have 64 bit registers or 8 bytes: it could be you are looking at some other data CRC or error correcting syndrome - noting the MCU has ECC memory also..

Yes, it could well be that the bottom 15 bits of the CRC register are indeed the 15 bit CAN bus CRC, the remainder of the bits would perhaps be shifted versions of older CRC values. But unlikely to be that specific. .

One thing to do is look up the properties of a CRC - AFAIR if you change one message bit and run the generator N times, you get the CRC polynomial raised to the power N. And when you put a complete message with a good CRC including its CRC through the checker, you should end up with the start state of the checker.

In other words there is an exact syndrome for a single bit change at any point in the message. Of course it is much easier to spot CRCs if you can make a message which is all "0" and then change one bit.

But really anything goes - provided the software can read its own data and confirm that it was the only source that could have created that 8 byte signature, it will be happy.

Also you seem to have found one documented way to make a 32 bit CRC into 64 bits by XORing with another set of numbers, and storing the result.

\$\endgroup\$
1
  • \$\begingroup\$ If I get it right, the TMS570 processor also uses a classic CRC64-ISO (ti.com/lit/an/spna235/spna235.pdf). I tried computing CRC64-ISO(CRC15-CAN) with RevEng, but since my CRC15-CAN message is just 2 bytes, I get around 3 bytes. Ex: CRC64-ISO(0x5253) = 0x0000000000F05B1A. I also tried calculating CRC64-ISO on my full message, but it doesn’t match my 8 bytes. I also used RevEng to compute CRC15(message) and then CRC15(message + result), but for some reason, it doesn’t return 0000. I can't set my whole message to 0, but I can shorten it to about 60 bytes and tweak a few. \$\endgroup\$ Commented Mar 18 at 13:06

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.