openinverter forum

Something I've seen mentioned in a few threads is the difficulty of determining the correct CRC to use when communicating with the various devices.

Came across a new tool released by security researcher Colin O'Flynn called CRC Beagle which is a python CRC reverse engineering tool.

He mentions an older tool called RevEng which is a C based tool for doing similar things.

The idea behind both seems to be you shove some example messages at them and give them an idea of the size of the CRC and it goes and figures out the rest. Apparently can even figure out some common obfuscation techniques and determine how much of a message header is included in the CRC.

Hopefully this might help someone's reverse engineering exploits.

Thanks Dave. Looks quite useful.

I have no experience or knowledge about CRC yet but I have got a CAN log and I know that CRC is 16 bit CCITT. Where do I start as a novice? Maybe a stupid question but it's not clear to me - if a CAN message sent has a CRC value in it so a receiving device receives it and checks if its correct so why if I play a CAN log I can't get a device to work as the messages in the CAN log already has CRC included?

m.art.y wrote: ↑Sun Sep 19, 2021 8:20 pm I have no experience or knowledge about CRC yet but I have got a CAN log and I know that CRC is 16 bit CCITT. Where do I start as a novice? Maybe a stupid question but it's not clear to me - if a CAN message sent has a CRC value in it so a receiving device receives it and checks if its correct so why if I play a CAN log I can't get a device to work as the messages in the CAN log already has CRC included?

It's true, CRC is generally used to validate that the traffic is correct. Usually it then follows that generating the proper CRC for a given message will cause it to be accepted. But, not always.

A couple of possible reasons:
1. Quite often any frame with a CRC also has a sequence signal. It might run 0-15 or 0-7. If you start to broadcast messages at the same time as the "original" sender of that frame you will be sending out of sequence and so might be ignored
2. Relatedly, if the original sender is still there it might overruling you by sending the correct frames
3. If the original sender is not there and you're trying to replay CAN outside the normal ecosystem then there might have been "setup" messages that get things to the proper state. This may or may not include the need for a challenge/response. If it does then the other end probably expects that it will send the challenge and you'll send the response. So, your canned response is not likely to satisfy the challenge and things lock out.

So, it could be many things. Additional details would be needed.