VeraCrypt dictionary attack
#1
Tongue 
Hi everyone Smile

I'll try to be the most precise I can about my problem.
My problem is certainly very common I guess, but I'm still stuck Tongue

I've recently created an encrypted Veracrypt container with a password that I've (obviously) forgotten.
As far as I know myself, I've probably (with a certitude >90%) used these settings :
- Encryption algorithm : serpent(twofish(AES)) or AES(twofish(serpent))
- Hash : SHA-512 or SHA-256 (surely not whirlpool because I know its weakness)
- Password : I don't remember, but I've created a dictionary with Python so that I'm sure one of these combinations is valid (actually I just don't remember the order in which I've put the words in my passphrase)

So my problem is "basic".
I'm running hashcat like so (on W7U) "hashcat64.exe -a 0 -m ?* "path to Veracrypt volume" "path to .dict" "
But it didn't work.

*For the -m I've used once each of 13713, 13723, 13733, 13753. If I did it wrong, that wouldn't surprise me Big Grin


As I'm absolutely sure that one of the 6400 combinations created with my Python script is valid, I thought that there was a problem in my way of "trying to crack the hash".

So I've created a new container with one password from the .dict that I'd created.

And I've done the same process as above.
And that didn't work.

So now I know that I'm making a mistake in my way of manipulating hashcat.

Does someone have any idea about how I could find either the right -m either solve my problem ?


I'd be really thankful if I can get the answer because I've some data inside that aren't anywhere else Sad


PS: One more precision.
I've tried each -m listed above with the official hashcat examples from here https://hashcat.net/wiki/doku.php?id=example_hashes
I've used the -a 0 mode and a .dict where "hashcat" was stored.
And that worked perfectly.


So I'm really lost now.
Thank you ! Big Grin
#2
Most important question: how did you generate the binary data file needed for hashcat, did you follow this guide: https://hashcat.net/faq#how_do_i_extract...pt_volumes ?
#3
First I've tried to extract the 512 first bytes of the container (I don't know if I did well actually).
The output was a file made with strange chars and started with "p»ïÿå=+“‡{&°ÛÑîx:w¢".
So I don't know if I should have got a digest or a hex string or anything else, but I got that kind of strange things that I've quoted.

Then as it didn't work, I've used the whole veracrypt container (I've read in an other post that it was possible as well but longer)

So... Sad
#4
Well, if you are 100% sure that the extracted data is what hashcat expects, we might need to find the culprit somewhere else. For instance, you didn't tell us how long these password candidates are... are you sure that the total password length isn't longer than the maximum supported password length ?

(You can see the number of rejected password candidates within the status screen. It might also make sense to test it by creating a test veracrypt volume with different passwords, i.e. smaller length etc)
#5
To be honest I'm not sure of what I did about the extracted data. So maybe / probably the problem comes from here. I wouldn't be surprised.
If I could get further informations about how I can create precisely this binary file that would be for sure welcomed Big Grin

For my password, its length is of about 40 characters. I know that I'd decrypted it successfully one time at least (with the Veracrypt program). But when I retried an other day, I had forgotten the password. So it's possible to hash the password and it's not too long.
It if was, I would have never been able to decrypt it, right ? Confused

And for the rejected password, I used to get 0.00% on each try.
I've done what you tole me and I've created a volume with random data and the password 0123456789*. I've put it in a .dict and ran the attack -a 0 with the .dict against the volume.
And with the -m 13723 the status was "cracked" and got the "Candidates #1 : hashcat -> 0123456789*".
So that worked I guess.


PS: I don't know if I mentioned it, but for the "real volume" I used to get the "Exhausted" status at the end of the process.
Plus when I was trying to crack it, the "Candidates #1" line had a hex value starting with "$HEX[ hex value ] -> $HEX[ hex value ]". I don't know if Iit's possible to extract informations from this hex values ?
#6
Well, that might explain it ("its length is of about 40 characters")... see https://hashcat.net/faq#what_is_the_maxi...ord_length

so max 31 for -a 0 (40 is already too long).

But you might be able to use -a 1 which is able to handle 31 chars from the first dictionary and 31 from the second one (but not longer than 55 in total). So try to split the password candidates and use -a 1 dict1.txt dict2.txt

BTW: you should definitely see the rejected count be larger than 0, if the password candidates are too long.
$HEX[] encoding could also just mean that the password candidates include some special chars like the colon (":") etc.


Update: actually, the 31 limit should only be true for fast hashes (and I forget that we talk about -m 13723 here, a slow hash), unfortunately I'm not sure if the FAQ section for max. password for 137xx is up-to-date/correct. Maybe you can test and see what is the max. length that hashcat cracks (and we should update the FAQ accordingly)
#7
I tried what you told about. With the two dictionaries.
And that didn't work better than previously in the end Sad

---

I've also tried to crack a Veracrypt container with different length with these settings : -a 0 -m 13723.
First a pw of 50 chars has been cracked.
Then 60 chars didn't.
So I tried 55 chars and that didn't as well.
At 54 chars has  been successfully cracked.

So I guess that the maximum length is 54 for these settings.

Also, with all these tries, I must admit that probably I did wrong with my dictionary Sad
So I guess finally that the problem is that I don't own all possible combinations.
Maybe with some time I'll be able to remember some details of my passphrase :p

Thank you very much for your help ! Wink


Attached Files
.png   hashcat -m 13723.PNG (Size: 22.27 KB / Downloads: 9)