Restore.Sub.#1. beginner question

[Kyssista]

I have been using hashcat for sometime now but as I noticed the new version had arrived I went and dwelled on the changelog and started looking pictures of the UI.

I looked at restore Restore.Sub.#1 and thought like it was new thing and fancied what it was, but eventually realised that it's been there always.

I think I know what it is, but more I look at it more questions it raises for me. I tried look in FAQ for this, but I didin't find it or somehow missed it.
Can anyone explain to me like 5 year old what it does or imply? What are the amplifiers and iterations and why it counts even on hashes known to be without a salt?


  hashcat.png (Size: 23.89 KB / Downloads: 5)
For context, here is screenshot of hashcat 6.0.0 from this site

Also, terribly sorry if I post this to wrong category

[philsmd]

We normally say that hashes that are "raw" or that are "unsalted" have no salt. And this statement is perfectly correct.

but you could also see it like this: a hash type/algorithm that does not have any salt, just has an empty string as a salt and therefore all the hashes have 1 (the same) salt. hashcat also makes this generalization sometimes, i.e. it just counts how many different salts there are and if it is unsalted, there is only 1 single "salt". of course with salted hashes it's much easier to think about this, most of the time it's even the case (if the salts are random, long and unique enough) that each and every hash has a different unique salt (that would be the perfect case for a good hashing algorithm, but not from the crackers stand point ).

The iterations should be very clear, several algorithms use a "cost factor" or iteration count that the OpenCL/CUDA kernels need to use as a parameter for iterating/looping (e.g. a hash that uses 10000 PBKDF2-HMAC-SHA1 "rounds" for -m 12000).

This of course also depends a lot on the algorithm because the iteration count could be fixed or different for each and every hash.

The amplifier is a little bit more complicated and depends on the attack mode (-a x), for instance for rules it could be the "position" in the rule file (which sets of rules are currently tested). Most of this only will show up for slow hash types that only have a init/loop/comp kernel. The amplifier could also be the left or right dict in -a 1.
Some of the details and inner workings of hashcat can also be seen if you try to understand how the --keyspace command works and how the number is computed: https://hashcat.net/wiki/doku.php?id=fre...a_keyspace . The amplifier is basically working similar i.e. the loop "variable" that makes sure that enough acceleration is given, therefore called the so-called "amplifier".
For mask attack (-a 3) and a slow hash, it's the left-hand side of the mask that gives amplification.

It's not important that you perfectly understand these numbers, but for the curious it's often interesting to see how long it would take to reach the next "restore point" and therefore we have this "sub" status line within the output. Yeah, sometimes with a lot of hashes of a slow hash types, it could take a little bit to reach the next "checkpoint" and threfore it's sometimes interesting to see where we currently are within the attack.

In general, you could just say that the iteration count depends on the algorithm and hashes themself, while the amplifier mostly depends on the current attack type (-a x). For fast hashes you won't see all these details, because they do the full amplification inside the main loop of the OpenCL/CUDA kernel, while most slow hash types already get the password candidates from the host or as a result of other kernels (e.g. the on-GPU rule engine kernels).

[Kyssista]

First of all, thank you very much for such indepth reply.

If I were to try explain it to non-techsavy client or friend, would it be too far off to boil it down to:
"Iterations are represented for the algorithms which corporate iterations which some need to be guessed and some are fixed. Amplifier is showcasing the keyspace inbetween restore points depending on the attack type and settings used."

[philsmd]

I think "guessed" is the wrong term. Most things (except of the password) are normally known when it comes to hash cracking. Normally you won't need to guess iterations counts (or cost factors), they are part of the hash like a -m 12000 = PBKDF2-HMAC-SHA1 which could start with:

Code:

sha1:10000: ...

in this case the 10,000 means that hashcat needs to perform 10000 iterations for this specific hash, while other hashes could start with "sha1:1000" and therefore it's just a tenth of the other hash with 10,000 iterations.
There are some special algorithms that do not make this "parameter" flexible, it's just hard-coded/fixed, therefore it doesn't need to be part of the "hash line" or hash format itself.
In any case, you wouldn't need to "guess" it, it should be something known.

The same normally holds for other parameters of the hash algorithm, yeah even the salt. The salt is something that shouldn't be guessed, it's just something known (also to the attacker normally) and should be part of the "hash"/hash line/hash format.

in short:
- iterations: cost factors depending on hash itself (if parametrized) and/or algorithm
- amplifier: mangles the base words (rules, word combinations, masks prefix, etc)

[Kyssista]

Ah, I see now.
Thanks again.