help with LUKS data recovery - Printable Version

help with LUKS data recovery - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: help with LUKS data recovery (/thread-7165.html)

Pages: 1 2

help with LUKS data recovery - j45645hn45 - 01-04-2018

Hello everyone, I am on the verge of losing 20years worth of data, since I set this system up 2 months ago and was still populating it, so there's no backup in place. Here goes...

... mistakes were made and I did not properly secure the passphrase on my self-built NAS. The data sits in a LUKS encrypted Raid 5 volume on an openmediavault system (a debian derived distro) and I'm pretty sure I used a combination of some passwords, so a dictionary attack is feasible.

Here's what I tried: I extracted the header using dd to crunch it using hashcat on my dual GPU workstation. The password wasn't found. To make sure the problem is not related to my config, I then recreated the whole setup inside a VM, encrypted a raid5 of virtual drives with LUKS using "password", and extracted the header file as well. I then verified the header file using cryptsetup and fed it the dictionary file which included the password. But it seems hashcat can't find it.

Here's how I saved the header:

Code:
root@openmediavault-test:/# dd if=/dev/md0 of=_luks4.luks bs=512 count=4097

4097+0 records in

4097+0 records out

2097664 bytes (2.1 MB) copied, 0.0180822 s, 116 MB/s

Here's the output of cryptsetup to check the header:

Code:
root@openmediavault-test:/# cryptsetup luksDump _luks4.luks

LUKS header information for _luks4.luks

Version:        1

Cipher name:    aes

Cipher mode:    xts-plain64

Hash spec:      sha1

Payload offset: 4096

MK bits:        256

MK digest:      05 d4 9d b2 4e f4 6a 8e ee 64 90 46 5c b8 d6 9b 8d 7c cb 92

MK salt:        97 27 2c 7e e6 9c 04 73 ba 71 bc a6 52 47 66 e6

               d8 1f c3 33 bb 07 fd a0 b9 39 a2 57 78 f9 02 5d

MK iterations:  202500

UUID:           529a9141-98b4-465b-a52c-c19fef1dea31

Key Slot 0: ENABLED

       Iterations:             815286

       Salt:                   f0 80 96 e3 a8 57 fa 04 ba f7 fd 55 15 40 ba 65

                               b9 96 44 4d 6c 2f a4 4d 87 1d 1e bd a7 3c 77 fc

       Key material offset:    8

       AF stripes:             4000

Key Slot 1: DISABLED

Key Slot 2: DISABLED

Key Slot 3: DISABLED

Key Slot 4: DISABLED

Key Slot 5: DISABLED

Key Slot 6: DISABLED

Key Slot 7: DISABLED

And here's the output of hashcat

Code:
C:\Users\omega\Desktop\hashcat-4.0.1>hashcat64.exe -a 0 -m 14600 _luks4.luks _luks.dict

hashcat (v4.0.1) starting...

* Device #1: WARNING! Kernel exec timeout is not disabled.

             This may cause "CL_OUT_OF_RESOURCES" or related errors.

             To disable the timeout, see: https://hashcat.net/q/timeoutpatch

* Device #2: WARNING! Kernel exec timeout is not disabled.

             This may cause "CL_OUT_OF_RESOURCES" or related errors.

             To disable the timeout, see: https://hashcat.net/q/timeoutpatch

OpenCL Platform #1: NVIDIA Corporation

======================================

* Device #1: GeForce GTX 1080 Ti, 2816/11264 MB allocatable, 28MCU

* Device #2: GeForce GTX 1080 Ti, 2816/11264 MB allocatable, 28MCU

Hashes: 1 digests; 1 unique digests, 1 unique salts

Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Rules: 1

Applicable optimizers:

* Zero-Byte

* Single-Hash

* Single-Salt

* Slow-Hash-SIMD-LOOP

Password length minimum: 0

Password length maximum: 256

Watchdog: Temperature abort trigger set to 90c

