hashcat Forum - Recovering an encrypted file

Hi,

as from the topic you might gather, this probably isn't the typical use-case for hashcat (or at least that's my understanding), but my problem is kind of inverse from the usual cracking problem. Short story long, I've had a filesystem corrupted making me unable to recover any of the encrypted Veracrypt files located there. As Veracrypt doesn't have any plaintext headers, it's basically impossible to find the files without going through every block and try to decrypt the first 68 bytes (well, use the first 64 bytes as the salt and then try to decrypt the next four and see if it decrypts to VERA).

So, I know the password and plaintext (VERA), I do not know the salt, KDF nor the cipher. And to top it all, I don't know even where the file is located. Assuming that salt and header have not been corrupted and the files are not extremely fragmented, I should have a chance to recover the data at least partially.

I already made a simple python script using fastpbkdf2 and cryptoplus libraries, but using CPU it's just way too slow (cascade ciphers make the KDF quite slow). Question is, could I utilize hashcat for this purpose? If yes, then I shall delve into hashcat's manuals more deeply, but if not.. could I utilize the OpenCL kernels from hashcat?

Or does my reasoning have a glaring hole somewhere and I just made myself a clown? Smile

(11-01-2018, 07:20 PM)nn55 Wrote: [ -> ]Short story long, I've had a filesystem corrupted making me unable to recover any of the encrypted Veracrypt files located there. As Veracrypt doesn't have any plaintext headers, it's basically impossible to find the files without going through every block and try to decrypt the first 68 bytes (well, use the first 64 bytes as the salt and then try to decrypt the next four and see if it decrypts to VERA).

Actually this is more of a data-recovery/computer forensics question than a crypto question as far as I can tell. Depending on the filesystem in use, and the current state of the the filesystem remnants it may be possible to do a full recovery of the files in question.

I would think that taking the existing remnants of the filesystem into account would give you a much higher chance of success than the sector by sector brute-force attack you describe.

Your best bet would be to contact a data recovery professional, with extensive expertise in parsing damaged filesystems.

Good luck!

(11-02-2018, 11:13 AM)jallis Wrote: [ -> ]Actually this is more of a data-recovery/computer forensics question than a crypto question as far as I can tell. Depending on the filesystem in use, and the current state of the the filesystem remnants it may be possible to do a full recovery of the files in question.

Yeah, you are correct about that. The thing is that basically all traditional methods of recovery that I could imagine of have been exhausted (with the exception of resorting to expensive recovery services). As nothing of value was lost, this is could be thought more of an academic exercise.. and it might even be helpful for other people who get their filesystems corrupted.

Maybe a more suitable question for this forum would be: is there any way of passing hashcat a list of salts and a list of passwords and get the resulting derived keys as the output? This way the most taxing work would be done by hashcat and I could then use the results to bruteforce my way to the stars. I doubt this is possible though without poking the source code. I guess my safest bet is to try to understand the OpenCL kernels if they're anyhow usable for my purpose.

hashcat supports veracrypt with the hash modes

Code:
137XY | VeraCrypt

     X  | 1 = PBKDF2-HMAC-RIPEMD160

     X  | 2 = PBKDF2-HMAC-SHA512

     X  | 3 = PBKDF2-HMAC-Whirlpool

     X  | 4 = PBKDF2-HMAC-RIPEMD160 + boot-mode

     X  | 5 = PBKDF2-HMAC-SHA256

     X  | 6 = PBKDF2-HMAC-SHA256 + boot-mode

      Y | 1 = XTS  512 bit pure AES

      Y | 1 = XTS  512 bit pure Serpent

      Y | 1 = XTS  512 bit pure Twofish

      Y | 2 = XTS 1024 bit pure AES

      Y | 2 = XTS 1024 bit pure Serpent

      Y | 2 = XTS 1024 bit pure Twofish

      Y | 2 = XTS 1024 bit cascaded AES-Twofish

      Y | 2 = XTS 1024 bit cascaded Serpent-AES

      Y | 2 = XTS 1024 bit cascaded Twofish-Serpent

      Y | 3 = XTS 1536 bit all

you could use the modes 13713, 13723, 13733, 13753 (for non-boot disks) if you really have no clue about the hashing used.

Both truecrypt and veracrypt as far as I know do not really have a header (meta information), LUKS, for instance, instead has a header with all this information.

here are example hashes: https://hashcat.net/wiki/doku.php?id=example_hashes
and here is an explanation on how to extract the data: https://hashcat.net/wiki/doku.php?id=fre...pt_volumes

I would recommend that you try to create similar volumes/disks and crack them as a test before cracking the target data (just to be sure that you are using the correct steps).

(11-02-2018, 07:15 PM)philsmd Wrote: [ -> ]Both truecrypt and veracrypt as far as I know do not really have a header (meta information), LUKS, for instance, instead has a header with all this information.

Yeah, that's correct. The header itself is encrypted making it (nigh) impossible to distinguish the file from random data without the filesystem metadata or using black magic.

(11-02-2018, 07:15 PM)philsmd Wrote: [ -> ]and here is an explanation on how to extract the data: https://hashcat.net/wiki/doku.php?id=fre...pt_volumes

I was sure the first thing I checked was the FAQ, but I guess I didn't do it well enough. Thanks for the tips, will check that out!

To pinpoint the header of your Veracrypt file you can calculate the Shannon entropy on all the sectors (or better clusters) of the filesystem. High entropy files are easily recognizable in this way (shannon entropy very close to eight, e.g. 7.999). This gives you an indication of where the Veracrypt header might start in the corrupted filesystem. Assuming the file was initialized on a not heavily fragmented filesystem it should be a continues block of high entropy. By plotting the entropy gives you a nice overview. A tools capable of doing this is e.g. is binwalk but you can also use rdd (https://sourceforge.net/projects/rdd/) which writes block entropy's to a file that can be plotted with gnuplot using an included pythonscript.

Good luck

(11-03-2018, 11:56 AM)lapwing Wrote: [ -> ]To pinpoint the header of your Veracrypt file you can calculate the Shannon entropy on all the sectors (or better clusters) of the filesystem. High entropy files are easily recognizable in this way (shannon entropy very close to eight, e.g. 7.999). This gives you an indication of where the Veracrypt header might start in the corrupted filesystem. Assuming the file was initialized on a not heavily fragmented filesystem it should be a continues block of high entropy. By plotting the entropy gives you a nice overview. A tools capable of doing this is e.g. is binwalk but you can also use rdd (https://sourceforge.net/projects/rdd/) which writes block entropy's to a file that can be plotted with gnuplot using an included pythonscript.

Good luck

Yeah I was looking into calculating the entropy and plotting it, but since I'm not the sharpest marshmallow stick on a campfire I didn't get very far with it. Thanks for letting me know about those tools, I will surely try them out!

What a nice piece of software that binwalk is: found some really nice candidates where to target first.

Tried also out hashcat Veracrypt modes, seems to work but as I can only pass a single hash in the "hashlist" it doesn't do much good.. unless I've misunderstood something ( https://hashcat.net/forum/thread-7668.html )?

Is there any way to use the mode 12100 and get the derived keys as a result in the outfile (with or without poking the source code)? That way I could at least offload most of the work to the GPU. But I guess the hash comparison is done in-kernel and no hashes are read back from the GPU?