The archived FAQ covers hardware and drivers that are no longer relevant. Its advice is out of date. Use the current pages instead.
(short URL: https://hashcat.net/faq/ubernoobs)
The reason for this is that the hashcat tools are command-line tools only.
See the wiki page Help for ubernoobs to troubleshoot this problem.
Windows may flag or remove hashcat because antivirus products often classify password recovery tools as potentially unwanted software. A warning alone does not mean the download is corrupt.
hashcat.exe is not code signed. There is no certificate in the file, so SmartScreen has no signature to check and warns about an unrecognised app. Separately, antivirus products flag password recovery tools by category rather than by behaviour, so a clean hashcat is often quarantined or deleted straight out of the archive.
Verify the archive's PGP signature before extracting it. The signature confirms that the file was published by the project and has not been changed. See How do I verify the PGP signatures?.
After verifying the archive, add the hashcat folder to your antivirus exclusion list if the software quarantines it. Do not disable antivirus protection entirely. Download hashcat only from hashcat.net.
The best way to get started with software from hashcat.net is to use the wiki, especially the general guide links. You can also search the forum for your specific question using its search function.
Please do not immediately start a new forum thread. First use the built-in search function or a web search engine to see whether the question has already been asked and answered.
There are also some tutorials listed under How-tos, videos, papers, articles, etc. from around the web to learn the very basics. Note that these resources may be outdated.
NOTE: YOU CANNOT USE HASHCAT TO RECOVER ONLINE ACCOUNTS (Google, Facebook, Instagram, Twitter, etc.) - even if you have permission from the account owner. hashcat works on password hashes stored offline. It cannot recover an account password from a username.
(short URL: https://hashcat.net/faq/online)
You can't. That's not the way hashcat works.
hashcat cannot help you if you only have a username for some online service (like Facebook, Google, Instagram, Twitter, etc.). hashcat can only attack back-end password hashes.
Hashes are a way of storing passwords on the server side. It is like cracking open a shell to get the nut inside, hence the term “hash cracking”. If you don't have the password hash to attack offline, there is no hash for hashcat to attack.
We cannot recommend other ways to recover online passwords - that would require the explicit permission of both the account holder and the company operating the website or service. If you don't have both of those things, you're probably doing something that could get you into serious trouble.
It doesn't matter if it's your own account. It doesn't matter if you have your “friend's” permission.
Don't do it.
There is one hashcat program for CPUs and GPUs. It can use several compute backends:
Use hashcat -I to see which devices and backends are available on your system.
It was not always one program. oclHashcat, oclHashcat-plus, and oclHashcat-lite were separate, and hashcat 3.00 merged them. Its changelog opens “This release marks the fusion of hashcat and oclHashcat into hashcat”. hashcat-legacy is a different thing again, the CPU-only program under its post-split name, and it is retired. If you are reading a guide that names any of the old ones, it predates 3.00. See the Archive.
The archive holds two binaries, both 64-bit:
hashcat.bin for Linuxhashcat.exe for WindowsmacOS is supported, and hashcat has a Metal backend for Apple's GPUs, but the archive does not include a macOS binary. Build it from source, or install it through a package manager.
CPU usage is normally low while cracking. Two exceptions are selecting an OpenCL-capable CPU as a device and using one of the seven bridged modes. Neither indicates a fault. Bridged modes move hashing off the GPU and place more work on the host. Those are -m 70000, 70100, 70200, 73000, 74000, 75000 and 79000, and --help marks each of them [Bridged: ...].
Start by fetching the signing key. Ask for it by its full fingerprint rather than the short ID, because short IDs can be forged:
$ gpg --keyserver keyserver.ubuntu.com --recv-keys A70833229D040B4199CC00523C17DA8B8A16544F
Then download hashcat and its signature:
$ wget https://hashcat.net/files/hashcat-8.0.0.7z $ wget https://hashcat.net/files/hashcat-8.0.0.7z.asc
Finally, verify the signature:
$ gpg --verify hashcat-8.0.0.7z.asc hashcat-8.0.0.7z gpg: Signature made Sun 25 Oct 2026 06:53:45 PM CET gpg: using RSA key A70833229D040B4199CC00523C17DA8B8A16544F gpg: Good signature from "Hashcat signing key <signing@hashcat.net>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: A708 3322 9D04 0B41 99CC 0052 3C17 DA8B 8A16 544F
“Good signature” means the signature is valid. The warning below it means GPG cannot confirm that you trust the signing key. It does not indicate a failed check. Compare the fingerprint above with the one on the download page. They must match exactly.
A70833229D040B4199CC00523C17DA8B8A16544F. Searching by address is less reliable, and a short ID can be forged..asc signature into the same folder..asc file, open “More GpgEX options” and click “Verify”. Check that “Input file is a detached signature” is ticked, then click “Decrypt/verify”.
There is no official GUI. This FAQ no longer names a third-party one because both previously recommended tools have disappeared: hashkiller.co.uk/hashcat-gui.aspx is no longer available, and github.com/s77rt/hashcat.launcher has been removed from GitHub.
A third-party GUI is not ours to support, so questions about one are best taken to whoever publishes it, or to the forum you found it on.
We have not developed a GUI because we believe in the power and flexibility of command-line tools. Besides, hashcat is an advanced password recovery tool, and using the command line should be a basic requirement for using it.
To use the archive version, extract it and run hashcat from that folder.
The archive contains hashcat.bin on Linux and hashcat.exe on Windows, but does not add it to your PATH. From the extracted folder, run ./hashcat.bin on Linux or hashcat.exe on Windows. If you installed a distribution package, run hashcat instead. For brevity, the examples below use hashcat.
On macOS there is more to it, because the archive contains no macOS binary: build from source or install through a package manager.
Please note that your GPU must be supported and the driver must be correctly installed to use this software.
If your operating system or Linux distribution provides a pre-built hashcat package, you may be able to install it using the system's package manager. For example, you can use the following on Ubuntu, Debian, or Kali Linux:
$ sudo apt-get update && sudo apt-get install hashcat
and update it with:
$ sudo apt-get update && sudo apt-get upgrade
Even if some distributions support package installation, we do not directly support those packages because package maintainers are responsible for updates, dependencies (some packages may add wrappers, etc.), and sensible installation paths.
If something is not working with a package installed through your package manager, download the hashcat archive directly, enter its folder, and run hashcat. This is the preferred and only directly supported method to “install” hashcat.
Some distribution packages are several major versions behind the current release. They may lack modes and options described on this wiki. Check what you have with hashcat -V against the download page before assuming a missing feature is a wiki error. See this Repology list of hashcat package status.
hashcat compiles its kernels while it runs. The graphics driver provides OpenCL. To use CUDA on NVIDIA or HIP on AMD, install the matching compiler package as well.
| your hardware | what to install | backend you get |
|---|---|---|
| NVIDIA GPU | the NVIDIA driver, plus the CUDA Toolkit | CUDA |
| AMD GPU, Linux | ROCm | HIP |
| AMD GPU, Windows | the Adrenalin driver, plus the AMD HIP SDK | HIP |
| Intel GPU | the Intel Graphics Compute Runtime, known as NEO | OpenCL |
| CPU | the Intel CPU Runtime for OpenCL, or PoCL | OpenCL |
| Apple | no install needed, macOS carries Metal and OpenCL itself | Metal |
If the compiler package is missing, hashcat warns you and continues through OpenCL:
* Device #1: CUDA SDK Toolkit not installed or incorrectly installed.
CUDA SDK Toolkit required for proper device support and utilization.
Install drivers and compiler packages from supported vendor sources. Check that the versions work together, especially when the driver came from a distribution package or Windows Update.
Platform-specific instructions follow.
Install the driver and the CUDA Toolkit. hashcat opens two libraries at run time: libcuda.so from the driver, and libnvrtc.so from the Toolkit.
hashcat scans for the newest versioned name, so a system carrying only the CUDA runtime libraries still gets the CUDA backend. Older guides recommend installing the unversioned libnvrtc.so symlink from the development package, but it is no longer needed.
Check these version requirements as well:
compute_75 and newer, so a Maxwell, Pascal or Volta card cannot have its kernels compiled by a CUDA 13 NVRTC. Older cards need an older Toolkit.To verify:
$ cat /proc/driver/nvidia/version # the driver is loaded $ nvidia-smi # the card is visible $ hashcat -I # a CUDA Info: section exists
The CUDA.Version. line in -I is the driver's CUDA version, from cuDriverGetVersion, not the installed Toolkit version. hashcat never prints the NVRTC or Toolkit version, so -I cannot establish whether the Toolkit is suitable. The “CUDA Version” in nvidia-smi also refers to the driver's capability.
Install ROCm. hashcat opens two libraries, the HIP runtime libamdhip64.so and the HIP compiler libhiprtc.so, and takes the newest versioned name it finds, so AMD's own packages work without extra symlinks.
Group membership is the most common cause of a card that is not detected. hashcat checks for it and its own advice is incomplete:
Cannot access /dev/dri/card0: Permission denied. This causes some drivers to crash when OpenCL is used! Adding your user to the "video" group usually fixes this problem: $ sudo usermod -a -G video $LOGNAME
video alone is not enough for ROCm, which also needs render for the DRM render nodes its compute path uses. Add both, then log out and back in, because group membership is only picked up at login:
$ sudo usermod -a -G video,render $LOGNAME
The check has two limitations. It only looks at card0, so it never runs or prints a warning if the AMD card is card1. It is also skipped entirely for root. Running as root can therefore appear to fix the problem without correcting group membership.
When /dev/kfd is unusable, which is what missing groups produce in practice, the card disappears from both backends: hashcat prints hipInit(): no ROCm-capable device is detected. rocminfo fails the same way, with HSA_STATUS_ERROR_OUT_OF_RESOURCES.
To verify:
$ rocminfo | grep -E 'Name|gfx' # ROCm sees the card $ hashcat -I # a HIP Info: section exists
A card that is not on AMD's supported list may still work: hashcat enumerates whatever ROCm enumerates. HSA_OVERRIDE_GFX_VERSION can make an unsupported card report a supported ISA, but it applies to every GPU in the machine rather than the one you meant, and a malformed value makes them all report gfx000, which is unusable.
Install the Adrenalin driver and the AMD HIP SDK. The minimums are Adrenalin 23.7.2 and HIP SDK 23.Q3.
hashcat reads HIP_PATH, which the SDK installer sets, and takes the newest matching DLL out of the bin directory it points at. The version in the file name is HIP's own rather than the ROCm release, so reading the directory is the only reliable way to find it. If HIP_PATH is unset or wrong, PATH is searched next, which is where the graphics driver leaves its own older copy.
hashcat refuses HIP on Windows for any AMD device whose architecture does not parse as gfx1000 or higher, printing This HIP version does not support this device on Windows. Falling back to OpenCL. So pre-RDNA cards are OpenCL-only on Windows whatever you install.
Install the Intel Graphics Compute Runtime, known as NEO. An Intel GPU is OpenCL only: hashcat has four backends, CUDA, HIP, Metal and OpenCL, and there is no Level Zero or oneAPI backend, so there is no fast path to reach. hashcat enforces no minimum version for NEO and uses it on a best-effort basis, so if it misbehaves, check its version yourself.
Mesa's rusticl is an OpenCL implementation that hashcat can use. It has some limitations:
RUSTICL_ENABLE to make them visible to hashcat. Mesa warns that enabling devices can affect system stability while it addresses remaining issues.hashcat enforces no minimum version for rusticl and uses it on a best-effort basis. It cannot identify problems specific to rusticl. If your card has a vendor runtime available, ROCm on AMD or NEO on Intel, use that instead. See Mesa's rusticl documentation to enable rusticl.
Two options, and hashcat treats them differently:
Outdated or broken Intel OpenCL runtime
CPU devices are off by default, because a busy CPU slows down GPU synchronisation. Ask for one with -D 1, or -D 1,2 for both. The exception is a machine with no OpenCL GPU at all, where hashcat enables the CPU by itself so a CPU-only box needs no flag.
The archive does not include a macOS binary. macOS provides Metal, which hashcat supports. Build hashcat from source or install it through a package manager.
Outdated NVIDIA CUDA driver version detected! Falling back to OpenCL… and carries on. Older releases exited instead.Unsupported AMD HIP runtime version '6.1.0' detected! Falling back to OpenCL…--force does override that one.
--force does not lift the CUDA or HIP runtime version gates. The floors are set by what a current distribution can install, and docs/hashcat-requirements.md in the release states them along with the reasoning.
hashcat -I to see what loaded. A backend that did not come up has no section at all, so a machine with an NVIDIA card and no CUDA Info: block is missing the CUDA Toolkit. That absence is the most useful thing in the output.-I to decide whether a device is usable. It deliberately turns the version and suitability checks off, so it lists devices a real attack would refuse. To see the skip reasons, start an actual run: those messages are printed then, not by -I.--force does not lift these.ATTENTION! No OpenCL, HIP or CUDA compatible platform found means no runtime loaded at all, so either no runtime is installed or none is reachable. No devices found/left means a runtime did load but every device in it was excluded, by -d, by --backend-devices, or by a suitability check.xorg.conf, DISPLAY and xhost belongs to a driver generation that is gone.No, that is expected. A card that more than one backend can reach is listed once per backend, and hashcat cross-references the copies so you can see they are the same hardware:
HIP Info:
Backend Device ID #01 (Alias: #03)
Name...........: AMD Radeon RX 9070 XT
OpenCL Info:
Backend Device ID #03 (Alias: #01)
Name...........: AMD Radeon RX 9070 XT
That is one GPU, reachable through HIP and through OpenCL. Two GPUs plus a CPU can easily report six device entries this way. hashcat uses one of each alias pair rather than both, so no device is counted twice during an attack.
One other thing in that output surprises people: the CPU is listed under a platform named for a different vendor. An AMD processor showing up under Name....: Intel(R) OpenCL is normal, because Intel's CPU runtime drives AMD CPUs too.
(short URL: https://hashcat.net/faq/wrongdriver)
The usual cause is not an incorrect driver but a missing compiler package, so read the driver question before you uninstall anything. Work through this in order, because each step is cheaper than the one after it.
$ hashcat -I
If hashcat does not show CUDA Info: on an NVIDIA system, check that the CUDA Toolkit is installed and available. If it does not show HIP Info: on an AMD system, check the HIP installation.
Remember that -I deliberately skips the suitability checks, so it lists devices a real run would refuse. If -I looks fine but an attack does not, start an attack and read those messages instead.
This is worth doing before anything drastic, because a stale compile survives a driver change and produces failures that look like a broken driver.
There is more than one cache, and hashcat's own is the smallest and least likely culprit:
~/.nv/ComputeCache, movable with CUDA_CACHE_PATH and disableable with CUDA_CACHE_DISABLE=1. AMD's ROCm compiler cache is ~/.cache/comgr. PoCL's is ~/.cache/pocl. Mesa and rusticl use ~/.cache/mesa_shader_cache.On one machine here, hashcat's cache is under a megabyte while the runtime caches total nearly three gigabytes. After a driver change, a runtime cache is more likely to contain stale compiled code.
Note that ~/.local/share/hashcat is not a cache: it holds your potfile and your sessions. Do not delete it to fix a driver.
Uninstall through Settings, Apps first. If that leaves a mixed state, both vendors publish a cleaner and there is no need for anything third-party:
Reboot between removing and installing. Then install the driver and its compiler package, and on AMD check that HIP_PATH is set, since that is where hashcat looks for the HIP SDK first.
Match the removal to the install route, because mixing them is what creates the mess in the first place:
.run installer: nvidia-uninstallamdgpu-install: use its own uninstall option
Then check the ICD loader. Several packages may provide libOpenCL. A vendor runtime and ocl-icd-libopencl1 can both be installed. Check which runtimes the loader has registered:
$ ldconfig -p | grep libOpenCL $ ls /etc/OpenCL/vendors/
That directory is how the loader finds each vendor, so a driver that installed no .icd file there will not be found through OpenCL however well it is installed otherwise.
Reinstall, then add yourself to the right groups if you have not: video and render for ROCm, followed by a logout.
$ clinfo | head # the ICD loader sees a platform $ hashcat -I # hashcat sees the devices $ hashcat -b -m 0 # it can actually compile and run
If it still does not work, ask on the forum with the full output of hashcat -I, your exact command line and the hashcat version. Without those three nobody can tell a driver problem from a hashcat problem.
hashcat compiles its kernels the first time it needs them and caches the result, which is why the first run of a mode is slow and later ones start at once. A stale cache is worth clearing after a driver change.
There is more than one cache involved, and hashcat's own is the smallest. That matters, because the usual reason for clearing anything is a driver change, and a driver change invalidates the runtime's cache rather than hashcat's.
On Windows it is always the kernels directory beside hashcat.exe, because the home-directory logic is POSIX-only. On Linux and macOS it depends on how hashcat was installed:
kernels directory beside the binary. Delete that directory.make install or a distribution package: under your home instead, because the program directory is not yours to write to. That is $XDG_CACHE_HOME/hashcat/kernels, meaning ~/.cache/hashcat/kernels unless you set the variable. Older versions preferred ~/.hashcat/kernels whenever that directory existed. hashcat 8.0.0 no longer does, so if you have one from an earlier install your kernel cache, potfile and sessions have moved to the XDG locations. No files are copied or deleted, and hashcat prints where they are now, so move anything you want to keep.Every backend compiler keeps its own cache as well, and a release build of hashcat leaves them all enabled. (It disables the CUDA and PoCL caches only in a debug build, where its own cache is off too.)
| what writes it | default location | environment variable |
|---|---|---|
| NVIDIA CUDA JIT | ~/.nv/ComputeCache | CUDA_CACHE_PATH, CUDA_CACHE_DISABLE |
| AMD ROCm compiler, which hashcat's HIP compile writes into | ~/.cache/comgr | |
| PoCL | ~/.cache/pocl | POCL_CACHE_DIR, POCL_KERNEL_CACHE |
| Mesa, rusticl | ~/.cache/mesa_shader_cache |
The scale is worth seeing. On one machine here hashcat's cache is 908 KB while ~/.cache/comgr is 1.5 GB and ~/.cache/pocl is 1.3 GB. So if you cleared hashcat's cache after a driver change and the speed did not improve, the reason is that you cleared the wrong one.
hashcat also sets TMPDIR to its own profile directory when TMPDIR is unset, so a runtime that caches into TMPDIR lands inside hashcat's directory rather than /tmp.
~/.local/share/hashcat is hashcat's data directory. It holds hashcat.potfile and sessions/. Deleting it loses your cracked passwords and your restore state, so keep it out of any cleanup.
$ ls kernels # beside the binary $ ls ~/.cache/hashcat/kernels ~/.hashcat/kernels $ du -sh ~/.nv/ComputeCache ~/.cache/comgr ~/.cache/pocl 2>/dev/null
hashcat prints this as clCreateBuffer(): CL_INVALID_BUFFER_SIZE. The number -61 is what older versions printed, and is kept here so people arriving from old forum threads find the page.
This is the typical out-of-memory error, and it is not driver related. It refers to your GPU memory, not host memory.
There is a limit on how much can be allocated in a single block, which is lower than the card's total memory, and that is usually what you have hit. Do not go looking for a fixed figure: it depends on the backend, the runtime and the device. OpenCL guarantees only that a quarter of total memory can be allocated at once, and a runtime is free to allow more. On one machine here the same question gets four different answers, from a quarter up to 85 percent.
Read your own number off hashcat -I. Where the runtime reports a single-block limit, hashcat prints it next to the total:
Memory.Total...: 16304 MB (limited to 13858 MB allocatable in one block)
Not every device prints the suffix. When it is absent the runtime did not report a separate limit.
What to try:
-n (--kernel-accel)
hashcat prints this as clEnqueueCopyBuffer(): CL_INVALID_VALUE. The number -30 is what older versions printed.
This error is unrelated to the driver. It most often occurs when you use too many rules. To reduce the total rule count:
-g value-r files
There is an arithmetic ceiling you can work out rather than guess at. The release's docs/limits.txt gives it: a rule is capped at 31 functions, which makes each rule 128 bytes on the device, and the whole rule buffer has to fit in one allocation. So the limit is roughly the single-allocation size divided by 128, which that file works out as about 16M rules on an 8 GB card.
702 is CUDA's CUDA_ERROR_LAUNCH_TIMEOUT. A kernel ran for longer than the display driver's watchdog allows, so the driver killed it and reset the device. It is unrelated to your rule count.
This happens on a card that is also driving a monitor, because that is where the watchdog applies, and it gets more likely the harder you push. In order:
--kernel-accel (-n) or --kernel-loops (-u) by handIf you need full speed on the card that runs your screen, the watchdog itself can be turned off. On Windows that is a documented Microsoft registry value, and Driver Timeout Patch has the exact steps for Windows and for X11.
Note that hashcat gives you no hint about this: it used to warn “Kernel exec timeout is not disabled” at startup and that warning is commented out, so the timeout is the first you hear of it.
The same overrun on the OpenCL backend usually surfaces as CL_OUT_OF_RESOURCES or a bare driver reset rather than a 702.
Old archives stay on hashcat.net, but there is no index to browse: the URL is https://hashcat.net/files/hashcat-<version>.7z, so hashcat-6.2.6.7z and so on. Tagged releases are also on GitHub.
Use the current version unless you have a specific reason not to. A newer release generally brings fixes, more modes and better hardware support. A problem on an old version may already be fixed. In our view, the only valid reason to use an older hashcat version is when AMD/NVIDIA has dropped support for your graphics card and hashcat developers have chosen to support newer cards and drivers instead.
Look at the Usage line at the top of --help:
Usage: hashcat [options]... hash|hashfile|hccapxfile [dictionary|mask|directory]...
The positional arguments have a fixed order: the hash or hash file first, then the wordlist or mask. Options are not positional and can go anywhere, including after the mask.
$ hashcat -m 0 -a 3 hash.txt ?l?l?l?l # right $ hashcat -m 0 -a 3 ?l?l?l?l hash.txt # wrong
The wrong one does not give you the usage, though. hashcat takes ?l?l?l?l as the hash and stops with Hash '?l?l?l?l': Token length exception and No hashes loaded, which is the same thing you see when a hash file path is wrong. See Line-length exception, wait what?
The usage means the number of positional arguments does not fit your attack mode. hashcat counts them per mode and prints the usage when the count is wrong, before it looks at anything else. The two common cases:
-a 1, given one wordlist or three. It wants exactly twoThree other commonly suspected causes produce different symptoms:
-m runs autodetect. You get a table of candidate modes and Please specify the hash-mode with -m [hash-mode].-a leaves you in straight mode, so your mask is treated as a wordlist path and you get ?l?l?l?l: No such file or directory
Quote a mask anyway: on Linux if your shell expands ?, and on Windows if it contains ^ or &. Be aware that hashcat does not report this expansion. Surplus words left by an expansion are dropped in silence, so the run proceeds with a mask you did not intend. Check Guess.Mask on the status screen against what you typed.
If that is not your problem, read the full --help output and search the wiki.
Yes, mostly. hashcat 8.0.0 extracts to about 106 MB, and there is only one thing in there worth deleting.
Almost half of it is modules, the per-hash-mode plugins, and the archive ships both platforms: 728 .so files for Linux and 728 .dll files for Windows. You only ever load one set, so the other set is dead weight.
On Linux:
$ rm modules/*.dll
On Windows:
C:\> del modules\*.so
That takes the folder to about 74 MB on Linux, or about 91 MB on Windows, and everything still works. The same is true of the two top-level binaries and the bridges folder, which also carry both platforms, but those are small enough not to bother with.
Do not go looking for kernels to delete. Old advice told you to remove precompiled .ptx files for GPUs you do not own, or AMD kernels by VLIW generation. hashcat ships no precompiled kernels at all. It ships OpenCL source in OpenCL, 28 MB of it, and compiles what it needs on first use into a kernels directory that does not exist until you run it. Deleting from OpenCL will break modes you later want.
The kernels directory grows as hashcat compiles kernels for each mode and device combination. You can delete its contents at any time. hashcat will rebuild them, though the next run may be slower. See Where does hashcat keep its compiled kernels?
Exhausted means hashcat has tried every password combination in the specified attack without cracking 100% of the supplied hashes. It has exhausted the search. Run another attack with a different wordlist, mask or set of rules.
A hashcat mask file is a set of masks stored in a single plain text file with extension .hcmask.
The line format is described here: hashcat mask file
Each line of a .hcmask file can contain the following fields (the order of the fields is exactly as mentioned here):
--custom-charset1 (short -1, optional): define a custom char set which you can reference in the mask with ?1--custom-charset2 (short -2, optional): define a custom char set which you can reference in the mask with ?2--custom-charset3 (short -3, optional): define a custom char set which you can reference in the mask with ?3--custom-charset4 (short -4, optional): define a custom char set which you can reference in the mask with ?4Fields are separated by commas (“,”, without quotes). If an optional field is omitted, its comma must also be omitted. To specify only a mask, use lines like these:
?u?l?l?l?l?s ?u?l?l?l?l?l?s ?l?l?l?l?l ?l?l?l?l?l?s
Note: no custom charsets are set (-1, -2, -3, -4) or used (?1, ?2, ?3, ?4). Each line therefore has 1 field and no commas.
On the other hand, if, for instance, you only need --custom-charset1 (or short -1), your lines would look something like this:
?l?d,?l?l?l?l?1 ?l?u,?1?1?1?1?1?1
Note: --custom-charset1 is set to ?l?d on the first line and ?l?u on the second. These 2 lines are independent. When --custom-charset1 (short -1) is set, use it in the mask with ?1. Conversely, using ?1 requires a valid --custom-charset1 (short -1) definition.
If 2 custom char sets are needed, you would use something like this:
?l?d,?u?l,?2?1?1?1?1?1?1
Note: here we set --custom-charset1 (or short -1) to ?l?d and --custom-charset2 (or short -2) to ?u?l and then use those custom char sets within the mask.
… and so on (up to the 8 supported custom charsets).
There are 4 important syntax rules:
You can use .hcmask files as follows:
$ ./hashcat.bin -m 0 -a 3 md5_hash.txt my.hcmask
In other words, specify the path to the .hcmask file at the position in the command line where you normally would use the single mask.
A weak hash is one whose plaintext is empty, meaning the password has a length of zero. This can happen when someone presses Enter without typing a password.
hashcat used to check for these by itself at startup, and --weak-hash-threshold set how many salts it would do that for. That feature was removed, because it cost startup time on a list with many salts and caused crashes on macOS. hashcat no longer looks for empty passwords on its own.
You can still try one, and it costs a single candidate. Put an empty line in a wordlist:
$ printf '\n' > empty.dict $ hashcat -m 0 -a 0 hash.txt empty.dict d41d8cd98f00b204e9800998ecf8427e:
(short URL: https://hashcat.net/faq/potfile)
The potfile stores which hashes were already cracked, and thus won't be cracked again.
Otherwise, for example, the output file (--outfile, -o) could contain the same hash output repeatedly if different attack types generate password candidates that match it.
It also has an enormous effect on cracking salted hashes. If hashcat notices that all hashes associated with a specific salt have been cracked, it no longer needs to generate guesses for that salt. For example, if you have two hashes with different salts and crack one, the speed doubles. If you restart the session, the potfile marks the cracked hash as found, so hashcat can skip that salt and you start with twice the guessing speed.
You can disable potfile support completely with --potfile-disable. However, we strongly recommend leaving it enabled. If you have a large list of salted hashes and do not use --remove, restarting the session for any reason means you lose the extra guessing speed.
Using a potfile differs from using --remove. To create a list containing only uncracked hashes while retaining the original hashlist, use the --left switch. After the session finishes, run:
$ ./hashcat.bin --left -o leftlist.txt -m 0 hash.txt
You now have both the original list and the list of remaining hashes.
It's also safe to copy (or append) the data from one potfile to another.
The potfile is a file named hashcat.potfile in hashcat's profile folder, and --potfile-path overrides the location.
Where the profile folder is depends on how hashcat was installed, not on the operating system. If you extracted the archive and run hashcat from that folder, which is how most people run it, the profile folder is that folder, so the potfile sits next to hashcat.bin or hashcat.exe and not under your home directory at all.
The home-directory locations apply to a build installed to a system prefix, by make install or by a distribution package, and only on Unix-likes and macOS. There hashcat picks the first of:
$XDG_DATA_HOME/hashcat if XDG_DATA_HOME is set.$HOME/.local/share/hashcat/ otherwise.If you cannot find it, that list is the search order. Note this is the data directory, which also holds your sessions, so it is not the same thing as the kernel cache and should not be cleared casually. See Where does hashcat keep its compiled kernels?
There is no definitive way to identify a hash algorithm from the hash alone.
Some hashes include a signature that identifies the format, such as “$1$” for md5crypt. A signature is useful, but it does not guarantee that the hash was generated by that algorithm. For example, a different algorithm could use the same prefix, as in crypt(sha256(pass), “$1$”).
Without a signature, it may be impossible to identify the algorithm from the hash alone. For example, a 32-character hexadecimal string could be LM, NTLM, MD4, MD5, or many other formats.
Use --identify to list modes whose structure matches your hash:
$ hashcat --identify hash.txt
The following hash modes match the structure of your input hash:
# | Name | Category
======+============================================================+========================
500 | md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) | Operating System
The output lists formats with a matching structure, but it does not identify the algorithm with certainty. A signed hash may have one match. A bare 32-character hexadecimal string has 12 possible matches:
$ hashcat --identify hash.txt
The following 12 hash-modes match the structure of your input hash:
# | Name | Category
======+============================================================+========================
900 | MD4 | Raw Hash
0 | MD5 | Raw Hash
70 | md5(utf16le($pass)) | Raw Hash
2600 | md5(md5($pass)) | Raw Hash salted and/or iterated
...
NTLM is in that list too, further down. The point is the length of it, not the order.
Third-party “hash identifier” tools do the same regular expression matching but present one answer as though it were certain, which is worse than presenting twelve.
Use --identify to get the shortlist, then choose a mode based on the hash's source: the operating system, application and version. If its source code is available, check how it generates hashes.
For some example hashes see the example hashes wiki page.
Leaving -m off does not pick a default. hashcat tries to work the mode out from the shape of your hash, and there are two outcomes.
One mode fits, so it uses it and warns you that it guessed:
Hash-mode was not specified with -m. Attempting to auto-detect hash mode.
The following mode was auto-detected as the only one matching your input hash:
500 | md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) | Operating System
NOTE: Auto-detect is best effort. The correct hash-mode is NOT guaranteed!
Do NOT report auto-detect issues unless you are certain of the hash type.
Several fit, so it refuses to choose and stops:
The following 12 hash-modes match the structure of your input hash: ... Please specify the hash-mode with -m [hash-mode].
The second outcome means several modes fit, so hashcat will not choose one automatically. A bare 32-character hex string could match a dozen formats. Choose the right mode based on the hash's source and pass it with -m.
To ask for the shortlist deliberately, without starting an attack, use --identify. See How can I identify the hash type?
When no plains are printed and everything was already cracked, hashcat prints that, and what to do about it:
INFO: All hashes found as potfile and/or empty entries! Use --show to display them.
If only some were already known, you get a count instead:
INFO: Removed 3 hashes found as potfile entries.
and the singular form INFO: Removed hash found as potfile entry. for one. A hash whose password is the empty string is reported separately, as INFO: Removed hash found as empty hash.
In either case, hashcat does not try to crack the hashes again:
--show.hashcat avoids displaying or storing the same result again because the password is already available. At startup, it reads the potfile and marks matching entries in the hash list as already cracked.
Use --show to display every previous result stored in the .potfile. Specify a different potfile with --potfile-path if needed. You can keep a separate .potfile for each hash list. The default name is “hashcat.potfile”.
You can avoid the warning and storing all cracks by using --potfile-disable.
To accomplish this, you need to use the --show switch.
Use --show after cracking the hashes. You only need these command-line arguments:
--show (required)-m). There is no default mode: leave -m off and hashcat tries to autodetect, which works when exactly one mode fits the hash and refuses when several do. A bare 32 character hex hash matches 12 modes, so for the raw hashes in this example you must give -m--potfile-path, optional): specify a specific input .potfile (containing previous cracks)--username, optional): tell hashcat that the hash file has user names / email addresses in the first field of each and every line--outfile, -o, optional): file to store the output--outfile-format, optional): which fields to print, and you can ask for several separated by commas, so --outfile-format=1,2 gives hash then password. See --help for the list--quiet, optional): enables the quiet mode (does not show any extra info)--remove does modify / delete hashes from the hash fileExample:
$ ./hashcat.bin -m 0 --show -o formatted_output.txt --outfile-format 2 original_MD5_hashes.txt
That prints the passwords alone. For the email:password format, add --username so hashcat treats the first field of each line as a name, as in the two-step example below.
Note: You do not need, and should not specify, any mask, dictionary, wordlist directory, etc.
Here is an example of this two-step process:
1. crack the hashes:
$ ./hashcat.bin -m 0 --username --potfile-path md5.potfile original_MD5_hashes.txt rockyou.txt
2. output the hashes to a file with --show:
$ ./hashcat.bin -m 0 --username --potfile-path md5.potfile --show -o formatted_output.txt --outfile-format 2 original_MD5_hashes.txt
Keyspace usually refers to the number of possible combinations for an attack. In hashcat, it has a more specific meaning. The output of --keyspace is designed for distributing work. Divide the value from --keyspace into x chunks and use -s/-l to assign them to nodes. If the nodes differ in performance, size the chunks accordingly.
To control which candidates devices generate on the GPU, hashcat tracks some candidates on the host. It uses two loops: the “base loop” on the host and the “mod(ifier) loop” on the device.
To work between multiple compute nodes, hashcat must divide up and distribute portions of the base loop. This is where --keyspace, -s, and -l come into play. --keyspace reports the size of the base loop that executes on the host so that we know how to divide up the work. -s and -l control the start/stop positions of the base loop.
In other words, hashcat's --keyspace is specifically designed to optimize distribution of work, and is not a literal representation of the total possible keyspace for a given attack.
What --keyspace reports is the size of the base loop, so the number is usually smaller than the real number of candidates, and rules never multiply it:
| attack | base loop |
|---|---|
-a 0 | words in the wordlist |
-a 0 with rules | words in the wordlist, unchanged. The rules run in the mod loop |
-a 1 | depends on the kernel, see below |
-a 3 | the mask positions in the base loop only, so ?d?d?d?d reports 1000 and not 10000 |
-a 6 | words in the wordlist, because the dictionary is the significant side |
-a 7 | the mask, because the mask is the significant side, so ?d?d with a list reports 100 |
-a 9 | not meaningful, one candidate is tried against one hash |
-a 1 is worth spelling out, because it changes with the kernel. With the pure kernels, which is the default, the left wordlist is always the base loop and the right one runs in the mod loop, so the keyspace is the left list's word count whichever list is bigger. With the optimized kernels, under -O or on a mode that has only an optimized kernel, hashcat picks the bigger list as the base instead. So the same two files can report two different numbers depending on -O, and swapping their order changes the answer only in the first case.
| attack | base loop |
|---|---|
-a 4 | the grammar's own count, which is large: the shipped ruleset reports 12747516022634 |
-a 5 | words in the wordlist |
-a 8 | whatever the feed produces, for a wordlist feed the words in it |
-a 12 | the mask, unless ?w is the first marker, in which case the wordlist |
A worked example, with a 3 word list and a 3 rule file:
$ hashcat -m 0 -a 0 words.txt --keyspace 3 $ hashcat -m 0 -a 0 words.txt -r rules.txt --keyspace 3 $ hashcat -m 0 -a 3 ?d?d?d?d --keyspace 1000
These figures describe candidate generation on the device, which is the normal case. With -S (--slow-candidates) the host generates every candidate instead, so rules do multiply the number and a mask reports its whole keyspace. If you are splitting work across nodes, check which of the two you are running before you divide anything up.
Do not try to derive these by hand. Run --keyspace and use what it gives you.
Leave the hash file out of a --keyspace command. It takes the attack, not the hashes, and passing a hash file makes it read that as the wordlist.
See also this forum post.
Hash algorithms operate on bytes, not characters. The same password containing a German umlaut can therefore produce different hashes when encoded as ISO-8859-1, UTF-8, or UTF-16.
Use --encoding-from to specify the wordlist encoding and --encoding-to to specify the encoding required by the hash mode. This example shows the UTF-8 bytes for the German name “müller”:
$ xxd words.txt 00000000: 6dc3 bc6c 6c65 720a m..ller. $ hashcat -a 0 --stdout words.txt | xxd 00000000: 6dc3 bc6c 6c65 720a m..ller. $ hashcat -a 0 --stdout words.txt --encoding-from utf-8 --encoding-to iso-8859-1 | xxd 00000000: 6dfc 6c6c 6572 0a m.ller. $ hashcat -a 0 --stdout words.txt --encoding-from utf-8 --encoding-to utf-16le | xxd 00000000: 6d00 fc00 6c00 6c00 6500 7200 0a m...l.l.e.r..
With no options the bytes go through untouched: the umlaut stays two bytes, c3 bc. Converted to iso-8859-1 it becomes the single byte fc, and converted to utf-16le every character gains a null byte. Those are three different inputs and they give three different hashes, which is the whole problem in one picture.
--stdout with xxd is the way to check you are feeding the algorithm what you think you are.
If you would rather convert the file up front, iconv does it:
$ iconv -f utf-8 -t iso-8859-1 rockyou.txt > rockyou.iso
For brute force there are ready-made charsets in the charsets folder, organised by language and encoding:
$ ls charsets base58.hcchr combined DES_full.hcchr DES_special special standard $ ls charsets/special Castilian Catalan French German Greek Italian ...
Note: hashcat charset files (.hcchr) can be used like any other custom charsets (--custom-charset1 (-1) through --custom-charset8 (-8)).
But note, nowadays a lot of sources use utf-8. This makes things a bit more complicated.
When a charset file does not cover what you need, --hex-charset lets you write the characters as raw bytes, and --hex-salt and --hex-wordlist do the same for salts and wordlists. Every encoding question comes down to bytes in the end, and those options let you specify the exact bytes.
There is no guaranteed way to determine a hash's encoding. Try cracking hashes with the encoding you consider most likely. To check that hashcat generates the intended candidates, create example hashes and try to crack them with a dictionary attack or a mask attack using .hcchr files or --hex-charset.
(Short URL: https://hashcat.net/faq/rainbowtables)
Rainbow tables store precomputed hashes in a space-efficient form. They are useful for unsalted, fast hash algorithms when the password keyspace is limited and the same table can be reused. Creating or storing a table for one hash is usually less practical than running a targeted attack with hashcat. Salts also make precomputed tables impractical because a separate table would be needed for each salt.
GPU-based attacks are more flexible. They let you change the candidate keyspace and apply wordlists, masks, and rules without generating and storing tables in advance.
This is like asking "How long is a piece of string?".
This 100% depends on three things:
At one extreme, if you have no information at all about your password, then you might crack it instantly … or never.
At the other end of the spectrum, if you know exactly how the password was generated, and you know how much compute power you have available and how fast hashcat will run on that hardware, then you can calculate exactly how long it will take to crack, in the worst case, by exhausting the entire possible keyspace.
Between these extremes are cases where you know some things about the password and other details are unknown. If you can quantify those details, you can predict a maximum cracking time. Otherwise, you cannot calculate it.
For example, suppose you guess a number between 1 and 100 and receive “yes” or “no” after each guess. The best case takes one guess. The worst case takes 100 guesses. (Password cracking works the same way: you make guesses.)
Notice, however, that there are two factors in play in this scenario: how many possibilities there are (100), and how long it takes you to make each guess (in this case, spoken aloud). If the guessing rate is faster, it will take less time to exhaust. But even if you know the selection strategy, if the total number of possibilities is very high, it may be impossible to exhaust. (If I picked a random number between 1 and a quadrillion, and you had to speak each guess, you could never guess them all!).
But all of this example only applies if you know how the password was created. If you don't know, then the cracking process becomes less about math and more about psychology:
See hash type categories.
Read Mask attack. A mask attack is a modern and more advanced form of “brute force”.
It can fully replace brute force, and at the same time mask attacks are more flexible and more capable than traditional brute force attacks.
The general options you should consider/need are:
--increment (optional): specifies that the length of the password candidates shouldn't be fixed, but increase in length--increment-min (optional): the minimum length for --increment (if --increment is used but --increment-min was not set, it defaults to 1)--increment-max (optional): the maximum length for --increment (if --increment is used but --increment-max was not set, it defaults to the length specified by the mask, see the mask entry below)--custom-charset1 (-1), --custom-charset2 (-2), --custom-charset3 (-3), --custom-charset4 (-4) (all optional): you can define custom charsets e.g. all lower letters together with all upper letters, plus all digits: --custom-charset1 ?u?l?d (Attention: this is just the definition of a custom charset, you need to use these custom charset definitions within the mask)--increment option is not used, it specifies the fixed length (because min and max length would be set to the length implied directly from the mask length itself)An example command would therefore look something like this:
$ ./hashcat.bin -m 0 -a 3 --increment --increment-min 4 --increment-max 6 hash.txt ?a?a?a?a?a?a?a?a
Explanation:
--increment: enable incremental mode (see #1 above)
Although the mask has length 8, --increment-min and --increment-max limit the password candidates to lengths 4 to 6.
If --increment-max 6 was not specified, the maximum length would be implicitly set to 8 since the mask itself is of length 8.
You can use --increment (or short -i), --increment-min and --increment-max.
Always specify a mask. Its length must be at least the --increment-max value, or the maximum candidate length you want to try if --increment-max is omitted.
The value of --increment-max should not exceed the mask length. The mask length is the main limit. A smaller --increment-max further limits candidate length.
./hashcat.bin -m 0 -a 3 -1 ?d?l --increment --increment-min 5 md5_hash.txt ?1?1?1?1?1?1?1?1
Note: the limiting length is set by the mask (?1?1?1?1?1?1?1?1). Therefore you can think of this command as if there was an automatically added --increment-max 8. This means that you do not need to specify --increment-max 8 if it can be automatically determined by the mask length.
./hashcat.bin -m 0 -a 3 -i --increment-min 2 --increment-max 6 md5_hash.txt ?a?a?a?a?a?a?a?a
Note: --increment-max is set to a value less than the mask length. This lets you keep the 8-position mask unchanged (?a?a?a?a?a?a?a?a).
./hashcat.bin -m 0 -a 3 -i --increment-min 6 --increment-max 8 md5_hash.txt ?a?a?a?a?a?a?a?a
Note: it is even possible to set the --increment-max value to the same length of the mask even if the --increment-max value would be implied anyway by the mask length.
./hashcat.bin -m 0 -a 3 -i --increment-max 6 md5_hash.txt ?l?l?l?l?l?l?l?l?l?l
--increment-min is optional. Without it, the increment starts at length 1.
-ii (--increment-inverse) grows the mask from the right instead of the left, which is what you want when the end of the password is the part you know.
Attention: do not use these commands. They demonstrate settings that do not work or do not behave as expected.
./hashcat.bin -m 0 -a 3 --increment --increment-max 8 md5_hash.txt ?a
Note: the mask length is always the upper limit (here, length 1). Setting --increment-max to 8 cannot extend a shorter mask. A mask attack requires a charset for every position. Without a charset for the next position, hashcat stops at the last defined position (length 1 here). This is deliberate: inferring another charset could produce unexpected results.
./hashcat.bin -m 0 -a 3 --increment --increment-min 2 --increment-max 3 md5_hash.txt ?a
Note: the --increment-min of 2 is what makes this fail, because it is longer than the one-position mask. The --increment-max of 3 would merely have been capped to 1 and ignored.
./hashcat.bin -m 0 -a 3 --increment --increment-min 6 --increment-max 10 md5_hash.txt ?a?a?a?a?a?a?a?a
Note: this one does run, but not as far as you asked. An --increment-max above the mask length is silently capped at the mask length, so this covers lengths 6 to 8 and stops, with no warning that the 9 and 10 you asked for were dropped. Lengthen the mask to ?a?a?a?a?a?a?a?a?a?a if you want them. An --increment-min above the mask length is the one that is rejected outright.
./hashcat.bin -m 0 -a 3 --increment --increment-min 4 --increment-max 3 md5_hash.txt ?a?a?a?a?a?a?a?a
Note: --increment-min must be less than or equal to --increment-max. This condition is not met here because 4 > 3.
For more details about mask attacks see Why should I use a mask attack? I just want to "brute" these hashes!
It is a reasonable idea, but hashcat never walks a custom charset in the order you typed it, so reordering one gains you no speed.
With Markov on, which is the default, the order comes from the statistics in the .hcstat2 file. With --markov-disable the statistics are zeroed and the charset is then walked in ascending byte order. Neither is your order. So -1 531ba gives you 1 b a 3 5 by default and 1 3 5 a b with --markov-disable, and never 5 3 1 b a.
Your order is already the default behaviour in spirit, because that is what the Markov statistics are for: they put the likely characters first, per position, from real password data. Reordering a charset by hand is trying to do the same job with worse data.
If you have better frequency data than the shipped statistics, the supported way to use it is to build your own .hcstat2 and pass it with --markov-hcstat2. hcstat2gen from hashcat-utils builds one from a wordlist.
-r is the one you want most of the time. It takes one or more rule files, and hashcat applies every rule in them to each word.
-r works in every attack mode.
-j and -k take a single rule each and apply it to one side of the input, -j to the left and -k to the right. A rule on one side only is the one thing -r cannot express, because -r applies to the finished candidate. That is the reason to reach for them.
-g (--generate-rules) follows exactly the same mode rules as -r.
For example a combinator attack that toggles the first character of every input from the leftside.txt:
$ ./hashcat.bin -a 1 example0.hash leftside.txt rightside.txt -j T0
First of all … you cannot use rules files with -j or -k. This is a common source of confusion.
The -j and -k parameters accept only individual rule commands specified directly on the command line, not paths to rules files.
What -j and -k do:
-j, --rule-left=RULE applies rules to each word from the left (first) wordlist-k, --rule-right=RULE applies rules to each word from the right (second) wordlist
-j and -k are primarily used in combinator attacks (-a 1) and hybrid attacks (-a 6, -a 7), where there are two input sources. In a straight attack (-a 0) there is only one input, so only -j has an effect.
But what you can do is chain multiple rule functions into the single -j or -k parameters:
$ echo "password" | hashcat --stdout -j 'c $1 $!' Password1!
Also, remember your shell escaping. Some characters (especially $ and !) have special meaning in shells. Use single quotes to prevent shell interpretation, or escape characters appropriately:
For Linux:
# Correct (single quotes prevent shell expansion): $ ./hashcat -m 0 -a 1 hash.txt d1.txt d2.txt -j '$1' # Also correct (escaping the dollar sign): $ ./hashcat -m 0 -a 1 hash.txt d1.txt d2.txt -j "\$1" # Wrong (shell interprets $1 as a variable): $ ./hashcat -m 0 -a 1 hash.txt d1.txt d2.txt -j $1
For Windows Command Prompt (cmd.exe)
# Use double quotes, no $ escaping needed: C:\hashcat> hashcat.exe -m 0 -a 1 hash.txt d1.txt d2.txt -j "$1"
For Windows PowerShell:
# Escape the $ with backtick, use double quotes: PS C:\hashcat> .\hashcat.exe -m 0 -a 1 hash.txt d1.txt d2.txt -j "`$1"
Some rule syntax works only with -j or -k, not with rule files (-r):
-j applies to the left input and -k to the right, and whichever names a side that is not a wordlist is accepted and then silently has no effect. So in -a 0 only -j has an effect, in -a 6 only -j, and in -a 7 only -k. No warning is given.-j/-k in hashcat.-j or -k.For more information, see rule-based attacks.
-j and -k take a single rule, not a file. Hand one a path and hashcat reads the path itself as a rule: sometimes that is refused with Invalid or unsupported rule specified -j/--rule-left, and sometimes the characters in the path happen to form a valid chain, in which case it runs and quietly produces nonsense or no output at all.
For a rule file in a combinator or hybrid attack, use -r. It works there directly, so pre-expanding with --stdout or chaining several runs is no longer needed.
For appending or prepending a mask the hybrid attacks already do it: -a 6 puts the mask after the word, -a 7 puts it before. See Hybrid attack. For a mask in the middle of the word, -a 12 takes one mask with ?w where the word goes.
First, distinguish between two cases:
For the first case, you can concatenate the individual files.
Note: remove duplicate rules, for example with sort -u. This may leave rules that differ only in whitespace or produce the same candidates. A set of 2 textually different rules can produce similar or identical plains for some or all inputs.
The following description will deal only with case number 2 (the rules should be chained, applied at the same time).
To stack rules in hashcat, add more rule files to the attack.
Note: hashcat legacy does not support stacking. Only a single -r parameter is permitted.
$ ./hashcat.bin -a 0 -m 0 -r rules/best66.rule -r rules/toggles2.rule hashlist.txt dict.txt
Note: the order of the -r arguments can matter. The first file on the command line is applied first, then the second, and so on.
Use attack mode 12. You write one mask for the whole candidate and put ?w where the word goes, so both sides are just part of the mask:
$ hashcat -a 12 -m 0 hash.txt ?d?d?w?d?d wordlist.txt
That is two digits prepended and two appended, and no more than that. ?w can sit anywhere in the mask, and you can type fixed characters straight into it as well.
Before (How does one use several rules at once?). It still works, and it is still the answer if you want a rule's other effects at the same time:
-a 12 existed you had to reach for the rule-stacking feature
$ hashcat hash.txt wordlist.txt -r rules/hybrid/append_d.rule -r rules/hybrid/append_d.rule -r rules/hybrid/prepend_d.rule -r rules/hybrid/prepend_d.rule
Such rules exist for all the common charsets.
You can easily create your own hybrid rules using maskprocessor: rules_with_maskprocessor
Given an attack
$ ./hashcat.bin -a 6 example0.hash example.dict ?a?a?a?a?a --increment
With --increment (-i), hashcat runs the attack once per mask length, growing the mask each time until it reaches the full length. You can watch it in the status display, which names the two sides of a hybrid attack:
Guess.Base.......: File (example.dict), Left Side Guess.Mod........: Mask (?a) [1], Right Side
then, for the next pass:
Guess.Base.......: File (example.dict), Left Side Guess.Mod........: Mask (?a?a) [2], Right Side
and so on through [3], [4] and [5]. With -a 7 the mask is on the left and the dictionary on the right, so the two labels swap.
The number in brackets is the mask length, which is the quickest way to see how far the increment has progressed.
For more details about mask attacks see Why should I use a mask attack? I just want to "brute" these hashes!
-t is not accepted in every attack mode. It is refused in the straight, combinator and association attacks, where hashcat reports Option --markov-threshold is not allowed in combination with --attack mode 0. Markov ordering applies to mask positions, so it only means something where hashcat is generating a mask.
If you use hashcat with a dictionary attack (-a 0) you can specify several dictionaries on the command line like this:
$ ./hashcat.bin -m 0 -a 0 hash.txt dict1.txt dict2.txt dict3.txt
Attack modes -a 0, -a 6 and -a 7 accept multiple wordlists. In the hybrid modes, every positional argument except the mask is a wordlist. -a 1 is the exception: it takes exactly two wordlists and no directory. hashcat reads files directly inside a named directory and skips subdirectories. For nested collections, flatten the files or name them individually. Shell globbing also works because the shell expands patterns into file paths:
$ ./hashcat.bin -m 0 -a 0 hash.txt ../my_files/*.dict
To use a directory instead, specify its path on the command line:
$ ./hashcat.bin -m 0 -a 0 hash.txt wordlists
Note: consider preparing wordlists before using them with hashcat. For example, if several dictionaries may overlap, sort the words and remove duplicates:
$ sort -u -o dict_sorted_uniqued.txt wordlists/*
hashcat-utils can also help prepare wordlists. For example, use splitlen.
You often hear the following: A great and simple way to make your password harder to crack is to use upper-case characters. This means you flip at least two characters of your password to upper-case. But note: don't flip them all. Try to find some balance between password length and number of upper-case characters.
We can exploit this behavior to create an extremely optimized version of the original Toggle-case attack by generating only all these password candidates that have two to five characters flipped to upper-case. The real strong passwords have this balance, they will not exceed this rule. So we don't need to check them.
This can be done by specialized rules and since hashcat and hashcat legacy support rule-files, they can do toggle-attacks that way too.
See rules/toggles1.rule through rules/toggles5.rule. The number in the name is the most characters a rule in that file will flip, and the files are cumulative: each one covers every combination of 1 up to N flips across positions 1 to 15, so toggles5.rule already contains everything in toggles1 through toggles4. The counts are 15, 120, 575, 1940 and 4943 rules.
So pick the single file that matches how many flips you want to allow. Passing several with repeated -r does not widen the search, it just makes hashcat try the same candidates more than once.
Two other ways exist now. The Table attack with tables/toggle.table gives you every combination rather than a capped number, and attack mode 12 lets you keep these rules while a mask puts something around the word.
hashcat/hashcat legacy have default values for masks and custom charsets, so omitting a mask does not produce a syntax error. These defaults can help new users get started.
The default mask can also cause confusion. It does not consist of the built-in charsets ?a or ?b, as some users expect. Instead, it targets common patterns without covering a huge keyspace. See the default values page for the current mask.
If you omit the mask, its reduced keyspace may miss passwords you expect the attack to find. Therefore, we encourage you to always specify a mask explicitly to avoid confusion.
If you still do not know how to do so, please read Why should I use a mask attack? I just want to "brute" these hashes!
Careful with the attack mode number. hashcat-legacy had PRINCE built in as -a 8. In hashcat that number is the Generic attack, so an old guide telling you -a 8 means PRINCE is wrong.
In hashcat you pipe princeprocessor in instead:
$ ./pp64.bin rockyou.txt | hashcat -m 22000 test.hc22000
For a fast hash you need an amplifier on the hashcat side to reach full speed, because one host process cannot feed a GPU on its own:
$ ./pp64.bin rockyou.txt | hashcat -m 0 test.md5 -r rules/rockyou-30000.rule
Yes, a mask attack can use this information. Start with the basics in Mask attack.
For example, suppose the first 4 characters of the password are “Pass”, followed by 3 or 4 or 5 unknown characters that could be letters, digits or symbols. Use the following mask:
Pass?a?a?a?a?a -i
To understand how this works with the incremental, please also read this article:
I do not know the password length, how can I increment the length of the password candidates?
-a 9 pairs a candidate list with a specific hash rather than trying every candidate against every hash. It is the mode for the case people ask about most often: you know something about this particular account and want to try it against that account's hash only.
The hints that work are the obvious ones: the username, an old password from an earlier breach, a password hint field, the local part of an email address.
The hash file carries the hint alongside the hash, and you give one candidate per hash:
$ hashcat -a 9 -m 500 user500.hash 1word.dict -r rules/best66.rule
Rules can turn known information into likely password candidates. For example, a hint may be one rule away from the password. -r works in every attack mode.
Since each candidate is tried against one hash instead of all of them, the keyspace is tiny and a run finishes quickly even on a slow hash.
There are two hash-modes for Vbulletin. Between versions v3 and v4, the default salt length changed from 3 characters to 30 characters. This makes little difference in a high-level programming language, but it matters at the GPU kernel level because hashes process fixed-size blocks.
Vbulletin uses this scheme: md5(md5(pass).salt)
It first computes the MD5 hash of the password, then concatenates it with the salt. Since the software relies on PHP, and PHP's md5 function returns an ASCII hexadecimal representation by default, the input to the final md5() transformation is 32 + 30 = 62 characters long.
The problem is that 62 > 55, and 55 is the maximum buffer for a single md5 transformation call. At the low level, this requires processing the buffer of 62, followed by another md5 transformation with a nearly empty buffer, as required by the RFC. The version boundary is 3.8.5, not 3 versus 4. Before 3.8.5, the salt is 3 bytes and the computation takes 2 md5 calls, using -m 2611. From 3.8.5 onward, the salt is 30 bytes and the computation takes 3 md5 calls, using -m 2711. The scheme itself is unchanged, but the GPU kernels differ, so these are separate hash-modes.
The -t value in hashcat is the Markov threshold. At startup, hashcat loads the Markov data and sorts the character transition tables for fast access. Characters are then indexed from 1 to N by frequency. Index 1 is the most likely character at a given position. The -t threshold limits how far hashcat explores these tables. For example, -t 5 excludes characters at index 6 or higher at any position.
Without a threshold, the entire Markov space is used, all 26 lower-case characters in Markov order:
$ ./hashcat --stdout -a 3 a?l aa ao ae ai au ar al ah an am as ay at ac ap aw ad ab ak aj av ag af az ax aq
When a threshold is supplied, the Markov space traversal is reduced to the first N most common elements:
$ ./hashcat --stdout -a 3 a?l -t 5 aa ao ae ai au
And note that the stats thresholds are per position:
$ ./hashcat --stdout -a 3 bbba?l -t 5 bbban bbbar bbbal bbbas bbbam
Not at all. The hashing happens on your GPU and the driver is the same code on both, so use whichever you are comfortable with.
The one practical difference is the packaging, not the speed. On Linux an AMD card wants ROCm, and on Windows it wants the Adrenalin driver plus the AMD HIP SDK. See the driver question.
If you want to find out the maximum performance of your setup under ideal conditions (single-hash brute-force), you can use the built-in benchmark mode.
$ ./hashcat.bin -m 0 -b hashcat (v8.0.0) starting in benchmark mode ... Speed.#*.........: 15904.5 MH/s ...
Underneath, it is a brute-force attack with a mask big enough to keep your GPUs busy, against a single dummy hash that no candidate can crack: an all-zero digest carrying the mode's own self-test salt. No part of it is randomised, which is why the equivalent command below uses a hash of 32 zeros. The nearest cracking command is:
$ hashcat -m 0 00000000000000000000000000000000 -a 3 -O ?a?a?a?a?a?a?a
To match benchmark results, include -O in the cracking command. Benchmark mode uses optimized kernels by default:
Benchmarking uses hand-optimized kernel code by default. You can use it in your cracking session by setting the -O option. To disable the optimized kernel code in benchmark mode, use the -w option.
-b benchmarks the optimized kernels and -B the pure ones. In a normal attack -O selects the optimized kernels. The benchmark mask varies by hash mode.
Leave -O out and you are measuring the pure kernels, which is a fair number for real work but will not match -b.
Please note the actual cracking performance will vary depending on attack type, number of hashes, number of salts, keyspace, and how frequently hashes are being cracked.
The parameters you should consider when starting a benchmark are:
--benchmark (short -b, required): tell hashcat that it should perform a benchmark--hash-type (short -m, default is to benchmark several important algorithms, optional): tell hashcat which hash types should be benchmarked-B (--benchmark-pure, optional): benchmarks the pure kernels instead of the optimized ones. This replaces the old --benchmark-mode--benchmark-all, --benchmark-min and --benchmark-max (optional): benchmark every hash mode, or a range of themFor example, this command:
$ ./hashcat.bin -b
will give you a list of benchmark results for the most common hash types available in hashcat, using the hand optimized kernels.
Benchmark mode and a normal attack may use different kernels. -b uses the optimized kernels. A normal attack uses the pure kernels unless you add -O. hashcat prints a notice when it uses pure kernels:
ATTENTION! Pure (unoptimized) backend kernels selected. Pure kernels can crack longer passwords, but drastically reduce performance. If you want to switch to optimized kernels, append -O to your commandline.
Append -O and you get the benchmark's kernels, at the cost of a password length cap, 55 rather than 256 on most modes. See the length question.
Kernels are only the first reason, though. A benchmark is the best case by construction: one hash, no salt, a mask big enough to saturate the device. A real attack is slower whenever it has more salts, too little work to fill the GPU, or hashes being cracked and removed as it goes. If -O does not close most of the gap, the problem is workload rather than kernels, and How to create more work for full speed? is the place to look.
Leave the GPU that draws your desktop out of the attack. That is the durable answer, because it removes the cause rather than throttling around it. Run hashcat -I to get the device numbers, then name the others with -d:
$ hashcat -I $ hashcat -m 0 -a 3 -d 2,3 example0.hash ?a?a?a?a?a?a?a?a
On a single-GPU machine there is no second device to exclude, so your options are to turn the pressure down by hand with -T (--kernel-threads), -n (--kernel-accel) and -u (--kernel-loops), or to stop using the machine while it works.
There is also a power limit, which is outside hashcat: capping the card's board power with the vendor's own tool drops temperature and fan noise far more than it drops cracking speed. See the overheating question.
Workload profiles are retired, so -w no longer has an effect. The old answer, with the profile table, is in the archived FAQ.
hashcat no longer has a 32-bit version. The Linux and Windows binaries are both 64-bit.
The question mattered back when both were built. For hashcat-legacy the 64 bit build was faster, because it hashes on the CPU. For hashcat it made no difference to cracking speed, since the work happens on the GPU, though the 64 bit build could address more memory.
GPU power is how many base words one GPU works on in parallel per kernel invocation. It is the product of three numbers, with a fourth that changes how they are packed rather than how many there are:
hashcat -I reports it as Processor(s)hashcat -I reports it as Preferred.Thrd., and it follows the architecture rather than the vendor: 32 on RDNA and on NVIDIA, 64 on the older GCN parts-n and which autotune sets for you
Do not read constants off this page for your own card. Run hashcat -I and use what it reports. You can override -n, the inner loop with -u, and the thread count with -T, but autotune picks these well and beating it by hand is unusual.
(short URL: https://hashcat.net/faq/morework)
hashcat needs enough candidate work to keep the GPU busy. The amount of work available depends on the attack mode and the input you provide. A small wordlist or mask may not keep every device fully occupied.
For fast hash modes, candidate generation and transferring data to the GPU can affect performance. hashcat can expand candidates on the device in supported attack modes, using rules or masks. For slow hash modes, the hashing work itself is often enough to keep devices busy.
If a fast hash mode does not fully use your GPU, try a larger wordlist, a rules file, or a mask or hybrid attack. The best combination depends on the hash mode, devices, and candidate set, so compare performance on your system.
The advice above applies to most hash algorithms, with the exception of very slow ones. Slow algorithms use compute-hardening techniques that make hashing more resource-intensive and time-consuming. They often keep the GPU busy without an amplifier. Attacks without amplifiers can therefore be more efficient.
Because we are very limited in the number of guesses we can make with slow hashes, you're often working with very small, highly targeted wordlists. However, sometimes this can have an inverse effect and result in a wordlist being too small to create enough parallelism for the GPU. There are two solutions for this:
-S (--slow-candidates), which is hashcat's own on-host generator and does this in one process instead of two: $ hashcat -m 22000 test.hc22000 wordlist.txt -r rules/best66.rule -S
Unlike a pipe it keeps the keyspace, so you still get a progress percentage and a working restore point.
$ hashcat --stdout wordlist.txt -r rules/best66.rule | hashcat -m 22000 test.hc22000
$ pp64.bin wordlist.txt | hashcat -m 22000 test.hc22000
$ mp64.bin test?d?d?d?d?d?d | hashcat -m 22000 test.hc22000
Note: pipes work in Windows the same as they do in Linux.
Those attack modes are usually already built into hashcat, so why should we use a pipe? The reason is, as explained above, masks are split in half internally in hashcat, with one half being processed in the base loop, and the other half processed in the mod loop, in order to make use of the amplification technique. But this reduces the number of base words, and for small keyspaces, reduces our parallelism, thus resulting in reduced performance.
No, piping is usually just as fast. The cost is not speed but information: with input arriving on a pipe hashcat has no keyspace, so there is no progress percentage and no estimated time, the interactive prompt gives way to periodic status output, and the restore point cannot advance, so a piped session cannot be resumed. If you only wanted host-side candidate generation, -S does that in one process and keeps all of the above.
However, most candidate generators are not fast enough for hashcat. For fast hashes such as MD5, expanding candidates on the GPU with rules or masks is crucial to achieve full acceleration. However, different rule sets do not produce constant speeds. Large rule sets can significantly reduce speed, so the gain from using rules as an amplifier can be canceled out, depending on how complex the rules are.
-n and -u are the manual levers if you want to trade speed for a responsive desktop--hwmon-temp-abort defaults to 90 degrees on Linux and Windows, 100 on macOS. So a hot card first gets slow and then aborts. See the overheating questionGPU utilization below 100% usually indicates a keyspace too small to provide enough work.
If the attack generates too few base words, there may not be enough work to keep every GPU busy.
Near the end of an attack, the remaining base word count falls below the combined GPU power of all devices. Read What is it that you call "GPU power"?
hashcat displays this message when the attack is nearing the end of its keyspace:
Approaching final keyspace - workload adjusted.
When it happens, hashcat shares out the base words that are left across the devices in proportion to how much work each one can take, rather than handing every device a full batch. Each device therefore runs with less parallelism than it wants, and less parallelism means a lower rate, so the reported speed falls even though the run is healthy.
If your GPUs have different speeds, some may finish sooner than others and show 0 H/s.
(short URL: https://hashcat.net/faq/slowprogress)
This is a problem related to (a) how GPU parallelization works in general in combination with (b) an algorithm with a very high iteration count.
Modern hashing algorithms are typically designed so that their calculations are not parallelizable and must be done in sequence. You cannot start computing iteration 2 if you have not computed iteration 1 before. They depend on each other. For slow algorithms such as 7-Zip, this means that to use the GPU's parallel processing power, we must assign one password candidate to each shader and compute the entire hash there. This can take a very long time, depending on the iteration count of the algorithm. A single hash computation can take up to a minute. In return, hashcat can compute hundreds of thousands of candidates at the same time, making use of the GPU's parallel processing power. This is why hashcat can take so long to report progress: each hash computation takes that long when the iteration count is high.
In the past, hashcat reported 0H/s in these cases. The computation itself is unchanged: the GPU still needs the same time to complete it. Newer versions estimate speed from iteration progress. For example, hashcat measures how long a shader takes to process 10,000 of 10,000,000 iterations, estimates the time for the full count, and converts that into an approximate hashing speed. The speed counter displays this estimate rather than a measurement from completed hashes.
In practice, a GPU needs more candidates than it has shaders to keep all of them busy. Context switching is outside our control, so we must supply many times that number of candidates.
(See this forum post for an illustration with examples)
//
“Bitmap table overflowed at 24 bits.
This typically happens with too many hashes and reduces your performance.
You can increase the bitmap table size with --bitmap-max, but
this creates a trade-off between L2-cache and bitmap efficiency.
It is therefore not guaranteed to restore full performance.”
//
If you get this message, you're working with larger lists of hashes than most ordinary users of hashcat - on the order of millions of hashes.
First, why you're seeing it. hashcat needs to work with lists of hashes quickly, and loads them into a memory structure for this. By default, this memory structure is sized to use hardware, memory, and caching efficiently for typical hardware and hash-list sizes. But beyond a certain number of hashes, the size of this memory structure can become less efficient (sort of like running out of RAM and having to swap to disk, but this is only a very rough analogy).
So by default hashcat sets a maximum size that this structure may be grown to, and only grows it as far as needed. Raising that maximum with --bitmap-max can win back some performance, but it also costs a significant amount of GPU memory, so it is a trade-off rather than a free improvement.
You can increase the bitmap size manually, but this may reduce performance more than expected. Another option is to split the hash list into smaller lists that fit within the bitmap table size and run the attack on each list. For a few million hashes, adjusting the bitmap size may be more efficient. For larger lists, splitting may work better.
If you're working with large lists like this, it is up to you to test your use case with your hardware to find the performance that works best for you.
This Reddit thread has an interesting overview of what bitmap tables are for in hashcat.
The command line switch you are looking for is --restore.
The only parameters allowed when restoring a session are:
--restore (required): tell hashcat that it should restore a previous session--session (optional): specify the session name of the previous session that hashcat should restore--restore-file-path (optional): use specific restore file path
Note: if you did use --session when starting the cracking job, you also need to use --session with the same session name to restore it.
--restore no longer resumes anything: it prints the command line recorded in the restore file and stops. Resuming is --restore-position, which takes only the saved position out of the file and runs the command line you type. So you repeat the original command and add the one option:
$ hashcat --restore-position --session mysession -m 22000 hashes.hc22000 wordlist.txt
A restore file contains a whole command line. Previously, parsing it allowed a file you did not write to select any hashcat option. Supplying the command line yourself also lets you change it between runs, which the release does not allow. The saved position is meaningful only for the same attack with the same wordlist.
A session fed from a pipe cannot be resumed. hashcat never advances the restore point for candidates arriving on stdin, so there is no restore point to resume from and a restore would re-read the stream from the beginning. You can see it in the status of a piped run:
Guess.Base.......: Pipe Progress.........: 3000000 Restore.Point....: 0
Compare the same attack reading the wordlist as a file, where both figures advance and carry a total:
Progress.........: 3000000/3000000 (100.00%) Restore.Point....: 3000000/3000000 (100.00%)
So if a long job needs to survive an interruption, give hashcat the wordlist as a file rather than piping it, or use -S when you wanted host-side candidate generation, since that keeps the keyspace and the restore point.
Other parameters are currently ignored when restoring. For example, adding -d 2 (i.e. --restore -d 2) has no effect. To change parameters in a .restore file, an experienced user can use a third-party tool such as analyze_hc_restore.
Also see restore for more details about the .restore file format.
Yes! All you need to ensure is that no files have been modified.
The most important file here is the .restore file (the file name depends on the session name used, see --session parameter, so it is $session.restore). You need to copy at least the original hash list and the .restore file to the new computer.
Therefore, if you move to a different PC make sure all the paths are the same and all files exist.
To get more information about which files we mean you can use this utility to find out: https://github.com/philsmd/analyze_hc_restore
If you want to make use of multiple computers on a network, you can use a distributed wrapper.
Hashtopolis is the one most people use. It works over the internet and is maintained in its own GitHub organization. Older links redirect there:
Hashview is the other one actively worked on, a web front end that queues and tracks jobs. It has never cut a tagged release, so a deployment builds from the branch.
Neither is maintained by us, so questions about either one are best taken to its own project.
Yes, with the brain. It is not a job scheduler like the wrappers above: it is a shared memory of what has already been tried, so several machines working the same hash list do not repeat each other.
One host runs the server:
$ hashcat --brain-server
and each client joins it with -z:
$ hashcat -z --brain-host 10.0.0.1 --brain-password secret -m 22000 hashes.hc22000 wordlist.txt
The port defaults to 6863 and --brain-port changes it.
--brain-client-features selects what a client tracks. The default, 3, tracks both attack positions and candidates. This enables -S because the brain must process candidates on the host to track completed work. The brain therefore suits slow hashes, where each guess is expensive. For fast hashes, bookkeeping can cost more than the duplicate work it saves.
Feature 2 is the exception: it reserves keyspace ranges and leaves the candidates alone, so it does not switch on -S and a fast hash keeps running on the device. Related options are --brain-session and --brain-server-timer.
Upgrading from an older hashcat resets the brain. The protocol moved to version 2, so clients and the server have to be upgraded together and a mismatch reports both versions. Session identities changed with it, so an existing database stays on disk but is not loaded: reusing a --brain-session value starts with empty deduplication data rather than picking up where it left off.
VCL was one of the first tries for distributed hashcat, but there are better alternatives today.
See this: How can I distribute the work on different computers / nodes?
No. To do this, you will need to wrap your hashcat attack in a script that sends an email when hashcat is finished.
The reason is that hashcat and hashcat legacy use this prompt:
[s]tatus [p]ause [r]ewind [a]dvance [b]ypass [c]heckpoint [f]inish [q]uit =>
(Press p to pause. When paused, the prompt shows [r]esume in place of [p]ause. Some attacks offer [e]xtend as well.)
Normally a terminal hands a program a whole line at a time, so pressing “s” would sit in a buffer until you also pressed Enter. That would make the prompt useless.
So hashcat puts the terminal into non-canonical mode and asks for a minimum of one byte, which is what lets a single keypress arrive immediately. In code that is clearing ICANON and setting VMIN to 1.
The side effect is that a script feeding hashcat's stdin through an ordinary pipe does not get that behaviour, because a pipe is not a terminal. hashcat checks for one and reads key presses only when it finds it, so a wrapper that used to push s, c or q down a pipe cannot pause, checkpoint or quit that way.
You can still drive hashcat from a script, but you have to give it a PTY: use expect, or Python's pty module, or script -c.
Yes. This is especially useful when cracking salted hashes.
Imagine that you have a large hashlist with 100 salts. This will reduce your guessing speed by a factor of 100. Once all hashes bound to a given salt are cracked, hashcat notices this and skips over that specific salt. This immediately increases the overall performance, because now the guessing speed is only divided by 99. If you crack another salt, the speed is divided by 98, and so on. That's why it's useful to tell hashcat about cracked hashes while it's still running.
When hashcat starts it creates a $session.outfiles directory, so hashcat.outfiles by default and named after --session otherwise.
Where it appears follows the same rule as the potfile. Running the extracted archive, it is created beside hashcat.bin. For a packaged install it is under the session directory in your home, ~/.local/share/hashcat/sessions unless XDG_DATA_HOME or an existing ~/.hashcat moves it. It only exists while a session is running, so look for it during the run rather than afterwards, and --outfile-check-dir puts it wherever you want.
This directory can be used to tell hashcat that a specific hash was cracked on a different computer/node or with another cracker (such as hashcat-legacy). Each line must contain the full hash[:salt]:plain record, not just the plaintext.
So point another cracker's --outfile at that directory, or copy finished result files into it, and the running hashcat picks them up within --outfile-check-timer seconds.
The parameters that you can use to modify the default settings/behavior are:
--outfile-check-dir | Dir | Specify the directory to monitor 3rd party outfiles --outfile-check-timer | Num | Sets seconds between outfile checks to X
hashcat continuously checks this directory for new results and modified files. You can synchronize it between computers in several ways, such as an NFS export, a CIFS share or rsync.
Note: some users confuse the induction (--induction-dir) and loopback (--loopback) features with the feature mentioned above, but they are very different:
Use office2john.py from John the Ripper to extract the required information from an Office file. The older office2hashcat.py lived in a repository that has since been removed.
After you have extracted the “hashes” with the script linked above, you need to know the Office version or compare the hashes directly with the example_hashes. Depending on the version number or hash signature, select the corresponding hash mode and start hashcat with the -m value you got.
Use pdf2john.pl from John the Ripper to extract the required information from PDF files. The older pdf2hashcat.py lived in a repository that has since been removed. The output “hashes” can have different signatures depending on the PDF version. See example hashes (-m 10400, -m 10500, -m 10600 or -m 10700).
pdf “hashes” with different hash types (-m values) need to be cracked separately, i.e. you need to have different cracking jobs for each hash type and specify the correct -m value. But if several hashes were generated by the same PDF software version, they can be cracked together and the hash file would look like any other multi-hash file (one hash per line).
In order to crack TrueCrypt volumes, you will need to feed hashcat with the correct binary data file. Where this data lives depends on the type of volume you are dealing with.
The rules are as follows:
dd if=hashcat_ripemd160_AES_hidden.raw of=hashcat_ripemd160_AES_hidden.tc bs=1 skip=65536 count=512
You do not have to do any of that by hand. hashcat ships the converter, in tools:
$ python3 tools/truecrypt2hashcat.py /dev/sda > hash.txt $ hashcat -m 29311 hash.txt wordlist.txt
It does the seek for you, so --offset replaces the arithmetic above:
| the volume is | pass |
|---|---|
| a file, or a partition that does not boot | no option needed, offset 0 is the default |
| a boot volume | --offset bootable |
| a hidden volume | --offset hidden |
| a hidden volume on a boot drive | --offset bootable+hidden |
tools holds 22 of these converters, so it is worth a look before writing a pipeline: veracrypt2hashcat.py, luks2hashcat.py, bitlocker2hashcat.py, metamask2hashcat.py and more.
If you would rather do the seek by hand, these are the three cases as dd commands:
$ dd if=/dev/sda of=header.bin bs=512 skip=62 count=1 # boot volume, offset 31744 $ dd if=volume.tc of=header.bin bs=1 skip=65536 count=512 # hidden volume $ dd if=volume.tc of=header.bin bs=512 count=1 # anything else
Watch the units: the boot case skips 62 blocks of 512 bytes, the hidden case skips 65536 single bytes. Mix them up and you get 512 bytes of the wrong place, which parses as a hash and then never cracks.
Given a 512 byte header in a file, the hash line is $truecrypt$ or $veracrypt$, then the first 64 bytes as hex, then $, then the remaining 448 bytes as hex:
$ xxd -p -c 512 header.bin | sed -E 's/^(.{128})(.*)$/$truecrypt$\1$\2/' > hash.txt
Picking the mode. The last two digits, written XY here, identify which hash and which key size, and boot mode is its own X per hash rather than a flag you add, so do not try to derive one mode from another. For TrueCrypt, -m 293XY:
| X | hash |
|---|---|
| 1 | RIPEMD160 |
| 2 | SHA512 |
| 3 | Whirlpool |
| 4 | RIPEMD160, boot mode |
Only RIPEMD160 has a boot variant here. Y is 1, 2 or 3 for XTS 512, 1024 or 1536 bit. So -m 29311 is RIPEMD160 with XTS 512 bit and -m 29341 is the same volume in boot mode.
If you do not know which, do not work through twelve slow modes by hand. Run --identify on the hash line and it will narrow the list for you:
$ hashcat --identify hash.txt
The older -m 62XY and -m 137XY modes are marked (legacy) in --help. They take the raw 512 byte file directly instead of a hash line, and they still work, but new material should use the current modes.
The example hashes page lists both. As always the password for an example hash is “hashcat”.
Use the converter hashcat ships, exactly as for TrueCrypt, with the same --offset choices:
$ python3 tools/veracrypt2hashcat.py /dev/sda > hash.txt $ hashcat -m 29411 hash.txt wordlist.txt
VeraCrypt's modes are not TrueCrypt's with a 4 in front. It supports more hashes, and the boot variants sit at their own numbers, so -m 294XY has its own table:
| X | hash |
|---|---|
| 1 | RIPEMD160 |
| 2 | SHA512 |
| 3 | Whirlpool |
| 4 | RIPEMD160, boot mode |
| 5 | SHA256 |
| 6 | SHA256, boot mode |
| 7 | Streebog-512 |
| 8 | Streebog-512, boot mode |
Y is 1, 2 or 3 for XTS 512, 1024 or 1536 bit. Note that SHA512 and Whirlpool have no boot variant at all, so there is no mode for a SHA512 boot volume: if you are looking for one, the volume is using a different hash than you think.
If the volume boots and the password was typed on a non-US keyboard, you need one more option. A pre-boot password is entered against the bootloader's own US scancode map, so the bytes stored are not the ones your layout produces. Pass the matching file from layouts with --keyboard-layout-mapping:
$ hashcat -m 29461 hash.txt wordlist.txt --keyboard-layout-mapping tables/layouts/de.table
See Keyboard layout mapping for how this works and how to add a layout. Fourteen ship, in tables/layouts: ch_de, ch_fr, da, de, it, ru and se, each with a -reverse partner that maps the other way. A .hckmap file you kept from an older version still parses.
Without the right one the attack runs to exhaustion and finds no plain even when the password is in your wordlist, which is a miserable way to spend a week.
VeraCrypt also supports a personal iterations multiplier. If the volume uses one, specify a search range with --veracrypt-pim-start and --veracrypt-pim-stop. Supply keyfiles with --veracrypt-keyfiles.
Apache htpasswd password files support several hashing algorithms, for instance Apache MD5 (“$apr1”), raw sha1 (“{SHA}”), DEScrypt, etc
Depending on the signature, you need to select the correct hash type (-m value). See example hashes for some examples.
The format of htpasswd lines is:
user:hash
You can keep the username and use the --username switch.
Which format you encounter depends on the flag used to create the file. htpasswd has defaulted to MD5 since Apache 2.2.18, so $apr1$ is still the common case, and everything else has to be asked for:
| htpasswd flag | signature | hashcat |
|---|---|---|
none, or -m | $apr1$ | -m 1600 |
-B | $2y$ | -m 3200 |
-2 | $5$ | -m 7400 |
-5 | $6$ | -m 1800 |
-s | {SHA} | -m 101 |
-d | no prefix | -m 1500 |
DEScrypt, -m 1500, turns up in old files and truncates the password at 8 characters:
admin:48c/R8JAv757A
(the password here is “hashcat”)
Start by going somewhere else. We don't care where you go from there.
The story behind this: https://hashcat.net/forum/thread-1887.html
Use -m 22000, and it is easy, because 22000 is a text format with one handshake per line. Put the lines in one file and hashcat cracks them all in the same run.
hcxpcapngtool already does this for you. Point it at a capture and it writes every handshake it found into a single file:
$ hcxpcapngtool -o all.hc22000 capture.pcapng
To join files you converted separately, just concatenate them:
$ cat single/*.hc22000 > all.hc22000
On Windows:
C:\> copy /b single\*.hc22000 all.hc22000
The networks do not have to come from the same capture. See Cracking WPA/WPA2 for instructions on capturing handshakes.
Expect the speed to drop as you add networks, because each one is a different salt and hashcat has to work on all of them. That is normal and it is still far quicker than running one attack per network. Use --status to watch progress, and hashcat writes each recovered password to the potfile as it is found.
Older guides tell you to concatenate .hccapx files instead. That worked for -m 2500, and hashcat will not run that mode at all: it prints the deprecation notice and stops without cracking anything. --deprecated-check-disable forces it, but that is the wrong answer here. Convert the capture with hcxpcapngtool and use 22000. The old material is on the hccapx page in the archive.
There are two possible reasons why some password candidates are rejected:
Some hashing algorithms have password length limits. For -m 1500 = DEScrypt, the maximum is 8 characters. hashcat and hashcat legacy apply these restrictions by filtering out candidates that exceed the limits and increasing the rejected count.
This can also be seen in the status screen:
... Rejected.........: 1/4 (25.00%) ...
In this case, 1 out of 4 password candidates (25%) was rejected by hashcat.
hashcat can also reject entire masks (e.g. if you have several of them in a .hcmask file, but it is not limited to .hcmask files). You will see a warning like this one:
WARNING: skipping mask '?l?l?l?l?l?l?l?l?l' because it is larger than the maximum password length
You can use rules to prevent password candidates from being rejected, for instance see I don't want hashcat to reject words from my wordlist if they are too long, can it truncate them instead?.
When applying rules (-j/-k/-r) or combining words (-a 1), the host (CPU) cannot always reject candidates immediately. hashcat applies rules and combines plains on the GPU. Candidates that become invalid there cannot be rejected or counted as rejected by the host.
If you want to avoid this behavior, you can just pipe the password candidates to hashcat (and thus avoid that -a 1 or rules are used by hashcat at all). When you pipe candidates into hashcat, it uses a dictionary attack (-a 0). It can then reject candidates as early as possible because the built-in filter on the host (CPU) can identify candidates that do not meet the length limits. Which method is faster depends on the case: use -a 1 (or -r) on the GPU, or pipe candidates to filter them as early as possible.
(short URL: https://hashcat.net/faq/lengths)
256 bytes, for the pure kernels, which is what hashcat uses by default. 559 of the 728 hash modes allow the full 256.
With -O you get the optimized kernels instead, and those stop at 55. Some modes only have an optimized kernel, 44 of them, so those are limited to 55 whether you ask for -O or not.
A minority of modes are limited by the algorithm rather than by hashcat, and no kernel choice changes that. LM cannot hold more than 7 characters, descrypt more than 8. Those are properties of the hash.
Do not guess, and do not trust a list on a wiki page. Ask hashcat. It prints the limits for the mode you chose on every run:
$ hashcat -m 0 -a 3 hash.txt ?l?l?l Minimum password length supported by kernel: 0 Maximum password length supported by kernel: 256 ... Kernel.Feature...: Pure Kernel (password length 0-256 bytes) $ hashcat -m 0 -a 3 hash.txt ?l?l?l -O Maximum password length supported by kernel: 55 ... Kernel.Feature...: Optimized Kernel (password length 0-55 bytes)
To look a mode up without running an attack, ask for its details:
$ hashcat -m 500 <nowiki>--example-hashes --machine-readable</nowiki>
{ "500": { "name": "md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)", ...
"password_len_min": 0, "password_len_max": 256,
"salt_len_min": 0, "salt_len_max": 256,
"kernel_type": [ "pure", "optimized" ], ... } }
That is generated from the module, so it will not drift the way a hand-written table does. One caveat: it reports the pure kernel's figure. For the 44 modes that have only an optimized kernel it can show 256 while the run itself enforces 55 or less.
So when the number matters, take it from the run rather than from the table. Every run prints it:
Minimum password length supported by kernel: 0 Maximum password length supported by kernel: 55 ... Kernel.Feature...: Optimized Kernel (password length 0-55 bytes)
256 bytes for the pure kernels, and 525 of the 556 salted modes allow the full 256. With -O the limit is 51.
As with passwords, some modes set a shorter salt length because the application that produced the hash does. hashcat reports the number for your mode on every run, when the mode has a generic salt:
$ hashcat -m 10 -a 3 hash.txt ?l?l?l -O Maximum password length supported by kernel: 55 Minimum salt length supported by kernel: 0 Maximum salt length supported by kernel: 51
55. The reason it is not 256 is performance, and it is not a small difference: allowing long passwords costs somewhere between zero and a factor of three, depending on the algorithm. Four things cause that.
Some limits come from the algorithm and are not hashcat's choice at all:
-m 3000 LM, 7-m 1500 descrypt, 8-m 8500 RACF, 8-m 9710, -m 9810, -m 10410 the collider modes, 5For fast hashes, the attack mode matters too. In a combinator attack neither word may exceed 31 characters, but the two together may, so a 24 character word on the left and a 28 character word on the right is fine and gives a 52 character candidate.
Algorithms that hash UTF-16 halve what you can reach from a plaintext point of view, because each character costs two bytes. 27 characters is 54 bytes.
This page used to carry a table of per-mode limits. It has been removed because 14 of its 17 entries had become incorrect: the pure kernels raised most of those modes to 256 while the table still claimed 16 or 40. Use --example-hashes --machine-readable for the mode you care about, as shown above.
51 for the generic hash types such as md5($pass.$salt) or HMAC-SHA256. hashcat prints it on every run, so you never have to take a wiki page's word for it:
Maximum salt length supported by kernel: 51
The named hash types are different. For something like Drupal7 the salt length follows the specification of the application that created the hash, so the question does not really arise: you are not choosing the salt, the application did.
You cannot raise this limit. What you can do is ask for a new named hash type with its own limits, which makes sense when the application is prominent enough to deserve one. See I want to request some new algorithms or features, how can I accomplish this?
Yes. For example, DEScrypt hashes have a maximum password length of 8. A typical wordlist such as “rockyou.txt” contains many passwords that are 9 characters or longer.
hashcat will reject those words.
There is a simple way to avoid this. If you truncate all words from the wordlist to length 8 hashcat will not skip them. This can be done on-the-fly using the -j rule.
'8
The ' rule means truncate. This has some negative effects, too. For example imagine your wordlist contains something like this:
password1
password1234
password1337
Truncating these words at position 8 turns all of them into “password”, causing duplicate checks.
hashcat-utils ships a command line utility called combinator3. This tool allows one to specify 3 (different or identical) wordlists as command line parameters and it will combine each word within the first wordlist, with every word from the second and third wordlists.
$ ./combinator3.bin dict1.txt dict2.txt dict3.txt
The total candidate count is words_in_dict1 * words_in_dict2 * words_in_dict3. It can become very large depending on the line counts of the 3 files.
In some (rare) cases it could make more sense to use -a 1 (combinator attack) with -j / -k rules to prepend/append a static plain or pipe combinator2 to hashcat and apply some rules with the -r argument. It depends on the case which method is faster and/or easier.
This is not supported.
If all the hashes in your hashlists are of the same hash-type it is safe to copy them all into a single hashlist.
If they are not all the same type you can still put them in one file, but be careful with --remove. It rewrites the hash file to hold the uncracked hashes it was able to parse for the -m you gave, which means hashes that it cannot parse in that mode are dropped as well. Mixing types and using --remove therefore loses the hashes belonging to the other types. Keep a copy of the original before you start.
hashcat does not have this feature built in. maskprocessor supports it through its -q option. Pipe its output to hashcat, or use fifos with hashcat legacy.
That looks like the following:
$ mp64.bin -q 3 ?d?d?d?d?d?d?d?d | hashcat -m 22000 test.hc22000
maskprocessor has a second, different limit, which counts a character's occurrences anywhere in the candidate rather than only in a run:
$ mp64.bin -r 3 ?d?d?d?d?d?d?d?d | hashcat -m 22000 test.hc22000
Do not confuse the two. -q limits identical characters that sit next to each other, -r limits how many times a character may appear in the whole string. See maskprocessor for what the numbers mean.
Pipes behave the same on Windows as on Linux, so this works there too.
Current versions of hashcat support this natively.
--show will show the hash (part1) and plain if cracked, and --left will show the hash parts which were not crackedELSE if the hash is 32 chars long (“both parts” of the hash in one line):
--left will only show the parts that were not cracked or the whole hash (2 parts) if both parts were not found1 The reason for calling these “parts” is that LM hashes can represent passwords of up to 14 characters. The hashes can be split into two individual hashes (which hashcat does to optimize the attack). hashcat can crack the easier part of the password separately, and the user can use the information to make educated guesses for the second part. Each part supports a maximum password length of 7 characters.
Also, the --username switch and the --outfile-format command line argument work with this --show feature for LM hashes
IOW, to make use of it, you need to use the --show parameter. To understand how to use --show correctly, refer to this article:
Here's an example:
$ cat hash ec97b64dce94d891299bd128c1101fd6
$ ./hashcat.bin -m 3000 -a 3 -o cracked.txt --quiet hash ?u?u?u?u?u?u?u
Here's the “normal” outfile, one hash per line:
$ cat cracked.txt ec97b64dce94d891:AMAZING 299bd128c1101fd6:HASHCAT
But now let's put them back into one piece:
$ ./hashcat.bin -m 3000 --show --quiet hash ec97b64dce94d891299bd128c1101fd6:AMAZINGHASHCAT
PS: You can also use -o to write to an outfile
To prevent errors, hashcat checks at the start of each new attack that the product of the base word count and the amplifier count does not overflow an unsigned 64-bit integer. In some cases this check is delayed, such as when using mask files, increment mode, or folders with wordlists.
The solution is usually to reduce the total number of possibilities in the attack.
In practice the question answers itself through the driver. hashcat needs a current driver and its compiler package, and those stopped supporting old cards long before hashcat did, so if the vendor's current driver installs and sees your card, hashcat will too. See the driver question.
hashcat refuses runtimes below its minimum versions. The minimum is CUDA 12.0 for both the driver and NVRTC, and HIP 6.2.0 on Linux and Windows alike. Below either, hashcat falls back to OpenCL. --force does not bypass these checks. See How does one install the correct driver for the GPU(s)?
The quickest check is to run hashcat -I and see whether your card is listed. Two things in that output look like faults and are not: the same card appears once per backend that can reach it, cross-referenced by an (Alias: #N) line, and a CPU is listed under whichever vendor's OpenCL runtime drives it, which may not be the CPU's own vendor. See hashcat -I lists my GPU more than once.
This list changes as new cards are released, so check the manufacturer's current specifications as well. The old advice here was to buy a high-end dual-GPU card for speed by watt. Nobody has made one of those since the Radeon Pro Duo and the Titan Z, so it no longer applies. For more information about total speed and speed per price, see Is there a general benchmark table for all GPUs?
It depends on how busy the cards would be, and the break-even is easier to work out than people expect.
Renting wins when you crack occasionally. Idle time between jobs costs you zero, you skip the up-front cost, and the power, cooling, noise and depreciation are somebody else's problem. You can also take a much bigger machine than you would ever buy, for the few hours you need it.
Buying wins when the cards would run most of the time. Rented compute is priced to cover the hardware plus a margin, so past a certain duty cycle you are paying for the card several times over.
Things worth knowing before you start:
hashcat -b for your hash mode, and work out the cost per hash from real numbers rather than from the instance name.--session, and keep the session files and the potfile on storage that outlives the instance. A replacement instance is a different machine, so the relevant answer is Can I restart hashcat on a different PC? rather than the plain restore one: the paths have to match.No, and there has not been a maintained one for years. Every attempt has gone stale, including the one this page used to link, which was made for hashcat v1.30 in 2014 and is no use for judging a card you can buy today.
Two things work better:
hashcat -b takes a few minutes and gives you numbers for your own card, your own driver and the current version, which is what you need to compare.-b output there, and a result from someone running a recent version is worth more than any table.When you compare numbers from somewhere else, check which hashcat version and which hash mode they used. A speed without both of those is not a measurement.
In theory, yes, but in practice, usually not. If you go for pure Brute-Force it has absolutely no effect.
If you go for wordlist-based attacks, the only difference is how long it takes for your host system to copy new wordlist data to your GPU. While it copies the data, the GPU is busy and cannot compute. For example with PCI-E v2.0 x1 it can transfer 4 Gbit/s and with x16 it can transfer 64 Gbit/s. This sounds like a lot, but it's not. First, this number is in bits, not bytes. More importantly, it is a transfer rate, while guessing speed is measured in candidates per second. If transferring a batch takes a full second, the GPU cannot process any candidates during that second. That means that, to avoid affecting the guessing speed, we need to be able to transfer our wordlist data in less than one percent of a second.
Here is the shape of it. hashcat sends one batch of base words per kernel invocation, and the batch is as large as the device's parallelism, the S * T * N figure from GPU power. The words are packed for the trip, a compressed buffer plus an index, rather than each getting a fixed-width slot, so the cost per word is close to the length of the word itself and a full batch is a few megabytes rather than tens.
Two factors matter:
So: pure brute force is unaffected, because the candidates are made on the device and no candidates are sent. A wordlist attack with a decent amplifier is effectively unaffected for the same reason. A wordlist attack with no amplifier against a fast hash is the one case where the link can show up, and there you have a much bigger problem than PCI-Express, described in How to create more work for full speed?
If you want a number for your own setup rather than a rule of thumb, measure it: run the same attack at a low and a high -n and see whether the speed scales with the batch size. If it does, you are not transfer bound.
Mostly a moot question now, since neither vendor ships those bridges for current consumer cards. If you have them on older hardware, do not use them for cracking.
Such a bridge makes several GPUs look like one to software that cannot handle more than one, which is mainly a concern for games. hashcat handles multiple GPUs natively, so the bridge adds overhead and takes away the per-device control that -d gives you.
hashcat will not pause and resume, but it will stop: --hwmon-temp-abort takes a temperature in Celsius and aborts the run when a device goes above it, so the default of 90 stops at 91. Only OpenCL GPU devices are watched, not CPU devices. It is on by default, at 90 degrees on Linux and Windows and 100 on macOS, so a normal cracking run stops before a card cooks itself.
The watchdog does not cover every run. -b, --speed-only and --progress-only set the abort temperature to 0, so those run with no thermal limit. Do not use a benchmark to find out whether marginal cooling holds up: run a real attack for that.
$ hashcat -m 0 -a 3 hash.txt ?a?a?a?a --hwmon-temp-abort=85
Pausing is deliberately not offered, because a card that is too hot at full load will be too hot again the moment it resumes, so you would get a loop rather than a fix. Better to run cooler on purpose: -w 1 asks for the low workload profile, and --kernel-loops (-u) and --kernel-accel (-n) let you turn the pressure down by hand.
You can also reduce heat by lowering the card's power limit with the vendor's tool, nvidia-smi -pl on NVIDIA or the ROCm equivalent on AMD. This reduces temperature far more than cracking speed because the highest clock rates consume disproportionate power. It is usually a better trade than -w 1.
Do not use --hwmon-disable to silence high temperature readings. It also disables the temperature limit. Use this option only when hashcat cannot read the device's sensors. In that case, monitor the temperature another way and set the fans manually.
The best way to fix the problem is to investigate how to improve cooling. Once you find a solution, consider investing in better cooling hardware (such as more or better high-pressure fans) or improving airflow.
A modern GPU has more than one temperature sensor, and the two programs are not reading the same one.
hashcat asks the vendor's monitoring library for the edge temperature, which is the sensor on the outside of the die. Afterburner and similar tools often show the hotspot, also called junction, which is the hottest point inside the die. The hotspot always reads higher, and a gap of 15 to 25 degrees under load is normal rather than a fault.
Neither number is wrong. If you are setting --hwmon-temp-abort, set it against the figure hashcat itself reports, because that is the one it compares against.
There is a limit of 256 backend device entries. hashcat refuses to start if it finds more than that with Illegal use of the --backend-devices parameter because too many backend devices were found. The catch is that entries are not cards: a GPU reachable by two backends takes two entries, so a machine can hit 256 with rather fewer than 256 cards. The remedy is the one hashcat suggests, to select what you want with -d or to switch a backend off with --backend-ignore-opencl and friends.
The limits come from what is underneath it. CUDA and OpenCL impose no count that we know of, but drivers historically have, and AMD's were once capped at 8 devices. Dual-GPU cards, which is where that cap used to bite hardest, are no longer made.
On Linux a headless machine needs no X session for CUDA or ROCm, so the old warnings about X11 sitting in the middle no longer apply.
Generally it's a better idea to use multiple computers with only a few GPUs per system. For example, if you use a distributed solution (How can I distribute the work on different computers / nodes?) then there's really no limit to how many systems you attach to your cluster.
Start from hashcat -I, because the numbers you need are the Backend Device IDs it prints.
-d takes those IDs, comma separated: -d 1 or -d 1,3. This is the usual answer, and it is how you exclude the card that drives your display.-D selects device types rather than individual devices: 1 CPU, 2 GPU, 3 FPGA/DSP/co-processor. A CPU device is not used unless you ask for it, so -D 1 or -D 1,2 is how you bring one in.--backend-ignore-cuda, --backend-ignore-hip, --backend-ignore-metal and --backend-ignore-opencl switch a whole backend off. That is the clean way to deal with a card listed twice when you want the OpenCL entry rather than the CUDA or HIP one, or to cut the device count on a large rig.
Remember that the IDs come from the enumeration, so adding or removing a card, or switching a backend off, can renumber them. Check -I again after any hardware or driver change rather than reusing an old -d line.
FPGAs, yes, on supported boards. hashcat offloads some slow hashes to an FPGA through the assimilation bridge, which puts the expensive inner part of the algorithm on the board while hashcat keeps generating the candidates, applying the rules and comparing the hashes. bcrypt is the mode to start with:
$ hashcat -m 75000 hashes.txt wordlist.txt
Three things decide whether this is for you. It is Linux only, because the drivers hashcat needs exist only there. Your board has to be one it supports, currently the Alveo U50, the ZC706, the YPCB, the Enigma X1, the ZTEX boards and the Arty Z7, each with its own setup. And the board needs hashcat's own bitstream, which is the part that makes a mining board useless: that hardware is programmed for one algorithm and carries no candidate generation.
A normal compute device is still required, because the FPGA hashes but does not generate candidates. It does not have to be a GPU. A CPU OpenCL runtime is enough, and the load on it is light.
See FPGA support for the short version and docs/hashcat-fpga-setup.md in the release for the per-board steps, the bitstreams and what the bridge reports when something is missing. The assimilation bridge page covers the mechanism.
Mining FPGA bitstreams are still useless for it: they implement one algorithm with no candidate generation, which is the part that matters.
ASICs are application-specific by definition. Bitcoin ASICs work only for bitcoin. For password cracking, they could handle only passwords exactly 80 bytes long and hashed as double SHA256. This makes them of little use for other algorithms.
Building ASICs specifically for password cracking would waste a huge amount of time and money. Making an ASIC flexible enough to handle multiple hashes, algorithms and attack modes would effectively produce a GPU. GPUs offer a useful balance of cost, speed, flexibility and ease of programming.
Yes. This FAQ previously stated that Intel GPUs did not work on Linux, but they have been supported for years.
Install the Intel Graphics Compute Runtime, known as NEO, and hashcat sees the GPU through OpenCL. hashcat enforces no minimum version for it, so it uses it on a best-effort basis: if it misbehaves, check the version yourself, because hashcat cannot judge it for you. Mesa's rusticl is a second option with real caveats, described under the driver question.
On speed, set expectations by the hardware rather than by the vendor. An integrated Intel GPU has very little raw compute, and a modern CPU with AVX2 may well beat it. A discrete Intel card is a different proposition and worth benchmarking. Either way, run hashcat -b and compare the number rather than guessing.
Note that the GPU runtime is a different package from the CPU one. For Intel CPUs you want the Intel CPU Runtime for OpenCL, or PoCL. See the driver question.
hashcat reports what the runtime gives it, and the runtime gives three different figures that are easy to confuse:
Memory.Total...: 16304 MB (limited to 13858 MB allocatable in one block) Memory.Free....: 13160 MB
Total is the card's memory. Free is what is unallocated right now, which is less than total because your desktop, your browser and anything else on the card are already using some. The figure in brackets is the largest single allocation the runtime will grant, which is a runtime property and not a hashcat one.
The single-allocation limit can be far below total memory. OpenCL guarantees only a quarter of total memory in one block, and runtimes differ widely above that. On one machine here, the reported limits are 25 percent, 42 percent, 85 percent, and a flat 4096 MB, depending on the runtime. Some devices do not report this limit, in which case hashcat prints no bracket.
None of this is hashcat misreporting. If an allocation fails because of it, see the clCreateBuffer error.
The problem is that the echo command adds a newline character (\n). To avoid this, use the -n parameter.
$ echo test | md5sum d8e8fca2dc0f896fd7cb4cb0031ba249 -
$ echo -n test | md5sum 098f6bcd4621d373cade4e832627b4f6 -
This error (and the similar “token length exception”) can have several causes, but generally it means that the hash file (or the hash specified on the command line) could not be parsed, so hashcat could not load it.
In practice the message you see most is “Token length exception”, which means the same thing: the line did not parse. There are two shapes of it.
The file exists, but one of its lines could not be parsed. hashcat names and displays that line:
$ hashcat -m 0 md5_hashes.txt dict.txt Hashfile 'md5_hashes.txt' on line 1 (010203invalidhash): Token length exception * Token length exception: 1/1 hashes No hashes loaded.
The file does not exist, so hashcat treated its name as a hash and tried to parse it:
$ hashcat -m 0 non_existing_file.txt dict.txt Hash 'non_existing_file.txt': Token length exception * Token length exception: 1/1 hashes No hashes loaded.
The second one is worth recognising, because the real problem is a wrong path, not a wrong hash. If hashcat quotes your filename back at you as though it were a hash, check the path first.
Now that we have covered the different error messages, let us look at their most common causes:
--hash-type command line option or short -m)--username switchIf hashcat quoted your filename back at you as though it were a hash, the path is the problem, not the hash. If it quoted a line from the file, that line is the problem.
If you left -m off, the same failure reads differently, because autodetect reports it: No hash-mode matches the structure of the input hash. The causes are the same as the list above. See I left out -m and hashcat printed a list of hash modes and stopped.
To check whether your hash matches the expected format, see the example hashes page.
No. hashcat removes duplicates itself when it loads the list, so the same hash appearing twice costs you no time and --remove behaves correctly.
This question exists because the retired hashcat-legacy did not deduplicate. It cracked only the first copy, so --remove could leave a hash in the file that had in fact been cracked. If you are following an old guide that tells you to deduplicate first, that is where the advice comes from and you can skip it.
Should you want to anyway, on a list large enough that the file size matters:
$ LC_ALL=C sort -u hashlist.txt > hashlist.new && mv hashlist.new hashlist.txt
Before an attack starts, hashcat cracks a known hash on each device to verify that it returns the correct result. If the check fails, hashcat stops:
* Device #1: ATTENTION! HIP kernel self-test failed. Aborting session due to kernel self-test failure. You can use --self-test-disable to override, but do not report related errors.
The backend named changes with the device, so you may see CUDA, OpenCL or Metal instead.
The self-test uses a hash built into hashcat. If it fails, the device returned an incorrect result. Check the runtime and driver first:
-d and see whether the rest are fine. That indicates the problem is with the device or its runtime rather than your install.
--self-test-disable makes it run anyway. That is useful for narrowing the problem down, but a device that fails the self-test can return wrong results, so do not trust cracks from it and do not report bugs found that way.
To resolve this error, disable the self-test or recompile the plugin with a matching self-test hash. Use --self-test-disable to disable the check.
Background: for the scrypt family hashcat compiles the kernel to match the hash's own N, r and p parameters, which buys a little speed. That is what ties a built kernel to one specific configuration. The modes concerned are -m 8900, 9300, 15700, 22700, 24000, 27700, 28200 and 29800, plus the bridged 70100 and 70200. Argon2 does not raise this error, despite also being parameterised.
This happens when the hash you are cracking has a different configuration from the plugin's built-in self-test hash. The self-test would fail against a kernel built for your parameters, so hashcat stops rather than proceeding on a kernel it cannot verify.
The same mechanism, one step further along. The kernel is built for one set of scrypt parameters, so every hash in the session has to share them. If your list mixes two different N values, hashcat refuses the run and shows you the two hashes that disagree:
ERROR: Mixed configuration detected. The specified target hash: -> ... does not match the configuration of another target hash: -> ...
There is no option that makes one kernel serve both. Split the list by parameters and run each group as its own session. The modes this applies to are the scrypt family listed above.
Already an instance '/path/to/hashcat.bin' running on pid 12345
hashcat writes a pid file named after the session, and the session is called hashcat unless you say otherwise. So starting a second attack while the first is running collides, because both want the same name.
Give each run its own name:
$ hashcat --session=job2 -m 0 -a 3 hash.txt ?d?d?d?d
If no hashcat is running, the pid file was left behind by one that was killed. Check with ps first, and only then delete the <session>.pid file from the session directory, which is beside the binary for the extracted release. Do not delete it while a run is live.
A batch of driver error messages used to be answered on this page and are now in the archived FAQ. They belong to fglrx, Catalyst, ADL and ForceWare, none of which exist any more, so the answers were doing more harm than good. They are kept there because the messages are still findable in old forum threads.
If your error is not on either page, ask on the forum or open a GitHub issue, and include the output of hashcat -I along with the exact command you ran.
It does work on Kali. Start with hashcat -I and read what came up, then work down this list.
The old answer here was about a glibc mismatch between Kali and the build host. That is long closed: the 8.0.0 Linux binaries need no glibc newer than 2.17, which predates every distribution still in use, and Kali rolling is far newer than that.
You can run it, but it will only see the devices the hypervisor hands the guest, and a desktop hypervisor hands it no GPU. So VirtualBox, VMware Workstation and Hyper-V normally give you either no usable device or a CPU device only.
With no runtime reachable at all you get:
ATTENTION! No OpenCL, HIP or CUDA compatible platform found. You are probably missing the OpenCL, CUDA or HIP runtime installation.
which reads like a missing driver, and inside a guest usually is not: there is no GPU there to have a driver for.
This is the most common reason a Kali user reports that hashcat does not work, because Kali is usually run as a guest.
What to do, in order of how well it works:
Individual functions, mostly yes: where the two share a letter it usually does the same thing, and the rule syntax documentation marks the differences.
A JtR rule file, usually no. Three things get in the way, and all three are ordinary in a real john.conf:
[List.Rules:Wordlist] and the like are not rules, and hashcat has no concept of them.<, >, _, ! and the rest do not work in a rule file at all. hashcat accepts them only with -j and -k. JtR rulesets use them constantly.
Note also that the memory functions such as M go the other way round from what you might assume: hashcat-legacy implemented them and hashcat does not. The rule table marks those with a +.
If hashcat cannot parse a rule, it skips the entire line and reports the file and line number. The other rules in the file continue to run:
Skipping invalid or unsupported rule in file my.rule on line 12: ...
The one to watch for is JtR's preprocessor, because it does not fail, it misfires. In JtR, l[cu] expands to two rules, lc and lu. In hashcat [ and ] are its own truncate-left and truncate-right functions, so that line parses cleanly as five ordinary rules and quietly produces something else:
$ hashcat --stdout -r r.rule w.txt # r.rule holds l[cu] ASSWOR
password became ASSWOR: lowercase, delete the first character, capitalise, uppercase, delete the last. No warning, exit 0, because every rule in it was valid. hashcat cannot detect this for you.
So expand a preprocessor rule file before you use it, and check any rule containing [ or ] by eye. maskprocessor is the tool, and Using maskprocessor to generate rules is the how-to.
A wordlist is a list of candidate passwords. It is not specific to WPA or any other hash type.
The usual concern is the 8-character minimum. In a plain dictionary attack, hashcat applies each mode's limits while reading the wordlist. It drops invalid words and counts them as rejected.
Once you add rules it stops working the way you would hope. With -r, hashcat judges the wordlist line against the minimum before the rules run, because the rules run on the GPU. So a 6 character word is discarded even if your rules would have appended two characters and made it valid. If you want short base words to survive into 8 character candidates, do the lengthening before hashcat sees them, by piping --stdout into the real run.
Two smaller cases worth knowing. In a combinator attack only the maximum is checked on each half, since the halves are still to be joined. And a mask shorter than the mode's minimum is refused rather than filtered, because every candidate it makes would be too short.
For a hash-mode, try a recipe before you ask. With -m 4000 you describe the scheme on the command line and hashcat compiles it into a kernel at startup:
$ hashcat -m 4000 --hash-recipe 'md5(md5(salt) . pass)' hash.txt wordlist.txt
This is not a slow fallback. Most recipes run within a few percent of a hand-written kernel and some beat one. They cover the usual hash functions and their HMAC forms, PBKDF2, AES and DES, transforms on the password, salt and digest, hex and base64 salts, and a second salt, a pepper or the user name read from the hash line. If you work with John the Ripper, --dynamic-x reads the format out of a $dynamic_N$ hash and picks the matching recipe, so you need neither -m nor --hash-recipe. See Hash recipes, and docs/hashcat-hash-recipe.md in the release for the reference.
So a scheme nobody wrote a plugin for is often a one-line job rather than a wait. Ask for a hash-mode when the recipe language cannot express it, or when the algorithm needs real kernel work.
First, pick the right place. The project draws the line in its own issue templates: GitHub is for bugs and features, not for support. So:
Opening an issue gives you a template for the kind you chose. Fill it in rather than replacing it, and search first, because the template asks you to.
Please use the search function to make sure that the feature or problem has not already been reported.
Here is a reminder of the information to include in a GitHub issue:
Not as a public issue. The project asks for these privately, so that a fix exists before the details are public.
Use the Security tab on the hashcat repository and choose Report a vulnerability. That opens a private draft advisory visible only to you and the maintainers. If you cannot use GitHub, email security@hashcat.net instead, bearing in mind that plain email is not encrypted.
Include enough for someone to reproduce it: the hashcat version or commit, the exact command line, the input that triggers it, what happens, and what you expected.
The full policy is in SECURITY.md in the repository.
hashcat is released under the MIT licence, and the source is at github.com/hashcat/hashcat.
The retired CPU-only program remains available at github.com/hashcat/hashcat-legacy under the same licence. For current work, use hashcat.
You can help improve hashcat and hashcat-utils with problem reports and feature requests through their GitHub issue trackers. The retired hashcat-legacy repository has issues switched off and takes no more reports.
Roughly in the order that gets you an answer fastest:
Whichever channel you choose, include the output of hashcat -I, your exact command line, and the hashcat version. Nearly every unanswered question is missing one of those three.
Team Hashcat is a team of hand-selected enthusiasts who have dedicated themselves to representing the hashcat name in cracking contests.
The team has competed in every major cracking competition for over fifteen years, including Korelogic's “Crack Me If You Can” at DEF CON, “Hash Runner” at Positive Hack Days, CracktheCon at Cyphercon and Jabbercracky. CMIYC is the most prestigious of them and the team has won it many times.
Everything the team publishes lives in one place: the team-hashcat repository on GitHub. That is where the running record of results is, along with the writeups and the tools and rule files built during each contest. This page used to carry copies of both tables and they drifted, so the repository is now the single source and this answer does not duplicate it.
Note: there was no CMIYC in 2016, and in 2017 it was held at DerbyCon rather than DEF CON.