02-25-2014, 03:40 PM
Gentlemen, I am standing before a tough problem. I have constructed hashtopus with great agent unstability in mind because it is designed for agent deployment on computers which are not dedicated for hash cracking. Basically, I expect the agent could disconnect without warning any second. That is why I transfer cracked hashes to server almost in real time (using a small buffer) and why I dispatch chunks of relatively small time worth of computing (default 5 minutes).
That is also why I wanted to implement protection against mid-chunk interruption. Basically, with each cracked hashes buffer flush, I would also report in what part of keyspace am I currently in the cracking, so the server could keep track how much of the incomplete chunks was already performed. Should the agent die mid-cracking, the reassign to another agent feature (already implemented) wouldn't have to reasign the whole chunk but only the remaining part.
But recently I have discovered that if the base loop of keyspace (depends for example on -n parameter and first letter of brute force mask) is too big, the .restore file might not get updated the whole 5 minutes chunk. That means I have to find other way to track individual chunk progress.
One way that popped to my mind was to have the hashcat periodically output [s]tatus, but since I normaly crack with --quiet parameter and read the output to achieve instant event-driven output capturing, I would have to rewrite to be file-based which would create even bigger problems since no virtual files exist on Windows.
I am therefore asking if someone of you doesn't see anything to solve this I am missing.
That is also why I wanted to implement protection against mid-chunk interruption. Basically, with each cracked hashes buffer flush, I would also report in what part of keyspace am I currently in the cracking, so the server could keep track how much of the incomplete chunks was already performed. Should the agent die mid-cracking, the reassign to another agent feature (already implemented) wouldn't have to reasign the whole chunk but only the remaining part.
But recently I have discovered that if the base loop of keyspace (depends for example on -n parameter and first letter of brute force mask) is too big, the .restore file might not get updated the whole 5 minutes chunk. That means I have to find other way to track individual chunk progress.
One way that popped to my mind was to have the hashcat periodically output [s]tatus, but since I normaly crack with --quiet parameter and read the output to achieve instant event-driven output capturing, I would have to rewrite to be file-based which would create even bigger problems since no virtual files exist on Windows.
I am therefore asking if someone of you doesn't see anything to solve this I am missing.