Good question!
Arbitrary iteration is currently out of scope for hashcat. atom has previously added specific cases when it's a commonly needed hash, but that's it.
Outside of the hashcat world, the capability that you're describing is a component of two different other suites:
* John the Ripper jumbo, using its dynamic format syntax
* MDXfind, using its -i option
Both of these are currently confined to CPU. But there's a lot of flexibility, and they're both taking advantage of CPU speed features to make the attack pretty efficient (though obviously slower than a well-tuned GPU attack).
What's interesting about MDXfind is that -i specifies an upper bound. For example, if you use -i 1000, it will try sha1(pass), sha1(sha1(pass)), sha1(sha1(sha1(pass))) ... on up through 1000 iterations of SHA1. And you can tell it multiple hash types as well, so it will try 1000 iterations of MD5 at the same time. When dealing with a pile of unidentified hashes, this is pretty powerful.
Arbitrary iteration is currently out of scope for hashcat. atom has previously added specific cases when it's a commonly needed hash, but that's it.
Outside of the hashcat world, the capability that you're describing is a component of two different other suites:
* John the Ripper jumbo, using its dynamic format syntax
* MDXfind, using its -i option
Both of these are currently confined to CPU. But there's a lot of flexibility, and they're both taking advantage of CPU speed features to make the attack pretty efficient (though obviously slower than a well-tuned GPU attack).
What's interesting about MDXfind is that -i specifies an upper bound. For example, if you use -i 1000, it will try sha1(pass), sha1(sha1(pass)), sha1(sha1(sha1(pass))) ... on up through 1000 iterations of SHA1. And you can tell it multiple hash types as well, so it will try 1000 iterations of MD5 at the same time. When dealing with a pile of unidentified hashes, this is pretty powerful.
~