Injecting candidates /re-reading pot
#5
@truekonrads
it seems that the idea is very good... I discussed this a little bit w/ atom now and of course we also see the benefits of such a feature.
It is currently not supported and the main problem is that devs need to find a clever/robust and always-working solution to remove the hashes from the *running* process (and also check that the GPU is in "sync" w/ that updated list) ... w/o any stability etc problems.
There are/may be a couple of problems involved w/ such a feature, but if the devs are able to come up w/ a good strategy to remove the (maybe huge) list of salts and hashes w/o introducing any major stability problems and conflicts that may even lead oclHashcat to stop working etc.... it would really be a nice feature to have.

So, it would be great if you could open a trac ticket here https://hashcat.net/trac/ and describe this enhancement again there...
Maybe we can already discuss here or on trac, what *we* would like to have (w/o considering the technical details):
- status PROMPT should have an option (show a key shortcut) to start this removing process AND/OR
- signal's e.g. sigusr1 should be used to start this removing process
- hashes that we delivered to oclHashcat should/should not end up in the *.pot file
- the input file should/should not be a known/fixed file (e.g remove_this_please.txt ... or remove.pot) and if soo.... what should be the name of this file OR
- the input file should be the same *.pot file... why? this may lead to a corrupted pot file if you update/change it while oclHashcat is working w/ it
- .... any recommandations/suggestions are welcome (preferable on trac I suppose)


Messages In This Thread
RE: Injecting candidates /re-reading pot - by philsmd - 11-11-2013, 06:05 PM