I want to know if the hashcat software supports getting the hash for me if I supply the encrypted container file on the commandline?
Because, that's what I've been trying and I am not having any success in hashcat cracking my "known" password.
I'm giving hashcat all characters of my password except 1 letter and it's not finding the password. But the target.hash shows up as the encrypted container file and not the hash itself, so I would really like to see this software update the user better about what it found and what it is doing. Like, "Processing encrypted container", "Found Encrypted Container Hash", and show the real hash target and not just the filename.
The flexibility to allow the dumb end-user to provide the TrueCrypt/VeraCrypt container name and have the hashcat get the hash for them would be incredibly wonderful.
Is this functionality present now, and can it be in the future?
and no, this type of hashcat will do everything for you will not happen (except the basic hash guessing)
the user has to know what he is doing, what he is attacking and he is in charge to prepare the target, hashlists, wordlists, masks, rules and so on (there are penty examples already shipped)
EDIT:
True/Veracrypt attack input is binary data, so you will "see" no hash for this, also, you have to provide a outputfile otherwise your found password is only shown on command line and maybe you missed it
02-04-2022, 01:23 PM (This post was last modified: 02-04-2022, 02:06 PM by 4Str4yC4t.
Edit Reason: I felt it necessary and I'm human? More data was added for the discussion.
)
(01-30-2022, 08:03 PM)Snoopy Wrote: you will need the first 512 bytes of the container see
and no, this type of hashcat will do everything for you will not happen (except the basic hash guessing)
the user has to know what he is doing, what he is attacking and he is in charge to prepare the target, hashlists, wordlists, masks, rules and so on (there are penty examples already shipped)
EDIT:
True/Veracrypt attack input is binary data, so you will "see" no hash for this, also, you have to provide a outputfile otherwise your found password is only shown on command line and maybe you missed it
Thank You very much for your response. So, what's happening when I supply the name of an actual True/VeraCrypt container file is that hashcat is literally thinking the filename is the hash. If this is the case, it's no wonder I'm not having any success.
I have since created a distinct hashfile using a disk editor to pull the first 512 bytes into a file.
If the software will not hold my hands then it maybe it could use tough love on me and at least respond with a message that tells me what I am attempting to do is going to produce no good results. A simple filesize check could throw up a warning at least. "The has you have provided is not 512 bytes in size. Are you sure you are providing a hash?" Or whatever size is appropriate for the encryption at hand.
As a programmer myself, I know it would be very easy to check and see if the "hash" supplied by the end user ends in an extension of .tc (or .vc for veracrypt?) as well. This could be another "red flag".
Lastly, I've read a post somewhere that says if you always select one of the 1536 bit methods of TrueCrypt/VeraCrypt this will allow you to skip the others if you don't know exactly how you encrypted it to begin with.
There are literally like 36 different options for TrueCrypt/VeraCrypt and 12 of those are the 1536-bit methods. I have no idea what encryption I used. Is my safest but assured bet to try the 12 1536-bit "-m" options to crack my TrueCrypt/VeraCrypt passwords?
I read somewhere in another post that the 1536-bit methods will default to taking care of the lesser bit options but I don't think it works the other way around.
No, I'm not missing my password. I'm looking at the 0/1 digest stat in the application. 0/1 I'm assuming means no luck for me.
so yeah, higher mode also succesfully decrypts lower ones AND hashcat accepts the full container (i assume it just reads the first 512 bytes) but i wouldnt take a bet that this also works with containers with some hundrets of gigabytes
02-04-2022, 03:40 PM (This post was last modified: 02-04-2022, 04:05 PM by 4Str4yC4t.)
(02-04-2022, 03:24 PM)Snoopy Wrote: i made a test setup, generating a little veracrypt container vc-1234 of just 1mb, all settings standard, pw is 1234
so yeah, higher mode also succesfully decrypts lower ones AND hashcat accepts the full container (i assume it just reads the first 512 bytes) but i wouldnt take a bet that this also works with containers with some hundrets of gigabytes
are we talking about a TRUECRYPT or VERACRYPT Container?
For Veracrypt Sha512 XTS 512 seems the default, the latest truecrypt 7.1a was using rimpemd-160 XTS 512
Ah, the student schools the master. then hashcat "does" accept the actual container as command-line input for getting the hash? Nice. That might be made more explicit somewhere in the --help screens or just added to the official FAQ.
My containers are 25GB in size so that I can burn them to BD-R if I want.
But why would either TrueCrypt or VeraCrypt pull the first 512 bytes of a container and concern itself with how big the container is? As a programmer, once again, that doesn't make sense to me that it would fail on a big container size. What's your reasoning there?
Pseudo-Code: Get first 512 bytes of container file. Done!
I "think" my 25GB container was made with TrueCrypt but I have no issues mounting it up with VeraCrypt. This brings up another good question though that I don't know the answer too. Are the two applications mutually exclusive in terms of mounting containers? I'm not opting in to use "TrueCrypt Mode" when I mount it so does that mean it "must be" a VeraCrypt volume? I don't know.
And where are the AES, TWOFISH, BLOWFISH options in the --help?
02-04-2022, 04:50 PM (This post was last modified: 02-04-2022, 05:01 PM by Snoopy.)
im talking about hashcat, not tc or vc and how they act with the container
i know, that hashcat for example loads the contents of a wordlist, hahslist etc. fully into ram, but as i mentioned, i dont know how hc act with this container input
i used old truecrypt to generate containers with ripe and sha512 and i was not able to mount them unless i opt-in truecrypt mode, if im right, verycrypt changes the iteration count, cause this was one point mentioned when the truecrypt code was reviewed
the options are showed when creating the volume/container, see attachment
but when mounting, new veracrypt test all these options on the fly, so you dont have to specify them manually, so they only diff in speed, AES should be always the fastest, because most computers have this acceleration in hardware
EDIT: so yeah, your container should be a veracrypt container and therefore mode 13721 should do the trick, unless you diddnt manually specify another algorithm
02-04-2022, 05:59 PM (This post was last modified: 02-04-2022, 06:12 PM by 4Str4yC4t.)
You literally stated in your message that:
"AND hashcat accepts the full container (i assume it just reads the first 512 bytes) but i wouldnt take a bet that this also works with containers with some hundrets of gigabytes"
I think you're a bit confused.
But that issue aside maybe you can answer this question for me. How do I translate something like a triple encryption method with these funny words into the actual mode I'm supposed to select? There is not a 1 to 1 correlation? For instance, if I selected, from the image you posted, the triple AES(TwoFish(Sepent)). What the hell mode does that correspond to in the VeraCrypt HashCat options?
i do not know how or what hascat really does when providing the container as input, so it COULD be a difference in providing a 1mb container compared to a 500 GB container, IF hashcat just reads the first 512 bytes then everything should work as intended, if hashcat throws an error, i would stick to "plz give me just the first 512 bytes okay?"
the encryption algorithm doesnt* really matters, all what matters is the hashalgorithm, if you read the article (its from 2010, so it seems i missed some details over the years)
*as you can see from the article, the 512, 1024, 1536 bit correspondend with the double and tripple encryption from the first options, as you can also read in the article, this doesnt really matter (for hashcat), all what you have to know is the hashing algortihm (see attached picture) thats the reason why you can crack XTS 512 with 1024 and 1536 bit, because the first 512 ar allways the same
