oclHashcat v1.02 will come with a new Feature called outfile-check. Just to explain this new feature shortly:
When we started to add more distributed support with -s and -l and --keyspace we thought that might be enough to motivate people to build 3rd party applications around oclHashcat to make it distributed. And it was true, some people started working on such solutions.
Soon after they started they realized that they are now able to distribute the workload, but what about the results, the cracked hashes. Usually that wouldn't matter if you run BF attack against an unsalted raw hashlist, but it's different when you have let's say a salted hashlist.
If you have a hashlist with 100 salted hashes, the time to process a keyspace is 100 timer longer than with a single salt, that should be clear, right?
oclHashcat has this optimization, if you crack all hashes bound to a specific salt, it marks it as cracked. In that case, it can skip over the test and thus decreasing the total time to complete efficiently. But in a distributed environment, there can be a node that cracked a specific salt completly by cracking all the hashes bound to it, but the other nodes do not know about that and still process that keyspace unnecessarily.
I had the same problem a while back with oclHashcat-lite. It already supported that -s and -l syntax and people started writing distributed systems around it and they originally brought up exactly that problem that if one node cracked a hash (oclHashcat-lite was single hash) how do the other nodes now about it.
This finally end up in the following question: How to inform a running oclHashcat session with the information that a hash that it is trying to crack was cracked by a different node.
We came up with a very easy solution. You just put the cracked hash into your outfile. Then, oclHashcat periodically reads it's own outfile and matches all the cracked hashes against its internal table that tell it which hash and which salt is cracked and which not and updates it.
It's not required, but for example, to automate that process completly all you need to have is a shared folder in which all your distributed nodes can write. Point all your nodes to write into the same outfile in that shared folder. Once a node cracks a hash, it writes into that outfile and all other nodes get informed about that.
There's a new parameter added "--outfile-check-timer" that can be used to configure the period in seconds to rescan the outfile. The default is set to 5 seconds and you can disable it by setting it to 0.
When we started to add more distributed support with -s and -l and --keyspace we thought that might be enough to motivate people to build 3rd party applications around oclHashcat to make it distributed. And it was true, some people started working on such solutions.
Soon after they started they realized that they are now able to distribute the workload, but what about the results, the cracked hashes. Usually that wouldn't matter if you run BF attack against an unsalted raw hashlist, but it's different when you have let's say a salted hashlist.
If you have a hashlist with 100 salted hashes, the time to process a keyspace is 100 timer longer than with a single salt, that should be clear, right?
oclHashcat has this optimization, if you crack all hashes bound to a specific salt, it marks it as cracked. In that case, it can skip over the test and thus decreasing the total time to complete efficiently. But in a distributed environment, there can be a node that cracked a specific salt completly by cracking all the hashes bound to it, but the other nodes do not know about that and still process that keyspace unnecessarily.
I had the same problem a while back with oclHashcat-lite. It already supported that -s and -l syntax and people started writing distributed systems around it and they originally brought up exactly that problem that if one node cracked a hash (oclHashcat-lite was single hash) how do the other nodes now about it.
This finally end up in the following question: How to inform a running oclHashcat session with the information that a hash that it is trying to crack was cracked by a different node.
We came up with a very easy solution. You just put the cracked hash into your outfile. Then, oclHashcat periodically reads it's own outfile and matches all the cracked hashes against its internal table that tell it which hash and which salt is cracked and which not and updates it.
It's not required, but for example, to automate that process completly all you need to have is a shared folder in which all your distributed nodes can write. Point all your nodes to write into the same outfile in that shared folder. Once a node cracks a hash, it writes into that outfile and all other nodes get informed about that.
There's a new parameter added "--outfile-check-timer" that can be used to configure the period in seconds to rescan the outfile. The default is set to 5 seconds and you can disable it by setting it to 0.
xyxy where x= a,e,i y=1,2,3, 
5:cf)