Using DD to get the hash of a non-system partition encrypted by VeraCrypt

Question

I am trying to use DD for Windows to obtain the hash of a non-system partition that was encrypted via Veracrypt, but have run into a bit of a problem.

The command I used to get the hash of the encrypted partition looks like this

dd if=\\?\Device\HarddiskVolume11 of=hash_output.txt bs=512 count=1

And this command (in theory) should create a file called hash_output.txt that contains the encrypted hash that should, for example, look something similar to this:

(Šö÷…o¢–n[¨hìî‹¬ùlŒ‡¬»J`<Q›þIšê1ªCúÍbÔcN„ÐŒ3+d.dWr€-¡tä66¶ˆÎ

However, the output I am getting when issuing the DD command above looks more like this:

fb55 d397 2879 2f55 7653 24a3 c250 14d3
3711 7109 e563 617f ab73 f11a 3469 33bb

Which is obviously not the hash I was expecting so I am hoping someone might be able to help me figure out what I am doing wrong.

Some things to note:

I am 100% positive that the drive I am selecting in the DD command is the right drive.
There is only 1 encrypted partition on the drive that spans the entire size of the drive.
There is no physical / functional damage to the drive which would cause this issue.
This on an external 1tb drive that is connected via usb 3.0 (I have tried other cables and ports).
The same DD command worked fine for a test drive that I encrypted using the same parameters that were set for this drive.

How does this dd command provide a hash? It just provides the first 512 bytes of the partition. And it looks like in one case you just dump binary data as text which makes strange but unusable output while in another case you dump data as hex. It is not clear for me what you are doing (like how you view hash_output.txt) and what you are are really expecting (again, it is not a hash). — Steffen Ullrich, Mar 28 '20 at 21:36
Ignoring the "its not a hash argument" for a moment, what I am trying to do, is get the HASH for the partition so that I can feed it to HASHCAT to crack a forgotten password. The "OUTPUT" that you are confused about is from 2 different drives that were both encrypted using the exact same parameters in Veracrpt, yet only the one that shows the garbled up text (whatever you want to call it) is actual data that Hashcat needs, and the other (non garbled example) is NOT hashcat needs and I simply wondered why I get diffrent results using the same parameters in Veracrypt and DD for both drives. — Stumpped, Mar 28 '20 at 22:04
I see, you want to extract the volume header since it contains the information needed by hashcat. Still, one output looks like binary dumped as text and the other like a hexdump. Still not clear how you generated these outputs, i.e. how you've viewed the generated file. But likely it is only the difference in viewing the file (binary vs. hex) which leads to the different output. — Steffen Ullrich, Mar 28 '20 at 22:12
I viewed them both output files in a text editor called Sublime Text 3 by simply right clicking on the file in Windows explorer and selecting "Open with Sublime Text". The files are both plain text files and even if I open them both in an something like Notepad for example, they show different formatting, with the "dumped binary text" showing up the same as it does in Sublime Text, but the "hex dumped version" showing up as Chinese characters inside of Notepad. The editor I am using is not the issue though I assure you, it's more like the "hex dumped version" is grabbing the wrong data or ... — Stumpped, Mar 28 '20 at 22:31
the more probable issue is I am looking for it in the wrong part of the drive whereas in the first example, the data hashcat needs is indeed in the first 512 bytes, but in the "hex dump" example, it's located elsewhere on the drive despite the fact that I used the exact same setup parameters for both drives. Problem is, where do I look? — Stumpped, Mar 28 '20 at 22:33
*"but the "hex dumped version" showing up as Chinese characters inside of Notepad."* - both Notepad and Sublime Text seem to guess how to best display binary data - in some cases it will be interpreted as Unicode while an another as pure binary so it is shown as Hex. __The difference is purely in how the data are displayed, not how they actually are.__ Best would be to enforce the same kind of display in your editor, ideally as hex since anything else does not make much sense for binary data. — Steffen Ullrich, Mar 28 '20 at 23:37

user10216038 · Answer 1 · 2020-03-29T21:28:25.943

Your dd command is simply copying 512 bytes to the output file. If you want a hash, you need to pipe it into a hash function such as:

dd if=\\?\Device\HarddiskVolume11 bs=512 count=1 | md5sum

For example on my Linux machine (with normal slashes instead of Windows backslashes):

dd if=/dev/sdb bs=512 count=1 | md5sum
1+0 records in
1+0 records out
512 bytes copied, 0.00163753 s, 313 kB/s
5b31a7aa24ccde6a44083cb30e33db4d

-------- edit --------

I see; you are trying to get a volume header not produce a hash.

First you need to make sure you're viewing data in a consistent manner. I'm not sure what Windows commands and tools you have available, but I suggest you display your data in a canonical format. One way is by piping your data to hexdump, for example:

dd if=veracryptcontainer bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes copied, 0.0578936 s, 8.8 kB/s
00000000  21 09 b4 29 58 67 31 ca  22 f3 8f bb c9 65 33 63  |!..)Xg1."....e3c|
00000010  54 de 18 44 2e 95 2e 7b  74 6b cc 4a dd 80 77 8b  |T..D...{tk.J..w.|
00000020  e8 c3 fb 5f ec 44 ea 67  1a de 9a 21 2a e9 06 c8  |..._.D.g...!*...|
00000030  bb 5a b8 c0 79 ad 66 c2  6b 51 03 03 8c ba 74 94  |.Z..y.f.kQ....t.|
00000040  96 de 57 8f 34 6b 65 e0  92 56 bf 14 71 0b 37 43  |..W.4ke..V..q.7C|
00000050  f3 dd d2 cd 06 aa 50 ee  46 20 c9 2d 55 4b a5 df  |......P.F .-UK..|
00000060  73 cf a3 d3 a3 d3 b2 86  07 a0 d0 1b 4f ea 68 ce  |s...........O.h.|
00000070  77 01 98 e0 5b ea e5 22  be ff 09 0b ef 6e f9 ce  |w...[..".....n..|
00000080  c9 e6 6a 15 30 85 ff e5  bc 7b 5e b8 2f 35 f1 4a  |..j.0....{^./5.J|
00000090  ac 1a 76 e5 33 e2 37 8d  fd a0 b8 e5 ad e2 85 58  |..v.3.7........X|
000000a0  0f 8a 1a 42 85 f5 23 2b  b9 be ef 8e a8 68 82 b0  |...B..#+.....h..|
000000b0  63 a5 91 1d 7c 74 b4 c9  bc 9f fe 4e a1 e8 63 17  |c...|t.....N..c.|
000000c0  af 77 0d 73 70 7d 27 12  a6 48 3d 82 bc e2 ba 08  |.w.sp}'..H=.....|
000000d0  be c5 2d 4a a9 86 d6 e6  1f 9c 5e da d1 0e c9 e6  |..-J......^.....|
000000e0  0b 94 47 df 3a 21 f3 73  3a d4 56 d3 a2 cb 0c de  |..G.:!.s:.V.....|
000000f0  ca 20 64 bb f0 c9 1a f4  b4 a7 78 c1 d9 3a 85 7a  |. d.......x..:.z|
00000100  51 f8 27 02 c6 4c f3 03  e1 69 b7 5f a2 9d 6f 10  |Q.'..L...i._..o.|
00000110  c2 dd ac 1f 39 5c 76 e6  44 15 f7 12 7c 25 42 6a  |....9\v.D...|%Bj|
00000120  d9 68 91 2b b5 9b 79 be  70 c7 07 a4 97 2f 53 57  |.h.+..y.p..../SW|
00000130  1c 62 22 89 7a fd f0 66  e8 ce 4e 33 78 9a 6a 2c  |.b".z..f..N3x.j,|
00000140  7d b3 d1 3a bc dd a7 2b  bf 7a 5f ce 93 55 c7 2e  |}..:...+.z_..U..|
00000150  41 b2 24 9e fe 94 17 8a  34 17 2f 8a 3b d0 b9 d1  |A.$.....4./.;...|
00000160  ca 6b 07 1f 3c 40 66 88  f9 38 b2 d1 2a 07 b3 01  |.k..<@f..8..*...|
00000170  10 3c a8 5a 8c 62 42 fa  37 df 4f 16 3d 73 f5 9d  |.<.Z.bB.7.O.=s..|
00000180  08 3b 22 d0 a0 58 b7 fa  f1 0c f8 0e 6f c0 eb ce  |.;"..X......o...|
00000190  2f 7f a5 36 12 3f 14 52  28 97 c9 42 e3 71 66 81  |/..6.?.R(..B.qf.|
000001a0  92 90 6f 74 ee 42 df 49  1a 08 77 53 83 0c bc e2  |..ot.B.I..wS....|
000001b0  13 a5 76 49 96 50 b4 e2  66 17 95 b4 6f f4 7b 9b  |..vI.P..f...o.{.|
000001c0  73 72 ae da ed 4e 2a 82  2d b4 7b c8 1d b4 f4 9e  |sr...N*.-.{.....|
000001d0  8f f9 30 ee f1 50 db 3d  bc 55 25 27 0b 62 78 15  |..0..P.=.U%'.bx.|
000001e0  bb 6b 9a f0 ac 3c e1 b4  e3 9f 00 8d 5e b3 aa bd  |.k...<......^...|
000001f0  72 55 6c 2e c5 34 ff 48  4c 18 41 e2 2b ca 20 17  |rUl..4.HL.A.+. .|
00000200

Second cracking Veracrypt without knowing at least a targeted subset of candidate passwords is a mighty undertaking. Veracrypt non-system hash round counts defaults to a half million. On top of that it allows custom round counts.

The Veracrypt volume header structure is documented here: Veracrypt Volume Format

If you pull this off, please tell us!

---- Second Edit -----

I fired up a Windows VM and tried out "DD for Windows" which I had never used.

When you run dd --list, pay careful attention to the target device. Does it show more than one partition? I plugged in a simply FAT32 thumb drive with only a single partition but DD for Windows showed it as two partitions like this:

\\?\Device\Harddisk1\Partition0
  link to \\?\Device\Harddisk1\DR2
  Removable media other than floppy. Block size = 512
  size is 4089446400 bytes
\\?\Device\Harddisk1\Partition1
  link to \\?\Device\HarddiskVolume5
  Removable media other than floppy. Block size = 512
  size is 4089069568 bytes

Examining this in Linux with fdisk shows the start of the one and only partition is not zero. Apparently DD for Windows represents this offset as a partition.

The net result is that the difference in sizes of the two partitions divided by 512 is the skip=value you need for your dd command if you picked the raw device instead of the partition.

The OP does not actually want the hash of the partition even if the question might look like this. The OP wants instead the volume header of the Veracrypt volume which contains the encrypted keys. And the command used actually does this, only the OP fails to interpret the output properly. See the comments on the question. — Steffen Ullrich, Mar 29 '20 at 06:23

Using DD to get the hash of a non-system partition encrypted by VeraCrypt

1 Answers1