Watchdog: Temperature retain trigger set to 75c

Dictionary cache built:

* Filename..: _luks.dict

* Passwords.: 1

* Bytes.....: 9

* Keyspace..: 1

* Runtime...: 0 secs

The wordlist or mask that you are using is too small.

This means that hashcat cannot use the full parallel power of your device(s).

Unless you supply more work, your cracking speed will drop.

For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.

Cracking performance lower than expected?

* Append -w 3 to the commandline.

  This can cause your screen to lag.

* Update your OpenCL runtime / driver the right way:

  https://hashcat.net/faq/wrongdriver

* Create more work items to make use of your parallelization power:

  https://hashcat.net/faq/morework

Session..........: hashcat

Status...........: Exhausted

Hash.Type........: LUKS

Hash.Target......: _luks4.luks

Time.Started.....: Thu Jan 04 17:45:29 2018 (6 secs)

Time.Estimated...: Thu Jan 04 17:45:35 2018 (0 secs)

Guess.Base.......: File (_luks.dict)

Guess.Queue......: 1/1 (100.00%)

Speed.Dev.#1.....:        0 H/s (0.35ms)

Speed.Dev.#2.....:        0 H/s (0.39ms)

Speed.Dev.#*.....:        0 H/s

Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts

Progress.........: 1/1 (100.00%)

Rejected.........: 0/1 (0.00%)

Restore.Point....: 0/1 (0.00%)

Candidates.#1....: password -> password

Candidates.#2....: [Copying]

HWMon.Dev.#1.....: Temp: 37c Fan: 33% Util: 75% Core:1961MHz Mem:5005MHz Bus:16

HWMon.Dev.#2.....: Temp: 43c Fan: 33% Util:  0% Core:1569MHz Mem:5005MHz Bus:16

Started: Thu Jan 04 17:45:17 2018

Stopped: Thu Jan 04 17:45:37 2018

C:\Users\omega\Desktop\hashcat-4.0.1>pause

I would sincerely appreciate any pointers in the right direction.

RE: help with LUKS data recovery - philsmd - 01-04-2018

Did you try to crack the example files from https://hashcat.net/wiki/doku.php?id=example_hashes ?
(search for 14600 or LUKS)

RE: help with LUKS data recovery - j45645hn45 - 01-05-2018

(01-04-2018, 08:06 PM)philsmd Wrote: Did you try to crack the example files

I just tried, and this worked.

I compared the provided header files and noticed that mine consists of 90% of NUL characters. I figure that this should not be the case, correct? The same is true for both the "real" header and the one I created in the VM.

RE: help with LUKS data recovery - philsmd - 01-05-2018

I'm not sure if this observation you made about 90% NUL characters reveals some problems. Instead, I think that also the examples have several NUL chars within the "header". I would not conclude that this is 100% a problem (did you even compare if the example have much less NUL bytes?).

I would rather suggest looking at other possibilities:
1. what type of architecture (64 bit amd, x86 32 bit, mips, arm) is used by the system
2. little or big endian
3. what file system (ext3/ext4/ntfs...) does the system use
4. does the system use keyfiles together with luks
....

