How important is it to know the password ? Is that your most important goal or do you just want to decrypt and extract the data ?
As far as I understand (and yeah I've just quickly tested it), VIM's old encryption (VimCrypt~01!) just uses the encryption algorithm from the old pkzip ZIP format, but without compression. That's already very good for you, because compression/encoding would probably make an attack more difficult and complex (for instance it could otherwise happen that you do NOT know the exact plaintext, because it could otherwise be compressed with varying compression options, but that's NOT the case for VimCrypt, it seems).
There are tools like vimzipper (vimzipper.c) or vimdecrypt (-w option) that help you to create a zip file from a VimCrypt file, but the problem here is that it doesn't help much because the main information that would be needed to test if a password is correct (a checksum for instance) is already missing in the VimCrypt file. Therefore the step to convert a VimCrypt file to an actual .zip file is quite useless (it would just add some zip header/metadata around the encrypted data), you can directly use the original VimCrypt file with the attack explained below.
The only working method is a known plaintext attack (but this also means you NEED to know or guess what's inside the decrypted/raw file, best case would be if you know the starting characters), even VIM doesn't seem to know when a password is correct, it just opens the file with whatever password you give it (there is no CRC32 checksum or similar), therefore with the wrong password it looks like garbage (because of a wrong pass/key).
So you need to know some plain text from the file. Best would of course be that you know the exact sequence of characters from the start of the file.
Use bkcrack or pkcrack for the known plaintext attack on zip (PKZIP) files, this also works for VimCrypt files (don't get confused about this recommendation, hashcat can still come handy later on when it comes to guessing the actual password, but won't really help much when we just try to match ciphertext to plaintext, i.e. the master key recovery which has little to do with "hashes").
The header is 12 bytes at the start of your target vim encrypted file (VimCrypt~01!), skip/remove this (with dd or hex editor) and save these raw bytes into a new file cipher.bin, i.e. the file cipher.bin will be almost the same as your original file, for instance named vim_encrypted_file.txt, but with the 12 byte header removed.
Code:
dd if=vim_encrypted_file.txt of=cipher.bin bs=1 skip=12
To recover the master key, you would need to run bkcrack/pkcrack like this (bkcrack is faster in my experiments):
Code:
bkcrack -o -12 -e -c cipher.bin -p plain.txt
or with pkcrack instead (just slower ?):
Code:
pkcrack -o -12 -c cipher.bin -p plain.txt
The plaintext (stored in the file plain.txt in the example below) is the text you would expect at the start of the decrypted/raw file (must at least be 12 chars long, the more the better).
ATTENTION: make sure that the file plain.txt (containing the paintext, the known text) doesn't contain new lines (\n or \r) or other whitespace (spaces or tabs) that shouldn't be there. Especially the ending is important, remove all new lines if they should NOT be in the known plaintext. Text editors often add new lines at the end of a file, you must remove them with either a good text editor (vim?
) or by using a hex editor, or use something like this instead:
Code:
echo -n "This is the known plaintext at the start of the file" > plain.txt
(This could be the text at the start, replace it with your known plaintext, the -n option is important)
This actually is also true for cipher.bin, it shouldn't contain any added/wrong bytes, use a hex dumping tool or hex editor to be sure (or use the dd command from above, which for sure adds no new line at the end) and double-check it against the original vim file vim_encrypted_file.txt (the only difference is that 12 bytes from the start are missing).
Setting the offset of the plaintext (-o 12 , see parameter above) is important to get the correct master key that can be cracked with hashcat. If you do not need the password, you could probably make it work ("only" the decryption) also without this offset AND without skipping the first bytes from the original file vim_encrypted_file.txt (i.e. cipher.bin could be the same as vim_encrypted_file.txt if you do not want to crack the password if you use -o 0, or the default option without the -o option). It's important that you understand the difference and that a key (that can decrypt your files perfectly fine by using the bkcrack/pkcrack decryption features, -d decrypted_output.txt) won't be the same and won't be crackable (by hashcat etc) with the "correct password" if you do not use the skip header approach (-o 12). The keys you get WITHOUT the offset set correctly and WITHOUT cipher.bin generated by the dd or hex editor trick above, won't be crackable with the original password (different input/offsets imply different keys, these keys might not be wrong for decrypting the file, but definitely wrong for recovering the password).
You can crack the master key (3 keys are in the output of bkcrack/pkcrack, but you just format it by padding the 3 times 8 hex blocks with zeros - if needed -, 3 * 4 bytes = 12 bytes but converted to hex as the output of bkcrack/pkcrack does, and removing the spaces, concatenate them, see example hash with hashcat's --example-hashes option, 24 hex char hash) that bkcrack/pkcrack gave you with hashcat mode -m 20500 or -m 20510 (the password candidates for -m 20510 should be given WITHOUT the first 6 bytes/chars):
Code:
hashcat -m 20500 -a 0 -w 3 hash.txt dict.txt
Code:
hashcat -m 20510 -a 0 -w 3 hash.txt dict_without_first6.txt
(hash type -m 20510 of course only works if the password itself is longer or equal to 6 chars and the input or password candidates you provide do not include the first 6 chars)
It's needless to say that all of this only works for the PKZIP/zip like algorithm (VimCrypt~01! must be at the start of the file, vim option
). Therefore, for any other forum users here that have a newer VimCrypt file, this method WON'T WORK.
It's also important to stress again that you need to be very careful which data you provide to bkcrack/pkcrack, double-check the input to make sure that the data is correct and has no wrong/additional bytes. You could get very wrong results/keys if you are not careful enough.
BTW: you can find pkcrack/bkcrack/vimdecrypt etc all on
https://github.com