hashcat Forum
LUKS Support - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Misc (https://hashcat.net/forum/forum-15.html)
+--- Forum: User Contributions (https://hashcat.net/forum/forum-25.html)
+--- Thread: LUKS Support (/thread-6225.html)

Pages: 1 2

LUKS Support - atom - 01-21-2017

After multiple weeks of coding and preparations I've completed the support for hashcat to crack LUKS protected partitions and volumes.

LUKS offers a set of "crypto items" (hashes, ciphers, blockmodes and keysizes) which can be used to configure an encrypted block device. The user can freely select them which then creates a large number of possible crypto relevant combinations. This made it a very work intensive implementation especially without a crypto library and on GPU.

The following crypto items are supported for LUKS:

Hashes:
  • PBKDF2-HMAC-SHA1
  • PBKDF2-HMAC-SHA256
  • PBKDF2-HMAC-SHA512
  • PBKDF2-HMAC-RipeMD160
Ciphers:
  • AES
  • Serpent
  • Twofish
Modes:
  • CBC-Plain
  • CBC-Plain64
  • CBC-ESSIV
  • XTS-Plain
  • XTS-Plain64
Keysizes:
  • 128
  • 256
  • 512
Hashcat computes all of the crypto items and their combinations 100% on GPU. On top of that, hashcat also computes the anti-forensic merger code and the shannon entropy check 100% on GPU.

To find out which crypto items are configured in your LUKS volume you can use the command:

Quote:$ cryptsetup luksDump /dev/XXXX

Unless you're using some very uncommon setup, I'm certain that hashcat will support all of the crypto items in your LUKS volume. Hashcat will automatically detect them and automatically select the correct kernel for you.

Short story on LUKS is:
  1. Do a PBKDF2 on the password with a very high iteration count
  2. Use the derived key to decrypt a large set of anti-forensic data
  3. Merge the decrypted AF data to form the masterkey
  4. Do a PBKDF2 on the masterkey again with a high iteration count
  5. Compare the derived data with the data stored in the LUKS header to verify if the password was correct
This is how LUKS does it.

The first PBKDF2 iteration count is automatically selected from cryptsetup by measuring how many iterations can be done in 1000ms on the host CPU (unless the user override the time using -i). However, the second PBKDF2 is not needed actually. While it provides a bullet-proof way to check if the password is correct, it also adds a very expensive PBKDF2 with usually more than 100000 iterations (on a modern system). It is preferable to avoid it, and that's why hashcat does the following instead:
  • Since we have the masterkey after the first PBKDF2 we can start decrypting the payload data
  • If we can predict the data after decrypt we can do a known-plaintext attack
  • Unfortunately the data isn't 100% known, but from my tests it shows it's different to random data (see below)
  • Decrypted data with an invalid key looks like random data, therefore hashcat can do an entropy check on it
  • If the entropy is below some threshold we can assume the password was correct
So how can hashcat know anything about the content. Well, it can't and this isn't bullet-proof. But from my tests it turns out that the most common used filesystems on linux zero the first sector or write some sort of header to it. I've tested the following filesystems:
  • EXT2
  • EXT3
  • EXT4
  • XFS
  • Reiser4
  • Btrfs
I've also successfully checked some more rare filesystems like vfat, but I don't think anyone uses this on a linux box.

This is how I tested how the first sector changes after a format:

Quote:$ 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
$ xxd -l 512 /dev/mapper/tmp ## should no longer be random data
$ cryptsetup luksClose tmp
$ rm test

The idea is simply to find out if the mkfs.XXX is doing "something" to the first sector at initialization (formating). And they do, all of them! They either set zero bytes or some kind of header. That's what we're hoping for, because that enables us to do an entropy check on it with the goal to workaround the expensive 2nd PBKDF2 computation.

Hashcat also supports the cracking of the multiple keyslots that can be used in LUKS. For those who are not familiar with this concept: LUKS allows the use of multiple passwords ("keyslots", up to 8) for the same volume. We can not know which one contains the easiest password, but each of them have its own iteration count. In theory it makes sense to attack the one with the lowest iteration count, but after some thought I decided against it. We need to test all of them, regardless of the iteration count because it's easier to crack a simple passwords with 1000000 iterations than a hard one with just 100 iterations. Therefore it doesn't make any sense to give the user control on which keyslot to test, but if anyone has a good idea why it would make sense letting the user choose, please let me know and I'll add a parameter for it.

There's two things missing (at the moment) in order to make hashcats LUKS support "full featured":
  1. Support for Keyfiles
  2. Support for Whirlpool
In LUKS there's actually two (or more) different Keyfiles that can be used. There's one for each of the keyslots and one for the masterkey. However, I'm unsure if we really need them. If I'm getting enough feedback from people who actually need keyfile support (or whirlpool) I'll rethink about adding them.

To crack LUKS with hashcat, simply use hash mode 14600 and specify the path to the partition "file". For instance that is /dev/sda1 on where you normally specify the hash file. There's no luks2hashcat or so required. To make the LUKS image more "portable" you can also use this command:

Quote:$ dd if=/dev/XXXX of=header.luks bs=512 count=4097

This creates a 2mb file which includes all the data hashcat needs to start cracking.

Being able to crack LUKS using hashcat doesn't mean that LUKS is broken. There's also no reason to criticize the KDF of LUKS because of the possible shortcut. The high iteration count and the large AF dataset makes this algorithms one of the slowest you can think of. At least I was able to make it 15 to 25 times faster (yes, times, not percent!) than any other password cracker (both commercial and non-commercial) on the same system/hardware. I'm very proud on this work.

- atom

RE: LUKS Support - bigblacknose - 01-21-2017

Wow. You did it again. Respect.
Going to try this right away.

RE: LUKS Support - royce - 01-21-2017

I wondered why it'd been quiet in #hashcat lately. Smile Amazing work!

Some quick benchmarks, stock clocks. Indeed, a slow algorithm.

hashcat (v3.30-20-gf88644f) starting in benchmark mode...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 970, 1009/4036 MB allocatable, 13MCU
* Device #2: GeForce GTX 750 Ti, 500/2000 MB allocatable, 5MCU

Hashtype: LUKS

Speed.Dev.#1.....:     4002 H/s (9.55ms)
Speed.Dev.#2.....:     1448 H/s (10.32ms)

RE: LUKS Support - kiara - 01-21-2017

which kind of device/software/os are using this kind of encryption ?

(update1)

The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) uses this.

by the way atom, ur a god Tongue gj on ur work and thanks alot!

RE: LUKS Support - bigblacknose - 01-21-2017

(01-21-2017, 10:09 PM)royce Wrote: I wondered why it'd been quiet in #hashcat lately. Smile Amazing work!

Some quick benchmarks, stock clocks. Indeed, a slow algorithm.

hashcat (v3.30-20-gf88644f) starting in benchmark mode...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 970, 1009/4036 MB allocatable, 13MCU
* Device #2: GeForce GTX 750 Ti, 500/2000 MB allocatable, 5MCU

Hashtype: LUKS

Speed.Dev.#1.....:     4002 H/s (9.55ms)
Speed.Dev.#2.....:     1448 H/s (10.32ms)

I can tell you that this speed is way ahead of what other tools can produce!
(even if it is slow)

RE: LUKS Support - tacohashcat - 01-24-2017

(01-21-2017, 11:15 PM)bigblacknose Wrote:
(01-21-2017, 10:09 PM)royce Wrote: I wondered why it'd been quiet in #hashcat lately. Smile Amazing work!

Some quick benchmarks, stock clocks. Indeed, a slow algorithm.

hashcat (v3.30-20-gf88644f) starting in benchmark mode...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 970, 1009/4036 MB allocatable, 13MCU
* Device #2: GeForce GTX 750 Ti, 500/2000 MB allocatable, 5MCU

Hashtype: LUKS

Speed.Dev.#1.....:     4002 H/s (9.55ms)
Speed.Dev.#2.....:     1448 H/s (10.32ms)

I can tell you that this speed is way ahead of what other tools can produce!
(even if it is slow)
Agreed on the speed. Passware LUKS support is painful slow at best.

Atom is awesome.

RE: LUKS Support - timi2shoes - 02-03-2017

Excellent work atom!

Using right now on a LUKS drive, getting about 1200 H/s!

Speed.Dev.#1.....:      302 H/s (41.72ms)
Speed.Dev.#2.....:      311 H/s (40.28ms)
Speed.Dev.#3.....:      302 H/s (41.54ms)
Speed.Dev.#4.....:      306 H/s (41.07ms)
Speed.Dev.#*.....:     1221 H/s

Thank you!!

RE: LUKS Support - kiara - 02-04-2017

D:\hashcat-3.30 + 100>hashcat64.exe -b -m 14600
hashcat (v3.30-100-gcc991ee) starting in benchmark mode...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1080, 2047/8192 MB allocatable, 20MCU
* Device #2: GeForce GTX 1080, 2047/8192 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2047/8192 MB allocatable, 20MCU
* Device #4: GeForce GTX 1080, 2047/8192 MB allocatable, 20MCU
* Device #5: GeForce GTX 1080, 2047/8192 MB allocatable, 20MCU
* Device #6: GeForce GTX 1080, 2047/8192 MB allocatable, 20MCU
* Device #7: GeForce GTX 1080, 2047/8192 MB allocatable, 20MCU
* Device #8: GeForce GTX 1080, 2047/8192 MB allocatable, 20MCU

Hashtype: LUKS

Speed.Dev.#1.....: 6788 H/s (5.75ms)
Speed.Dev.#2.....: 6803 H/s (5.70ms)
Speed.Dev.#3.....: 6815 H/s (5.75ms)
Speed.Dev.#4.....: 8661 H/s (5.69ms)
Speed.Dev.#5.....: 6786 H/s (6.99ms)
Speed.Dev.#6.....: 6795 H/s (5.75ms)
Speed.Dev.#7.....: 6784 H/s (5.81ms)
Speed.Dev.#8.....: 7653 H/s (5.65ms)
Speed.Dev.#*.....: 57085 H/s

Started: Sat Feb 04 20:08:35 2017
Stopped: Sat Feb 04 20:09:33 2017

http://pastebin.com/qXZREGJS

RE: LUKS Support - duhblow7 - 02-05-2017

wow. bravo!

RE: LUKS Support - unknown1819 - 07-02-2017

Hello,

With this method and with hashcat can i with wordlist bruteforce dm-crypt plain aes.xts.plain64.512.sha512 hard drive or file?
I know some part of password but i forget other part i wolud like to test from files all password i have zuluCrypt its too many password to test manualy how to automate it?

Best regards