# 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

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