I can manipulate with the data part of this sequence of bytes so here are some more examples: Example 2: Then comes two byte checksum ED76 followed by 00 sort of separator (newline?) byte that I also think doesn't take part in computing checksum.Īfterwards follows data sequence: 312e362e37544553540000000000000000000000000000000000000000 which finally is proceeded by 00 terminating character that I also think has nothing to do with checksum. Here the first byte 0E represents a sort of index, that I still think doesn't take part in generating checksum. Honestly, I don't know where else to look.Īny hints/help or anything at all is much appreciated. I have tried comparing these checksums to most if not all common crc algorithms using online calculators but none of them give even close outputs to those above. Here the checksum bytes are relocated at the end, as reveng expects them in this format. I tried fiddling with reveng to reverse engineer the polynomial with following command: reveng -w 16 -s 01456e 02466e 05496e I wish I could post more diverse values but these are only ones I've been able to capture so far. Here are few more examples of packets with various data values: 1f466e02
Next two bytes 456e represent a checksum that presumably is a variation of CRC-CCITT with non-standard polynomial. Where first byte 1f seems to repeat itself in each packet and I assume it doesn't take part in generating checksum.
#16 BIT HEXADECIMAL CHECKSUM CALCULATOR ONLINE CODE#
I am trying to reverse engineer a 16 bit checksum algorithm of one relatively old (10 years) LAN game that is no longer supported nor has source code available.Īs it seems, data packets don't have standard structure when it comes to placing checksum bytes: Example 1:
0 kommentar(er)
