[How to] Brute forcing password cracking devices (LUKS)

We have written in the past about how to crack passwords on password-protected RAR and ZIP files, but in those cases someone wrote a program to extract the password hashes from the RAR and ZIP files first. After that, we could use John the Ripper to generate passwords (or use a dictionary) to attack the password hashes. In this case, John the Ripper generates a password, then hashes the password with the same hashing/salting method as the hash we are attacking. If the hash matches, then we have the clear-text password.

However, in some situations, we don't have a password hash to attack, or maybe we don't know what algorithm is used. Either way, we may not be able to extract a hash for whatever reason. In this case, we can still brute-force the password using the standard authentication mechanism.

In this tutorial, I will be brute-force attacking a LUKS encrypted file using John the Ripper. A LUKS encrypted file is similar to a truecrypt container. It could be used to encrypt a disk, partition, or file.

Let's assume that an investigator extracted all files from a suspect disk. By looking at the file headers, we find the following:

encrypted: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 811f8a08-85da-4f7d-b50f-3e64ed7a66f4

Maybe the investigator has no memory image of the suspect device or any other information regarding the file, but still needs to get into it....

To mount a LUKS file from the (linux) command line, you have to use cryptsetup . The command usually looks like cryptsetup luksOpen container mountpoint . When you attempt to mount, by default it will ask for a password 3 times if the attempts are incorrect. We cannot pass the password directly to cryptsetup as an option, it will always ask for a password.

Regardless of some challenges, cryptsetup does have some useful options, such as -T which controls how many times it will ask for a password before giving up. And also the option --test-passphrase, which will see if the password worked without actually opening the device. So right now we have the following command to open the LUKS device:

cryptsetup luksOpen $1 x --test-passphrase -T1


Now we can use John the Ripper in incremental mode sending the output to standard out to generate our password list.

john -i --stdout


Now we just need a small script to capture the output of JtR and test the cryptsetup password:

#!/bin/bash

# Using john the ripper to brute-force a luks container
startTime=$(date)
if [ $(file $1 | grep -c "LUKS encrypted file") ]; then
    john -i --stdout | while read i; do
        echo -ne "\rtrying \"$i\" "\\r
        # as root
        echo $i | cryptsetup luksOpen $1 x --test-passphrase -T1 2> /dev/null
        STATUS=$?
        if [ $STATUS -eq 0 ]; then
          echo -e "\nPassword is: \"$i\"
          break
        fi
    done
    echo "Start time $startTime"
    echo "End time $(date)"
else
        echo "The file does not appear to be a LUKS encrypted file"
fi


This bash script first uses file to check whether the input is recognized as a LUKS encrypted file. If so, it will run JtM in incremental mode, and output to stdout. A while loop is used to capture the generated password as a variable "i". We then echo the password, and pipe it to the luksOpen command. That way, when cryptsetup asks for a password it will use the password we have piped to it. The status will be either 0 if it worked or 2 if the password failed. If the status is 0, then we print the password, and how long it took. If the status is not 0, we get a new password and try again.

Now, if you start to run this script you may notice that it is very, very, very slow. Generating passwords with JtM is relatively quick, but trying the passwords on a LUKS device is designed to be slow.

This process will likely take a very long time, but 1) it will eventually crack any type of device and 2) it can be used when you have no other option.

Try to use the script to play around with other password-protected files/devices.