Avoiding startup lag when running hashcat in a loop - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Support (https://hashcat.net/forum/forum-3.html) +--- Forum: hashcat (https://hashcat.net/forum/forum-45.html) +--- Thread: Avoiding startup lag when running hashcat in a loop (/thread-8007.html) |
Avoiding startup lag when running hashcat in a loop - aligg73 - 12-11-2018 Hi, I would like to run a combinator attack, but the issue is, that the left wordlist is different for each hash to crack (the right wordlist stays the same). Now, that is not a problem as I can start individual hashcat commands, one by one, with the proper left wordlist for each. This leads to quite some performance degradation however, as hashcat initializes device kernel and memory at every invocation, which takes a bit of time (i should say 15 - 30 secs.) Am I overcomplicating matters and is there another way? Rule based wouldn't work for the left wordlist, as the left wordlist is a combination of words itself (in fact, it's a list of candidate emails). I should note that I am using --force, as I am testing this on a CPU. Maybe once I run this on a machine with a GPU and abandon --force, the startup lag goes away? Thanks for your guidance. RE: Avoiding startup lag when running hashcat in a loop - philsmd - 12-12-2018 First of all, --force is not used to enable your CPU, but --force is used to run hashcat even if it detected some hard problems on your system. -D 1 (or --opencl-device-types 1) instead needs to be used if you have GPUs and CPUs on your system (because hashcat defaults to using only your GPUs, because they are faster in general) and you want to enable all your CPU devices. Again, this only needs to be done if you have at least one graphics card on your system. Whenever you use --force you will see this: Code: You can use --force to override this, but do not report related errors. This means that you shouldn't report any problems but fix the (most likely always) driver installation instead. I know we are toxic sometimes when it comes to people reporting bugs/problems and at the same time use --force, but it should be quite clear that the (mostly driver installation) problems need to be fixed first before reporting anything .... and even worse claming that with --force everything works (in your case you claim that you do not even need to use -D - which is correct but --force has in fact nothing to do with enabling CPUs - , but just can use --force, which is kind of missleading... because --force has nothing to do with your device type and device selection, but it just ignores some very serious problems/errors on your system). Back to the "lag" problem. There is no such thing as (initialization) lag in hashcat. When hashcat starts it needs to initialize a lot of things and most importantly the OpenCL devices are initialized and info is queried (this somtimes takes some time). There are other steps that hashcat does of course at startup, like checking the files, counting lines in the hash and word list etc... all of this sums up to a few milliseconds to seconds, but is probably negligible (because the driver initialization takes most of the time). Of course this initialization step can't really be skipped and I would say (my opinion) there is little room for improvement (even if you optimize everything possible, it still would take about 20 seconds on your system @ startup). Furthermore, you should always mention the hash type that you are trying to attack. There might be the possibility for much more clever attacks (like salted vs non-salted hashes etc). In some cases it might also be better to use the stdin mode (by using a pipe) and generate the password candidates with an optimized password candidate generator that only produces very likely candidates. If this is efficient of course depends also on the hash type (if it is ntlm or bcrypt makes a lot of difference for instance). I would also argue that 20 seconds shouldn't matter too much if you optimize your attack s.t. each job runs for several hours/days with very many hits (rule based attack etc ?). Therefore, the startup time of the next run is negligible again (a few seconds compared to a couple of days)... but this of course depends a lot on your use case (but in general very quick runs of just a few seconds are not really recommended, because it might also mean that hashcat has not enough keyspace to fully accererate) RE: Avoiding startup lag when running hashcat in a loop - aligg73 - 12-12-2018 Thanks for your answer. I understand the reservation with regards to --force. I took it out, configured OpenCL properly and now there is no lag. So thanks again for pointing me in the right direction! |