hashcat Forum

Hello! I am in a situation where I know the exact pass length (64), the exact number of the most recurring character occurrences (8), and the exact number of the most consecutive characters in a row(3). I used the following maskprocessor command first - 

Quote:mp64.exe -r 8 -q 3 mask_file.hcmask | cudaHashcat64.exe -m 1400 -a 0 -o hashout.txt hash.txt

. My mask file contained this: 

Quote:?l?d, ?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1?1

. The result was a quick termination with all the stats being zeroed out. I thought it was maybe something to do with the hashcat.hcstat file so I tried using another one that I made earlier and it kept outputting 

Quote:WARNING: Hashfile 'custom.hcstat' in line 1 (): Line-length exception

for as many words I used in the wordlist to create the hcstat file. I'm not really sure what I'm doing wrong, so if anyone can give some insight, it would be extremely helpful. Thanks!

I see many problems here.
1. maskprocessor does not support .hcmask files, you can see this easily yourself by checking the output of the maskprocessor command (mp64.exe)
2. there are limitations on the max. password length in place to allow several optimizations: see https://hashcat.net/wiki/frequently_aske...ord_length
3. the .hcstat file is only used by statsprocessor or oclHashcat/cudaHashcat by using certain attack modes only. oclHashcat will check if the file is valid, but in your case, by using -a 0, it isn't really involved at all, only when you use -a 3 (mask attack) it will be involved
4. your keyspace is incredible large, it is: (26 + 10) ^ 64 - (negligible few candidates) ~ 4,011,991,914,547,630,480,065,053,387,702,443,812,690,402,487,741,812,225,955,731,622,655,455,723,258,857,248,542,161,222,254,985,216 (try reading this aloud )

You should easily have found these (and many more) facts by just reading the documentation (wiki/faq/forum) or just by searching for this info e.g. "maximum supported password length"

(03-10-2016, 08:06 PM)philsmd Wrote: [ -> ]I see many problems here.
1. maskprocessor does not support .hcmask files, you can see this easily yourself by checking the output of the maskprocessor command (mp64.exe)
2. there are limitations on the max. password length in place to allow several optimizations: see https://hashcat.net/wiki/frequently_aske...ord_length
3. the .hcstat file is only used by statsprocessor or oclHashcat/cudaHashcat by using certain attack modes only. oclHashcat will check if the file is valid, but in your case, by using -a 0, it isn't really involved at all, only when you use -a 3 (mask attack) it will be involved
4. your keyspace is incredible large, it is: (26 + 10) ^ 64 - (negligible few candidates) ~ 4,011,991,914,547,630,480,065,053,387,702,443,812,690,402,487,741,812,225,955,731,622,655,455,723,258,857,248,542,161,222,254,985,216 (try reading this aloud )

You should easily have found these (and many more) facts by just reading the documentation (wiki/faq/forum) or just by searching for this info e.g. "maximum supported password length"

Oops! I'm sorry for not checking, but I read somewhere that you can recompile it to change the max password length, and when I checked it said it was 64. But I just remembered that was only for statsprocessor. My rationale was that it would possibly work because of the -r and -q parameters because I asked a statistics professor how many possible combinations with length 64 and with max 8 of the same characters and max 2 consecutive characters (by accident) and I believe he said it would be somewhere around ~10^19 so I thought that max 3 consecutive characters would reduce that number heavily. Do you see my problem even being solvable with oclHashcat? At this point, I've exhausted all of my ideas  Thank you!

(03-10-2016, 08:06 PM)philsmd Wrote: [ -> ]I see many problems here.
1. maskprocessor does not support .hcmask files, you can see this easily yourself by checking the output of the maskprocessor command (mp64.exe)
2. there are limitations on the max. password length in place to allow several optimizations: see https://hashcat.net/wiki/frequently_aske...ord_length
3. the .hcstat file is only used by statsprocessor or oclHashcat/cudaHashcat by using certain attack modes only. oclHashcat will check if the file is valid, but in your case, by using -a 0, it isn't really involved at all, only when you use -a 3 (mask attack) it will be involved
4. your keyspace is incredible large, it is: (26 + 10) ^ 64 - (negligible few candidates) ~ 4,011,991,914,547,630,480,065,053,387,702,443,812,690,402,487,741,812,225,955,731,622,655,455,723,258,857,248,542,161,222,254,985,216 (try reading this aloud )

You should easily have found these (and many more) facts by just reading the documentation (wiki/faq/forum) or just by searching for this info e.g. "maximum supported password length"

I did not post the same thread. I posted the same problem but I am trying to troubleshoot it because with the thread that you just closed, I tried different ways of solving it and still didn't get any feedback on whether or not it is even possible so I honestly have no clue why you closed the thread..

Did you ever find a way to increase the password input length?

I have a sha256 hash that has been created by hashing a word eg"password" then hashing the resulting string again and again.

Eg Password > hash 1
Hash1 > hash2
Hash2 > hash3
Hash3 > hash4
Hash4 > hash5

So for example I know hash5 and hash4 but how do I get hashcat to recognise hash5 = sha256(hash4) ?
I can't find a way of using hash4 as an input.

Would it be possible to use the first 55 characters of hash4 and use a rule/mask to tell hashcat to add 9 hexadecimal characters to it?

Is it iterating over binary or hex-encoded sha256?

Thanks for the reply, It is iterating as hex.

Eg
e7cf3ef4f17c3999a94f2c6f612e8a888e5b1026878e4e19398b23bd38e**** = sha256(password)

Iv replaced the last 4 characters as * to follow forum rules

The best way to handle this would be to add a new mode that can do iterated sha256. If it were binary I'd say base it off of 7400, but since it's hex you'll have to do a bit more work. Would probably be easiest to base it of off 4500 + 1400.