Fix relative_progress with new hashcat release

[MelvinFrederiks]

As observed in hashcat/hashcat#4805, the --machine-readable PROGRESS format has changed to not include the --skip amount anymore.

This caused the relative_progress to report incorrect values, this is now fixed with a version check to determine if we need to adjust for passed --skip (old setup) or not (now).

[MelvinFrederiks]

Maybe this is not necessary, as we could use CURKU instead of PROGRESS field to get the absolute position in the search space?

[jessevz]

Maybe this is not necessary, as we could use CURKU instead of PROGRESS field to get the absolute position in the search space?

Using the CURKU seems to be the intended way from hashcat to distribute work. So i agree that using that would be the most straight forward solution

[s3inlc]

Thanks for working on a fix to adapt to the change in hashcat. There is a problem though we currently have when dealing with this. The "unit" of the values of CURKU, skip and limit is not the same as the one used in PROGRESS. That's why I think this does not work properly when we just add the skip value to the progress value.

The values of CURKU, skip and limit are in the units of steps on the value of --keyspace of the task (hashcat keyspace, not actual number of candidates).
The PROGRESS value is actually the amount of candidates to be tested (depending on the hash type multiplied by the number of salts), so this value gets much larger normally.

Edit: I think it's a bit nontransparent to change the behavior in the getters of the status. Actually, we do quite some calculations in hashcat_cracker.py:L341+ to handle the old behavior (change from one scale to the other), so it would make more sense to handle the two cases there (and the new case will be quite a bit more simple than the current way).

[MelvinFrederiks]

I see. I think we can solve this by just changing the calculation of relative_progress.

[s3inlc]

Yes exactly, I think that's the only change really needed, all the keyspace part with CURKU etc. should not be affected.

A question on the way you determine the version, do I see it correctly that you check for 7.2.x versions?
The problem is that then all currently floating around hashcat betas (and other subsequent 7.1.3+) would still not work properly.
Ideally, we would have a way by either go by the exact build number in the version (where we typically have +N in the name denoting the number of commits since release) or by a way to look at the PROGRESS values themselves and being able to deterministically say if it is before or after the change.

[MelvinFrederiks]

Great, I didn't know there was a build number available. It looks like this hashcat behaviour was changed in hashcat/hashcat@c885bee (src/status.c), which seems to be v7.1.2-546-gc885beef8 so build 546, so i've now refined the version check to check against this specific build.

[s3inlc]

Yes, this looks good now, that should do the differentiation now exactly at when it happens. Thanks for updating.