Well, if it wasn't really clear yet, this specific algorithm is not supported yet by hashcat since you can't really extract a hash, but need to generate the AES-XTS keys on-the-fly and verify the decryption on-the-fly to check the crc32 checksum (or just the "DCRP" sequence of bytes if you allow some/several false positives).
It's not the most difficult kernel to implement, because most of the stuff should be already in hashcat (like the AES decryption and PBKDF2-HMAC-SHA512 hashing (in your case the AES key generation)).
It could make sense to implement just the bare minimum for you (like the -a 3 = mask attack OpenCL kernel, well it will be a so-called "slow" kernel anywasys with init/loop/comp kernel functions
) and that might be feasible and cost/time effective.
It would also make sense to provide and/or generate some examplles.
I think the correct password and the first 2048 bytes of the volume (i.e. the encrypted volume header including the very important 64 bytes of salt see https://diskcryptor.net/wiki/Volume) should be enough to at least come up with a POC verify script.
It's needless to say that you should of course make backups of the data you want to recover and make sure there is no further attack vectors (disconnect everything from the networks) that the attackers could use to make it even worse (maybe contacting a data recovery (forensic) company or a professional security company should be considered too, before you make even *more?* mistakes).
It's not the most difficult kernel to implement, because most of the stuff should be already in hashcat (like the AES decryption and PBKDF2-HMAC-SHA512 hashing (in your case the AES key generation)).
It could make sense to implement just the bare minimum for you (like the -a 3 = mask attack OpenCL kernel, well it will be a so-called "slow" kernel anywasys with init/loop/comp kernel functions
) and that might be feasible and cost/time effective.It would also make sense to provide and/or generate some examplles.
I think the correct password and the first 2048 bytes of the volume (i.e. the encrypted volume header including the very important 64 bytes of salt see https://diskcryptor.net/wiki/Volume) should be enough to at least come up with a POC verify script.
It's needless to say that you should of course make backups of the data you want to recover and make sure there is no further attack vectors (disconnect everything from the networks) that the attackers could use to make it even worse (maybe contacting a data recovery (forensic) company or a professional security company should be considered too, before you make even *more?* mistakes).