+- 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: Hashcat Caching Previously Calculated Hashes (/thread-8263.html)
Hashcat Caching Previously Calculated Hashes - Yousif - 03-27-2019
Hello
I am trying to crack passwords using hashcat using the straight mode (Dictionary Attack). I am trying to compare the speed of running hashcat against files that have different number of hashes using the same dictionary. I noticed that the first run takes a while and all consecutive runs finish very fast even if the files have more hashes than the first file. I assumed that hashcat stores the hashes of previously calculated entries and stores them somewhere in the RAM. ( I am not talking about the potfile because i delete the potfile after each run. Hashcat seems to store the calculated hashes even they weren't a match for the cracked list)
Is there a way to delete this cache, so that you can get a fair comparison between different runs (without rebooting)?
Thanks
RE: Hashcat Caching Previously Calculated Hashes - philsmd - 03-27-2019
there is no such additional cache for storing cracked hashes except the potfile.
Maybe you are confusing the startup time with the OpenCL kernel compilation time, which only happens once for each kernel and those files are cached within the kernels/ directory.
I would highly recommend that you are not comparing with very low runtimes (less than a dozens of minutes), because otherwise some minor factors like the initialization/startup time can't be ignored (e.g. the more devices you have, the more devices need to be initialized etc, all of this actually small times are not really good to take into account and are negligible if you let the benchmarks/tests run longer)
BTW: there is also the hashcat.dictstat2 file (dictionary cache) that could take some time to generate for each different dictionary... this is also something that should be very obvious to notice, because hashcat tells you what it is doing when it is generating the dictstat etc
RE: Hashcat Caching Previously Calculated Hashes - Yousif - 03-28-2019
[quote="philsmd" pid='44262' dateline='1553711113']
there is no such additional cache for storing cracked hashes except the potfile.
I am not talking about the cracked hashes. I am talking about the other words in the dictionary. So when i run throught the dictionary attack the first time it give me a reasonable amount of time to crack a specific hash which is fine.
But when i run through the same dictionary again for a different word even (if that word was just one above or below the previous word), it is way faster the second time and not even close.
RE: Hashcat Caching Previously Calculated Hashes - philsmd - 03-28-2019
I'm not 100% sure what you are seeing/experiencing over there, but also remember that hashcat is highly parallelized and therefore all your OpenCL devices and all cores of just a single device (CPU/GPU) run different password candidates. That means that you can't really say that one word is run before the other, because the chuncks are run in parallel and start at different offsets. even if a word is at a higher line number than another word, doesn't mean that it is tested later... because a different core could run it because it's next in the queue within this particular chunk/split.
parallelization is often not so easy to grasp, I'm not sure if this is what you are seeing or just the dictstat generation etc, but it is for sure something very easy to understand if you somehow understand the architecture/inner working of hashcat.
I don't think it's a problem, but you could try to explain it in more detail and maybe we can find out what is going on. What are the times we are talking about here ? hours/days ? or just seconds (again it's difficult to compare with very small time frames)... and the second question is, are you sure it's not the init phase that makes the difference for you ? did you try testing with --runtime etc instead ?
BTW: also salts influence the speed by a lot. You should also always mention the hash type you are targeting. If you run hash lists with much fewer salts, it's of course much faster... Did you look at the Speed status prompt (H/s, kH/s or MH/s), is it almost the same between all the different commands you are trying ?