CRC RevEng Activity
Arbitrary-precision CRC calculator and algorithm finder
Brought to you by:
regregex
Activity for CRC RevEng
-
Cheatha Girl posted a comment on discussion General Discussion
hi, my inputs length is 1028 byte that have CRC-16 . i have 4 inputs with their CRCs. but when i run the program, get the following message: "cannot reallocate memory for poly" what should i do? please help.
-
CRC RevEng updated /3.0.5/reveng-3.0.5.zip
-
-
-
-
-
-
David Pye modified a comment on discussion General Discussion
Hi, I'm trying to reverse a serial protocol between a device and its' battery as part of an OSS battery management firmware project. The battery sends packets to the device at regular intervals to prove it's alive (and genuine, I suspect...) without which the device won't run. All that changes each packet is the sequence number, and the last four bytes of the packet. I've not had any luck figuring out whether it's some kind of crc/checksum or a rolling code. The packets look as follows: (0x12 are...
-
Hi, I'm trying to reverse a serial protocol between a device and its' battery as part of an OSS battery management firmware project. The battery sends packets to the device at regular intervals to prove it's alive (and genuine, I suspect...) without which the device won't run. All that changes each packet is the sequence number, and the last four bytes of the packet. I've not had any luck figuring out whether it's some kind of crc/checksum or a rolling code. The packets look as follows: (0x12 are...
-
Vladimir Semenov posted a comment on discussion General Discussion
Hello everyone out there. My question may will sound stupid but it's due to lack of knowledge and experience only. Well, long story short. I'm playing around with a printer's rfid chips. I've already made about one hundred dumps in different conditions and sequences so I figure out almost everything about the data stored there like color, expiration date, ink type, remained volume etc. My goal is to program my own chips as both machines and inks are discontinued by the manufacturer So basically the...
-
Robet Sack posted a comment on discussion General Discussion
Hello, i have three matched pairs of message + CRC and i am unfortunately not able to reverse CRC algo... The data (hex) is (Message CRC): 3731302E3030303836337700000000000000B0000000 0A74 3731302E3030303530397700000000000000B0000000 06B1 3731302E3030303530397604000000000000B0000000 1278 I know that it is a CRC, i only not know if it is one 16 bit CRC or two (different type) 8 bit CRCs. You mention in the manual that crossed-endian reversing is switched off because it is not common. Is there a way...
-
hojat deldar posted a comment on discussion General Discussion
Hi I try Reveng CRC for for reversing and finding model. when I try .\reveng.exe -m CRC-24/OPENPGP -c and then I copy my hex value, below error will accure: Program 'reveng.exe' failed to run: The filename or extension is too longAt line:1 char:1 + .\reveng.exe -m CRC-24/OPENPGP -c 0100000400030001000101020000001C000 ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~. At line:1 char:1 + .\reveng.exe -m CRC-24/OPENPGP -c 0100000400030001000101020000001C000 ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~...
-
Rafael posted a comment on discussion General Discussion
NVM I'm just dumb, the refin has effect on the initial value too.
-
So, I'm writing a C++ header file for the ~112 CRCs in this site(by using a template type class ofc) but when I added CRC-16/TMS37157 and CRC-16/RIELLO they where failing the library test, but everything was right, there wasn't anything missing, so after reading the sources listed on the catalog I found in the references that RIELLO uses 0x554D for it's initial value, instead of 0xB2AA, and TMS37157 datasheet says it uses 0x3791 as initial value, instead of 0x89EC. I changed to these values and the...
-
Alex modified a comment on discussion General Discussion
Hello, I'm wondering if anyone can help me out. I am going to learn a bit of can-bus stuff and did some logs to find out how messages are created. Everything is clear, except the last byte where i think it is a kind of checksum but i can not figure out how it is created. What i found out: First message sent to the receiver. First Byte (in all messages) is the address of the receiver. 0x23 0x10 0x08 0x2C 0x01 0xF3 0x00 0x55 so the 0x23 is address if the receiver. 0x10 is initial count of message (followed...
-
Hello, I'm wondering if anyone can help me out. I am going to learn a bit of can-bus stuff and did some logs to find out how messages are created. Everything is clear, except the last byte where i think it is a kind of checksum but i can not figure out how it is created. What i found out: First message sent to the receiver. First Byte (in all messages) is the address of the receiver. 0x12 0x10 0x08 0x2C 0x01 0xF3 0x00 0x55 so the 0x12 is address if the receiver. 0x10 is initial count of message (followed...
-
ʕʘ̅͜ʘ̅ʔ posted a comment on discussion General Discussion
Hi, I got the same issue with all algorithm with refin=true refout=true otherwise I got the same bytes oder. My test command: D=$(X=$(echo -n "abcdefghijklmnopqrstuvwxyz-ABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789" | xxd -p -);reveng -m CRC-32/JAMCRC -X -c $X);echo $D result F5DD0C72 I expect 0x720CDDF5 D=$(X=$(echo -n "abcdefghijklmnopqrstuvwxyz-ABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789" | xxd -p -);reveng -m CRC-32/BZIP2 -X -c $X);echo $D result A9377A2E equal to expected 0xA9377A2E Regards
-
Juergen posted a comment on discussion General Discussion
Hi, first thanks a lot for the great software, i use it to get the crc algorithm for unknown crc modules! All used works fine. It seems only the CRC-16/MCRF4XX does not work correctly, the byte sequence is reversed. width=16 poly=0x1021 init=0xffff refin=true refout=true xorout=0x0000 check=0x6f91 residue=0x0000 name="CRC-16/MCRF4XX" E.g. on reveng 3.0.5 reveng.exe -m CRC-16/MCRF4XX -c 1516432d31332d4d3756504f57747250423066413d3d gets af10 On other CRC modules (NXP on Chip, selfmade or http://www.sunshine2k.de/coding/javascript/crc/crc_js.html...
-
Ken Brown modified a comment on discussion General Discussion
I am trying to search for the parameters of a 64-bit CRC algorithm. I have used the same command line options to successfully find a standard 32-bit CRC algorithm, but when it comes to the 64-bit non-standard algorithm it doesn't seem to actually try different parameters, but immediately says 'no models found' and quits. Here is the command I'm using... ./reveng -w 64 -f -Fs file1 file2 file3 file4 file5 ./reveng: no models found Edit: It appears that RevEng was just finishing its search much faster...
-
I am trying to search for the parameters of a 64-bit CRC algorithm. I have used the same command line options to successfully find a standard 32-bit CRC algorithm, but when it comes to the 64-bit non-standard algorithm it doesn't seem to actually try different parameters, but immediately says 'no models found' and quits. Here is the command I'm using... ./reveng -w 64 -f -Fs file1 file2 file3 file4 file5 ./reveng: no models found
-
I am trying to search for the parameters of a 64-bit CRC algorithm. I have used the same command line options to successfully find a standard 32-bit CRC algorithm, but when it comes to the 64-bit non-standard algorithm it doesn't seem to actually try different parameters, but immediately says 'no models found' and quits. Here is the command I'm using... ./reveng -w 64 -f -s file1 file2 file3 file4 file5 ./reveng: no models found
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Greg Cook posted a comment on discussion General Discussion
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...
-
Johann N. Löfflmann posted a comment on discussion General Discussion
Hi Greg, first of all, I would like to thank you very much for gathering all the details and sharing the CRC catalogue with the public. I am happy to contribute to it. I would like to suggest two CRC-64 for the CRC catalogue. I suggest the names CRC-64/JONES, and CRC-64/REDIS. Let's see ... recently I stumbled over this commit from 2012 https://github.com/redis/redis/commit/9510d65dc8b0cff77402bd97078636680fe50da0 I found the code comment "Redis uses the CRC64 variant with "Jones" coefficients and...
-
-
-
-
-
-
-
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
-
-
-
-
-
-
-
-
septs posted a comment on discussion General Discussion
I ported this project to browser see https://crc-reveng.septs.app Source Code: https://github.com/NiceLabs/crc-reveng
-
Mitch Minton posted a comment on discussion General Discussion
I'm trying to work out an equation for which a "Calculation|Algorithm" is being created from. I know the resulting value, and I know the potential bytes of data it's getting it's calculation from (CANbus data packets), i'm just having a hard time understanding which arguments to use in order to come up with the testing using this program. all data is in hex, 1st byte (2 characters) are the algorithm value, all following bytes are where the potential calculation would be coming from. EC0C00C0F0C1FFFF...
-
Dieter posted a comment on discussion General Discussion
Hi Greg, I see now it was pretty simple my fault :( My input into the calculator was 518100, 518200, etc with zero padding for the 8Bit CRC code. No idea what I thought, when I did it. So all good with reveng. In fact, I don't remember where these codes exactly came from, but I found them when I was searching for some hints to identify my unknown checksum algorithm here This is neither simple XOR nor CRC as far as I found. best regards, Dieter
-
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;...
-
Hi Greg, I'm wondering why Reveng is not getting a solution for the following data. I have verified with CRC calculator that checksum is correct . It's custom CRC-8 with Polynomial = 0x1d Input Reflected = no Result Reflected = no Initial value = 0x3a Final Xor Value = 0x00 best regards, Dieter reveng -w 8 -s 518155 518281 5183cd 518434 518578 5186ac 5187e0 518843 reveng: no models found
-
Christian Herrmann posted a comment on discussion General Discussion
Hello Greg! Yes, even Merlokk (he is another Pm3 contributor) managed to get a preset into yours. We found some new ones during the years. I don't know if all of them found the way back to you. No easy channel of comms, I suppose. Funny, I use that same saying myself. It is indeed the way how to do it. I did do migrations by your new version by version, but it got tedious :) We are currently on #define VERSION "1.6.2" One reason for the problems is that we needed a way to call your client direct...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
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,...
-
Stephen More posted a comment on discussion General Discussion
Looks like mostly user error: Somehow the first time I ran it I missed the following: reveng: configuration fault. Update config.h with these definitions and recompile: #define BMP_BIT 64 #define BMP_SUB 32 But once I updated config.h it started working as expected: $ ./reveng -m crc-8 -c 436174732f2a88c02a2f72756c65 ed
-
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...
-
-
-
-
-
-
-
-
-
-
1 >