3

Hashcat: How to discard words of length less than N after rules have been applied?

I know of the rules <N and >N that discards the word if its length is less than and greater than N, respectively.

The problem is that these rules can only be applied using the -j or -k options of Hashcat, which means that they operate on the wordlist itself, and not on the rules-transformed words.

Using "old" Hashcat I can use the <N and >N rules in the rule file itself, but then I can't crack using the GPU...

Any suggestions on how to discard rule-transformed words of length smaller than N?

  • Limiting characters to LESS than N only saves you 10% of the processing time it would take the crack a password N length long. I don't know the answer, but thought it was worth mentioning that you're not loosing a ton of time guessing the keyspace below N length. – Daisetsu Oct 14 '18 at 18:13
  • @Daisetsu - are you sure? What if the hash-mode is MsCacheV2, which iterates a hash algorithm 10200 times? Then I guess, it would be much faster to check if the string has length greater than N than to compute the resulting hash? – Shuzheng Oct 15 '18 at 9:38
4

The answer depends on the "speed" of the target hash:

  • If it's a fast hash (like MD5), Daisetsu is roughly correct - that it's not worth the trouble to worry about it (though it can vary based on attack and targets);

  • If it's a slow hash (like bcrypt), the GPUs won't be starved for candidate passwords, so you have the luxury of generating candidates externally (off-GPU) without slowing down your attack.

A common technique for the latter is to combine hashcat's --stdout option with your attack to generate your candidates, and then pipe that hashcat to another instance of hashcat (which does the actual cracking).

To inject length requirements into that pipeline, the hashcat-utils len utility works this very efficiently. If there are complexity requirements, the req utilities from hashcat-utils is also very efficient.

So you could do something like this to generate the candidates:

$ hashcat rockyou.txt -r rules/best64.rule  --stdout
123456
654321
123456
123456
1234560
1234561
1234562
1234563
1234564
1234565
[snip]

... and then pipe that to another hashcat (for example, assuming a requirement of length minimum of 8, and maximum of 11):

hashcat rockyou.txt -r rules/best64.rule  --stdout | len 8 11 | hashcat -a 3200 targets.hashes

... but keep in mind that this is useful only for slower hashes.

Note that if the hash is slow enough, you can use anything (Perl, shell scripts, crunch, etc.) to do whatever fancy candidate generating and sifting that you want. As the speed of the hash starts to increase, you'll want to benchmark your pipeline to make sure that you're not starving the GPUs (they should usually show 100% in hashcat's status output). hashcat and len are very fast, as are the other tools in hashcat-utils, so I usually point people there.

|improve this answer|||||
  • thank you! - why don't Hashcat implement <N or >N in rules? And is it possible to pipe hashcat's output to another instance of hashcat, if the piped content is, say, >10GB size? Is piping streamed; if not, there won't be enough memory (RAM)? – Shuzheng Oct 15 '18 at 9:43
  • If you like the answer, please accept it. :) Hashcat doesn't implement length rules because rejecting candidates at high speed on GPU would significantly slow down GPU cracking. The way that pipes work is independent of size (it is streamed). – Royce Williams Oct 15 '18 at 13:44
  • Thank you! So, it doesn't matter whether hashcat --stdout outputs, say, content that would be stored as 15GB on disk? The pipe mechanism reads it in chuncks, so that it would never require 15GB of memory? I know it is off-topic, but you seem to know stuff ;) - what happens if the first program in a pipe outputs data at a much higher rate than the second program reads it? In this case 15GB of (virtual) memory would be used? Also, since piping is streamed, does both programs, on either side of the pipe, run in parallel? – Shuzheng Oct 16 '18 at 8:26
  • it's all general Unix-like pipeline stuff. The output candidates will be streamed, no disk or memory consumption (other than that involved in generating them). Slowest link in the pipeline will govern the overall speed, and each process runs concurrently. – Royce Williams Oct 16 '18 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.