Yes, in theory you could use also a hex editor to extract the 512 bytes. Just make sure that the final "hash file" contains the data in binary (it does not work with hexadecimals in the hash file, it must be the raw bytes).
An advanced user might have no problems to extract the correct bytes with kind of any tool that can read bytes from the volume... but any deviation from the original steps in the guide *might* introduce errors that could be avoided. dd.exe also exists for windows users and you could simple use it within a cmd window (command prompt).
I'm not sure what you mean by permutations. Hashcat and hashcat-utils support a huge set of different manipulation of the input (in general the input are password candidates).
you could use the --stdout command line argument of hashcat to see the password candidates that hashcat generates.
This might be interesting in this regard: https://hashcat.net/wiki/doku.php?id=rule_based_attack
and https://hashcat.net/wiki/doku.php?id=hashcat_utils and https://hashcat.net/wiki/doku.php?id=princeprocessor and https://hashcat.net/wiki/#core_attack_modes etc
With dictionary attack + rules you could cover many password candidates of course it depends on how your "permutations" should look like.
Mask attack (-a 3) is normally not a good idea for very, very slow hashing algorithms (like veracrypt). A full brute-force should be avoided. of course! mask attack only makes sense with a very reduced number of chars and a limited length of the mask (the overall keyspace should be very small. if this is the case, a small mask could make sense in very rare scenarious, but again the other types of manipulations, e.g. rules, should be preferred in general).
For some attack modes you have the choice of either pre-generating a dictionary or use the built-in attack modes that are supported by hashcat. In most cases it doesn't make sense to pre-generate very large dictionary files, if hashcat already has built-in support for the manipulation (using the built-in attack could save a lot of disk space and most importantly I/O).
In some situations it also makes sense to use a pipe "|" and therefore "send" the output of one tool directly into the stdin (standard input) of hashcat. There are some advantages and disadvantages also with this approach (e.g. resume, quit and restore might be little bit more complicated with pipes etc).
Again, most manipulations can be done as simple as this:
where 13721 must be replaced with the correct hash type and my_specific_rules.txt is a file containing rules (one per line) that are kind of hand crafted for this specific attack (you could just have a look at the wiki or at the rules folder of hashcat to see some example rules).
An advanced user might have no problems to extract the correct bytes with kind of any tool that can read bytes from the volume... but any deviation from the original steps in the guide *might* introduce errors that could be avoided. dd.exe also exists for windows users and you could simple use it within a cmd window (command prompt).
I'm not sure what you mean by permutations. Hashcat and hashcat-utils support a huge set of different manipulation of the input (in general the input are password candidates).
you could use the --stdout command line argument of hashcat to see the password candidates that hashcat generates.
This might be interesting in this regard: https://hashcat.net/wiki/doku.php?id=rule_based_attack
and https://hashcat.net/wiki/doku.php?id=hashcat_utils and https://hashcat.net/wiki/doku.php?id=princeprocessor and https://hashcat.net/wiki/#core_attack_modes etc
With dictionary attack + rules you could cover many password candidates of course it depends on how your "permutations" should look like.
Mask attack (-a 3) is normally not a good idea for very, very slow hashing algorithms (like veracrypt). A full brute-force should be avoided. of course! mask attack only makes sense with a very reduced number of chars and a limited length of the mask (the overall keyspace should be very small. if this is the case, a small mask could make sense in very rare scenarious, but again the other types of manipulations, e.g. rules, should be preferred in general).
For some attack modes you have the choice of either pre-generating a dictionary or use the built-in attack modes that are supported by hashcat. In most cases it doesn't make sense to pre-generate very large dictionary files, if hashcat already has built-in support for the manipulation (using the built-in attack could save a lot of disk space and most importantly I/O).
In some situations it also makes sense to use a pipe "|" and therefore "send" the output of one tool directly into the stdin (standard input) of hashcat. There are some advantages and disadvantages also with this approach (e.g. resume, quit and restore might be little bit more complicated with pipes etc).
Again, most manipulations can be done as simple as this:
Code:
hashcat -m 13721 -r my_specific_rules.txt extracted_512_bytes.bin dict.txt