# Reverse engineering a single checksum byte [closed]

I am working to understand a system which saves a few bytes of data together with what appears to be a single checksum byte that provides a very naive guarantee that the data has not been tampered with. My current task is to understand how this checksum is being calculated.

I cannot currently post any specific data, but I do have reason to believe the checksum calculation is very easy to compute. I also know for a fact that it receives no more than 6 bytes of data as input, and quite possibly as little as one byte.

Given that I have a table of several samples of data bytes + checksums, is there a formal process to reverse engineer this checksum, or do I have to rely on simple logic deduction from the known facts that I have?

-

## closed as too broad by e-sushi, poncho, rath, AFS, GillesMay 25 '14 at 19:47

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Huh? Why the downvote? –  Yuval Adam May 24 '14 at 16:06
I'm not the downvoter, but I guess because at its current state the question is not really answerable. –  DrLecter May 24 '14 at 16:41
This question appears to be off-topic because it is not about cryptography. It might be suitable for Reverse Engineering, though more information would probably be required for a useful answer. –  Gilles May 25 '14 at 19:47

You would have to see about the given pairs of plain text and checksum. Try to find two only marginal different plain texts with the same checksum. (Shouldn't be do difficult with only one byte (256 possibilities) per checksum. Try a few one byte long plain texts and look for correlations of the checksum. What's the checksum of 8 zero bits? And 8 one bits? What's the checksum of the byte value of 1?

You say the checksum only gets 6 bytes as input... Is this because the checksum doesn't change with a seventh byte or because the input is just truncated / never exceeds 6 bytes?

A good guess could be the Cyclic redundancy check with 8 bits or with 32 bits truncated to 8 bits.

The most important thing is to know which algorithm was used. After that, the whole thing becomes much easier.

-
I have a few test cases where a single increment to a single significant data byte (i.e. from a1 to a2) changed the checksum byte by 2 (i.e. from 54 to 56). The checksum receives at most 6 bytes since those are the only relevant data bytes for this process, and as mentioned, it might possibly be just a single byte that is checked. So just for testing, what would an 8-bit CRC check on a single byte look like? –  Yuval Adam May 24 '14 at 12:05
@YuvalAdam You can look at the definition of CRC through the link in my answer (i have corrected the link). Would it be possible to get some more pairs of plain text - checksum? –  Nova May 24 '14 at 12:46
yes I'll try to clean the data and publish some of it. –  Yuval Adam May 24 '14 at 12:50