CRC reverse engineering

Introduction and miscellaneous that we haven't created categories for, yet
Post Reply
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

CRC reverse engineering

Post by davefiddes »

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.
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: CRC reverse engineering

Post by Jack Bauer »

Thanks Dave. Looks quite useful.
I'm going to need a hacksaw
m.art.y
Posts: 550
Joined: Sat Jun 06, 2020 6:54 pm
Location: UK
Has thanked: 24 times
Been thanked: 17 times

Re: CRC reverse engineering

Post by m.art.y »

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?
collin80
Posts: 110
Joined: Sun Aug 30, 2020 3:28 pm
Location: United States, Michigan
Been thanked: 4 times
Contact:

Re: CRC reverse engineering

Post by collin80 »

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.
Post Reply