Doesnt seem to work on Ubuntu 23

[MeisterLone]

The file:

It seems like it reads the correct CRC from file (8D BB 3A 66) but when it starts up, it shows CRCs/s=5 briefly, then goes down to 0 in a second or two, then nothing happens after that and the screen shows as below.

Very strange. 5 crc/s also sounds really slow for my pc

Cheers!

file.txt

` sudo ./bruteforce-crc --verbose 1 --file file.txt --start 0 --end 1056 --width 32 --offs-crc 1056 --probe-initial true --threads 1
Extracted message with crc 8dbb3a66
Extracted 1 messages and CRC values
Brute Force CRC Settings

CRC Width : 32
Truncated Polynomial : 0x0 to 0x0
Truncated Polynomial : 0x0 to 0xffffffff
Initial value : 0x0 to 0xffffffff
final xor : 0x0
Probe reflect in : false
Probe reflect out : false
Feed type : auto
Permutation count : 18446744065119617025

Multithreaded CRC Brute Force Initiated

Number of threads : 1
Number of test vectors : 1

Testing Known CRC's for Length 32

Starting brute forcer over selected threads

Starting Thread 0, searching from 0 to ffffffff

time=198s CRCs/s=0 .42101e-17% (10 of 18446744T) time_to_go=5124095573644338 h`

[nitram2342]

Hello @MeisterLone. Thanks for your feedback. There is clearly a bug. Once, there was a check if the polynomial width is more than 16 bit and then there was at least a warning. I am not sure right now, what is going on, but the program should stop before it runs into unexpected conditions. But before I start investigating, I like to give an early response.

First of all, there is not need to run the program with elevated privileges (sudo). It will work without as long as file permissions of other files allow reading them.

Second, bruteforcing a polynomial is fine for smaller degrees like 16, which is common and sufficient for communication protocols. For comm protocols, you may have a telegram of 100 byte. Even TCP uses a 16 bit checksum (not CRC). CRC-32 is often used for large data blobs. Bruteforcing it with probing different parameters is not feasible. It may work for probing a single parameter. I would say it is better to check common CRC-32 formats and start testing these standard methods first. An overview can be found here. Maybe there is even a tool for this purpose, but I am not aware of any specific program. If you find any tool for this, I would be glad to hear about it and to add it in the documentation.

[MeisterLone]

Hey @nitram2342 !
Thank you for your response, much appreciated!
So I was able to get it to work by not using the --probe-initial param. That seems to be the cause of this issue. If I take that out, it seems to work.

Yes this is a network packet that I am trying to emulate.

`Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 03 0A 82 ED 86 39 61 D2 03 14 1E 32 B6 CA 00 3C ..‚í†9aÒ...2¶Ê.<
00000010 EE 0D BF DF 53 30 37 32 32 35 35 30 00 00 00 00 î.¿ßS0722550....
00000020 00 FF 06 01 01 00 00 00 29 02 1E 00 25 00 00 00 .ÿ......)...%...
00000030 00 00 10 00 FC 01 17 01 00 00 00 00 37 01 F4 01 ....ü.......7.ô.
00000040 F5 35 32 00 01 00 00 00 00 00 00 00 00 00 00 00 õ52.............
00000050 D7 FA 00 1C 20 61 F3 3C 00 30 30 30 30 30 30 30 ×ú.. aó<.0000000
00000060 30 30 30 00 00 00 91 47 14 02 00 00 00 00 00 00 000...‘G........
00000070 00 00 00 00 00 00 00 00 32 8C 00 30 00 D5 75 CA ........2Œ.0.ÕuÊ
00000080 00 00 00 00 8D BB 3A 66 .....»:f
`

The last 4 bytes in the packet is a checksum, seemingly CRC32. It is possible that they are only CRC a critical part of the packet (not the entire packet) but I am not sure.
Default CRC32 settings, does not yield the correct checksum. I tried XOR it, still incorrect. I find it rather unlikely that they would go through the effort of implementing a custom crc32, but I guess I have to look at all possibilities.

Here is a second packet, of the same type, with the checksum in the same spot. Last 4 bytes

`Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 03 0A 82 ED 86 39 61 D2 03 14 1E 32 B6 CA 00 3C ..‚í†9aÒ...2¶Ê.<
00000010 27 B3 98 BA 53 30 37 32 32 34 33 30 00 00 00 00 '³˜ºS0722430....
00000020 00 FF 04 01 01 00 00 00 22 04 1E 00 28 00 00 00 .ÿ......"...(...
00000030 00 00 0F 00 F0 03 1C 02 00 00 00 00 46 02 DC 00 ....ð.......F.Ü.
00000040 78 2D 16 00 01 00 00 00 00 00 00 00 00 00 00 00 x-..............
00000050 D7 FA 00 1C 10 17 6E 3B 00 30 30 30 30 30 30 30 ×ú....n;.0000000
00000060 30 30 30 00 00 00 A9 75 6B 06 00 00 00 00 00 00 000...©uk.......
00000070 00 00 00 00 00 00 00 00 32 8C 00 30 BA 47 99 B3 ........2Œ.0ºG™³
00000080 00 00 00 00 AC 87 FF 56 ....¬‡ÿV
`

Have a good day!

[multiplemonomials]

I can confirm this issue is related to --probe-initial. Getting the exact same behavior.