+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Is this a bug? (/thread-11498.html)
Is this a bug? - Rannek - 07-06-2023
So i started algo veracrypt SHA 512 and 256 on two different cloud servers. XTS 1536
I had a list of passwords, some of which exceeded the maximum password length of 128 characters. I assumed Hashcat would handle these longer passwords correctly.
However, I noticed that even with the same password list, it seemed to be incorrectly processing the longer passwords. Additionally, despite having the same hash rate, one process writes 6 minutes while the other writes 21 minutes. Both processes were running on RTX 4090 graphics cards and had identical settings.
Can anyone help me understand why these issues are occurring?
In addition, I noticed that even though both encryption algorithms have the same maximum password length of 128 characters, the processes didn't start at the same completion percentage.
01.png (Size: 45.63 KB / Downloads: 69)
02.png (Size: 50.09 KB / Downloads: 67)
RE: Is this a bug? - Rannek - 07-06-2023
Now both Streebog and Whirlpool starts from 16.91% which is weird. I also made a line counter, so all four algo should start at 78.47%
RE: Is this a bug? - Snoopy - 07-06-2023
well im not quite sure about this, but do you strip the line-endings before getting the lenght of your lines?
regarding your 2 screeenshots from above (first 2 screens), hashcat rejects both times 311.088 from your passlist, which is quite "near" your count of 317.904, the mismatch of ~6.900 could just be the number of passes which are in fact 128 chars long but you count them as >128 because of the line ending which counts
hashcat uses bulks the feed gpu, first bulk was completly rejected, just wait und you should see, that this will rise to the 311.088 from above
regarding string lenght see this (line ending counts ^^)
RE: Is this a bug? - Rannek - 07-06-2023
(07-06-2023, 07:13 PM)Snoopy Wrote: well im not quite sure about this, but do you strip the line-endings before getting the lenght of your lines?
regarding your 2 screeenshots from above (first 2 screens), hashcat rejects both times 311.088 from your passlist, which is quite "near" your count of 317.904, the mismatch of ~6.900 could just be the number of passes which are in fact 128 chars long but you count them as >128 because of the line ending which counts
hashcat uses bulks the feed gpu, first bulk was completly rejected, just wait und you should see, that this will rise to the 311.088 from above
regarding string lenght see this (line ending counts ^^)
OMG you are so right. I am so stupid.
You are correct, the newline characters \nat the end of each line were being counted, which could potentially distort the length of the line. Now these are the results.
Thanks for the comment so hashcat is working fine. I just don't really understood how it works
newline.png (Size: 19.84 KB / Downloads: 29)
RE: Is this a bug? - Snoopy - 07-07-2023
you are welcome
there are many more tripwires, like UTF-8 <->ISO-8859-15 misconversion and so on
jfyi: another common mistake for bruteforce and masks with non asciii chars
when trying to crack non ascii chars like german umlauts äöü e.g. ö is HEX C3 B4, as hashcat works on bytesyized objects, to crack this "single" char, the mask for bruteforce has to be of length 2.
so for cracking "öl" the mask has to be of lenght 3. 2 for ö and 1 for standard ascii l which is one byte in size
RE: Is this a bug? - Rannek - 07-09-2023
(07-07-2023, 11:11 AM)Snoopy Wrote: you are welcome
there are many more tripwires, like UTF-8 <->ISO-8859-15 misconversion and so on
jfyi: another common mistake for bruteforce and masks with non asciii chars
when trying to crack non ascii chars like german umlauts äöü e.g. ö is HEX C3 B4, as hashcat works on bytesyized objects, to crack this "single" char, the mask for bruteforce has to be of length 2.
so for cracking "öl" the mask has to be of lenght 3. 2 for ö and 1 for standard ascii l which is one byte in size
Thanks for those awesome tips! I didn't know those facts before.
