After publishing the first article in the series, we received numerous comments challenging our claims. We carefully reviewed every comment, reread and reevaluated our original article.  Elcomsoft vs. Hashcat Rev.1.1 is here.

The unsupported algorithms

In our original article, we made the following claim:

“While both Hashcat and Elcomsoft Distributed Password Recovery advertise hundreds of supported formats and generally tick all the basics, our tool covers a few things that Hashcat does not.”

We’ve been caught red-handed; some Hashcat users claimed that some of the formats we listed as unsupported are, in fact, supported by Hashcat. Exactly 11 claims we’ve made have been challenged. After thorough verification, we discovered that, while two of the claims were ambiguous, the facts still stand.

Office 97/2003 (key search), PDF with 40 bit encryption (key search). Hashcat does not support the key search attack. It does not support rainbow tables for either Office 97/2003 or Adobe PDF, and it definitely does not support Thunder Tables, which are ElcomSoft (R). In other words, where our tools break encryption by targeting the encryption key (the “key search” attack) in a matter of minutes, Hashcat users will have to resort to recovering the original password, which is orders of magnitude slower. When breaking encryption, reading manuals by the letter can be extremely important. Missing the (key search) moniker made some users disavow the whole claim, which is incorrect.

Apple iWork. At the time we wrote the original article, example_hashes [hashcat wiki] did not contain the iWork support. After re-visiting the page, I discovered that Apple iWork (23300) has been added (it’s been mentioned in GitHub, too). However, an attempt to attack an Apple iWork hash threw out the “Cannot load module ./modules/module_23300.dll” error. The module is, indeed, missing. I am still not sure what to think about it; let us see how it turns out.

Hangul/Hancom Office. At the time of this writing, example_hashes [hashcat wiki] does not mention any of these formats. The commenter who claimed us being wrong might’ve been confused with the CMYIC presentation, which mentioned the Korean alphabet (which has a name “hangul”). Korean Document · Issue #2461 · hashcat/hashcat (github.com) mentions an ongoing issue with this data format.

PGP Disk and other PGP formats. Not mentioned in example_hashes [hashcat wiki]. Explicitly mentioned as “not supported” in hashcat Forum – Decrypt PGP encryption (Symantec). Formats not supported.

Quicken. Not mentioned in example_hashes [hashcat wiki]. Unanswered question at Quicken File password (hashcat.net). Format not supported.

macOS Keychain. It’s a bit of a tricky subject. Hashcat does not break the keychain password directly, but it does support the recovery of macOS user passwords, which can be taken from the shadow file. In many cases, the user password, if recovered, can decrypt the keychain. However, the keychain password may differ from the user account password, in which case you’ll still need to attack the keychain password directly. Interestingly, this makes a lot of sense even if you suspect that the user account and keychain passwords are one and the same, as the keychain password is (surprisingly) faster to attack compared to macOS user account passwords.

EDPR with a single NVIDIA GeForce 1080 card delivers the following recovery speeds (in passwords per second):

Keychain: 1130000
macOS user password: 9650

Attacking the keychain directly is literally over a hundred times faster, so let me return the argument here: supporting the keychain directly is a major advantage of our tool over Hashcat.

BlackBerry backups: Never mentioned, not supported.

FileMaker: Never mentioned, not supported.

DMG passwords: Never mentioned. Discussions recommend John the Ripper.

DashLane: Never mentioned. John the Ripper mentioned as “probably relevant” in support for DashLane user master passwords · Issue #1317 · hashcat/hashcat (github.com).

Tally ERP: Never mentioned, does not even appear in Google.

We support CUDA directly

We’ve been accused of claiming that Hashcat does not have direct support for NVIDIA CUDA. I reread the statement in the original article, and did not find anything pointing to that conclusion; moreover, the very first screenshot of Hashcat just below the contested claim clearly shows CUDA support.

However, on a second thought, I agree that the original statement might be ambiguous. I should have made it clearer that Hashcat does support CUDA. You can decide for yourself; the original statement is quoted below:

“Hashcat is decidedly GPU only. The tool requires an AMD or NVIDIA video card to work, and you’ll need a compatible version of the graphic driver. Where Hashcat requires the use of the OpenCL runtime to interface with compatible CPUs (which we struggled to enable), Distributed Password Recovery addresses the CPU cores directly, utilizes the native CUDA for interfacing with NVIDIA boards, and uses OpenCL for everything else.”

Running in a VM makes no sense

Our own tool is explicitly usable and is routinely used in cloud instances, which *are* VMs. If running in a VM makes no sense to certain users, it does not mean that other users find the feature useless. The original claim, however, was about the fact that we’ve been unable to make Hashcat work solely on an Intel CPU, even after the correct OpenCL drivers were installed. We’ve been unable to make Hashcat work on a CPU-only PC without a supported video card.

AMD GPU simply require the driver

When I wrote that “We failed the quest when we tried using an AMD card”, I was trying to make it work in Ubuntu. Up until now, I’ve been unable to make Hashcat work in Ubuntu with an AMD card, no matter the drivers mentioned in Amd GPU with Ubuntu (hashcat.net) and the more recent Linux + AMD + hashcat.

We have been able to set up and run the Windows version of Hashcat with an AMD card.