1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2013
    Rep Power

    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]

    PHP Code:
    "1.6.5a"   -> checksum in hexac 47
    "1.6.5b"   -> checksum in hexad 9a
    "1.6.5c"   -> checksum in hexae ed
    "1.6.5r"   -> checksum in hexbd ca
    "1.6.5z"   -> checksum in hexc5 62

    "1.6.5aa"  -> checksum in hexed 52
    "1.6.5ab"  -> checksum in hexce c9
    "1.6.5ac"  -> checksum in hexaf 40
    "1.6.5ba"  -> checksum in hexee a5
    "1.6.5bb"  -> checksum in hexcf 1c
    "1.6.5zz"  -> checksum in hexff 09
    "1.6.5abc" -> checksum in hex71 2e

    "1.6.50"   -> checksum in hex84 4f
    "1.6.5!"   -> checksum in hex6c 87
    "1.6.5#"   -> checksum in hex6e 2d
    "1.6.5$"   -> checksum in hex6f 80
    "1.6.5%"   -> checksum in hex70 d3 
    I have tried to generate checksums with following algorithms:

    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
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2008
    Rep Power
    Try writing it out in binary - might make it easier to spot the pattern.

    Best regards,
  4. #3
  5. Contributed User
    Devshed Specialist (4000 - 4499 posts)

    Join Date
    Jun 2005
    Rep Power
    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?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2009
    Rep Power
    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)?

IMN logo majestic logo threadwatch logo seochat tools logo