Another newbie question
#1
Didn't want to hijack that other topic, so i created a new one because my problem is similar but different nonetheless:

I have an encrypted VeraCrypt Volume (non-hidden) and I somehow must've managed to sneak in the same typo TWICE when I last changed the pw yesterday :( 

So I have a general idea what the pw is, only there must be a typo in it somewhere. I don't remember which encryption algorithm I used since it didn't really matter to me (so I suspect it's probably the one VeraCrypt uses by default) but I DO know the PIM I used, no chance of a typo there.

I don't know anything on how to use hashcat, but it was suggested to me as a tool that might be able to help me recover my encrypted files. If anybody could give me a step-by-step guide how to do it, I would be really grateful ;)
Reply
#2
It's always a good idea to create a new and similar volume (same settings/steps) and use this with a password (could also be similar to the one that you think was used) for testing hashcat.

The first step is to follow the guide here: https://hashcat.net/wiki/doku.php?id=fre...pt_volumes

of course you need to download the latest version of hashcat from https://hashcat.net/hashcat first and make sure that your OpenCL setup (GPU drivers etc) is working.

you can use the output of the command (use cmd to start hashcat) "hashcat --help" (without quotes) to see which veracrypt options are available.

To test your example volume (for which you know the password) you could just use a command as simple as this
Quote:hashcat -m 13721 extracted_512_bytes.bin dict.txt
where 13721 must be replaced by the correct hash type that you used to create the veracrypt volume (compare it with the output of --help), the file extracted_512_bytes.bin contains the 512 bytes extracted by following the guide on the FAQ (see link above) and the file dict.txt contains the password (1 password on each line, separated by newline).

If everything is working fine you could start running hashcat on your original volume (by following the same extraction steps and -m settings etc).
Reply
#3
Thank you for the fast reply and the tips. Unfortunately I have to work on the weekend so I won't have time to do it until Monday. A few more questions though:

I don't have a Unix system and no experience in using one, so could I use this tool for data extraction instead? https://mh-nexus.de/en/hxd/StarManSaveSectors.htm

Also, is there a way to automatically generate a dict.txt file with as many permutations of the intended password as possible? I think so, because if I had to create that file manually, I wouldn't have to use hashcat after all Tongue but I don't know how to do that...
Reply
#4
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:
Code:
hashcat -m 13721 -r my_specific_rules.txt extracted_512_bytes.bin dict.txt
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).
Reply