Password cracking GUI

Jump to: navigation, search


Equipped with lists of password hashes from previous steps in the penetration testing process, testers face the challenge of finding a minimum of one password. In cases where many penetration testers share one resource (e.g. one workstation with high performance GPUs), job scheduling becomes a challenge when using the command line tool hashcat. There are different hashcat-based open source tools that provide job scheduling as well as a graphical user interfaces to monitor the jobs states. A list of these tools include

  • CrackLord
  • WebHashcat
  • WaveCrack
  • Hashtopolis

Besides checking if there are more open source password-cracking tools with job scheduling, the named tools should be benchmarked using one or two Nvidia GTX 980 graphic cards. An evaluation of the provided functions should help choosing a tool for real world cases.

Setting up a test system

All tools should be benchmarked using the same operating system. Some of the tested tools could be tested on multiple systems. A first research found out, that the tools require these operating systems.

CrackLord WebHashCat WaveCrack Hashtopolis
Operating system
  • Ubuntu
  • Debian
  • Kali
  • not known
  • Linux (?)
  • Windows
  • Linux
  • OS X

The test system is setup with Kali with the hope that all tools will work with this OS.

Main setup problems (Hardware)

  • With GTX 980 boot menu can not be displayed
  • With HDMI boot menu can not be displayed
  • Keyboard needs to be plugged into USB 3.0 port to display boot menu but within boot menu, only USB 2.0 works
  • 4 GB USB Stick is not sufficient for a installation (size: 3.1 GB)

Main setup problems (Software)

