This is the final part of the series of articles comparing Elcomsoft Distributed Password Recovery with Hashcat. We’ve already compared the features, the price and performance of the two tools. In this study, we tried breaking passwords to several common formats, including Word document, an encrypted ZIP archive, and a VeraCrypt container. We summarized our experiences below.

Case study 1: breaking an Office 97/2003 document

So you have successfully installed Hashcat, git and Python. Assuming that the Python installer had the required modules, you’re good to go and ready to launch an attack.

In the first case study, we’ll try to break a document in the Office 97/2003 format (the “.doc” extension; the file might have been saved in “Compatibility mode” by a newer version of Microsoft Office). The file is protected with a 40-bit RC4 key.

Hashcat. After processing the document with office2hashcat.py, we’ve got the hash. Hashcat started the attack on the password; considering the (high) speed of the attack, we estimated the attack to complete in about 1 to 1.5 years.

Elcomsoft Distributed Password Recovery correctly recognized the file format and offered an option to brute-force the 40-bit encryption keys. The estimated recovery time was 48 hours using a CPU alone. Note that the same document can be recovered in a matter of minutes if you use the Thunder Tables attack in Advanced Office Password Breaker.

Case study 2: breaking ZIP password

The second case study deals with a ZIP archive protected with AES-256 encryption.

Hashcat requires the use of a third-party tool to extract hashes from the target. This time around, you’ll need zip2john, which is a part of the John the Ripper package.

When attacking ZIP encryption, a single small hash file is not enough. The last step of the attack calculates hash sum of the entire encrypted file. The resulting hash file extracted with zip2john is about 2MB. However, we could not make Hashcat to open the file. The tool had crashed with the following error:

Counted lines in c:\hashcat-6.1.1\z2.hash… Oversized line detected! Truncated 402236 bytes

We tried finding a solution (here and here), but the only kind of solution we found was this:

hashcat supports a data length of about 8 KB (compressed of course) for -m 13600 = Winzip

…

Unfortunately, for -m 13600 you need the whole data_buf (encrypted and compressed data) to verify if the password is correct.

(github)

We’ve been unable to launch the attack on the ZIP file with Hashcat.

Elcomsoft Distributed Password Recovery was able to open that ZIP archive and run the attack in a matter of seconds.

Case study 3: breaking VeraCrypt

In the third case study, we’ll try breaking the password to a VeraCrypt container.

On paper, Hashcat had been offering support for VeraCrypt containers long before we did it in Elcomsoft Distributed Password Recovery, so we expect a well-ironed solution. We didn’t have much trouble running the attack on the hash file extracted from the VeraCrypt container. In this regard, Hashcat is a fast and mature solution for breaking encrypted containers. What we did have a problem with was producing the required hash file to launch the attack.

If you are attacking an encrypted container (the file), all you need are the first 512 bytes of the file. In the case of full-disk encryption, you will also need to extract the 512 bytes; however, the extraction process is somewhat more complicated. The Hashcat Wiki has the following explanation:

1. for a TrueCrypt boot volume (i.e. the computer starts with the TrueCrypt Boot Loader) you need to extract 512 bytes starting with offset 31744 (62 * 512 bytes). This is true for TrueCrypt 7.0 or later. For TrueCrypt versions before 7.0 there might be different offsets.Explanation for this is that the volume header (which stores the hash info) is located at the last sector of the first track of the system drive. Since a track is usually 63 sectors long (1 sector is 512 bytes), the volume header is at sector 63 – 1 (62).
2. if TrueCrypt uses a hidden partition, you need to skip the first 64K bytes (65536) and extract the next 512 bytes.

dd if=hashcat_ripemd160_AES_hidden.raw of=hashcat_ripemd160_AES_hidden.tc bs=1 skip=65536 count=512

1. in all other cases (files, non-booting partitions) you need the first 512 Bytes of the file or partition.

…

The same procedure should also work for VeraCrypt volumes (but you need to adapt the hash mode to -m 137XY – see the –help output for all the supported hash modes for VeraCrypt and the correct values for X and Y).

Additional troubles arise when you try to extract hashes from VeraCrypt volumes stored inside a forensic disk image. If this is the case, you may have to mount the disk image, calculate the address of the last sector of the first track on the disk, then extract the required binary data. We understand the theory but decided to skip this exercise due to lack of motivation.

It is exactly this kind of exercise we wanted to skip when developing Elcomsoft Distributed Password Recovery. In order to extract encryption metadata from one or several encrypted disks, you will need to open the physical device or forensic disk image in the included Elcomsoft Forensic Disk Decryptor (or boot the computer with Elcomsoft System Recovery). Simply ticking the required disk(s) in the GUI will do the trick.

Conclusion

This was the last part of the series comparing Elcomsoft Distributed Password Recovery with Hashcat. As we already stated in the beginning, Hashcat is a great tool and a strong competitor. Many of the differences are in the areas of usability and things actually working, let alone working out of the box. Where Elcomsoft Distributed Password Recovery just works the way you expect it to, you may have to spend a bit of time to make Hashcat work. These bits of time quickly accumulate, turning into multiple man-hours spent on setting up and configuring the distributed network, updating agents, distributing dictionaries across remote agents, finding and using hash extraction tools and overcoming the various obstacles, some of which we have described in this article.