+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Deprecated; Ancient Versions (https://hashcat.net/forum/forum-46.html)
+--- Forum: Very old oclHashcat-plus Support (https://hashcat.net/forum/forum-23.html)
+--- Thread: Injecting candidates /re-reading pot (/thread-2801.html)
Injecting candidates /re-reading pot - truekonrads - 11-10-2013
Hello,
Suppose you are brute-forcing a large-ish password file and hashcat finds a password for which you quickly recognise a pattern (e.g. jjsdsd99, jjsdsd98 and pattern therfore is jjsdsd?d?d) and use a 2nd instance of hashcat to exhaust this pattern finding more passwords. The main hashcat session would benefit from eliminating hashes with known passwords from its to-be-cracked list. My question is: how do I inject passwords to the main session so that it eliminates already known passwords from the hash list?
RE: Injecting candidates /re-reading pot - radix - 11-10-2013
you dont. let the run finish then run the mask.
RE: Injecting candidates /re-reading pot - truekonrads - 11-11-2013
(11-10-2013, 08:01 PM)radix Wrote: you dont. let the run finish then run the mask.
Well... some masks I am running now will take 1 year to finish, yet it manages to find new passwords. So reducing uncracked hash count makes sense
RE: Injecting candidates /re-reading pot - atom - 11-11-2013
You can "p"ause the current one, the long running session. And in a parallel instance crack the uncracked ones with the newly found pattern. But to automate this process would not make sense since the possible pattern that can be found are to many and you can not let decide a program to do that for you. But nothing keeps you to run a parallel instance. If you started the 1st one with --remove it's safe you're only cracking the uncracked ones. If not, you can use --left. Note: do not use the same output file as the 1st instance is using
RE: Injecting candidates /re-reading pot - philsmd - 11-11-2013
@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)
RE: Injecting candidates /re-reading pot - truekonrads - 11-12-2013
Discussion moved to track: #209