as you might know hashcat makes an entropy check to verify the data. This could in theory lead to problems if the decrypted data is random (which was never the case in our testings, see https://hashcat.net/forum/thread-6225.html)

You could also try to generate a test "volume" with the instructions from here: https://hashcat.net/forum/thread-6225.html

Code:
$ dd if=/dev/urandom of=test bs=1M count=100

$ cryptsetup luksFormat test

$ cryptsetup luksOpen test tmp

$ xxd -l 512 /dev/mapper/tmp # is random data at this point

$ mkfs.XXX /dev/mapper/tmp  # use the same file system that is used by your system/device

$ xxd -l 512 /dev/mapper/tmp # should no longer be random data

$ cryptsetup luksClose tmp

It would also make sense that you try to generate a luks volume on a different system (maybe on a 64-bit x86 system) just to make sure that those luks volume can be cracked correctly and to find out whether the problem only occurs whenever this openmediavault system is used.

RE: help with LUKS data recovery - j45645hn45 - 01-05-2018

I want to thank you for the time you take to try and help me.
I followed the instructions for the test on my VM system, and everything worked properly:

Code:
root@openmediavault-test:~# dd if=/dev/urandom of=test bs=1M count=100

100+0 records in

100+0 records out

104857600 bytes (105 MB) copied, 0.487188 s, 215 MB/s

root@openmediavault-test:~# cryptsetup luksFormat test

WARNING!

========

This will overwrite data on test irrevocably.

Are you sure? (Type uppercase yes): YES

Enter passphrase:

Verify passphrase:

root@openmediavault-test:~# cryptsetup luksOpen test tmp

Enter passphrase for test:

root@openmediavault-test:~# xxd -l 512 /dev/mapper/tmp

0000000: bcdf 1e02 2ef9 dfff 35d0 970d bddc fb65  ........5......e

0000010: 4e83 4155 61de 4b60 f4b8 6b50 681f 34d9  N.AUa.K`..kPh.4.

0000020: 7dff 6a7a 585b 8dc7 0fdc 06cb a50d 6f40  }.jzX[........o@

0000030: 1cc7 ae50 c7c8 f243 a740 7982 6d4e 7f36  ...P...C.@y.mN.6

0000040: 1541 7959 b0a3 4979 eebf b95c 3166 a5a8  .AyY..Iy...\1f..

0000050: 046d 8c4a 7da4 b3f0 9dbb 0b0e 72b3 c761  .m.J}.......r..a

0000060: cbef c3b5 4af9 72f9 6940 3ad3 be5b 220e  ....J.r.i@:..[".

0000070: ff7b db5e 9a34 88a4 b19a 371c 61f0 9d33  .{.^.4....7.a..3

0000080: ea24 5212 fb2b 88d0 e805 edbe 7969 5833  .$R..+......yiX3

0000090: 66e2 7071 1931 17c8 1039 1521 8420 d2ce  f.pq.1...9.!. ..

00000a0: 7d6b 5774 6059 12fe 10b1 7f56 d651 8d40  }kWt`Y.....V.Q.@

00000b0: 0a85 e4f0 80c1 278c 3b5a 973c 7e14 50fb  ......'.;Z.<~.P.

00000c0: 03d4 7607 a83f ea65 32ac c666 a965 cdbe  ..v..?.e2..f.e..

00000d0: 048c 8ede 0cc9 319e 5df0 8c0c 87ee 2ee5  ......1.].......

00000e0: 8939 46ea 2bd0 52f1 42bb 0577 066a 6170  .9F.+.R.B..w.jap

00000f0: 4f7d d0cd 5486 3dde 9e12 97e1 86cb dc6a  O}..T.=........j

0000100: 2511 1a68 4e04 fb75 e12e 3413 bea6 6fa2  %..hN..u..4...o.

0000110: 24ed d280 6779 13cc 257a 6663 e883 e9f8  $...gy..%zfc....

0000120: d544 042a 3653 9a74 b20d 3bc6 e38d c43d  .D.*6S.t..;....=

0000130: 6e90 125f c732 9a6e 7710 0dff 8073 c797  n.._.2.nw....s..

0000140: d2df 4e4d e132 c1cd d2d9 f58a d6ca c724  ..NM.2.........$

0000150: 4fa6 d8f1 eae6 3cf5 56dc ea2c f9fa 2736  O.....<.V..,..'6

0000160: 7cfb 2e00 423b 3e00 838a ce3d 64e0 b273  |...B;>....=d..s

0000170: 7f9f d294 ea23 397b bb49 548a a135 5d08  .....#9{.IT..5].

0000180: c0af 0ab3 bf17 38d8 a5ad 9e32 aa11 194a  ......8....2...J

