LUKS Support

[exaid]

Can it support LVM header from a raid device ?

[atom]

i have zuluCrypt its too many password to test manualy how to automate it?

Can it support LVM header from a raid device ?

No, LUKS has it's own header

[paule965]

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:

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

For the most it is correct to use 4096 sektors, but i know headers with smaller/ larger size. you need the first sector from the payload and the correct syntax for sectors would be "count=$(($PAYLOADOFFSET + 1))". Problem is that you can set the possible value for the PAYLOADOFFSET up to uint32 (1TB). So you can run out of gpu-memory or you have a high loadtime for the header-image.

I manipulated on my testimage (built with --align-payload 200000) the luksheader (4096 sectors from offset 0 and the first sector from the payload) with the filesize 4097 sectors, change the payload-offset to 0x1000 and voila, i have the right result. I dont know, if a usage of < 4096 sectors is possible...

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.

EDIT:

It would be a interesting option for a choice of each keyslots. The iterartion of my test-image is ~2.900.000. A really nice/ bad value - depends what side you sitting. if I set 8 keyslots it will be even better / worse and a pain for a dictionary-attack... i know, that it is a bit roulette, but should be try possible...?
LuksHeader4Hashcat:
rebuilds a luksheader for hashcat

• -parsing statusinformation about Luks
  
• -parsing statusinformation about Keyslots
  
• -allows selection of (only!) one Keyslot
  
• -activates 0xdead Keyslots with (valid?) entrys
  
• -changes the PayloadOffset if it is >4096 sectors and rebuild the luksheader with a max filesize 4096+1 sectors