Reverse Engineer CRC Calc (help!)

Hi all,

I have a product i’m trying to simulate an input for.

It takes packets of 8 bytes of data:

  • bytes 0-3 appear to always be 0’s

  • byte 4 is a incremental counter (always increments by a value of 4)

  • bytes 5 & 6 is a 16bit parameter

  • byte 7 appears to be a CRC or similar

I have ~11,000 unique samples of good data to work with.

I’m no mathematician/code-breaker, so have no idea where to start in trying to work out how to calculate that 7th byte.

Some examples of packet data in no particular order:

00 00 00 00 4C 15 31 4E
00 00 00 00 74 15 58 9D
00 00 00 00 1C 00 00 D8
00 00 00 00 B4 0A 1B 95
00 00 00 00 00 00 00 BC
00 00 00 00 38 02 8C 82
00 00 00 00 8C 03 75 C0

Here is the full list of unique values: http://pastebin.com/raw.php?i=ndm4ctmW

Can anyone help me work out that 7th byte???

Thanks!!!

The product will return an error if the 7th byte isnt valid.

Ive tried setting bytes 0-3 to a value of 1 one by one, while keeping 4-7 at a good known value (00 00 00 BC).

Setting bytes 0-3 does return an error, so im guessing that bytes 0-3 are used in the CRC calculation.

If i can’t find a valid calculation for that 7th byte, i i think i can brute force this.

If i send a code with a bad 7th byte, i get an error returned 3 sec later.

So it’ll take a max of 12min to find the valid 7th byte for a packet.

I think byte 4 can always be 0, and i don’t need the accuracy of 16bits for bytes 5-6 (8 will do), so 255*12min = ~20hrs (more like half that) to create a table of values.

Not ideal though.

Solved!

Its a simple checksum :stuck_out_tongue:

0xBC + sum of bytes 0->6

Ok. Wasn’t sure with this line

00 00 00 00 00 00 00 BC

but now guessing this was the big clue.

Good job and thanks for posting the solution.