Please note, this is a STATIC archive of website hashcat.net from October 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.

Table of Contents

Using maskprocessor to emulate brute-force attack

maskprocessor is a powerful tool and can be used in various ways, in this case: Brute-Force attack in oclHashcat-plus.

Write to STDOUT, read from STDIN

One of the features of oclHashcat-plus is the support of reading from stdin. This gives great flexibility since we can reuse every program that supports writing to stdout for password candidate generation.

Some examples:

To do this, all we need is to use a pipe in the commandline. A pipe is somewhat the most possible generic interface for data exchange between two processes. It is supported in both Linux and Windows. Even the syntax is the same. And it its very simple.

Using the pipe

It's easy. For Example:

mp64 ?d?d?d?d?d?d?d?d | oclHashcat-plus64 -m 2500 bla.hccap
mp64 -1 ?dABCDEF ?1?1?1?1?1?1?1?1 | oclHashcat-plus64 -m 2500 bla.hccap
./mp64.bin -1 ?dabcdef ?1?1?1?1?1?1?1?1 | ./oclHashcat-plus64.bin -m 2500 bla.hccap

See Mask attack for detailed instructions how to use maskprocessor.

Optimizing the attack

If we attack a so called “slow” algorithm, that is one of the following algorithm, we can skip this section:

To fully utilize the power of the GPU it's mandatory to keep the GPU busy with work. That means we have to constantly generate huge numbers of password candidates. In this article we talk about STDIN, that generates the following (massive) bottleneck:

  1. There is no word-generator that can generate 10B of password candidates per second and write it to STDOUT (write is a bottleneck).
  2. oclHashcat-plus has to read from STDIN (read is a bottleneck).
  3. It has to check for errors, parse the word, scan the length, remove the newline, optionally remove the carriage return, sort it into appropriate transfer buffer, update buffer fill rate, …
  4. Copy the Buffer over pci-express to the GPU's global memory (copy is a bottleneck).
  5. Finally the GPU Kernel has to read the password candidate from GPU global memory and then copy data to registers before it can start with the hash algorithm.

In short: Password candidates via STDIN itself is slow. But there is a way to optimize the Brute-Force attack, even when reading from STDIN, even for the “fast” algorithms. The “fast” algorithms are all the others supported by oclHashcat-plus which are not in the list above. But it requires a bit of help from our side. It can't be done automatically.

The goal is to use the rule-engine in order to increase GPU utilization. All we need to know is that the kernels of the fast algorithms in oclHashcat-plus have an embedded rule-engine. So what we have to do is to “distribute” the workload. If we can generate like 200 rules its fully enough to maximize the GPU utilization.

./mp64.bin -o bf.rule -1 ?dabcdef '$?1 $?1' 
./mp64.bin -1 ?dabcdef ?1?1?1?1?1?1 | ./oclHashcat-plus64.bin -m 2500 -r bf.rule bla.hccap

This will fully utilize the GPU.