Greg Cook

Hi Johann, thanks for the tip. The polynomial is named after Professor David T. Jones at University College London, who introduced it in a 2009 paper as a candidate to replace the polynomial then used as a hashing function in the SwissProt and TrEMBL databases. It was "empirically tested" to avoid hash collisions between entries differing by one or two amino acids - but even at the time, best practice in bioinformatics was migrating to secure hashes such as MD5. There is enough evidence in the GitHub...

Hello Mitch, thank you for your interest in CRC RevEng. I'm not familiar with this form of packet in CAN, but it's clear that the CRC is the first byte of the packet. Usually when this occurs, the rest of the message is checksummed in left-to-right order and the CRC is inserted at the beginning. CRC RevEng needs to receive the checksummed message in the order the calculator emitted it, and so the CRC must be moved back to the right-hand end of the message. The bytes in time sequence then look like...

Hello Mitch, thank you for your interest in CRC RevEng. I'm not familiar with this form of packet in CAN, but it's clear that the CRC is the first byte of the packet. Usually when this occurs, the rest of the message is checksummed in left-to-right order and the CRC is inserted at the beginning. CRC RevEng needs to receive the checksummed message in the order the calculator emitted it, and so the CRC must be moved back to the right-hand end of the message. The bytes in time sequence then look like...

Hi Septs, That's really impressive! And you've even rolled in my latest update! I heartily approve and wish you all the best. Greg

Hello Dieter, thank you for your interest in CRC RevEng. Thanks also for the link to a rather nice CRC calculator. It'll be handy for when I'm remote and I see it has presets from my Catalogue in it, too. Unfortunately, I could not get it to reproduce the codewords you've given: CRC RevEng agrees with the calculator: $ reveng -w 8 -p 1d -b -B -i 3a -x 00 -c 5181 5182 5183 5184 5185 5186 5187 5188 2a 0d 10 43 5e 79 64 df Just to be sure, I repeated your search command with only the first three codewords;...

Hello Christian and all Proxmark3 users, Thank you for your interest in CRC RevEng. I am delighted to see the app incorporated into the Proxmark3 firmware - as discovered while following up Phil's tip on CRC-8/HITAG. CRC RevEng has always been a hobby project and is now mature. I do not foresee any major changes being made now, only the addition of more preset models, so any refactoring work to bring your port to version 3 will only need to be done once. I should be very glad to offer assistance,...

Hi Stephen, thank you for your interest in CRC RevEng. It appears that all CRC output is truncated to 32*n bits, as a GSM CRC should be returned as 10 hex digits. What is your compiler version please? And what is the output when you enter: make clean bmptst echo $? I'd also like to know if this is confined to the string output function. Kindly run for me: ./reveng -S -e 436174732f2a88c02a2f72756c65 I try to ensure CRC RevEng runs everywhere, so if there's a snag I want to fix it. Kind regards, G...

Hello both of you, thank you for your interest in CRC RevEng. I'm sorry to disappoint, but having a checksum at the beginning is a red flag for a problem that will prove far from straightforward. It immediately raises a critical question of in which order are the bytes of the file processed by the CRC algorithm? Does it run from the end of the file to the beginning and prepend a CRC, or from offset 2 to EOF? CRC RevEng can only solve a CRC algorithm if the byte order is known, and if the files are...