September 14th, 2013, 07:26 AM
Does anyone recognize this checksum algorithm?
I have an application that produces two byte checksum for all the data (strings) that it sends over a network; much similar to TCP/IP Header checksums. I am trying to analyze/reverse the algorithm used to generate these two bytes but am currently stuck. Here are the examples of checksums for the variety of strings:
(one thing to notice: every string has an accompanied "1.6.5" substring when it is sent over a network, so, this substring might or might not take part in generating the checksum)
[consider following strings without quotation marks]
I have tried to generate checksums with following algorithms:
"1.6.5a" -> checksum in hex: ac 47
"1.6.5b" -> checksum in hex: ad 9a
"1.6.5c" -> checksum in hex: ae ed
"1.6.5r" -> checksum in hex: bd ca
"1.6.5z" -> checksum in hex: c5 62
"1.6.5aa" -> checksum in hex: ed 52
"1.6.5ab" -> checksum in hex: ce c9
"1.6.5ac" -> checksum in hex: af 40
"1.6.5ba" -> checksum in hex: ee a5
"1.6.5bb" -> checksum in hex: cf 1c
"1.6.5zz" -> checksum in hex: ff 09
"1.6.5abc" -> checksum in hex: 71 2e
"1.6.50" -> checksum in hex: 84 4f
"1.6.5!" -> checksum in hex: 6c 87
"1.6.5#" -> checksum in hex: 6e 2d
"1.6.5$" -> checksum in hex: 6f 80
"1.6.5%" -> checksum in hex: 70 d3
md5 LM NTLM sha1 sha256 sha384 sha512 md5(md5()) MySQL4.1+ ripemd160 whirlpool adler32 crc32 crc32b fnv132 fnv164 gost haval128,3 haval128,4 haval128,5 haval160,3 haval160,4 haval160,5 haval192,3 haval192,4 haval192,5 haval224,3 haval224,4 haval224,5 haval256,3 haval256,4 haval256,5 joaat md2 md4 ripemd128 ripemd256 ripemd320 sha224 snefru snefru256 tiger128,3 tiger128,4 tiger160,3 tiger160,4 tiger192,3 tiger192,4
but none of them matches the upper mentioned results.
Maybe someone recognizes the pattern? Thanks
September 14th, 2013, 10:38 PM
Try writing it out in binary - might make it easier to spot the pattern.
September 15th, 2013, 12:06 AM
Do you have actual wireshark traces of these messages?
Are you able to send any data packet on demand, or are you stuck with whatever the application happens to emit?
Why are you doing this? If this is a bought and paid for licence, then most (if not all) such licences forbid reverse engineering in most circumstances.
Which OS are you running on? Is analysing / debugging / tracing the program code an option?
September 16th, 2013, 03:04 PM
Glancing at the list of hashes you tried, I noticed that both of the CRCs are labelled 32 -- as in (I presume) 32 bits.
From your sample data, this hash is evidently 16 bits. It could be the truncation of a longer hash, but in case those two bytes are the "whole show," I suggest looking into 16-bit CRCs. You could write a program to test every possible polynomial for 16-bit CRC.
Bear in mind that there could be ambiguity concerning byte ordering (that is, the first example might correspond to 0xac47 or 0x47ac).
Also, it's possible that the hash is applied to only the characters of the string; the characters of the string plus a null termination at the end; or the entirety of a fixed length field, consisting of the string plus enough nulls to pad out the field.
I assume you have confirmed that the strings are plain ASCII (and not 16-bit Unicode, for instance)?