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).