hashcat Forum

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:


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

And here's the output of hashcat



I would sincerely appreciate any pointers in the right direction.

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

(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.

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

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.

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:


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?

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:

try to see if those bytes are not all zero:

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?

(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.

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?