View Full Version : Help on checksum analysis

July 13th, 2007, 06:46

I am working on a project and I have to break a checksum function. I have the checksum of different sets of numbers, but I don’t have the checksum algorithm.
I have tested all classic checksum algorithms (that I know) and none of them corresponds to mine.
Is there anything that I can do besides guessing?
It is important to know that I can not generate the checksum of what I want and I have only some checksums that are calculated on some numbers that I also have.
ex: checksum(38606008203910541469569)=609

Thanks in advance,


July 13th, 2007, 07:11
take a look at this thread and see if something like that is at work

Worse case scenario,

the relationship between checksum(38606008203910541469569) and its "checksum" f(x):609 can be completely arbitrary like randomly assignment in a database, instead of computationally derived, in which case you are screwed unless you have access to the data base.

July 13th, 2007, 17:52

Thanks for your reply. I am sure that there is no database in the generation process. Because you give these numbers (numbers + checksum) to a terminal (hardware) which is standalone (I mean it doesnít communicate with anything else) and it recalculates the checksum to verify if the numbers have been modified. So there is a mathematic formula that transform a sequence of 23 digits to a 3 digit hash.



July 13th, 2007, 18:08
Any way you could get into the code/trace/reverse the algo that does the checking?
The is the only simple way to do it.
Any hashing algorithm worth its name is expressly designed to have no discernible pattern in a brutal force attack (The plaintext-hash association looks pseudo-random), ergo they are effectively a one way transformation/function.

I am not aware of a general, analytic attack to this problem, except for the fact that the hash is only 3 digits (dec or hex?) in theory makes a brutal force attack/exhaustive guessing of a hash at least plausible.

More details??

July 14th, 2007, 07:27
What are these "numbers" you speak of?

Is the first a 64-bit (qord) int? Is the second a byte, a word, or a dord? First things first, get your data representation straight. Otherwise nothing will make sense.

July 15th, 2007, 12:47

Analyzing the code is part of the second phase of the project. The validation algorithm is on an embedded terminal. I will use an ICE to be able to step through the program and find the algo, but in the first phase I have to analyze the numbers.

To make things clearer, these numbers are represented as two barcodes and the last three digits of the second barcode are a checksum of the first and the second barcode to check the integrity. In the last post the "38606008203910541469569" is the concatenation of the two barcodes minus the 3 digits of the checksum and 609 is the checksum. I donít know how the checksum is calculated. I will post more checksum tomorrow. The goal is to find the checksum algorithm. Once in possession of this algorithm, I will be able to do more interesting attacks by modifying the barcode and recalculating the checksum. This will help me to find the meaning of the barcodes. If the checksum is not correct the terminal will reject the ticket.

Thanks to both of you for helping me,


July 15th, 2007, 15:36
Barcode you say? I'm 90% certain it's going to be one of a few dozen standard ones:


July 16th, 2007, 06:33

I have already checked that. The type of the barcode is: interleaved 2/5.
The checksum of this barcodes is modulo 10 but my checksum is 3 digits.
The other difference is that I have one checksum for two barcodes.
Here are more samples:


10541469569 609


11457359384 675


12225849833 318


13183993660 751


14009347878 552


10307979082 816

As you can see each couple of two barcodes has a checksum of three digits.

Thanks for your help and patience,


July 16th, 2007, 08:17
Can you obtain the checksum of

386060112168 000000000

Can you obtain check sums of sequential numbers???

386060112168 000000001

386060112168 000000002

386060112168 000000003

386060112168 000000004

If the algo is very trivial, you stand a chance. . .