It depends on how much and what you exactly remember about the missing characters.
Do you know their position (missing chars at the end, at the beginning, can be everywhere, ...) ?
Can you limit the characters to a specific set of characters (charset), i.e. do you know if they are all numbers, lower letters etc?
etc...
3 characters indeed doesn't sound "that bad", but it's also important to realize that veracrypt is a quite slow algorithm and that you really should try to first think about the best attack and most likely password candidates, which you should run first.
Well, since veracrypt is a quite slow algorithm, it doesn't matter too much if you are running a dictionary attack, or a mask attack or a rule based attack etc... the speed will almost be the same because the algorithm is very slow and disk I/O etc can be neglected here.
Therefore, you could for instance just use a mask attack with custom charsets (see https://hashcat.net/wiki/doku.php?id=mas...m_charsets) or if the total number of candidates is very small (and it should be because veracrypt is a hard algorithm) you could generate a dictionary where all most likely passwords are at the beginning of the file.
What does this mean? that for algorithms like veracrypt the speed difference between several attack modes (-a x) isn't really noticeable, but the most important thing is that you are prioritizing your password candidates (most likely passwords should be tested first).
when it comes to cracking, I would suggest that you generate a new test veracrypt file (with a known and maybe similar password) and test the whole extraction (https://hashcat.net/wiki/doku.php?id=fre...pt_volumes) and cracking process by trying to crack this test "hash" first.
There are unfortunately a lot of people that we know messed up some steps here (mostly extracting the correct sequence of bytes) and therefore waste a lot of cracking time by running a "uncrackable hash" (because it's the wrong data etc). I would say it's important to get the feeling about how it is to extract and crack the (test) hashes correctly first and you shouldn't skip this testing step (btw there are also some "hashes" available here: https://hashcat.net/wiki/example_hashes , but it's important to note that these are already extracted "hashes" and the step that many mess up is the one before you get the hash, i.e. the "dd" extraction etc). You could/should play with both the wiki hashes and your own newly generated veracrypt-encrypted file with known test password.
you could for instance use maskprocessor or hashcat --stdout to generate some password candidates (if you want to launch a dictionary based cracking session), but if you really need to "brute-force" all the missing characters because you have no clue about what these characters could be, I would recommend to use -a 3 (mask attack) instead (with custom charsets).
Good luck
Do you know their position (missing chars at the end, at the beginning, can be everywhere, ...) ?
Can you limit the characters to a specific set of characters (charset), i.e. do you know if they are all numbers, lower letters etc?
etc...
3 characters indeed doesn't sound "that bad", but it's also important to realize that veracrypt is a quite slow algorithm and that you really should try to first think about the best attack and most likely password candidates, which you should run first.
Well, since veracrypt is a quite slow algorithm, it doesn't matter too much if you are running a dictionary attack, or a mask attack or a rule based attack etc... the speed will almost be the same because the algorithm is very slow and disk I/O etc can be neglected here.
Therefore, you could for instance just use a mask attack with custom charsets (see https://hashcat.net/wiki/doku.php?id=mas...m_charsets) or if the total number of candidates is very small (and it should be because veracrypt is a hard algorithm) you could generate a dictionary where all most likely passwords are at the beginning of the file.
What does this mean? that for algorithms like veracrypt the speed difference between several attack modes (-a x) isn't really noticeable, but the most important thing is that you are prioritizing your password candidates (most likely passwords should be tested first).
when it comes to cracking, I would suggest that you generate a new test veracrypt file (with a known and maybe similar password) and test the whole extraction (https://hashcat.net/wiki/doku.php?id=fre...pt_volumes) and cracking process by trying to crack this test "hash" first.
There are unfortunately a lot of people that we know messed up some steps here (mostly extracting the correct sequence of bytes) and therefore waste a lot of cracking time by running a "uncrackable hash" (because it's the wrong data etc). I would say it's important to get the feeling about how it is to extract and crack the (test) hashes correctly first and you shouldn't skip this testing step (btw there are also some "hashes" available here: https://hashcat.net/wiki/example_hashes , but it's important to note that these are already extracted "hashes" and the step that many mess up is the one before you get the hash, i.e. the "dd" extraction etc). You could/should play with both the wiki hashes and your own newly generated veracrypt-encrypted file with known test password.
you could for instance use maskprocessor or hashcat --stdout to generate some password candidates (if you want to launch a dictionary based cracking session), but if you really need to "brute-force" all the missing characters because you have no clue about what these characters could be, I would recommend to use -a 3 (mask attack) instead (with custom charsets).
Good luck