0000190: efff 602d 3b3b 6e2a 89cf 40d8 92d7 4743  ..`-;;n*..@...GC

00001a0: eddd 5e67 3a04 fa45 71dd 30af 123f 2d78  ..^g:..Eq.0..?-x

00001b0: d4e3 ac50 6e30 e5a2 3a9c 9a54 8e6c 49c3  ...Pn0..:..T.lI.

00001c0: 33b4 75f6 48a2 a5ac 6288 b80d 4c90 f66a  3.u.H...b...L..j

00001d0: 2003 1e6f 09a7 56bd fc83 d0f7 a46a 92e8   ..o..V......j..

00001e0: 30a4 1132 6e5d e118 6c58 bcf7 a825 559d  0..2n]..lX...%U.

00001f0: 5823 e9a0 954c 8530 8172 c868 4755 34a3  X#...L.0.r.hGU4.

root@openmediavault-test:~# mkfs.ext4 /dev/mapper/tmp

mke2fs 1.43.3 (04-Sep-2016)

Creating filesystem with 100352 1k blocks and 25168 inodes

Filesystem UUID: ad5fe9aa-f669-4987-8581-e3b1cf0cfbde

Superblock backups stored on blocks:

       8193, 24577, 40961, 57345, 73729

Allocating group tables: done

Writing inode tables: done

Creating journal (4096 blocks): done

Writing superblocks and filesystem accounting information: done

root@openmediavault-test:~# xxd -l 512 /dev/mapper/tmp

0000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................

0000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

00001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

I noticed in the example files that the header has a lot of NUL chars too, but there's some apparently encrypted data at the very end. My header files don't have this and just EOF with NULs.

To answer the other questions:
1. architecture is 64bit amd
2. little endian
3. EXT4
4. Keyfiles are optional, but I didn't use them.

edit: could it be related to the raid5 that I use?

RE: help with LUKS data recovery - philsmd - 01-05-2018

Did you try to crack the volume that you created as an example on your vm ?

Can you perform the same test (creating a new luks "file") on the actual machine.

I'm not sure if the raid setup really makes any difference

update: since your payload offset seems to be 4096:

Code:
Payload offset: 4096

try to see if those bytes are not all zero:

Code:
dd if=_luks4.luks bs=1 skip=$((4096 * 512)) count=128 2>/dev/null | xxd -g 1

RE: help with LUKS data recovery - j45645hn45 - 01-05-2018

Code:
root@openmediavault-test:/hashcat# dd if=_luks4.luks bs=1 skip=$((4096 * 512)) count=128 2>/dev/null | xxd -g 1

0000000: 00 82 00 00 00 82 01 00 00 82 02 00 00 82 03 00  ................

0000010: 00 82 04 00 00 82 0c 00 00 82 0d 00 00 00 00 00  ................

0000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

0000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

RE: help with LUKS data recovery - philsmd - 01-05-2018

This payload data should be (look like) random data.
In your case it doesn't seem to be random data.

Is this also the case for your other examples?

RE: help with LUKS data recovery - j45645hn45 - 01-06-2018

(01-05-2018, 02:31 PM)philsmd Wrote: This payload data should be (look like) random data.
In your case it doesn't seem to be random data.

Is this also the case for your other examples?

The header from the original raid that I'm trying to decrypt has random data. My VM tests don't.

But I noticed that the real thing uses this cipher mode: cbc-essiv: sha256 and the VM uses xts-plain64 ... from my understanding though, that should have no impact on the randomness of the header data.

At this point, I have no idea how to proceed.

RE: help with LUKS data recovery - philsmd - 01-06-2018

I would suggest that you create a test with exactly the same settings (same hashing and encryption algorithm etc) and try to extract the data from it and crack it.

If the test works successfully, the same steps should also work with the "hash" you are trying to crack.

I'm not sure why your test settings are different. Was your original luks volume generated by some GUI or web-interface etc and you do not know what settings it uses?