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:
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:
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
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
10000after 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?dThe 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