Sources, to download packages from, were missing. Everything in sources.list was commented out. This is how the file should look like (I added the lines with no #).

deb kali-rolling main contrib non-free
deb-src kali-rolling main non-free contrib 

# deb cdrom:[Debian GNU/Linux 2019.3 _Kali-rolling_ - Official Snapshot amd64 LIVE/INSTALL Binary 20190>

#deb cdrom:[Debian GNU/Linux 2019.3 _Kali-rolling_ - Official Snapshot amd64 LIVE/INSTALL Binary 201908>
# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.

GPU drivers were missing. When trying to start hashcat, it resulted in an error.

hashcat -I
* Device #1: Not a native Intel OpenCL runtime. Expect massive speed loss.
  You can use --force to override, but do not report related errors.
        No devices found/left.

The error popped up, because the drivers were missing. The following line could have solved the problem of the missing drivers easily if Kali could have got all needed dependencies.

sudo apt install -y ocl-icd-libopencl1 nvidia-driver nvidia-cuda-toolkit

Some packages could be installed manually with no further effort by just typing

apt-get install <packagename>

Unfortunately, nvidia-cuda-toolkit needed the package nvidia-dev which needed libcublas10 in another version. libcublas10.2 was installed but v 10.1 was needed. To install a package in a specific version, first uninstall the current version and then specify your version with the syntax <packagename>=<versionname>

apt-get remove libcublas10
apt-get install libcublas10=10.1.105-3+b1

When hashcat was finally ready to do it's job, it looked like this

hashcat -I
root@alice:~# hashcat -I
hashcat (v5.1.0) starting...

OpenCL Info:

Platform ID #1
  Vendor  : NVIDIA Corporation
  Name    : NVIDIA CUDA
  Version : OpenCL 1.2 CUDA 10.1.120

  Device ID #1
    Type           : GPU
    Vendor ID      : 32
    Vendor         : NVIDIA Corporation
    Name           : GeForce GTX 980
    Version        : OpenCL 1.2 CUDA
    Processor(s)   : 16
    Clock          : 1240
    Memory         : 1010/4043 MB allocatable
    OpenCL Version : OpenCL C 1.2 
    Driver Version : 430.50

Platform ID #2
  Vendor  : The pocl project
  Name    : Portable Computing Language
  Version : OpenCL 1.2 pocl 1.3 None+Asserts, LLVM 7.0.1, SLEEF, DISTRO, POCL_DEBUG

  Device ID #2
    Type           : CPU
    Vendor ID      : 128
    Vendor         : GenuineIntel
    Name           : pthread-Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz
    Version        : OpenCL 1.2 pocl HSTR: pthread-x86_64-pc-linux-gnu-sandybridge
    Processor(s)   : 12
    Clock          : 3800
    Memory         : 16384/62385 MB allocatable
    OpenCL Version : OpenCL C 1.2 pocl
    Driver Version : 1.3

Installing the tools

The order of the tools to install did not follow any rule as it was planned to install all tools.


Cracklord is using two subsystems. There is one "client" (named queued) with which the user interacts and one "server" (named resourced) which manages the resources (the CPUs and GPUs). Both need to run at the same time, either on different hosts or on the same. The project owner says: "For now only Ubuntu is supported and unless someone has some expertise in package building it will likely stay that way. I will continue to try and update the build documentation so people can build it from source on various Linux/Unix/Windows systems." (Nov 6, 2016)

Download the queued and the resourced file from here Install both deb files that you downloaded with dpkg:

dpkg -i Downloads/cracklord-queued_1.0-beta-98-ge2bd792_amd64.deb
dpkg -i Downloads/cracklord-resourced_1.0-beta-98-ge2bd792_amd64.deb

As both files won't work out of the box, in the next step, we change some files.

apt-get install mc
ln -s /usr/bin/true /usr/bin/initctl

The Midnight-Commander can be used to setup an environment that makes it possible to run the postinstall script with dpkg

Finally, the queue instance as well as the resource instance are able to start. Though the GUI says, jobs run and finish with done, hashcat is actually not cracking passwords. This is how to make it work and why it is not functioning:

Cracklord is basically calling Hashcat with the parameters, the user provides in the GUI. It is starting hashcat as the user "Cracklord" which normally has no home directory. A quick hack for this is to provide Cracklord a home directory

mkdir /home/cracklord
chown -r cracklord:cracklord

At first glance, enabled potfiles prevented hashcat from working correctly but this idea went out to be wrong. There is no need to adapt the default settings about potfiles. (A potfile is an hashcat specific file where it saves its progress.)

Other difficulties rose with these configuration settings:

  • the location of the hashcat binary
  • writing permissions in the working directory
  • finding a dictionary that was accepted
  • defining a rule that does nothing


Installing WebHashcat worked well using this guide While installing, some dependencies must be added manually. For some of them, apt did not work but pip3 did. The default certificates did not work. We supposed the problem could be, that there was no alias set. With a config file and two lines of bash code, we were able to define aliases for all possible names. If you need to define a certificate with aliases, you can use/adapt this script, name it localhost.conf and execute the following commands in the same direction.

distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
C = DE
ST = B
L = Berlin
OU = Itsec
CN = localhost
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
DNS.1 = localhost
DNS.2 = alice
IP.1 =
IP.2 =
openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout server.key -out server.crt -config localhost.conf -extensions 'v3_req'
openssl x509 -in server.crt -noout -text

Finally, neither the default nor the self created certificate worked. To be able to work, the certificates are ignored by changing the method send to the following

def send(self, url, data=None):
        headers = {
            "Content-Type": "text/plain; charset=utf-8",
            "Accept-Encoding": "text/plain",
            "Authorization": "Basic %s" % self.key,

        # begin of editing
        # gcontext = ssl.SSLContext(ssl.PROTOCOL_TLSv1)  # disable certif validation
        # PROTOCOL_TLS_CLIENT requires valid cert chain and hostname
        gcontext = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
        gcontext.check_hostname = False
        gcontext.verify_mode = ssl.CERT_NONE
        # end of editing
        conn = http.client.HTTPSConnection(self.ip, self.port, context=gcontext)

        if data == None:
            conn.request("GET", url, headers=headers)
            conn.request("POST", url, "%s\r\n\r\n" % json.dumps(data), headers)

        res = conn.getresponse()

        data =

        return json.loads(data.decode("ascii"))

More errors are thrown because of male or not implemented functions.

  • Division by zero in API/ (Check if you have more than zero jobs in total before you calculate the ratio of successful jobs, otherwise you'll crash with 0/0)
  • Delaying of the remove_hashfile_task function in API/ (Using remove_hashfile_task.delay() wont make the function execute in the nearer future, just use remove_hashfile_task())
  • Not Implemented action for import_hashfile_task in Hashcat/templates/Hashcat/hashes.html (Add an action to the form that is submitted via the add new hashfile button. Don't forget to define backend functionality for loading up files)
Error How to fix
Division by zero in API/ Check if you have more than zero jobs in total before you calculate the ratio of successful jobs, otherwise you'll crash with 0/0
Delaying of the remove_hashfile_task function in API/ Using remove_hashfile_task.delay() wont make the function execute in the nearer future, just use remove_hashfile_task()
Not Implemented action for import_hashfile_task in Hashcat/templates/Hashcat/hashes.html Add an action to the form that is submitted via the add new hashfile button. Don't forget to define backend functionality for loading up files

Using the tools

[only for the specific setup on the used machine]


Starting the queued system:

/usr/bin/cracklord-queued --conf=/etc/cracklord/queued.conf

The queued server runs on port 443 and can be accessed using a secure connection. Firefox ESR displays https://localhost:443 well, other browsers were not tested.

Starting the resourced system with the shell script


wihich is the %postinstall-script of the dpkg modified to fit to our system:

#!/bin/sh -x
#description   "Cracklord Resource Server"
#author        "Lucas Morris & Michael McAtee"

#start on (net-device-up and local-filesystems and runlevel [2345])
#stop  on runlevel [016]


cd /var/cracklord/ &&\
runuser -u cracklord -g cracklord -- \
/usr/bin/cracklord-resourced --conf="/etc/cracklord/resourced.conf"

The resourced system runs on port 9443 and is not meant to be accessed via any browser.

Login Accessing the queued server on port 443, login is possible with the credentials from CONTENTS/queued.conf Admins credentials are: username admin, password changeme


Starting the background services:

 systemctl restart mysql
 systemctl restart hashcatnode
 systemctl restart redis-server

Starting WebHashcat:

cd /path/to/WebHashcat
./ runserver

You will not be able to run any hashcat job as long as you can not upload the files needed.


Cracklord was configured to use hashcat as the underlying tool so the performance hardly depends on hashcats efficiency. The queue is updated every 30s by default, so jobs may wait 15s in average unregistered. Working with huge lists, this time can be ignored.

WebHashcats scheduling system could not be tested nor analyzed until now. It uses hashcat internally but how scheduling is done needs to be further explored.


Both tools claim to be able to schedule, work with masks, rules, dictionary attacks as well as brute force attacks. In WebHashcat these functions could not be tested due to missing basic implementation. At first glance, Cracklord worked well but further tests will be required.

Further research

It should be tested if Cracklord works well using the OS version it was implemented for. If so, a container could be used to run the tool. For sure, such a system would be using functionality that could outdate soon. Hashtopolis should be tested next as it is the most promising project. HiSolutions is also interested in working with a student to develop a tool that meets the requirements of HiSolutions. For further research work, e.g. for a bachelor or masters thesis, contact Dominik Oepen from HiSolutions.