Checksum algorithm reverse engineering

Question

I've been analyzing some SPI EEPROM memory, and tried to find out which Checksum algorithm has been used;

For example I've got data: 14567D9h and checksum 187h. Assuming it's normal 16 bit check sum I've got 86h - no match, but after adding 101h it magically changes to 391h

Another Example: 8ADh and check sum B5h with this one is normal - 16 bit checksum results with exact number: B5h (perfect match)

I've checked it with 28 samples i was able to intercept. For some values i have to add 101h to checksum and for some it is only needed to sum it up.

Parity check doesn't fit - if you want I can share some more data - all gathered in one excel file, and calculated. After few days of brainstorm with my friend we haven't come up with anything :/

Maybe there is some additional part in the Algorithm, which i haven't found out yet? CRC and tonnes of other algorithms were checked - only 16 bit checksum was giving any promising results Thanks for help in advance!

copy of my spreadsheet: https://drive.google.com/file/d/0B2FO0-Y1n-ySMUZ2VTVkME9tdm8/view?usp=sharing

How many 16-bit chunks are typically being summed (in successful and in unsuccessful cases)? — Jerry Federspiel, Aug 07 '15 at 21:49
chunks are 1 byte long - 4 of them are summed. The checksum is 2 byte long. — Wasilij Grigoriewicz Zaitsev, Aug 07 '15 at 21:52
maybe there is also length included (counting from 0) as number of 4 byte chunks — Luka Rahne, Aug 07 '15 at 21:54
fact is - i only have copy of memory - I haven't used any software to analyze it - only some calculation in spreadsheet and paper. — Wasilij Grigoriewicz Zaitsev, Aug 07 '15 at 21:57
after comparison of files, i've found addresses where data is stored and just found way to read it. But to change it i have to write proper checksum. Have you read the excel file? Any problems with analysis? — Wasilij Grigoriewicz Zaitsev, Aug 07 '15 at 21:59
@Luka Rahne - length is not taking part in checksum - all "packets" has the same length. In memory its organised as follows: [2 bytes checksum][4bytes data] every time. — Wasilij Grigoriewicz Zaitsev, Aug 07 '15 at 22:07
most probably http://reverseengineering.stackexchange.com/ will be way better place for such tasks — Salvador Dali, Aug 07 '15 at 22:07
It could be that it's a two step process: in the first step you need to calculate the plain 16 bit checksum, then in the second step you XOR some of the bits of the checksum based on the original value. You should create a column in the spreadsheet with the difference of your calculated and the real checksum, maybe that would give you a clue. — biziclop, Aug 07 '15 at 22:07
[link](http://reverseengineering.stackexchange.com/questions/9578/determining-checksum-algorithm-from-known-values) new topic with some more info — Wasilij Grigoriewicz Zaitsev, Aug 07 '15 at 22:24

score 1 · Answer 1 · answered Oct 02 '15 at 11:32

1

From what I know, CRC is used for files to help identify file' corruption. The size of the CRC is fixed while the size of the file is not, and the file' size is much bigger.

In other word, the CRC is not reversible simply because it is a many-to-one relation.

answered Oct 02 '15 at 11:32

Mr. M

62
1
15

By CRC I meant a Checksum – Mr. M Oct 02 '15 at 11:33

Checksum algorithm reverse engineering

1 Answers1