m14600 confusing error message parsing container without payload data

[rixvet]

Describe the issue
When module 14600 (LUKS1 v1 (legacy)) is presented an binary header which does not contains payload data an confusing error message is reported 'Disabled LUKS key detected' instead of 'Invalid LUKS filesize'.

FYI: Using the newer approach (header extraction using luks2hashcat.py) yields the proper error message:

$ /tools/luks2hashcat.py ./myheader.img > foo.hdr
luks2hashcat.py: error: file contains less data than needed

To Reproduce
Please provide us with all files required to reproduce the issue locally on our development systems. For instance: hash files, wordlists, rule files, ...

# Create a 10MiB images with payload offset starting at 2MiB
$ truncate -s 10M LUKS1sample.img
echo 'Luks1Password' | cryptsetup luksFormat  --offset 4096 --type luks1 ./LUKS1sample.img

# Make sure some data structures exists on disk
echo 'Luks1Password' |  sudo cryptsetup open ./LUKS1sample.img mytest
sudo mkfs.ext4 /dev/mapper/mytest
sudo cryptsetup close mytest

cryptsetup luksDump ./LUKS1sample.img
LUKS header information for ./LUKS1sample.img

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
MK digest:      5e 0d 22 d3 28 dd f6 8a ee dd 6a 1f 01 e2 32 47 16 01 dd 7c
MK salt:        81 8e 95 36 e4 06 e9 51 02 46 1d 19 57 76 72 ae
                47 7d ee 25 31 ac 70 13 1f df 17 56 04 aa e1 00
MK iterations:  130031
UUID:           3f096335-fc5b-42f9-b616-7a85d8545a24

Key Slot 0: ENABLED
        Iterations:             2080506
        Salt:                   ca 11 6c 9e 20 c3 92 5b ce 0d b6 a9 97 bf 48 5f
                                95 84 1c 20 e4 78 4a 68 83 13 c7 22 d5 a7 5b e3
        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

# Create header which does not contain payload
dd if=./LUKS1sample.img of=myheader.img bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0103359 s, 101 MB/s

$ ./hashcat -a 3 -m 14600 ./myheader.img 'Luks1Password' --quiet
Hashfile './myheader.img': Disabled LUKS key detected
No hashes loaded.

Technically speaking the output is correct since the last keyslot is disabled, how-ever the error message is rather confusing, since the actual problem is the lack of the payload information.

Expected behavior

$./hashcat -a 3 -m 14600 ./myheader.img 'Luks1Password' --quiet
Hashfile './myheader.img': Invalid LUKS filesize
No hashes loaded

Proof-of-Concept patch

git diff
diff --git a/src/modules/module_14600.c b/src/modules/module_14600.c
index fa6a0f4d5..884c8e6eb 100644
--- a/src/modules/module_14600.c
+++ b/src/modules/module_14600.c
@@ -230,6 +230,7 @@ int module_hash_binary_parse (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE

   int hashes_cnt = 0;
   int last_error = 0;
+  int luks_key_disabled_cnt = 0;

   for (int keyslot_idx = 0; keyslot_idx < LUKS_NUMKEYS; keyslot_idx++)
   {
@@ -243,7 +244,15 @@ int module_hash_binary_parse (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE

     if (parser_status != PARSER_OK)
     {
-      last_error = parser_status;
+      if (parser_status == PARSER_LUKS_KEY_DISABLED)
+      {
+        luks_key_disabled_cnt++;
+      }
+      else
+      {
+        last_error = parser_status;
+      }
+
       continue;
     }

@@ -252,7 +261,14 @@ int module_hash_binary_parse (MAYBE_UNUSED const hashconfig_t *hashconfig, MAYBE

   if (hashes_cnt == 0)
   {
-    return last_error;
+    if (luks_key_disabled_cnt == LUKS_NUMKEYS)
+    {
+      return PARSER_LUKS_KEY_DISABLED;
+    }
+    else
+    {
+      return last_error;
+    }
   }
   else
   {

Hashcat version (please complete the following information):

• Version: v6.2.6-67-g2e684efeb+

The module is marked legacy, thus I am not sure if patches against this module are still accepted.

[ventaquil]

Hey @rickvanderzwet

New LUKS modules were introduced in GH-3321. This PR was a part of my work to improve FDE modules.

First PR changed TrueCrypt modules - GH-3293. Firstly I planned to replace old modules with new ones - due to backward compability we chosed to left old ones as is - #3293 (comment).

However naming convention could confuse potential user - #3293 (comment).

Finally old modules got suffix legacy to distinguish them from the new ones - GH-3311.

Patches for legacy modules are welcome here IMHO.

[jsteube]

Agree, please send in the PR

[Chick3nman]

Fix Merged, Closing.