+- 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: 4.6million character hash rar file (/thread-9538.html)
4.6million character hash rar file - Shqipz - 09-30-2020
So i have a rar file, don't know the password, i'm not sure on the password or how many characters.
I used john the ripper to get the hash being RAR3 [SHA1 256/256 AVX2 8X AES]
And the hash is about 4.6million characters, i am new to hashcat so im not sure if this means it uncrackable but i assume it relatively is.
My main question is it crackable/bruteforce and what would be the best way of going to crack it if it is.
RE: 4.6million character hash rar file - Shqipz - 09-30-2020
also im not even able to run the command on cmd to even attempt cracking since the whole hash cant be posted in cmd
RE: 4.6million character hash rar file - philsmd - 10-02-2020
First of all, it would always make sense to post the hash type that you are trying to crack, also see https://hashcat.net/wiki/example_hashes .
latest beta version of hashcat (https://hashcat.net/beta/) supports these types:
Code:
12500 | RAR3-hp | Archives
23700 | RAR3-p (Uncompressed) | Archives
23800 | RAR3-p (Compressed) | ArchivesThe general data limit (and it is actually a more global/general hash line length limit) is about 320 KiB raw or around 640 KiB (in hexadecimal)... so with signature etc it's slightly below 1 MB hash line length.
This is a limitation that affects basically all hash types and has several reasons (especially the memory allocation, but also catches problems with wrong input etc).
almost 5 MiB is a lot of data and hashcat doesn't support lines within hash files that are that long. Normally, compressed data is quite small and often (depending on hash type, algo etc) you have the possibility to chose the smallest files (like in 7-Zip, PKZIP etc).
You also need to keep in mind that whenever a key is computed the whole data needs to be loaded / tested, so a very huge input is not very good in general (there are of course exceptions, because some decompression libraries are able to decide already from the first couple of bytes if the decrypted data is malformed and therefore the decryption key is wrong).
There is little that we can do here... there were some users that have some success story with patching hashcat to increase the limit (slightly) for 7-Zip and winzip, but this should be only done by advanced users and only makes sense in very exceptional cases.
Please let us know what type of hash you have, the -m hash type and start (for instance $RAR3$*1*) of the hash, would be enough to understand which type of hashes you are trying to crack. Thx