My Bitcoin’s locked into Veracrypt container- 2 BTC to solve
#1
Hello everyone!
I have a critical problem that I have been trying to solve for over a week,
I have created a paper wallet with all my Bitcoin and saved it in a VeraCrypt encrypted file.
When I insert the file and run it with hashtcat 4.0 in search of password using a dictionary attack.
I remember that the password was about 60 characters.
The encryption type is Serpent (Twofish (AES)).
I prepared a list of passwords of about 10,000 records.
But when I try to activate it stops after only one time.
I checked the file using the Hex editor and saw that the initial offset is registered "00000000000000 ....." and the code actually begin only after about 100 lines.
I attach a picture at the beginning of the hex segment. I think there's a chance there's a problem in the container file.


 please help me!

Promising a prize of 2 Bitcoin ($ 12,500 at present).

Thanks!
#2
There's no picture attached
#3
@atom

https://imgur.com/3StD7lD
#4
Are you sure that you read the guide? see https://hashcat.net/wiki/doku.php?id=fre...pt_volumes

It basically follows the same steps that are also used for TrueCrypt. That means that if you have a boot volume you need to extract 512 bytes from offset 31744 (62 * 512).

Your offset from the picture (0xd000 = 53248) is not the correct offset.

Btw. you also need to know if hmac-ripemd160 or hmac-sha256 was used to encrypt the boot volume (in addition to the Twofish-Serpent algo), for all details see the output of --help (and have a look at all the 137XY = VeraCrypt hash types that are supported).
#5
(11-03-2017, 01:27 PM)philsmd Wrote: Are you sure that you read the guide? see https://hashcat.net/wiki/doku.php?id=fre...pt_volumes

It basically follows the same steps that are also used for TrueCrypt. That means that if you have a boot volume you need to extract 512 bytes from offset 31744 (62 * 512).

Your offset from the picture (0xd000 = 53248) is not the correct offset.

Btw. you also need to know if hmac-ripemd160 or hmac-sha256 was used to encrypt the boot volume (in addition to the Twofish-Serpent algo), for all details see the output of --help (and have a look at all the 137XY = VeraCrypt hash types that are supported).


Offset 31744 is “00000000000000” until offset 53248.
I think that was sha-512
#6
I think that you are looking at the whole disk instead of just the VeraCrypt boot volume.

Anyways, in your specific case, from offset 0xd000 (where the bytes ea 1e 7c 00 00 20 56 65 72 61 43 72 79 70 74 20 are, including the string "VeraCrypt") you need to skip 31744 bytes and extract 512 bytes after it.

I.e. (again in your specific case if you include the additional/preceding 0xd000 bytes) only 0x14C00 (84992) to 0x14DFF (85503) are interesting for us

the 512 bytes that you extract should look really random and should not contain a fixed string and should also not contain several zeros one after each other (it should look like really good random data).
#7
(11-03-2017, 09:27 PM)philsmd Wrote: I think that you are looking at the whole disk instead of just the VeraCrypt boot volume.

Anyways, in your specific case, from offset 0xd000 (where the bytes ea 1e 7c 00 00 20 56 65 72 61 43 72 79 70 74 20 are, including the string "VeraCrypt") you need to skip 31744 bytes and extract 512 bytes after it.

I.e. (again in your specific case if you include the additional/preceding 0xd000 bytes) only 0x14C00 (84992) to 0x14DFF  (85503) are interesting for us

the 512 bytes that you extract should look really random and should not contain a fixed string and should also not contain several zeros one after each other (it should look like really good random data).

Thanks for answering.
1 question.. 0x14C00 - 0x14DFF is 1KB and not 512 bytes. what I have to do?
BTW in which option to use in hashcat? 13722 is fine or another?
#8
No, that is not true. Your math is flawed:

0x14DFF-0x14C00 = 511

but remember between 0x14DFF (included) and 0x14C00 (included) their are 512 bytes. The same principle holds that is between 1 and 10 there are 10 - 1 + 1 (and therefore ten) numbers and not just 10 - 1 numbers (1,2,3,4,5,6,7,8,9,10).

Therefore the bytes between 0x14C00 and 0x14DFF are 512 bytes.

We can do the same with decimal numbers:

0x14DFF is 85503 and 0x14C00 is 84992

our math is x - y + 1 and therefore:
85503 - 84992 + 1 = 512 bytes

I hope this convinces you that your statement about the 1KB is completely incorrect.

Maybe you did extract it incorrectly or you did use the hex interpretation instead of the raw (binary) bytes.

hashcat expects 512 of raw/binary bytes.

Also note that:
- 1. there are several examples on https://hashcat.net/wiki/example_hashes also for VeraCrypt hashes
- 2. you should generate a new VeraCrypt volume/file with the exact same procedure you used to generate the original one and try to crack it (just to test that you are doing everything correctly and that hashcat works on your system)
- 3. you either need to remember the hashing algorithms and encryption algorithms or run all of them. There are only 2 hashing algorithms supported by VeraCrypt when using the boot mode, so you only need to test 2 different hashing algorithm if you are sure that you've used the boot mode option (if your system is starting with the VeraCrypt Bootloader). All modes are listed also within the --help output



Update: Please also tell us how exactly the VeraCrypt volume/file was created and which file/dump you use as input.
Is this a hidden partition, an entire encrypted drive, hidden operating system? Do you try to use the Recovery/rescue disk? How did you create the dump and where exactly did you find this "VeraCrypt Boot Loader" string (somewhere on the file system? within a file? at the start of a partition? at the start of a disk?) ? It's important to understand and distinguish these different types of VeraCrypt encrypted blobs, otherwise you might run a cracking job for several hours/days and the input data is not even the correct one (as said, best would be to try to generate an example that is almost exactly the same as the targeted one, except that you know the password for this new example, while you do not exactly remember the password for the one you try to crack).



update2: if you are sure that Serpent(Twofish(AES)) was used as encryption algorithm then -m 13722 is definitely the wrong hash type, you would need to use some hash type ending with the digit 3, e.g. -m 13723 if you are sure that PBKDF2-HMAC-SHA512 is used as hashing algorithm (but note: this mode is not supported by VeraCrypt as an algorithm for the boot mode, only -m 13743 (ripemd160) and -m 13763 (sha256) are supported by VeraCrypt for the boot mode)