Bruteforce with descending characters - zzz,zzy,zzx

[yungcheesecake00]

Hello, I'm trying to crack a password using all letters. Instead of starting it from aaaaa, how can I make it start at zzzzz and have it bruteforce backwards to zzzzy, zzzzx, zzzzw etc?

Thanks

[royce]

By default, hashcat doesn't start from 'aaaaa' - instead, it starts with sets of characters that appear most frequently in common passwords, called Markov mode. For example, if you try '?d?d?d?d?d', it will start with '12345', not '00000'.

It *does* behave how you're describing if you disable Markov mode, but I'm not aware of a way to invert the non-Markov bruteforce attack sequence.

[philsmd]

Furthermore, the left side is changed most frequently.

Is there any reason why you would need to change the order ?

You might be able to create a new hcstat2 file with hcstat2gen from hashcat-utils that almost perfectly does what you want with markov. Furthermore, you could use a dict or stdin/pipe to generate and supply to hashcat the specific order you want... but these approaches will both be slower and/or consume more disk space. So the question remains, why would you do that ?

[royce]

One use case I can think of is when you intend to bruteforce an entire keyspace, and want to "meet in the middle" by having one system work forwards, and the other system work backwards. This would work for any two-system attack, without having to calculate keyspace, etc.

What would be the hcstat2 method, philsmd? Just using an inverted list?

[philsmd]

yeah.
but even for the approach with testing first password candidates at the end, you could actually just use -s / -l until the whole keyspace was tested, i.e. split your keyspace in x chunks and test the later chunks first.

[royce]

Well, my point was that if you could just start a run from the other end, you wouldn't have to calculate keyspace at all (for the case of two attack systems)

[yungcheesecake00]

Hey, thank you for the replies! That use case "meet in the middle" is exactly what I'm trying to accomplish here. I have pm'd you guys with what I am trying to do in detail

[royce]

From the PM, it looks like you'd benefit from doing what philsmd described - using the 'skip' and 'limit' options to split the job across two nodes.

philsmd, I'm actually not aware of a simple tutorial for using these options - actual keyspace calculation, etc. Is there one on the wiki?

I'd start with understanding keyspace here: https://hashcat.net/wiki/doku.php?id=fre...a_keyspace

[yungcheesecake00]

Yes I agree, I feel like the chunks would make a lot of sense thanks for the keyspace calculation link royce.

philsmd could you elaborate on the chunks part?

[philsmd]

The --keyspace , --skip and --limit usage is very intuitive.

You just first determine the total "keyspace" (https://hashcat.net/wiki/doku.php?id=fre...a_keyspace) with the --keyspace parameter:

Code:

hashcat -m 0 -a 3 --keyspace ?d?d?d?d?d?d
10000

after that you split it (do the math) into the chunk size you want. e.g. consider you have 10 nodes/PC all with the same specifications/performance. In our case that would give an equally large chunk size of 10000 / 10 (--keyspace value divided by the number of nodes if they have the same specifications).
This means that our --limit (or short -l) value is 1000, 10000 / 10.

We now can distribute the work to all the 10 nodes and run these commands:
1st node:
-s 0 -l 1000
2nd node:
-s 1000 -l 1000
3rd node:
-s 2000 -l 1000
4th node:
-s 3000 -l 1000
....
8th node:
-s 7000 -l 1000
9th node:
-s 8000 -l 1000
10th node:
-s 9000 -l 1000

This actually would also work with other attack types other than -a 3, but for -a 3 it would look like this:

Code:

hashcat -a 3 -w 3 -s 0 -l 1000 hashes.txt ?d?d?d?d?d?d

The first node doesn't need to specify "-s 0" because this is implied; and the last node doesn't need to specify any --limit value, because hashcat will automatically stop when the last password candidate was processed (i.e. no --limit for node 10 needed in our case).

Of course, you shouldn't choose the chunk size way too small, otherwise you won't get full acceleration and you also would spend (percentage-wise) more time in starting/initializing the next job (I would say all chunks should AT LEAST run for several minutes and less chunk change on a specific system could have advantages).

I pretty sure some projects like hashtopolis also make heavy use of the -s/-l feature and you could have a look at how they manage the keyspace etc.

I'm not sure if we need a wiki page for this.... but on the other hand, it could make sense to highlight some particularities that user might get wrong (like -s always start at 0, not at 1; that the -l value doesn't reflect the ending offset, but is always referring to the "chunk size"/length etc etc etc).

Thx