+- 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: Crackpos incorrect (/thread-8156.html)
Pages:
1
2
Crackpos incorrect - ApexCracker - 02-14-2019
I'm doing some research into passwords attacks and noticed that crackpos is not correct.
I thought crackpos was supposed to represent the Nth attempt at a password.
But rockyou contains 14344391 passwords and my crackpos looks like this:
1954100
1954110
1954111
1957829
Even though the values that it cracked isn't at the N th position.
Second attempt on a different machine with the same list against rockyou.
These are the lowest values in the list.
2752512
2752515
2752517
These the highest:
15173999
15175368
Does this mean that out of all the attempts (14,344,384) one of them was at position 15175368?
14344384 < 15175368 which is impossible.
Any reason for this? If this it increments per 'attack' or session how can this be reset?
This seems to mainly occur with rules
Specifically looking at making a graph of % cracked vs attempts.
https://gyazo.com/84b08df9c4bade302558ff59d58d5ea7
example above
RE: Crackpos incorrect - philsmd - 02-15-2019
as you might already know, if you use any amplifier (like rules) the total number of password candidates will increase. This implies also that the "Progress" number in the status screen will get larger and larger the more rules you use.
The "crackpos" value will take this offset into account too. i.e. it won't only reflect the word position but also the word_pos * rule_pos etc... I think you get the idea (to get the full technical details I would recommend looking into the source code file e.g. src/outfile.c etc).
There is one caveat, crackpos must be considered as an indicator that helps for statistical/forensic/analysis purposes and should be treated as an indicator which passwords are cracked first (or which are easier to crack etc).
Of course it could in theory give slightly different results if you test with different systems and/or different GPUs on a system whenever for instance multiple rule+word combinations would crack the same hash etc.
Statistically viewing it it's a quite robust/good indicator, but of course since the password cracking is highly parallelized there could be different "crackpos" reported during different launches (especially if you have multiple GPUs or are comparing it with different machines etc).
At the end it's a negligible offset of course (if any), but that's how "crackpos" was intended to be used i.e. only to see which passwords are easier to crack compared to others etc.
RE: Crackpos incorrect - ApexCracker - 02-15-2019
(02-15-2019, 09:39 AM)philsmd Wrote: as you might already know, if you use any amplifier (like rules) the total number of password candidates will increase. This implies also that the "Progress" number in the status screen will get larger and larger the more rules you use.
The "crackpos" value will take this offset into account too. i.e. it won't only reflect the word position but also the word_pos * rule_pos etc... I think you get the idea (to get the full technical details I would recommend looking into the source code file e.g. src/outfile.c etc).
There is one caveat, crackpos must be considered as an indicator that helps for statistical/forensic/analysis purposes and should be treated as an indicator which passwords are cracked first (or which are easier to crack etc).
Of course it could in theory give slightly different results if you test with different systems and/or different GPUs on a system whenever for instance multiple rule+word combinations would crack the same hash etc.
Statistically viewing it it's a quite robust/good indicator, but of course since the password cracking is highly parallelized there could be different "crackpos" reported during different launches (especially if you have multiple GPUs or are comparing it with different machines etc).
At the end it's a negligible offset of course (if any), but that's how "crackpos" was intended to be used i.e. only to see which passwords are easier to crack compared to others etc.
I did some tests, yes, dividing the amount given by the amount of rules results in the right number (approx)
So rockyou could give:
21232f297a57a5a743894a0e4a801fc3:admin:19817
Rockyou with 10 rules could give:
21232f297a57a5a743894a0e4a801fc3:admin:198174
and Rockyou with 1254 rules could give
21232f297a57a5a743894a0e4a801fc3:admin:24850518
and as you can see 24850518/1254 = 19817.
example with:
21232f297a57a5a743894a0e4a801fc3:admin:79270
900e6fe77391e517e72d191fa20dc980:admin47646274:79271
with this ruleset:
u
d
:
$4$7$6$4$6$2$7$4
So you can see that it goes through each single word line by line, and for each word it applies each rule.
So the full formula for the ID would be:
word_pos-1 * total_rules + rule_pos
I also noticed that the first attempt / crack is at 0, which is technically incorrect as attempt 1 should be 1 instead of 0. Same goes for the 'rule' counter, which starts at 0.
I'm no sure how much implication it would have for other functions to change this but these small numbers are of course negligible
RE: Crackpos incorrect - atom - 02-15-2019
The password output given by hashcat is based on the crackpos. IOW, if the crackpos is wrong, the password is wrong, which is not the case. If you want to know more about the details, see here:
https://github.com/hashcat/hashcat/blob/b457f402c6c89c77e81eb7b70ff126b21afdfbf1/src/outfile.c#L380
RE: Crackpos incorrect - ApexCracker - 02-15-2019
(02-15-2019, 04:21 PM)atom Wrote: The password output given by hashcat is based on the crackpos. IOW, if the crackpos is wrong, the password is wrong, which is not the case. If you want to know more about the details, see here:
https://github.com/hashcat/hashcat/blob/b457f402c6c89c77e81eb7b70ff126b21afdfbf1/src/outfile.c#L380
I read through the code around that area but have some issues the "offset" when using rules.
This is seen in the graph.
https://i.gyazo.com/d0821e8fb8857ab0955a55c086475acf.png
Orange is the "Correct" attack with rockyou without rules.
But blue is around what you'd expect and orange / green is what you get.
RE: Crackpos incorrect - undeath - 02-15-2019
since the axes' labels are missing it's hard to tell what that chart is about at all. What is wrong with the red/green curves? Is this about the smallest crackpos being reported? If so, "number of guesses" on the x-axis is a bit misleading.
RE: Crackpos incorrect - ApexCracker - 02-15-2019
This is the crackpos reported. For each crackpos, the % cracked goes up by 1/<amount of hashes>
So 1M hashes means each crack goes up 0.0001%
Y = Hashes cracked total in %
X = Amount of guesses based on crackpos
Below is the original graph with the axis, didn't notice that cut out.
https://gyazo.com/84b08df9c4bade302558ff59d58d5ea7
The blue line is transposed to the left with a static value.
Red and Green have their first crack at 236,000,000 guesses according to the chart and crackpos, which seems ridiculous
RE: Crackpos incorrect - undeath - 02-15-2019
You are confusing crackpos with the number of guesses made. There are no guarantees that a lower crackpos means it's tried earlier, or analogously that a higher crackpos means some candidate is tried later. Due to how hashcat schedules things and the high amount of multithreading those results seem perfectly reasonable.
RE: Crackpos incorrect - ApexCracker - 02-15-2019
(02-15-2019, 09:24 PM)undeath Wrote: You are confusing crackpos with the number of guesses made. There are no guarantees that a lower crackpos means it's tried earlier, or analogously that a higher crackpos means some candidate is tried later. Due to how hashcat schedules things and the high amount of multithreading those results seem perfectly reasonable.
Is there any way to make an accurate graph of the amount of guesses or is this accurate / closest I can get?
RE: Crackpos incorrect - undeath - 02-15-2019
speed should be almost constant over time, you would usually end up with pretty much a straight line if you tried to plot the guesses made.